코드 한 줄 짜기 전에 다이어그램 세 장을 그리는 사람. 설계 없이는 손가락 하나 안 움직인다.
아키텍처 설계자(ARCH) 유형은 개발팀에서 가장 체계적이고 선견지명이 있는 개발자입니다. 이들은 새로운 프로젝트가 시작되면 가장 먼저 화이트보드나 노트를 꺼내 전체 시스템의 구조를 그리기 시작합니다. 데이터가 어떻게 흐르는지, 각 모듈이 어떻게 연결되는지, 미래에 어떤 기능이 추가될 때 구조가 어떻게 확장될 수 있는지를 머릿속에서 먼저 완성한 후에야 코딩을 시작합니다.
이 유형의 개발자들은 단순히 "작동하는 코드"에 만족하지 않습니다. 그들이 추구하는 것은 6개월 후, 1년 후, 심지어 3년 후에도 유지보수하기 쉽고 확장 가능한 코드베이스입니다. 때문에 초기 개발 속도가 다소 느릴 수 있지만, 장기적으로는 팀 전체의 생산성을 높이는 결과를 만들어냅니다. 이들이 설계한 시스템은 새로운 팀원이 온보딩할 때도 이해하기 쉽고, 버그가 발생했을 때도 원인을 찾기 쉬운 구조를 갖추고 있습니다.
ARCH 유형은 ERD(Entity Relationship Diagram), 시퀀스 다이어그램, 플로우차트, 아키텍처 다이어그램 등 다양한 시각적 도구를 즐겨 사용합니다. 회의에서 누군가 "그냥 빨리 만들면 안 돼요?"라고 물으면 내면적으로 작은 고통을 느끼는 타입이기도 합니다. 왜냐하면 이들은 지름길이 결국 더 긴 우회로가 된다는 것을 경험으로 알고 있기 때문입니다.
"일단 만들고 나중에 고치자는 말은, 일단 달리고 나중에 방향 잡자는 것과 같아요. 어디로 가는지 모르면서 빠른 게 무슨 의미가 있죠?"
— ARCH 유형 시니어 개발자새 서비스 개발 미팅에서 PM이 "이번 주 안에 MVP 만들어봐요"라고 했을 때, ARCH 유형의 개발자는 어떻게 반응할까요?
기술 부채가 쌓이는 속도가 현저히 낮습니다. 처음부터 올바른 구조를 설계하기 때문에 리팩토링에 드는 비용이 적습니다. 새 팀원이 합류했을 때 온보딩이 빠르고, 문서화가 잘 되어 있어 지식 전달이 원활합니다. 시스템 전체를 이해하는 깊이가 남다르기 때문에 복잡한 버그의 근본 원인을 찾아내는 데 특히 뛰어납니다. 또한 마이크로서비스 분리, API 게이트웨이 설계, 데이터베이스 샤딩 전략 등 대규모 시스템 설계 과제에서 두각을 나타냅니다.
설계에 너무 많은 시간을 쏟아 실제 구현이 늦어지는 과설계(over-engineering) 함정에 빠질 수 있습니다. 스타트업처럼 빠른 피벗이 필요한 환경에서는 상세한 초기 설계가 오히려 발목을 잡기도 합니다. "완벽한 설계"를 기다리다가 시장 기회를 놓치는 경우도 있습니다. YAGNI(You Aren't Gonna Need It) 원칙을 의식적으로 적용하며, 80% 설계 후 구현을 시작하고 나머지 20%는 실제 코드를 작성하면서 완성하는 연습이 필요합니다.