직접 만들고 고쳐야 설계가 된다: 대규모 시스템 설계의 현실

개발 문화 · 설계

직접 만들고 고치지 않으면 설계할 수 없다

대규모 시스템의 소프트웨어 설계는 “원칙을 얼마나 알고 있느냐”보다 코드베이스를 실제로 다루며 제약과 결합을 이해하는가에 더 크게 좌우됩니다. 추상적인 조언이 자주 무의미해지는 이유, 현장에서 설계가 이뤄지는 방식, 아키텍트 구조가 실패하기 쉬운 조건을 운영 환경에서는 어떻게 해석해야 하는지 정리합니다.

요약: 설계는 ‘원칙’이 아니라 ‘변경 가능한 현실’을 다루는 일

대규모 시스템에서 설계는 아름다운 다이어그램을 그리는 일이 아니라, 현재 코드가 가진 결합·제약·일관성을 파악한 뒤 “어떻게 안전하게 바꿀 수 있는가”를 결정하는 과정에 가깝습니다. 그래서 설계 논의의 중심은 DRY/WET 같은 일반론이 아니라, 특정 서브시스템의 데이터 흐름과 접근 경로, 변경의 파급 범위처럼 매우 구체적인 맥락으로 이동합니다.

핵심 주장 한 문장
소프트웨어 설계는 코드와 분리될 수 없고,
“직접 만들고 고치지 않는 사람”의 설계는 현장에서 쉽게 무너진다.

왜 ‘일반적 설계 조언’이 현장에서 약해지는가

일반적 설계 조언(generic design)은 대개 “도메인만 이해한 상태”에서 제시되기 쉽습니다. 하지만 대규모 코드베이스에서는 구체적 제약이 설계의 범위를 먼저 결정합니다. 예를 들어 데이터가 어디까지 노출되어 있는지, 어떤 계층이 이미 강하게 결합되어 있는지, 어떤 테스트·배포 전략을 전제로 운영 중인지가 바뀌지 않으면, 선택 가능한 구현 방식이 제한됩니다.

• 대규모 시스템은 “이상적 목표”보다 “현재 결합 상태”가 더 큰 제약이 된다
• 전체 재작성은 대부분 불가능하고, 안전한 변경은 작은 범위에서만 허용된다
• 원칙보다 일관성(consistency)이 생산성과 안정성에 직접 영향을 준다

실무 기준으로 보면
“좋은 설계”를 새로 도입하는 것보다,
팀이 매일 만지는 코드에서 예측 가능한 규칙을 유지하는 편이 더 큰 효과를 내는 순간이 많습니다.
다만 일관성이 ‘나쁜 습관 고착’이 되지 않도록 점진적 개선이 함께 붙어야 합니다.

현장에서 설계가 실제로 이뤄지는 방식

효과적인 설계 논의는 “대규모 회의”보다 시스템을 매일 다루는 소수 엔지니어 사이의 대화에서 더 자주 완성됩니다. 여기서의 설계는 철학이 아니라 경계(경로)와 의존성을 조정하는 작업입니다.

추상적 논의(현장과 멀어지기 쉬움)	구체적 논의(현장에서 실제로 발생)
“DRY가 맞나?” “레이어를 더 나눠야 하나?”	“이 기능을 어느 서브시스템에 넣을 수 있나?” “여기서 필요한 정보가 노출돼 있나?”
“마이크로서비스가 정답이다” 같은 결론형 주장	“배포/관측/온콜까지 고려하면 서비스 경계를 지금 바꾸는 게 안전한가?”
원칙을 지키는지 여부 중심	변경의 파급 범위와 롤백 가능성 중심

이 과정에서 중요한 기여는 종종 “큰 그림”이 아니라 작은 오해를 바로잡고 변경의 부작용을 사전에 잡아내는 것에서 나옵니다. 즉, 설계 역량은 코드에 대한 감각과 함께 자랍니다.

그럼에도 ‘일반 원칙’이 도움이 되는 순간

