- 소프트웨어 설계 능력을 향상시키고자 노력하고 있는데, 기존의 잘 설계된 코드베이스를 연구해 보라는 권유를 받았음
- 공개적으로 접근 가능한 코드베이스 중 소프트웨어 설계의 골드 스탠다드로 여겨지는 것은 어떤게 있는지 궁금함
1. 추천 코드베이스
-
대형/대표 프로젝트
- Git, Postgres, CPython
- Linux Kernel 의 "lieutenants model"
- UNIX v6, BSDs
-
프레임워크/라이브러리
-
시스템/서버
-
게임/특수 사례
-
교육용/학습 자료
-
기타
2. 코드 읽기 vs 문서/설계 학습
-
코드만으로 한계
- 코드베이스는 구현을 보여주지만 디자인 의도나 트레이드오프는 숨겨져 있음
-
설계 문서 중요성
- ADR(Architectural Decision Records), Rust RFCs, Python PEPs 같은 의사결정 기록이 디자인 학습에 훨씬 유익
- 디자인 문서 작성 자체가 훈련이 될 수 있음
-
책·문헌 추천
3. 실습 중심 학습론
-
경험과 시행착오
- 디자인은 문제를 반복적으로 겪고 피하는 법을 배우면서 익히는 것
- 코드 읽기만으로는 학습이 되지 않고, 직접 작성하고 실패를 해결하는 과정에서 배움
-
흥미 기반 학습
- 자신이 흥미 있는 프로젝트를 만들어야 깊이 배우게 됨
-
실패 비용이 낮은 특성
- 소프트웨어는 물리적 엔지니어링보다 실패 비용이 낮아 시도와 실패를 통한 학습이 효과적
4. 소프트웨어 엔지니어링 성격 논쟁
-
미성숙한 공학론
- 다섯 명의 엔지니어가 모이면 다섯 가지 다른 해법이 나오는 것은 공학으로서 미성숙함의 증거
-
실험 친화적 특성론
- 소프트웨어는 제약이 적어 다양한 해법이 존재하고, 물리 공학처럼 정답이 고정되지 않음
-
예술과 공학의 경계
- 디자인은 미적 요소를 가진 예술적 행위이기도 하지만, 기능적 요구를 만족하는 측면에서는 공학
- 소프트웨어는 예술적 유연성과 엔지니어링적 엄밀성 사이에 놓여 있음
5. 대안적 학습 방법
-
나쁜 코드 분석
- 잘 설계된 코드뿐 아니라 부실한 코드베이스를 고쳐보는 것도 큰 학습 효과
-
자신의 코드베이스 학습
- 팀 내부 코드베이스를 가장 많이 배울 수 있는 자료로 꼽음
- 단, 팀 코드가 부실할 경우 외부 사례 병행 필요
-
도메인 맞춤 학습
- 자신이 풀고 싶은 문제와 유사한 코드베이스를 읽는 것이 가장 효과적
주요 인사이트
- 잘 설계된 코드베이스는 도움이 되지만, 학습은 설계 의도를 이해하고 시행착오를 겪으며 병행해야 함
- 코드 읽기 자체보다 설계 문서와 의사결정 기록이 핵심 학습 자료임
-
대표적인 고품질 프로젝트(Git, Postgres, CPython, Rust std 등) 는 학습 가치가 높음
- 좋은 코드뿐 아니라 부실한 코드와 자신의 코드에서 배우는 것이 장기적으로 더 실질적임
주요 댓글 정리
대표적 코드베이스 추천 (CraigJPerry)
-
Postfix mail server
- 보안 중심 아키텍처로, 마이크로서비스 개념 이전에 이미 유사한 구조를 보여줌
- 현대적 마이크로서비스가 대규모 조직 분산에 중점을 둔다면, Postfix는 보안과 단순성을 위해 설계됨
-
Spring Framework
- 엔터프라이즈 환경 Java 개발자의 요구를 깊이 고려한 문화가 반영됨
- 사용자 중심 설계 접근을 배울 수 있음
-
Git
- 객체 데이터베이스(블롭, 트리, 커밋)와 레퍼런스 개념을 이해하면 나머지는 점진적 확장임
-
핵심 개념의 일관된 확장이 좋은 설계 사례로 제시됨
-
Varnish
- 고성능 리버스 프록시이면서, 학습 도구로 활용될 수 있을 정도로 잘 구성된 코드베이스
-
Linux Kernel Lieutenants Model
- 코드베이스는 아니지만, 대규모 소프트웨어 관리 모델로서 참고할 가치가 있음
- 단순히 "잘 설계된 코드"라기보다 디자인 의사결정이 강한 인상을 남긴 사례들임
실무 코드베이스 학습 강조 (crystal_revenge)
- 가장 큰 학습 가치는 자신의 팀 코드베이스에서 얻을 수 있음
- 실제 요구사항과 구현 간의 혼란스러운 연결 과정에서 좋은/나쁜 선택을 동시에 경험하게 됨
- 현실적 제약 중 가장 큰 요소는 시간 압박이며, 이상적 설계와 현실 사이의 균형을 익히는 것이 핵심
- 좋은 소프트웨어란 사용자 요구를 해결하는 것이며, 반복 경험을 통해 성공 가능성을 높이는 설계를 배우게 됨
과거 논의와 자료 링크 (sprobertson)
코드 vs 설계 문서 (alphazard)
- 코드베이스는 구현의 결과물일 뿐, 설계 자체는 아님
- 설계 학습에는 디자인 문서 작성이 더 효과적임
- 문서는 다른 사람이 그대로 구현할 수 있을 정도로 명확해야 함
- 대안을 열거하고 왜 배제했는지 기록하면 설계 고려의 증거가 됨
- 좋은 디자이너는 더 넓은 설계 공간을 고려하고, 적절한 지점을 선택하는 사람임
전체 시스템 이해 강조 (RossBencina)
- 코드베이스 전체를 이해하는 과정은 매우 가치 있음
- 단순히 잘 설계된 코드뿐 아니라 시스템의 큰 그림을 보는 훈련이 됨
- UML 등 다이어그램을 통해 관계를 시각화하는 것이 도움됨
- 학습 접근법:
- 자신이 개발 중인 것과 유사한 소프트웨어의 코드를 읽는 것이 효과적
- 이미 잘 아는 도메인의 코드(웹 프레임워크, 웹 서버, Python 표준 라이브러리, VSCode 등)를 시작점으로 추천
- 처음에는 작은 프로그램, 익숙한 도메인부터 접근하는 것이 좋음
좋은 설계의 기준 (mamcx)
- 좋은 설계는 목표와 아이디어, 코드베이스는 그것의 구현 정도를 보여줌
- 좋은 설계는 단순히 "빠르다, 안전하다"는 수식어가 아니라 구체적 고려와 트레이드오프 기록을 포함해야 함
- 사례: Erlang, 초기 Pascal, 다수의 RDBMS 설계에서 이러한 특징을 관찰 가능
- Rust의 std 라이브러리는 보안과 일관성을 강조하며 코드와 문서가 이를 충실히 반영하는 좋은 학습 자료
보이지 않는 설계 결정 (ben30)
- 잘 설계된 코드베이스를 볼 때 가장 중요한 부분은 보이지 않는 것임
- 복잡성 배제, 불필요한 추상화 지양, 특정 패턴 거부 같은 부재의 결정이 핵심
- 이를 보완하기 위해 ADR(Architectural Decision Records) 를 활용
- 대안과 그 배제 이유, 선택 근거를 기록하여 맥락을 남김
- 향후 유지보수자와 AI 도구 모두에게 큰 도움을 줌
- 학습 시, 단순 코드 외에도 ADR·RFC·PEP 등 설계 의사결정 문서가 함께 있는 프로젝트를 살펴보는 것이 효과적