직접 만들지 않는 소프트웨어는 설계할 수 없다
(blogbyash.com)대형 소프트웨어 시스템을 실제로 작업하는 엔지니어만이 설계 과정에 의미 있게 참여할 수 있으며, 구체적인 세부 사항에 대한 이해 없는 일반적인 설계 조언은 실무에서 무용함을 강조.
일반적인 소프트웨어 설계(Generic software design)의 한계
- 도메인에 대한 이해는 있으나 기존 코드베이스 지식이 없는 상태에서 제공되는 조언의 위험성.
- 대형 코드베이스에서는 '좋은 설계'보다 일관성(consistency) 유지가 더 중요함.
- 실제 코드베이스는 예측하기 어려운 부작용이 많아 구현 선택지가 극히 제한적임.
- 시스템은 항상 여러 설계 사이의 중간 상태에 있으므로, 이상적인 목표보다 개별 변경 후의 유지 가능성이 핵심.
구체적인 소프트웨어 설계(Concrete software design)의 특징
- 시스템을 깊이 이해하고 매일 작업하는 소수 엔지니어들 사이에서 발생하는 실질적인 논의.
- 추상적인 설계 원칙(예: DRY vs WET)보다 서브시스템 간의 데이터 흐름, 컨텍스트, 리팩토링 현황 등 난해하고 구체적인 세부 사항 중심.
- 설계의 핵심 기여는 철학적 논쟁이 아닌 구체적 사실에 대한 오해를 바로잡는 것에서 발생.
일반적인 소프트웨어 설계가 유용한 예외적 상황
- 기존 제약 사항이 없는 완전히 새로운 프로젝트를 시작할 때.
- 여러 현실적인 후보 경로가 모두 비슷해 보일 때 최종 선택을 돕는 기준(Tie-breaking).
- 회사 전체 차원에서 서로 다른 코드베이스 간의 일관성을 확보하고 기술 스택(클라우드, K8s 등)을 결정할 때.
아키텍트 역할과 로컬 미니멈(Local minima)
- 현업 엔지니어가 아닌 사람들에게 추상적이고 영향력 큰 결정만 맡기는 관행의 문제점 지적.
- 아키텍트와 구현 팀의 분리는 '책임 부재(Skin in the game)' 문제를 야기.
- 설계자가 구현에 참여하지 않을 경우, 성공 시 공을 차지하고 실패 시 구현 팀의 탓으로 돌리기 쉬운 구조적 결함 존재.
결론 및 요약
- 유용한 소프트웨어 설계 논의는 파일이나 코드 라인 단위의 구체성을 띠어야 함.
- 코드베이스를 깊이 알고 적극적으로 기여하는 사람만이 유용한 설계를 수행 가능.
- 프로젝트 설계를 제안한 사람이 출시와 성공에 직접 책임을 지는 구조가 바람직함.
- 실제 시스템을 출시하는 법을 아는 엔지니어가 설계 작업에 대한 정당한 평가를 받아야 함.