코드 한 줄 짜기 전에 다이어그램 세 장을 그리는 사람. 설계 없이는 손가락 하나 안 움직인다.
아키텍처 설계자(ARCH) 유형은 개발팀에서 가장 체계적이고 선견지명이 있는 개발자입니다. 이들은 새로운 프로젝트가 시작되면 가장 먼저 화이트보드나 노트를 꺼내 전체 시스템의 구조를 그리기 시작합니다. 데이터가 어떻게 흐르는지, 각 모듈이 어떻게 연결되는지, 미래에 어떤 기능이 추가될 때 구조가 어떻게 확장될 수 있는지를 머릿속에서 먼저 완성한 후에야 코딩을 시작합니다.
이 유형의 개발자들은 단순히 "작동하는 코드"에 만족하지 않습니다. 그들이 추구하는 것은 6개월 후, 1년 후, 심지어 3년 후에도 유지보수하기 쉽고 확장 가능한 코드베이스입니다. 때문에 초기 개발 속도가 다소 느릴 수 있지만, 장기적으로는 팀 전체의 생산성을 높이는 결과를 만들어냅니다. 이들이 설계한 시스템은 새로운 팀원이 온보딩할 때도 이해하기 쉽고, 버그가 발생했을 때도 원인을 찾기 쉬운 구조를 갖추고 있습니다.
ARCH 유형은 ERD(Entity Relationship Diagram), 시퀀스 다이어그램, 플로우차트, 아키텍처 다이어그램 등 다양한 시각적 도구를 즐겨 사용합니다. 회의에서 누군가 "그냥 빨리 만들면 안 돼요?"라고 물으면 내면적으로 작은 고통을 느끼는 타입이기도 합니다. 왜냐하면 이들은 지름길이 결국 더 긴 우회로가 된다는 것을 경험으로 알고 있기 때문입니다.
ARCH 유형이 추구하는 가장 중요한 원칙은 변경 용이성입니다. 소프트웨어에서 요구사항 변경은 피할 수 없는 현실이고, 좋은 아키텍처는 그 변경이 얼마나 적은 비용으로 가능한지를 결정합니다. 의존성 역전 원칙(DIP), 개방-폐쇄 원칙(OCP), 단일 책임 원칙(SRP)을 단순한 이론이 아니라 실제 코드에서 자연스럽게 적용합니다.
마이크로서비스 아키텍처에 대한 ARCH 유형의 시각은 균형 잡혀 있습니다. 마이크로서비스가 만능 해결책이 아니라는 것을 알고, 서비스 분리 기준, 서비스 간 통신 패턴, 분산 트랜잭션 처리, 서비스 디스커버리 같은 복잡성 비용도 이해합니다. 모놀리스로 시작해서 필요할 때 분리하는 Modular Monolith 전략을 적절히 권장하는 것도 ARCH 유형입니다.
아키텍처 결정은 되돌리기 어렵기 때문에 ARCH 유형의 신중함은 팀에게 큰 자산입니다. 하지만 완벽한 설계를 추구하다 실제 개발이 시작되지 못하는 '분석 마비(Analysis Paralysis)'에 빠지는 것이 이 유형의 가장 큰 위험입니다. '지금 알고 있는 것을 기반으로 한 최선의 결정'을 내리고, 새로운 정보가 생기면 아키텍처를 진화시킬 수 있다는 유연한 사고방식이 필요합니다.
ARCH 유형이 팀에서 영향력을 발휘하는 가장 효과적인 방법은 Architecture Decision Record(ADR)입니다. 주요 기술 결정을 내릴 때마다 배경, 고려한 대안들, 선택 이유, 예상 결과를 기록해두면 팀 내 기술 방향이 일관성을 갖게 되고, 새 팀원도 설계 의도를 빠르게 파악할 수 있습니다.
"일단 만들고 나중에 고치자는 말은, 일단 달리고 나중에 방향 잡자는 것과 같아요. 어디로 가는지 모르면서 빠른 게 무슨 의미가 있죠?"
— ARCH 유형 시니어 개발자새 서비스 개발 미팅에서 PM이 "이번 주 안에 MVP 만들어봐요"라고 했을 때, ARCH 유형의 개발자는 어떻게 반응할까요?
기술 부채가 쌓이는 속도가 현저히 낮습니다. 처음부터 올바른 구조를 설계하기 때문에 리팩토링에 드는 비용이 적습니다. 새 팀원이 합류했을 때 온보딩이 빠르고, 문서화가 잘 되어 있어 지식 전달이 원활합니다. 시스템 전체를 이해하는 깊이가 남다르기 때문에 복잡한 버그의 근본 원인을 찾아내는 데 특히 뛰어납니다. 또한 마이크로서비스 분리, API 게이트웨이 설계, 데이터베이스 샤딩 전략 등 대규모 시스템 설계 과제에서 두각을 나타냅니다.
설계에 너무 많은 시간을 쏟아 실제 구현이 늦어지는 과설계(over-engineering) 함정에 빠질 수 있습니다. 스타트업처럼 빠른 피벗이 필요한 환경에서는 상세한 초기 설계가 오히려 발목을 잡기도 합니다. "완벽한 설계"를 기다리다가 시장 기회를 놓치는 경우도 있습니다. YAGNI(You Aren't Gonna Need It) 원칙을 의식적으로 적용하며, 80% 설계 후 구현을 시작하고 나머지 20%는 실제 코드를 작성하면서 완성하는 연습이 필요합니다.
Q. 아키텍처를 잘 설계하려면 어떤 공부가 필요한가요?
클린 아키텍처(로버트 마틴), 도메인 주도 설계(에릭 에반스), 마틴 파울러의 엔터프라이즈 애플리케이션 패턴을 읽고, 실제 오픈소스 프로젝트의 구조를 분석해보는 것을 추천합니다.
Q. 아키텍처 설계자는 코딩을 안 해도 되나요?
코딩에서 멀어지면 실무 감각이 떨어지고, 설계가 현실을 반영하지 못하게 됩니다. 시니어 아키텍트도 코어 코드는 직접 작성하거나 리뷰하면서 감각을 유지해야 합니다.
Q. 작은 팀에서도 아키텍처가 중요한가요?
팀이 작을수록 초기 아키텍처 결정이 나중에 더 큰 영향을 미칩니다. 단, 팀 규모에 맞는 단순한 구조로 시작하고, 실제 문제가 생길 때 복잡성을 추가하는 것이 현명합니다.
💡 모든 아키텍처 결정에 '이 결정을 나중에 되돌리기 얼마나 어려운가'를 기준으로 우선순위를 정하세요. 되돌리기 쉬운 결정은 빠르게, 되돌리기 어려운 결정은 신중하게.