9. 무엇을/어떻게 공부해야 하나?
무엇을 공부해야 하나?
개발자로서 성장을 하기 위해 무엇을 공부해야 하는지 물어보는 분들이 많다.
벅민스터 풀러의 지식 배가 곡선(Buckminster Fuller's Knowledge Doubling Curve, with post-1982 addition by IBM)을 보면 지식이 2배가 되는데 1900년에는 100년, 2020년에는 12시간이 걸리는 것을 알 수 있다. chat-gpt가 일상에 들어와 있는 지금은 무엇을 배우기 위해 얼마나 걸릴까? 3시간?
이렇게 새롭게 배워야 하는 것이 기하급수적으로 빠르게 증가하는데 지금 내가 알고 있는 지식이 중요할까?
미적분 왜 배웠을까?
고교 때 배운 미적분은 내게는 정말 쓸 곳이 많지 않았다. Daum 검색 시절 훌륭한 상사분이 BM25라는 키워드 기반 랭킹 알고리즘을 1시간 정도 수식으로 유도해 주셨는데 이때 미적분이 사용되는 것을 보았고, 딥러닝에서 경사하강법을 공부할 때 미분이 사용되는 것을 본 정도가 전부이다. 그럼 왜 그렇게 고교 때 힘들게 미적분을 공부했을까? 또 이과인 나에게 참 흥미가 안 갔던 윤리, 역사 등 암기 과목은 왜 그렇게 열심히 배웠을까?
이런 고민에 대해서 어느 훌륭한 선생님은
그 과목을 배우는 것은 그 과목을 잘하기 위한 것도 있지만 후에 그 과목과 유사한 학문을 잘 배우기 위함이다
라고 하셨다.
무엇을 공부해야 할까? 변동성의 시대에서 우리는 늘 새로운 것을 배워야 하고, 또 기존의 알려진 지식에 대해서도 더 심도 깊게 공부해야 한다.
따라서
우리가 공부해야 할 가장 중요한 것은 잘 배우는 방법이다.
우리는 잘 배우는 방법을 배워야 한다.
유명 온라인 강좌를 듣는 것은 좋은 시작일 수 있다. 또 지름길일 수 있다. 하지만 경험상 강연을 할 때 나는 내가 아는 것 100%가 아니라 수강생들의 70% 정도는 이해할 수 있도록 강연을 구성한다. 즉 내 강연을 100% 이해했더라도 끝이 아니고 더 공부해야 한다는 것이다. 이처럼 무엇을 배우는 것의 목적은 그것을 아는 것만큼 그 경험을 통해 다른 것도 잘 배우는 것이다.
스스로 배우고 싶은 것을 잘 배울 수 있는 능력을 키워야 한다.
작년에 읽은 "Modern Software Engineering"이라는 책에서 저자인 Dave Farely는
Software development is a process of discovery and exploration; therefore, to succeed at it, software engineers need to become experts at learning
소프트웨어 개발은 발견과 탐색의 프로세스여서 성공하기 위해서는 배우는 것에 대한 전문가가 되어야 한다는 것이다. 지금까지 내가 생각한 무엇을 배워야 하는가에 대한 생각과 많이 일치한다고 생각해서 더욱 힘이 난다.
어떻게 공부해야 하나?
이 질문도 무엇을 공부해야 하는지 만큼 많이 듣는 질문이다.
자신만의 루틴
먼저 공부하는 방법과 관련해서 자신만의 루틴이 있어야 한다. 나는 일어나서 업무를 시작하기 전까지 루틴을 가지고 있다. 시간이 날 때마다 GTD(Getting Things Done) 툴(Things)의 Inbox에 넣어 둔 아티클, 책, 유튜브 영상 등을 저장해 놓는다. 그 외에 RSS, 뉴스레터 등도 매일 아침에 확인을 한다. 각 항목을 다루면서
어떤 항목은
소개 정도만 읽기도 하고
전체를 읽기도 하고
튜토리얼까지 따라 해보기도 하고
관련 책을 사서 읽기도 하고
마인드맵이나 Obsidian 등으로 정리를 하기도 하고
정리한 내용을 사내에서 공유하기도
한다.
이때 얼마나 시간을 들일지에 대한 기준은 "근시일 내가 할 가능성이 높은가?"이다.
가급적 재밌어 보여도 내가 할 가능성이 적은 주제는 튜토리얼 정도에서 멈춘다. 글을 빨리 보지 못해서 중요한 것을 보려면 보고 싶은 것을 다 볼 수는 없기 때문이다.
평일 루틴으로 부족한 것은 지금처럼 주말이나 휴일을 활용하기도 한다.
자신만의 루틴이 있는 것이 큰 도움이 된다. 루틴이 없으면 급한 일에 밀리고, 게을러질 수 있음
읽어야 할 서적의 종류
아래 내용은 소프트웨어 장인에서 산드로 만쿠소가 제안하는 분류이다. 내가 공부하는 것이 어느 영역에 해당하는지 알면 좀 더 도움이 될 것이다.
특정 기술에 대한 서적
업무를 위해 FW, 언어, SW 사용법 등을 급하게 알아야 할 때
ex. Java, JPA, Node.js, Clojure
특정 개념에 대한 서적
새로운 개념, 패러다임, 실행 관례 등
당장 활용하기 어렵고, 제대로 이해/습득하는데 긴 시간이 필요
ex. TDD, DDD, OOP, Functional Programming, NoSQL, DB 모델링 등
행동 양식에 대한 서적
개발과 관련된 인간적 측면, 프로페셔널리즘 등을 다루는 책
ex. 애자일 방법론, 소프트웨어 장인정신, 린 소프트웨어 개발, 심리학, 철학, 경영 등
혁명적 서적(또는 고전)
실용주의 프로그래머, Design Pattern(GoF), TDD(Kent Beck), Extreme Programming, Clean Coder, Software Craftmanship, Refactoring
전문가들의 문제 접근 방법은 마법사 같은 힘을 사용하지 않는다.
A Daily Practice of Empirical Software Design - Kent Beck - DDD Europe 2023에서 켄트벡은 복잡한 문제를 해결하는 방법에 대해서 아래와 같이 설명한다.
4~5년 차 훌륭한 개발자
문제를 열심히 푼다.
주니어 개발자는 복잡성을 다루는 방법을 모른다
트릭, 기술을 배우면서 조금씩 복잡성을 다루게 된다.
이런 사이클을 4~5년 하는 것은 좋다.
점점 스킬을 얻어서 점점 복잡한 것을 다루는 뇌가 포화되면 학습 전략이 바뀐다.
전문가들
문제를 작은 문제로 분리해서 일반적인 수준의 기술로 처리할 수 있도록 함
이런 분해는 많은 창의력과 기술을 요함
예. 행위와 구조 분리. DDD의 BoundedContext.
TDD도 복잡성 분리 전략(어떻게 구현할지 모른다면 테스트를 먼저 추가. 구현은 쉽다. 하지만 함께 하면 힘들다. make it run, make it right)
한 번에 하나씩 하면 뇌가 감당 가능. 함께 하면 과부하
소프트웨어 엔지니어는 복잡한 문제를 풀어야 한다. 많은 지식과 경험을 쌓았다면 복잡성을 다루는 기술에 관심을 가져보는 것이 어떨까 한다.
아래는 Dave Farely가 Modern Software Engineering에서 소개한 복잡성을 다루는 5가지 기술이다.
모듈화(Modularity))
응집도(Cohesion)
관심사분리(Separation of Concerns)
추상화(Abstraction, Encapsulation, Information Hiding)
느슨한 결합(Loose Coupling)
그는 이 5가지를 지탱하는 기술로 Testability를 언급했다. 즉 Test First를 하든 Test를 충분히 빨리 추가하든 테스트를 확보하면 복잡성을 다루기 쉬운 구조가 된다는 것이다.