일반 원칙이 완전히 무의미한 것은 아닙니다. 특히 새 프로젝트 초기처럼 제약이 적은 시점에는 좋은 출발점이 됩니다. 또한 구현안이 여러 개로 갈릴 때, 원칙이 “결정의 기준(tie-breaker)” 역할을 해 줄 수 있습니다.

• 신규 시스템 설계: 아직 결합이 굳기 전이라 원칙이 방향성을 준다
• 선택지가 비슷할 때: 성능/비용/운영 부담을 비교하는 프레임이 된다
• 회사 차원의 일관성: 온보딩·리뷰·유지보수 비용을 낮추는 공통 언어가 된다
• 광범위한 기술 선택: 클라우드/온프레미스 등 큰 결정에서 참고점이 된다

주의할 점
원칙은 “결정의 재료”이지 “결정 그 자체”가 아닙니다.
구체적 제약을 무시한 원칙 적용은, 좋은 말처럼 들리지만 실행 불가능한 설계로 이어지기 쉽습니다.

아키텍트 중심 구조가 실패하기 쉬운 이유

현장 경험이 부족한 아키텍트가 설계를 주도하고, 구현은 다른 팀이 떠안는 구조는 겉보기엔 효율적이지만 실패 확률이 높아집니다. 이유는 단순합니다. 설계를 제안한 사람이 결과에 책임을 덜 지기 쉽기 때문입니다. “스킨 인 더 게임(skin in the game)”이 부족하면, 구현 난이도·운영 리스크·점진적 마이그레이션 같은 현실 조건이 설계에 충분히 반영되지 않습니다.

책임지는 설계의 원칙
설계를 제안한 사람은 성공과 실패의 결과에 책임을 져야 합니다.
가능하면 설계의 주체는 “실제로 코드를 만지고 배포하는 엔지니어”가 되어야 합니다.

반대로 “너무 자유로운 문화”도 같은 방향의 문제를 만들 수 있습니다. 팀마다 제각각 구현이 쌓이면, 리뷰·버그 수정·온보딩 비용이 올라가고 결과적으로 전체 속도가 느려집니다. 그래서 핵심은 아키텍트 유무가 아니라, 실제 코드와 운영을 아는 사람이 기준을 만들고 조율하는 구조입니다.

현업 적용 체크리스트

아래 항목은 “추상 설계 회의”에서 “실행 가능한 설계 대화”로 옮겨갈 때 도움이 됩니다. 소프트웨어 설계라는 단어를 쓰더라도, 대화의 단위를 코드 변경으로 내리는 것이 핵심입니다.

• 코드베이스 기준점: 변경하려는 경로의 현재 결합(의존) 지도를 먼저 그린다
• 일관성 규칙: 지금 팀이 지키는 규칙을 문서화하고, 예외는 최소화한다
• 안전한 변경: 롤백/플래그/단계적 배포 등 “되돌릴 수 있음”을 설계의 일부로 둔다
• 점진적 개선: 큰 리라이트 대신, 만질 때마다 작은 개선을 축적한다
• 책임 구조: 설계 제안자가 구현·운영 피드백 루프에 반드시 참여한다

현장 코멘트에서 자주 반복되는 포인트

현장 반응을 보면 대체로 두 갈래가 함께 나옵니다. 한쪽은 “일관성이 곧 생산성”이라는 관점이고, 다른 한쪽은 “일관성 집착이 오히려 모듈별 요구사항 차이를 무시한다”는 관점입니다. 결론적으로는 둘 중 하나를 고르는 문제가 아니라, 일관성을 기본값으로 두되, 필요할 때 맥락 기반 예외를 설계할 수 있는 팀이 강합니다.

마무리

대규모 시스템에서 설계는 “설계 문서의 품질”보다 코드 변경을 얼마나 예측 가능하게 만들었는가로 평가됩니다. 운영 환경에서는 추상 원칙을 말하기 전에, 지금 코드가 가진 제약과 일관성을 먼저 이해하고 그 위에서 안전하게 움직이는 설계가 필요합니다.