소프트웨어를 직접 다루지 않으면 설계할 수 없다

• 대규모 시스템의 실질적 설계 참여는 해당 코드를 직접 다루는 엔지니어만 가능하며, 추상적 조언은 대부분 무의미함
• 일반적 설계 조언(generic design) 은 코드베이스를 모르는 상태에서 도메인만 이해한 채 제시되는 경우가 많음
• 실제 업무에서는 구체적 제약과 일관성 유지가 설계 원칙보다 훨씬 중요하며, 코드의 현재 상태 이해가 핵심임
• 새로운 시스템 설계나 회사 전체의 기술 방향 결정에서는 일반적 설계 원칙이 일정 부분 유용하게 작동함
• 그러나 현장과 분리된 아키텍트 중심 설계 구조는 실패하기 쉽고, 설계를 제안한 사람이 결과에 책임을 져야 함

일반적 소프트웨어 설계의 한계

• 대규모 시스템 설계에는 코드의 구체적 세부사항에 대한 깊은 이해가 필수
  • 추상적 조언은 실제 문제 해결에 거의 도움이 되지 않음
  • 실무에서는 일관성(consistency) 이 ‘좋은 설계’보다 더 중요함
• 실제 코드베이스는 복잡하고 예측 불가능한 결과를 낳기 때문에, 안전한 변경을 위해 선택 가능한 구현 방식이 제한됨
• 대규모 공유 코드베이스는 항상 여러 설계가 뒤섞인 중간 상태에 있으며, 이상적 목표보다 현재 코드의 결합 상태가 더 중요함
• 대부분의 시스템은 전체 재작성(rewrite)이 불가능하므로, 내부 일관성과 엔지니어의 세심함에 의존해야 함

구체적 소프트웨어 설계의 특징

• 효과적인 설계 논의는 시스템을 매일 다루는 소수의 엔지니어들 간의 대화에서 이루어짐
  • 논의 주제는 일반 원칙이 아니라 시스템의 세부 구조나 데이터 흐름 등 구체적 맥락 중심
• 예를 들어 “DRY가 좋은가”가 아니라 “이 기능을 A 서브시스템에 넣을 수 있는가, B 정보가 C 컨텍스트에서 접근 가능한가” 같은 세밀한 기술적 논의가 이루어짐
• 중요한 기여는 작은 오해나 코드 변경의 세부 영향을 바로잡는 데서 나옴

일반적 설계 조언이 유용한 경우

• 새로운 프로젝트를 처음 설계할 때는 구체적 제약이 없으므로 일반적 원칙이 유용함
• 여러 구현안 중 선택이 어려울 때 일반적 원칙이 결정의 기준(tie-breaker) 역할을 함
• 회사 전체 수준의 일관성 유지에도 도움이 되며, 이는 공식적인 소프트웨어 아키텍트의 역할 중 하나임
• 클라우드 vs 온프레미스, AWS vs Azure 같은 광범위한 기술 선택에서도 일반 원칙이 참고될 수 있으나, 여전히 구체적 제약을 무시할 수 없음

아키텍트와 ‘로컬 미니마’ 문제

• 많은 기업이 현장 경험이 없는 아키텍트 중심의 추상적 설계 구조에 빠짐
  • 이 방식은 겉보기엔 효율적이지만, 실제로는 현장 엔지니어가 구현 불가능한 설계를 낳음
• 아키텍트는 직접 구현하지 않기 때문에 성과에 대한 책임(skin in the game) 이 부족함
  • 설계가 성공하면 공을, 실패하면 실행팀의 탓으로 돌릴 수 있음
• 이런 구조는 실질적 가치보다 형식적 설계 활동을 강화하는 경향이 있음

결론 및 제안

• 유용한 설계 논의는 코드 단위 수준의 구체적 대화에서 이루어지며, 설계자는 반드시 코드베이스에 익숙해야 함
• 일반적 아키텍처 원칙은 새 시스템 설계, 기존 시스템의 세부 결정 보조, 회사 차원의 기술 방향 설정에 한정되어야 함
• 프로젝트 설계를 제안한 사람은 그 성공과 실패에 책임을 져야 하며, 실제로 코드를 다루는 엔지니어가 설계의 주체가 되어야 함
• 이를 통해 실제 시스템을 이해하고 배포할 수 있는 사람이 진정한 설계자로 인정받을 수 있음