ChatGPT(codex), Claude Code로 딸깍하면 되는데
CS(Computer Science)를 왜 배워야해요?
오호.. 흥미로운 질문입니다.
검색하면 정보를 찾을 수 있는데 학교에서 왜 배워야하죠?를 넘어
이제는 AI가 다 알려주고 심지어 Docs, PPT, Excel, Image, Music 못 만드는게 없죠
근데, 왜 CS를 알면 실무 실력이 향상될까요?
위 궁금증을 해결하기에 앞서, CS의 구성요소를 한번 파악해볼까요?
- 자료구조(Stack, Queue, Tree, Queue, Graph, …)
- 알고리즘(시공간 복잡도 계산, BFS, DFS, Dijkstra, Brute Force, …)
- 컴퓨터구조(CPU, ISA, Memory, 병렬 프로세스, Procedure, …)
- 운영체제(스케쥴링, 동기화, 교착상태, 입출력시스템, 파일 시스템, …)
- 네트워크(구성요소, TCP/IP 모델, OSI 7계층, IP 주소 체계, 라우팅, …)
- 데이터베이스(데이터란, 파일시스템, DB관리시스템, DB시스템, Data Model, 데이터 정규화, …)
- 논리회로(논리 게이트, 불 대수, 논리식 간소화, 조합논리회로, 플리플롭, 카운터, …)
- 이산수학(논리 연산, 명제, 함수, 집합, 그래프, 순열, 확률, …)
- 물론 웹 수업도 있고, 안드로이드 앱 개발도 배웠고, 그래픽스,
- …
정말 많이도 있습니다 !
각 과목의 [개념, 관점, 구체적인 기술 이름]이 나열되어 있네요
저 개별 요소를 알면 왜 실무를 더 잘하게 되는걸까요?
실무를 더 잘한다를 조금 더 쪼개본다면
- 문제 상황을 파악하고
- 어떤 문제인지를 분석, 모델링해서
- 문제를 실제로 해결한다
간소화하면 3가지 단계가 있습니다.
다시 표현하면 CS를 배운 사람은
- 문제 상황을 ‘더 잘’ 파악하고
- 어떤 문제인지 ‘더 잘’ 분석, 모델링해서
- 문제를 실제로 ‘더 잘’ 해결한다
.
.
.
CS의 역사는 문제 해결의 역사입니다
- 어떤 과목은 현실/실무의 ‘구체적인 문제’에서 태어나기도 했구요.
- 어떤 과목은 더 좋은 기술을 도입하기 위해 ‘고민’을 통해 고안, 설계되기도 했구요
- 어떤 과목은 이미 잘 해결하고 있지만 ‘더 효율적으로 해결’하기 위해 연구되기도 합니다
CS를 배우다보면 컴퓨터 과학을 연구한 사람들의 문제 해결 방법의 흐름을 엿볼 수 있습니다
문제 해결 방법 그 자체만 외우는 것 보다
어떤 문제가 있었고 -> 해결 방법 후보군들을 떠올리고 -> 최종 어떤걸, 왜 선택했을까?
라는 고민을 하며 배워본다면 CS 지식이 조금은 새롭게 느껴지실거에요.
한번 CS 과목을 다른 관점으로 해석해볼까요?
- 자료구조: 나의 문제를 잘 해결해줄 수 있는 연산 비용을 설계한다
- 알고리즘: 중복된 계산, 비효율적 계산 등, 계산 낭비를 줄인다
- 데이터베이스: 데이터를 안전하고 일관성있게 저장하고, 효율적으로 꺼낸다
- 운영체제: 프로그램의 다양한 실행환경을 이해하는 틀
- 네트워크: 시스템간 통신의 기본, 공통 모델
- …
이런 관점입니다. “이 과목 대체 왜 배우는거지?”
❓ 드라이버가 좋나요? 아니면 망치가 좋나요?
답변할 수 없습니다. 도구는 그저 도구입니다.
- ‘문고리가 헐렁하다’ -> 드라이버가 좋습니다
- ‘벽에 액자 걸어야한다’ -> 망치가 좋습니다
❓ 자료구조의 Stack, Tree 뭐가 좋나요?
답변할 수 없습니다.
❓ 데이터베이스의 SQL이 좋나요 NoSQL이 좋나요?
글쎄요?
내가 처한 문제 상황, 사용할 수 있는 자원(돈/시간), 내가 가지고 있는 지식과 실력 등
여러 요소를 기반으로 최선의(=가장 적은 자원으로 최고의 효율을 만들어내는) 선택을 해야합니다.
- 💻 코더는 주어진 일을 합니다
- 🛠️ 개발자는 능동적으로 기능을 만듭니다
- 🚀 엔지니어는 흔들리지 않는 결과를 만듭니다
저는 서버 개발자입니다 (가끔 프론트까지도 ㅎㅎ..)
저에게 주어진 문제상황을 분석합니다.
- 1개월 수준의 PoC인지? 1년은 사용할 운영용 서비스인지
- 혼자 해야하는지? 팀원은 몇 명과 함께하는지?
- 요구사항 기획이 확정되었는지? 기획이 불명확해서 변화가 많이 될 것 같은지?
- 나의 실력은 어느정도인지? 우리 팀원들의 실력은 어느정도인지?
- 회사 자체적으로 만드는 서비스인지? 클라이언트(도메인 전문가)가 외부에 따로 있는 상황인지?
- …
이런 질문 역시 수도 없이 많을 것 같습니다.
질문이 100개면 문제 해결이 잘 되나요?
그렇지도 않습니다.
현재 주어진 구체적인 문제를 눈앞에 두고 요리조리 뜯어봐야합니다.
- 어떤 문제는 3개의 질문으로도 해결할 수 있고,
- 어떤 문제는 20개의 질문을 준비하지 않으면 실패할수도 있고,
- 어떤 문제는 50개를 고려해야 사업이 시작이되는 경우도 있습니다
잠깐 딴 얘기를 했네요.
다시 주제로 돌아오면
“왜 CS를 알면 실무 실력이 향상될까요?”
CS는 기본 지식이다. 그리고 기본은 최소한의 구성 단위다
기본(基本)은 基(터 기)와 本(근본 본)을 사용합니다.
- 基 (터 기): 기초, 바탕
- 바탕本 (근본 본): 근본, 뿌리
출처: 나무위키
쉬우면 기본인가요? 아니요
당연하면 기본인가요? 아니요
- 기본은 한 분야의 최소한의 구성 단위입니다
- 기본은 한 분야를 이해할 수 있게 해주는 최소한의 사고 단위입니다
컴퓨터과학(Computer Science) 하나하나의 지식은 최소한의 사고단위입니다.
이번엔 핫한 Redis를 보는 관점을 바꿔볼까요?
- 자료구조: String, Hash, List, Set, Sorted Set, …
- 컴퓨터구조: 메모리 기반 (메모리는 통상 8ms 접근속도, 네트워크는 150ms)
- 운영체제: Single-Thread event loop
- 네트워크: client-server protocol
- DB: persisence, replication, 원자적 실행(동시성 문제가 없음)
- 분산: cluster, consistency trade off, failover
Computer Science를 배운 사람은 공부할 것이 적습니다.
❌ CS 기초가 ‘없는’ 사람은 이렇게 생각합니다
CS 기초가 없다면 Redis Docs를 모두 읽고 개념,용법과 용례를 공부합니다.
Redis 유행이 끝나고 새로운 훌륭한 기술이 나오면요?
구체적인 신기술 단위(라이브러리, 프레임워크)를 다시 공부해야겠군요.
기술 껍데기만을 좇아가는 사람의 관점에서 보면:
- 너무 외울것이 많습니다
- 트렌드가 너무 빨리 바뀌는 것이 스트레스 입니다
- 아는 지식은 많지만, 기본이 부족하니 활용이 안 될 때가 있습니다
- 수많은 기술중 뭐가 나한테 필요한지 판단하기 힘들어집니다
⭕ CS 기초가 ‘있는’ 사람은 이렇게 생각합니다
- 이 기술은 무엇을 쉽게 해주는가?
- 그걸 가능하게 만드는 이 기술의 하위 개념들은 뭐지?
- 비슷한 원리를 쓰는 다른 기술은 어떤게 있지?
결론: 이 기술은 A로 분류되고 B라는 장점 C라는 단점이 있구나
- 인식수준의 이해(Lv.1): 인식 가능한 수준의 앎. 누군가 얘기하면 ‘아~ 그거’라고 말함.
- 인출가능한 이해(Lv.2): 질문을 받으면 스스로 지식을 꺼내서 설명하는 것이 가능
- 적용가능한 이해(Lv.3): 새로운 상황을 보아도 ‘아, 이거 A, B, C 섞인거네’ 기존지식으로 분해, 연결함
소제목 다시 가져오겠습니다.
“CS는 기본 지식이다. 그리고 기본은 최소한의 구성 단위다”
내가 무언가에 막힌다 = 상위개념을 구성하고 있는 기본 개념이 [약하거나, 해상도가 낮거나, 없거나]
무언가에 막히면 99% 뭔가를 제대로 이해하고 있지 못한 것 입니다.
너무 쉽고, 당연해보여서 기본은 쉽게 등한시되고는 합니다.
