CS든 프로젝트든...

프로젝트가 일정수준 이상이 되고 잘 만들려고 하면
자연스럽게 CS지식도 따라오게 됨.

다만 이게 참 어렵지.


이론과 실무 간의 괴리.

CS지식을 위주로 파자니 이론이 가득해져 허망해지고

프로젝트 위주로 진행하자니 행함이 앞서 점차 위태로워지니

결국에는 중용이 답임.


하지만 공부해보면 알겠지만

CS지식이라는 게
우리가 일상적으로 접하는 개념을

컴퓨터용어적으로 표현해놔서

어렵게 느껴지는 것에 불과함.


운영체제 관련한 CS

1. Pub/Sub,

간단히 보면

어지럽게 만드는 놈(Pub) 따로 있고 치우는 놈(Sub) 따로 있다는 거임.

주문하는 놈(Pub) 따로 있고 주문대로 처리하는 놈(Sub) 따로 있다는 거임.

처리할 때 배치하는 놈(Pub) 따로 있고 배치하는 것에 따라 실행하는 놈(Sub) 따로 있다는 거임.


즉 이미 네 마음안에 있었지만 CS적으로 개념화가 안되어 있었을 뿐임.


2. 프로세스=캐시=메모리=보조기억장치와

사용자요청=캐시(Redis)=메모리(InMemory)=DB 간 유사성


쉽게 보면 집 나가서 마트(캐시) 에서 사면 빠른데
DB, 보조기억장치(농장) 까지 가서 사기에는 비용도 많이 들고 느리다는 말임.

공부하다보면 각종 FIFO, SJF 이런 거 보게 되는데

이거는 서비스와 정책의 분리에 해당하는 것이라 보면 됨.

저장장치 간 동기화 잘하고 캐시로 될 수 있으면

응답하자는 게 골자임.


즉 이 또한 이미 네 마음안에 있었지만 CS적으로 개념화가 안되어 있었을 뿐임.


3. 서비스와 정책의 분리


이건 서비스 컨테이너에서

서비스를 등록할 때 옵션을 통해
어떠한 정책으로 서비스 할지 결정하는 것으로 응용가능함.

예를들어 운영체제에서 프로세스 스케줄링으로

FIFO, SJF 이런거 있는데


프로세스 스케줄링이라는 서비스를 만들고

옵션으로 FIFO, SJF 개발자한테 선택하게 해서

서비스를 어떠한 정책으로 구성하게 만드는 그런 거임.


예를들어 누군가를 공격하는 서비스를 한다고 했을 때
공격전술에 있어서 다양한 시도들이 있을 수 있잖아?

여기서 다양한 시도들을 정책으로 묶고 공격을 서비스하는 것이라 보면 됨.


즉 이 또한 이미 네 마음안에 있었지만 CS적으로 개념화가 안되어 있었을 뿐임.


4. 병행성 제어를 위한 Lock(세마포어, 뮤텍스... 등)


이건 요즘에 .Net의 경우 async Task await 이것으로
대부분을 해결함.


뭔 말이냐면 처리하는 놈 여러명인데 이 처리하는 놈들이 무언가를 처리하기위해

공유되는 놈이 있다면 공유되는 놈 이용할 때 Lock하겠다는 것임.

아니 공부할려는데 도서관에 누군가가 공부하고 있으면 기달리잖아.

그게 Lock 개념이라는 거야.

그 개념에서 퍼져나가는게 은행원, 식사하는 철학자, 세마포어, 뮤텍스 등임.


즉 이 또한 이미 네 마음안에 있었지만 CS적으로 개념화가 안되어 있었을 뿐임.


데이터베이스 관련한 CS

1. SQL

2. 정규화

3. ERD 그리는 법


SQL 이건 어떠한 용어가 있는지 일단 파악만 하면 됨.

그리고 개발하다보면 그냥 자연스럽게 entities.Where.ToList()

이게 뭔 말인지 알음. entities를 where 조건으로 필터링해서 ToList() 해줘.

그냥 인간이면 다 아는 거임.

데어터가 있다(entities) 필터링을 좀 하고 싶다(Where) 리스트로 만들어서 보고싶다.(ToList)


즉 이 또한 이미 네 마음안에 있었지만 CS적으로 개념화가 안되어 있었을 뿐임.


정규화도 그냥 인간이면 다 알음.

정보가 어떠한 곳에 저장되어 있는데

다른 곳에도 저장이 되어 있어서

삭제 및 갱신했을 때 두군데가 다 바뀌는 게 정상이잖아?

그런데 그게 안되면 이상하잖아? 그런 거 다루는 게 정규화임(삭제, 갱신 이상)


즉 이 또한 이미 네 마음안에 있었지만 CS적으로 개념화가 안되어 있었을 뿐임.


3정규화든 2정규화든 그냥 분류를 잘하면 됨.

팁으로는

Spring Security 랑 Asp.net Core Identity 에서 User, Role, UserRole 개체가 있음.

User라는 독립된 개체와 Role이라는 독립된 개체의 기본키를 외래키로 받아
기본키를 형성하는 UserRole 개체.

이렇게 독립된 개체의 기본키들을 활용해 다른 객체의 기본키로 활용할 수 있다는 것임.

UserRole이라는 개체가 보이는 의미는 해당 유저는 해당 역할을 가지고 있다라는 의미를 얻게됨


또 다른 팁으로는

어떠한 유저의 토큰, 어떠한 유저의 주문, 어떠한 유저의 상품 이렇게

~의로 표현되는 경우에는 대체로 1 : N이라는 것임.


위 2가지 경우가 대체로 대부분임.

안되는 경우에는 내 경험상 대체로 M:N 관계라
테이블에 들어있는 속성을 쪼개버리면 됨.

그러면 UserRole 개체처럼 표현되든 1 : N 으로 되든 그렇게 됨.


아니면 Json으로 개체를 직렬화해서 한 속성에 문자열로 저장하던가....


소프트웨어공학에서 관련한 CS

간단히 말하면 단일책임원칙 이거 하나로

소프트웨어공학에서 말하는 여러가지 개념이 확장이 된다고 볼 수 있음.

나눌 수 있는 거는 될 수 있으면 나눠서 분할몰입하자는 거임.

그래서 객체지향설계원칙에서 단일책임원칙이 존재함.


분할몰입하기 위해 커다란 소프트웨어를 문서화까지 해가면서

잘개잘개 쪼개는 거임. UML, WBS 등등의 문서양식과
CQRS라는 아키텍처를 이용해가면서.


때로는 문서로, 때로는 코드로



a66d01ad1422b444be331764565bf7fdfdcabd9fc4eb8f9f586b0e9a340c37f2b7f6


창작은 개발임

행함은 테스트임

배움은 CS임

가름침은 요즘시대의 AI, 책, 교수, 직장동료, 친구, 선배임.

도리는 이미 네 마음 안에 만법을 갖추는 형상이 이미 존재한다는 것임.


위와 같이 이미 내 마음 안의 만법을 갖추는 형상이 있음을 아는 자에게는

다른 비전공 비개발자가 어느날 와서 "야, 나! 앱 만들었어!" 하는 식의 말도

쉽게쉽게 받아들일 수 있게 됨을 알아차릴 수 있게 됨.