2025년 11월 19일·7분
마틴 파울러의 관점: 유행 스택을 넘어 오래가는 아키텍처
마틴 파울러의 실용적 관점을 탐구합니다: 패턴, 리팩토링, 진화적 변화로 유행하는 스택을 넘어 장기적 리스크를 낮추는 방법.
마틴 파울러의 실용적 관점을 탐구합니다: 패턴, 리팩토링, 진화적 변화로 유행하는 스택을 넘어 장기적 리스크를 낮추는 방법.
새로운 프레임워크, 반짝이는 클라우드 서비스, 혹은 인기 회사의 "표준 스택"은 품질로 가는 지름길처럼 느껴질 수 있습니다. 하지만 스택 우선 사고는 도구와 구조를 혼동하게 합니다. 가장 최신 기술로도 엉망이고 변경하기 힘든 시스템을 만들 수 있고, 진부하지만 잘 알려진 선택으로 깔끔하고 적응 가능한 시스템을 만들 수도 있습니다.
스택을 먼저 고르면 팀은 슬라이드에서 보기에는 인상적이지만 실제 질문에는 답하지 않는 결정으로 밀려납니다:
기술 선택이 앞서면 아키텍처는 우연한 부산물이 되어 버립니다—결과적으로 강한 결합, 중복된 로직, 간단한 변경도 비싸게 만드는 의존성이 생깁니다.
그래서 “우리는 마이크로서비스를 사용한다”(또는 “이제 서버리스다”)는 것은 아키텍처가 아닙니다. 이는 배포와 도구 방향입니다. 아키텍처는 시스템의 구성 요소들이 어떻게 협력하는지, 어떤 결정이 미래 작업을 어떻게 제약하는지, 제품이 얼마나 쉽게 진화할 수 있는지에 관한 것입니다.
실용적 함의: 도구는 배달을 가속화할 수 있지만 아키텍처적 사고를 대체하지는 못합니다. 채팅을 통해 빠르게 생성하고 반복하는 최신 "vibe-coding" 접근에서도 동일한 질문들이 여전히 적용됩니다. Koder.ai 같은 플랫폼은 웹, 백엔드, 모바일 앱 구축을 극적으로 빠르게 할 수 있지만, 최상의 결과를 얻는 팀은 여전히 경계, 소유권, 변경 가능성을 일급 우선순위로 다룹니다(프레임워크가 마법처럼 해결해 주는 것으로 보지 않습니다).
마틴 파울러의 글은 중요한 것으로 다시 주의를 끌어옵니다: 유행하는 구성요소보다 명확한 설계, 이데올로기보다 실용적 절충, 배우면서 시스템을 진화시키는 능력. 그의 작업은 아키텍처를 일회성의 "대규모 설계"가 아니라 지속적으로 개선하는 것으로 다룹니다.
세 가지 반복되는 주제를 기대하세요: 규칙이 아닌 선택지로서의 패턴 사용, 규칙적인 습관으로서의 리팩토링, 그리고 확실성 대신 변화를 위해 설계하는 진화적 아키텍처.
엔지니어링 리더, 기술 리드, 혹은 품질이 무너지지 않으면서 더 빠르게 배포하려는 제품 팀이라면 이 글이 도움이 될 것입니다. 목표는 "완벽한" 스택을 고르는 것이 아니라 로드맵이 바뀌어도 소프트웨어를 쉽게 변경할 수 있도록 결정을 내리는 것입니다.
소프트웨어 아키텍처는 나중에 바꾸기 어렵고 비용이 많이 드는 방식으로 시스템을 형성하는 일련의 결정입니다.
이 정의는 의도적으로 평이합니다. 특별한 다이어그램이나 "아키텍트"라는 직함이 필요하지 않습니다. 소프트웨어가 어떻게 성장할 수 있는지, 팀이 어떻게 작업할 수 있는지, 운영 비용이 어떻게 될지를 결정하는 선택들에 관한 것입니다.
프레임워크, 도구, 코딩 스타일은 중요하지만—대부분은 진정한 아키텍처적 선택에 비해 교체하기 쉬운 편입니다.
아키텍처는 구조와 경계에 더 가깝습니다: 시스템의 부분들이 어떻게 통신하는가, 데이터는 어디에 있는가, 실패는 어떻게 처리되는가, 어떤 변경이 팀 간 조정을 필요로 하는가.
보편적 "최고"의 아키텍처는 없습니다. 주요 결정마다 어떤 목표를 최적화하고 다른 목표에 비용을 부과합니다:
좋은 아키텍처는 이러한 절충을 우연히 발생시키지 않고 명시적으로 만듭니다.
아키텍처적 결정: “고객 청구를 자체 배포 가능한 서비스와 자체 DB로 분리하고, 나머지 시스템과는 비동기 이벤트로 통합한다.”
이는 배포, 데이터 소유권, 실패 모드, 모니터링, 팀 조정에 영향을 줍니다.
라이브러리 선택: “PDF 생성에 라이브러리 X를 사용한다.”
유용하지만 보통 제한된 영향 범위 내에서 교체 가능합니다.
만약 어떤 결정을 되돌리려면 몇 주간의 조정 작업이 필요하다면, 그건 아마도 아키텍처입니다.
디자인 패턴은 반복되는 문제에 대한 재사용 가능한 해법으로 이해하는 것이 가장 좋습니다. 파울러의 일반적 입장은 실용적입니다: 패턴은 설계를 명확히 할 때 유용하고, 사고를 대신할 때 해롭습니다.
잘 사용하면 패턴은 팀의 공통 어휘를 제공합니다. “Strategy”나 “Repository”라고 말하면 긴 설명을 한 단어로 압축할 수 있어 리뷰가 빨라지고 오해가 줄어듭니다.
패턴은 시스템 동작을 예측 가능하게 만듭니다. 익숙한 패턴은 로직이 어디에 있는지, 객체들이 어떻게 협력하는지, 어떤 변경이 파급될지를 기대하게 합니다. 그 예측 가능성은 운영에서의 놀라움을 줄이고 신규 팀원이 “이게 어떻게 동작하냐?”고 느끼는 상황을 줄여줍니다.
실패 모드는 카고컬트입니다: 패턴이 인기 있어서, 책에 나와 있어서, 혹은 “우리가 항상 이렇게 해서”라는 이유로 적용하는 것입니다. 이는 종종 과도한 설계를 초래합니다—불필요한 계층, 간접성, 가치 없는 추상화가 생깁니다.
또 다른 함정은 “모든 문제에 패턴을 적용”하는 것입니다. 작은 문제마다 이름 붙인 해법을 적용하면 코드베이스는 유지와 배포를 위한 도구가 아니라 놀라운 아이디어들의 박물관이 될 수 있습니다.
문제에서 시작하세요, 패턴에서 시작하지 마세요.
물어볼 것들:
그런 다음 오늘에 맞는 가장 단순한 패턴을 골라 옵션을 열어두세요. 나중에 구조가 더 필요해지면 점진적으로 도입하고—보통 실제 고통에 의해 유도되고 리팩토링으로 확인되며, 추측으로 미리 도입하지 마세요.
리팩토링은 내부 설계를 개선하되 기능은 변경하지 않는 관행입니다. 사용자에게는 리팩토링 후 아무것도 달라진 것처럼 보이지 않아야 합니다—단지 미래 변경이 더 쉽고 안전하며 빠르게 되는 것이 차이입니다.
마틴 파울러의 요점은 “코드를 예쁘게 유지하라”가 아닙니다. 아키텍처는 시작할 때 그려놓는 일회성 다이어그램이 아닙니다. 아키텍처는 시스템을 얼마나 쉽게 변화시킬 수 있는지를 결정하는 선택들의 집합이고, 리팩토링은 그 선택들이 굳어 제약이 되는 것을 막는 방법입니다.
시간이 지나면 잘 설계된 시스템도 흐트러집니다. 새로운 기능은 시간 압박 속에 추가되고, 임시방편은 영구화되며, 경계는 흐려집니다. 리팩토링은 명확한 분리를 복원하고 우연한 복잡성을 줄여 시스템이 변경 가능하도록 하는 방법입니다.
건강한 아키텍처는 다음과 같은 특징이 있습니다:
리팩토링은 그런 속성을 보존하는 일상적 작업입니다.
보통 달력 때문에 리팩토링을 예약하지 않습니다. 코드가 저항할 때 합니다:
이런 신호가 보이면 이미 아키텍처에 영향이 가고 있는 것이며—리팩토링이 수리입니다.
안전한 리팩토링은 몇 가지 습관에 의존합니다:
이렇게 하면 리팩토링은 체계적 유지보수가 되어, 마지막 변경 후 시스템이 취약해지는 대신 다음 변경을 대비하게 됩니다.
기술 부채는 오늘의 지름길이 만드는 미래 비용입니다. 그것은 도덕적 실패로서의 ‘나쁜 코드’가 아닙니다; 때로는 합리적인 선택이며 나중에 변경 비용을 증가시킵니다. 파울러의 관점은 부채는 추적을 멈추고 없는 척할 때 문제가 된다는 점을 상기시켜 줍니다.
의도적 부채는 의식적으로 선택한 것입니다: “우리는 더 간단한 버전을 지금 내보내고 다음 스프린트에 단단히 만들겠다.” 이는 합리적일 수 있습니다—단, 상환 계획이 있어야 합니다.
우발적 부채는 팀이 빚지고 있는 것을 모를 때 생깁니다: 지저분한 의존성이 스며들고, 불분명한 도메인 모델이 퍼지며, 임시방편이 기본값이 되는 경우입니다. 우발적 부채는 보통 아무도 책임지지 않기 때문에 더 비용이 큽니다.
부채는 평범한 압력 속에서 쌓입니다:
결과는 예측 가능합니다: 기능 개발이 느려지고, 버그가 증가하며, 리팩토링이 일상적이 아니라 위험하게 느껴집니다.
거대한 프로그램이 필요하지 않습니다:
결정과 부채를 가시화하면(예: /blog/architecture-decision-records) 숨겨진 비용을 관리 가능한 작업으로 바꿀 수 있습니다.
소프트웨어 아키텍처는 한 번에 "정답"을 얻는 도면이 아닙니다. 파울러의 관점은 더 실용적입니다: 요구사항, 트래픽, 팀, 제약은 바뀔 것이라고 가정한 다음—고통스러운 재작성 없이 적응할 수 있게 설계하라는 것입니다.
진화적 아키텍처는 변화에 맞춰 설계하는 것입니다. 긴 호흡의 예측(“우리는 마이크로서비스가 필요할 것이다”, “100배로 확장할 것이다”)에 전부 걸지 않고, 안전하게 진화할 수 있는 아키텍처를 구축합니다: 명확한 경계, 자동화된 테스트, 자주 저위험으로 조정할 수 있는 배포 관행.
계획은 추측이고, 운영 환경이 진짜입니다. 작은 단위로 자주 배포하면 사용자가 실제로 무엇을 하는지, 운영 비용이 실제로 얼마인지, 성능이나 신뢰성이 어디에서 중요한지를 배울 수 있습니다.
작은 릴리스는 또한 의사결정 스타일을 바꿉니다: 한 모듈을 분리하거나 새 API 버전을 도입하는 등의 적당한 개선을 시도하고, 그것이 도움이 되었는지 측정할 수 있습니다—대규모 마이그레이션에 전부를 걸지 않고.
이 지점에서 빠른 반복 도구는 도움이 되지만, 아키텍처 가드레일을 유지해야 합니다. 예를 들어 Koder.ai 같은 플랫폼을 사용해 기능을 빠르게 생성·반복한다면, 그 속도에 안정적인 모듈 경계, 좋은 테스트, 잦은 배포를 결합해 "빠르게 배포하다가 모서리에 몰리는" 일을 피해야 합니다.
진화 아이디어의 핵심은 “피트니스 함수”: 아키텍처 목표를 보호하는 측정 가능한 검사입니다. 가드레일이라고 생각하세요. 가드레일이 자동화되어 지속적으로 실행되면, 자신 있게 시스템을 변경할 수 있습니다. 왜냐하면 가드레일이 벗어난 상황을 경고해 주기 때문입니다.
피트니스 함수는 화려할 필요 없습니다. 중요하게 여기는 것을 반영하는 간단한 지표, 테스트, 임계값이면 충분합니다.
모든 것을 재려 하지 마세요. 변경 속도, 신뢰성, 보안, 상호운용성 같은 아키텍처적 약속을 반영하는 소수의 체크를 골라 일상적 결정을 이끌게 하세요.
마이크로서비스는 엔지니어링 성숙도의 배지(badge)가 아닙니다. 파울러의 요점은 단순합니다: 시스템을 서비스로 분리하는 것은 기술적 결정만큼 조직적 결정이기도 합니다. 팀이 서비스별로 끝까지 소유(빌드, 배포, 운영, 진화)할 수 없다면, 이득 없이 복잡함만 얻습니다.
모놀리식은 하나의 배포 단위입니다. 장점: 부품이 적고 디버깅이 단순하며 데이터 일관성이 쉽습니다. 단점은 코드베이스가 얽힐 때 드러나며—작은 변경에도 큰 조정이 필요합니다.
모듈형 모놀리식은 여전히 하나의 배포 단위지만, 코드가 명시적 모듈로 분리되어 있습니다. 운영적 단순성을 유지하면서 내부 결합을 줄입니다. 많은 팀에 가장 적합한 기본값입니다.
마이크로서비스는 각 서비스가 자체 배포와 수명주기를 가집니다. 독립적 릴리스와 명확한 소유권을 가능하게 할 수 있지만, 조직이 준비되지 않으면 "하나의 어려운 문제"를 "열 개의 어려운 문제"로 만들기 쉽습니다.
마이크로서비스는 다이어그램에는 드러나지 않는 오버헤드를 추가합니다:
모듈형 모놀리식으로 시작하세요. 분할 전 실제로 나타나는 압력을 측정하세요: 릴리스 병목, 모듈을 둘러싼 팀 간 다툼, 확장 핫스팟, 혹은 신뢰성 격리 필요성. 그런 압력이 지속적이고 정량화되면, 명확한 경계와 전담 소유권, 운영 계획을 가지고 서비스를 분리하세요—코드만 있는 계획이 아니라 운영 계획을 세우세요.
좋은 아키텍처는 서비스 개수가 많은지가 아니라, 한 부분을 변경할 때 세 다른 부분이 우연히 깨지지 않도록 하는 능력에 관한 것입니다. 파울러는 이를 결합(coupling) 과 응집(cohesion) 으로 자주 설명합니다.
레스토랑 주방을 생각해 보세요. 응집된 스테이션(예: "샐러드")은 필요한 모든 것—재료, 도구, 명확한 책임—이 갖춰져 있습니다. 반면에 강하게 결합된 주방은 샐러드를 만들려면 그릴 담당이 멈추고, 제과사가 드레싱을 승인해야 하고, 매니저가 냉장고를 열어줘야 하는 식입니다.
소프트웨어도 같습니다: 응집된 모듈은 명확한 일을 담당하고, 느슨하게 결합된 모듈은 단순하고 안정적인 약속을 통해 상호작용합니다.
건강하지 못한 결합은 보통 코드보다 일정에서 먼저 드러납니다. 일반적 신호:
배달 과정이 정기적으로 그룹 안무를 필요로 한다면, 의존성 비용은 이미 회의와 지연으로 지불되고 있는 것입니다.
결합을 줄이기 위해 재작성할 필요는 없습니다. 실용적 조치들:
결정이 중요할 때는 /blog/architecture-decision-records 같은 가벼운 노트로 캡처해 경계가 의도적으로 유지되게 하세요.
공유 데이터베이스는 "비밀스러운" 결합을 만듭니다: 어떤 팀이든 테이블을 바꿔서 다른 팀을 망가뜨릴 수 있습니다. 공유 DB는 종종 시스템이 독립적으로 보이더라도 조정된 릴리스를 강요합니다.
더 건강한 접근은 데이터 소유권입니다: 한 시스템이 데이터셋을 소유하고 API나 이벤트로 노출합니다. 이렇게 하면 의존성이 가시화되어 관리할 수 있습니다.
소프트웨어 아키텍처는 상자와 화살표만의 문제가 아닙니다. 또한 사람들에 관한 문제입니다: 작업 분할 방식, 의사결정 방식, 현실이 설계와 다를 때 팀이 얼마나 빨리 대응할 수 있는지. 이것이 사회기술적 아키텍처입니다—시스템 구조가 팀 구조를 닮는 경향이 있다는 관점입니다.
일반적 실패 모드는 종이에 깨끗한 경계를 그려놓고 실제 업무 흐름이 그 경계를 가로지르는 경우입니다. 시스템은 기술적으로 컴파일되고 배포될 수 있지만 변경하기에는 비용이 많이 듭니다.
불일치의 징후:
완벽보다 소유권으로 시작하세요. 팀이 현실적으로 운영할 수 있는 방식에 맞는 경계를 목표로 하세요.
때로는 조직을 재구성할 수 없고, 레거시 모듈을 분리할 수 없고, 인원을 늘려 병목을 해결할 수도 없습니다. 그런 경우 아키텍처를 협상으로 보세요: 가장 비용이 큰 조정을 줄이는 경계를 선택하고, 자율성을 해방하는 리팩토링에 투자하며, 기술적·조직적 부채를 갚는 동안 과도적 타협을 수용하세요.
소프트웨어 아키텍처는 무엇을 만드는가뿐 아니라 그 과정에서 내린 결정들이기도 합니다. 아키텍처 결정 기록(ADR)은 맥락이 선명할 때 그 결정을 캡처하는 짧은 노트입니다.
ADR은 한 페이지 분량의 메모로: "우리가 무엇을 결정했고, 왜인가?"를 답합니다. 긴 설계 문서도, 허가서도 아닙니다. 팀의 지속 가능한 기억 저장소로 생각하세요.
구조를 일관되게 유지해 사람들이 빠르게 스캔할 수 있게 하세요. 가벼운 ADR에는 보통 다음이 포함됩니다:
ADR은 신규 팀원이 이유를 따라가게 해 온보딩을 가속합니다. 같은 질문이 몇 달 뒤 다시 나오면 ADR을 참조하고 업데이트하면 재논쟁을 피할 수 있습니다. 무엇보다 ADR은 절충을 명시적으로 만들어 현실이 바뀔 때 계획을 수정하기 쉽게 합니다.
간단한 템플릿을 사용하고 ADR을 코드 옆(예: /docs/adr/)에 보관하세요. 하나 쓰는 데 10–20분이면 충분합니다.
# ADR 012: API versioning strategy
Date: 2025-12-26
Status: Accepted
Owners: Platform team
Context:
We need to evolve public APIs without breaking partners.
Decision:
Adopt URL-based versioning (/v1/, /v2/).
Alternatives:
- Header-based versioning
- No versioning; rely on backward compatibility
Consequences:
+ Clear routing and documentation
- More endpoints to support over time
ADR이 서류 작업처럼 느껴지면 더 줄이세요—습관을 버리지 마세요.
아키텍처는 누군가가 깔끔한 다이어그램을 한 번 그렸기 때문에 유지되지 않습니다. 아키텍처는 시스템을 작은 단계로 안전하게 바꿀 수 있을 때 유지됩니다. 그래서 지속적 배포(CD)와 빠른 피드백 루프가 중요합니다: 이들은 진화를 위험한 이벤트가 아니라 정상적 습관으로 바꿉니다.
리팩토링은 변경이 작고 되돌릴 수 있을 때 가장 쉽습니다. 건강한 CI/CD 파이프라인은 모든 변경을 자동으로 빌드, 테스트, 검증해 사용자에게 도달하기 전에 확인합니다. 파이프라인을 신뢰할 수 있을 때 팀은 “언젠가 할 대규모 재작성”을 기다리지 않고 지속적으로 설계를 개선할 수 있습니다.
품질 게이트는 빠르고 일관되며 당신이 신경 쓰는 결과에 연결되어야 합니다. 일반적 게이트:
목표는 완벽이 아니라—파괴적 변경의 비용을 높이고 안전한 개선의 비용을 낮추는 것입니다.
좋은 아키텍처는 부분적으로 운영 환경에서 시스템이 무엇을 하고 있는지 아는 것입니다. 피드백 없이는 추측에 기반해 최적화합니다.
이 신호들이 있으면 아키텍처 결정을 의견이 아니라 증거로 검증할 수 있습니다.
진화하려면 자주 변경을 배포해야 하므로 탈출 해처치가 필요합니다. 기능 플래그는 배포와 릴리스를 분리하게 하고, 카나리 릴리스는 충격 반경을 작은 집단으로 제한합니다. 명확한 롤백 전략(데이터베이스 고려 포함)은 실패를 복구 가능한 사건으로 만듭니다.
스냅샷과 롤백을 지원하는 애플리케이션 플랫폼(예: Koder.ai)을 사용하면 제품 전달 계층에서도 같은 원리를 강화할 수 있습니다: 빠르게 움직이되 되돌릴 수 있고 운영상 안전을 기본값으로 유지하세요.
CI/CD와 피드백을 합치면 지속적으로 진화할 수 있는 시스템이 만들어집니다—바로 트렌드를 이기는 아키텍처입니다.
리팩토링이나 전면 재작성 없이도 더 나은 아키텍처를 얻을 수 있습니다. 설계 문제를 가시화하고 되돌릴 수 있게 하며 지속적으로 개선하는 몇 가지 반복 가능한 습관이 필요합니다.
다음 30일: 하나의 “핫스팟”(변경이 잦고 사고가 빈번한 영역)을 선택하세요. 특성화 테스트 스위트를 추가하고, 한 의존 체인을 단순화하며, 새 변경에 대해 가벼운 결정 노트 작성을 시작하세요.
60일 이내: 문제 있는 경계 하나를 리팩토링하세요: 모듈 추출, 인터페이스 정의, 또는 지속성이나 메시징 같은 인프라 관심사를 경계 뒤로 격리하세요. 변경의 “충격 반경”을 줄이세요.
90일 이내: 전달 루프를 개선하세요. 더 작은 PR, 더 빠른 빌드, 예측 가능한 릴리스 주기를 목표로 하세요. 마이크로서비스를 고려 중이라면, 기존 코드베이스 내에서 경계를 관리할 수 없다는 것을 증명해 보이세요.
(목표 중 일부가 더 적은 핸드오프로 더 많은 제품을 출시하는 것이라면 자동화가 도움이 되는 지점을 고려하세요. 일부 팀은 Koder.ai 같은 채팅 기반 빌드 워크플로—플래닝 모드, 소스 내보내기, 배포/호스팅, 커스텀 도메인, 무료부터 엔터프라이즈까지 계층화된 가격—를 사용하면 기계적 오버헤드를 줄이면서 경계, 테스트, 운영 피드백에 아키텍처적 주의를 집중할 수 있습니다.)
월별로 몇 가지 신호를 추적하세요:
이들이 개선되지 않으면 계획을 조정하세요—아키텍처는 변경을 더 안전하고 저렴하게 만들 때만 "더 나아진" 것입니다.
스택은 계속 바뀔 것입니다. 기본 원칙—명확한 경계, 리팩토링 규율, 빠른 피드백—은 지속됩니다.
아키텍처는 나중에 되돌리기 비용이 큰 결정들의 집합입니다: 경계, 데이터 소유권, 통합 방식, 장애 처리 방식 등.
기술 스택은 그런 결정을 구현하는데 사용하는 도구들(프레임워크, 라이브러리, 클라우드 서비스 등)입니다. 많은 도구는 비교적 쉽게 교체할 수 있지만, 경계나 데이터 흐름을 바꾸는 일은 보통 수주간의 팀 조정이 필요합니다.
좋은 테스트은 되도록을 확인하는 방법입니다: 그 결정을 되돌리려면 여러 팀이 조율해야 하고 몇 주가 걸린다면 그건 아키텍처적 결정입니다.
예시:
패턴은 특정 반복 문제를 해결하기 위해 사용하세요. 디자인을 전문가처럼 보이게 하기 위해 무작정 적용하면 과도한 설계가 됩니다.
간단한 체크리스트:
문제를 명확히 설명할 수 없다면 패턴을 추가하지 마세요.
리팩토링을 일상적 유지보수로 생각하세요. 다음 신호들이 보이면 리팩토링이 필요합니다:
테스트, 작은 단계, 엄격한 코드 리뷰로 안전하게 진행하세요.
부채를 부끄러운 비밀로 두지 말고 비용으로 관리하세요.
실용적인 관리법:
결정은 가볍게 ADR 같은 방식으로 명시하세요.
학습하면서 안전하게 방향을 바꿀 수 있도록 설계하는 것입니다. 장기 예측에 모든 걸 걸지 않고, 변경을 수용할 수 있게 만드는 접근입니다.
일반적인 구성요소:
목표는 ‘적응성’이지 완벽한 사전 설계가 아닙니다.
피트니스 함수는 아키텍처 목표를 보호하는 자동화된 가드레일입니다.
유용한 예:
속도, 신뢰성, 보안 같은 약속을 반영하는 몇 가지를 선택해 지속적으로 실행하세요.
기본값은 모듈형 모놀리식을 권합니다. 독립 배포가 정말 필요한지, 그 필요가 측정되고 지속되는지를 확인하세요.
마이크로서비스가 효과를 발휘할 때:
한 서비스를 편하게 운영할 수 없다면, 10개로 쪼개는 것은 고통을 곱할 뿐입니다.
의존성을 가시적이고 의도적으로 만드세요.
영향 큰 조치:
공유 DB는 ‘비밀스러운 결합’을 만들어 겉보기와 달리 조정이 필요하게 만듭니다.
ADRs는 ‘우리가 무엇을 왜 결정했는가’를 당시의 맥락으로 간단히 기록하는 도구입니다.
가벼운 ADR 구성요소:
코드 옆(예: /docs/adr/)에 보관하고 작성 시간은 10–20분 정도로 가볍게 유지하세요.