한 줄 정의
유능한 팀 만들기란 아키텍트가 개발 팀과 양방향으로 협업하며 적절한 경계와 지침을 제공해, 팀의 생산성과 자율성을 동시에 끌어올리는 리더십 기법입니다.
쉽게 말하면
좋은 아키텍처를 그리는 것과 그 아키텍처가 실제로 작동하게 만드는 것은 다른 문제입니다. 종이에 완벽한 다이어그램을 그려놓고 개발 팀에 던져 놓으면, 십중팔구 의도한 대로 구현되지 않습니다.
아키텍트의 진짜 일은 개발 팀을 이끄는 것입니다. 너무 세세하게 통제하면 개발자들이 떠나고, 손을 놓으면 시스템이 산으로 갑니다. 그 사이에서 적절한 “방(room)“의 크기를 찾아주는 것이 유능한 아키텍트의 역할입니다.
왜 중요한가?
- 해결하는 문제: 아키텍처 결정과 실제 구현 사이의 단절을 메우는 문제입니다. 폭포수식 단방향 전달 모델은 거의 작동하지 않습니다.
- 이게 없다면: 아키텍트와 개발 팀이 분리되면 아키텍처의 목표가 달성되는 경우가 거의 없습니다. 개발 팀은 의도를 모르고, 아키텍트는 현장의 제약을 모르는 채로 각자 일하게 됩니다.
핵심 내용
협업: 단방향 전달에서 양방향 협업으로
전통적인 모델은 단방향입니다. 아키텍트가 비즈니스 요구사항에서 아키텍처 특성을 추출하고, 패턴과 스타일을 선택하고, 논리적 컴포넌트를 만든 뒤 그 결과물을 개발 팀에 넘깁니다. 개발 팀은 이를 받아 클래스 다이어그램을 만들고 UI를 구축하고 코드를 작성합니다.
flowchart LR A[아키텍트] -->|단방향 전달| B[장벽] B --> C[개발자] A -.- A1[아키텍처 특성/스타일/컴포넌트 구조] C -.- C1[클래스 설계/UI/소스 코드]
이 모델의 문제는 화살표 방향에 있습니다. 아키텍트의 결정이 개발 팀에 항상 전달되지도 않고, 개발 팀이 아키텍처를 변경할 때 그것이 아키텍트에게 다시 전달되는 일은 거의 없습니다.
해결책은 둘 사이의 장벽을 허물고 하나의 가상 팀 으로 묶는 것입니다.
flowchart LR A[아키텍트] <-->|리더십 / 멘토링| C[개발자] A --- COMP[컴포넌트 구조] A --- STYLE[아키텍처 스타일] C --- IMPL[클래스 설계 / UI / 코드] COMP -.- IMPL
요즘은 폭포수가 아니라 반복(iteration)마다 아키텍처가 진화합니다. 따라서 아키텍트와 개발 팀의 긴밀한 협업이 성공의 필수 조건이 됩니다.
제약조건과 경계: ‘방’의 크기 정하기
아키텍트의 역할 중 하나는 개발 팀이 아키텍처를 구현할 때 지켜야 하는 제약조건(constraint) 들을 작성해서 전달하는 것입니다. 이 제약조건들은 개발 팀이 그 안에서 일할 ‘방(room)‘의 경계 를 규정합니다.
| 경계 | 결과 |
|---|---|
| 너무 엄격함 | 도구·라이브러리·관행 접근 차단 → 불만 → 개발자 이탈 |
| 너무 느슨함 | 모든 결정을 팀이 떠안음 → 끝없는 PoC → 좌절 |
| 적당함 | 자율성과 지침이 균형 → 유능한 팀 |
너무 엄격하면 방이 작아져 필요한 도구에 접근할 수 없게 되고, 너무 느슨하면 방이 너무 커져 모든 중요한 결정을 개발 팀이 스스로 내려야 합니다. 이 경우 사실상 개발 팀이 아키텍트 역할까지 떠안게 됩니다.
아키텍트 성향 세 가지
경계 설정 방식에 따라 아키텍트의 성향은 크게 세 가지로 나뉩니다.
| 성향 | 경계 | 결과 |
|---|---|---|
| 통제광 (control-freak) | 너무 엄격 | 개발자 이탈, 존경심 상실 |
| 탁상공론 (armchair) | 너무 느슨 | 팀 혼란, 생산성 저하 |
| 유능한 (effective) | 적절 | 협업과 자율성의 균형 |
통제광 아키텍트
소프트웨어 개발 프로세스의 모든 세부 사항을 통제하려 듭니다. 결정이 지나치게 저수준(low-level)이라 그 결과 경계가 너무 엄격해지고 제약조건이 너무 많아집니다.
예를 들어 오픈소스나 서드파티 라이브러리 사용을 막거나, 명명 규칙·클래스 설계·메서드 길이까지 제약을 가합니다. 심지어 개발 팀이 구현할 의사 코드를 직접 작성해 개발자에게서 프로그래밍이라는 예술(art)을 빼앗기도 합니다.
특히 개발자에서 아키텍트로 막 전환한 사람이 빠지기 쉬운 함정입니다. 클래스 다이어그램을 직접 만들고 설계 패턴을 선택하는 데 익숙하기 때문입니다. 하지만 그것은 개발자의 몫이지 아키텍트의 몫이 아닙니다. 아키텍트의 역할은 논리적 컴포넌트를 정의하고 컴포넌트들이 어떻게 상호작용하는지를 결정하는 것까지입니다.
탁상공론 아키텍트
코딩한 지 아주 오래되었거나, 한 번도 해보지 않은 채로 아키텍처를 만들 때 구현 세부 사항을 고려하지 않는 아키텍트입니다. 보통 개발 팀과 단절되어 있고, 초기 다이어그램을 완성한 후에는 다음 프로젝트로 넘어가 버립니다.
징후는 다음과 같습니다.
- 비즈니스 도메인이나 사용 기술을 완전히 이해하지 못한다
- 소프트웨어 개발에 대한 실무 경험이 부족하다
- 특정 아키텍처 솔루션 구현에 따르는 영향(복잡성, 유지보수, 테스트 등)을 고려하지 않는다
일부러 탁상공론이 되려는 사람은 거의 없습니다. 너무 많은 프로젝트나 팀에 관여하다 기술과 도메인의 접점을 잃어 ‘자신도 모르게’ 그렇게 됩니다.
유능한 아키텍트
적절한 제약조건과 경계를 만들고, 팀원들이 서로 잘 협력하도록 보장하며, 올바른 수준의 지침을 제공합니다. 팀이 올바른 도구와 기술을 갖추게 하고, 개발 팀과 목표 사이에 놓인 장애물들을 제거합니다.
무엇보다도 개발 팀과 긴밀히 협업하고 그들의 존경을 얻어야 합니다.
어느 정도까지 관여할 것인가? — 탄력적 리더십
탄력적 리더십(Elastic Leadership)은 로이 오셔로브가 주창한 개념으로, 상황에 따라 관여도를 조절하는 리더십입니다. 다음 다섯 가지 요인이 관여도를 결정합니다.
| 요인 | 평가 | 관여도 영향 |
|---|---|---|
| 팀 친숙도 | 서로 잘 모름 ↔ 잘 앎 | 모를수록 더 관여 |
| 팀 규모 | 큼(>12) ↔ 작음(≤5) | 클수록 더 관여 |
| 전반적 경험 | 주니어 多 ↔ 시니어 多 | 주니어 多일수록 더 관여 |
| 프로젝트 복잡도 | 높음 ↔ 낮음 | 복잡할수록 더 관여 |
| 프로젝트 기간 | 짧음(2개월) ↔ 김(2년) | 짧을수록 덜 관여 (긴 프로젝트는 긴장감이 떨어져 더 관여 필요) |
각 요인은 저울의 바늘을 20점만큼 좌(+)/우(-)로 움직입니다. 양수는 통제광 방향(관여 많음), 음수는 탁상공론 방향(관여 적음)입니다.
시나리오 1: 잘 알려진 작은 숙련 팀, 단순 단기 프로젝트
| 요인 | 평가 | 점수 |
|---|---|---|
| 팀 친숙도 | 신규 팀원들 | +20 |
| 팀 규모 | 소규모(4명) | -20 |
| 전반적 경험 | 모두 숙련됨 | -20 |
| 프로젝트 복잡도 | 비교적 단순 | -20 |
| 프로젝트 기간 | 2개월 | -20 |
| 총점 | -60 (탁상공론 쪽) |
이런 상황에서는 아키텍트가 일상에 거의 관여하지 말고 촉진자(facilitator) 역할만 하는 게 좋습니다. 질문에 답하고 진행 상황만 확인합니다.
시나리오 2: 친한 대규모 주니어 팀, 복잡한 6개월 프로젝트
| 요인 | 평가 | 점수 |
|---|---|---|
| 팀 친숙도 | 서로 친함 | -20 |
| 팀 규모 | 대규모(12명) | +20 |
| 전반적 경험 | 대부분 주니어 | +20 |
| 프로젝트 복잡도 | 높음 | +20 |
| 프로젝트 기간 | 6개월 | -20 |
| 총점 | +20 (통제광 쪽) |
이때는 멘토링과 코칭에 상당히 관여해야 합니다. 단, 팀을 방해하는 정도는 아니어야 합니다.
흥미로운 점은 단기 프로젝트일수록 덜 관여한다 는 것입니다. 직관과 반대일 수 있는데, 단기에는 팀이 이미 강한 긴박감을 느끼고 있으므로 통제광 아키텍트는 방해만 됩니다. 반대로 장기 프로젝트는 긴장감이 풀려 점심시간이 길어지고 휴가 계획이 들어오기 때문에, 아키텍트가 일정과 우선순위를 챙겨야 합니다.
팀의 이상 징후
팀이 너무 큰지 아닌지를 판단하는 세 가지 신호가 있습니다.
프로세스 손실 (Process Loss)
프레드 브룩스의 『The Mythical Man-Month』에서 나온 개념으로, 브룩스의 법칙(Brooks’s Law) 이라고도 알려져 있습니다.
프로젝트에 사람을 더 투입할수록 프로젝트를 수행하는 시간이 더 길어진다.
flowchart LR P1[👤] --> GP[집단 잠재력] P2[👤] --> GP P3[👤] --> GP P4[👤] --> GP GP --> AP[실질 생산성] GP --> PL[프로세스 손실]
집단 잠재력(group potential)은 팀 모든 구성원이 함께 노력한 결과로 정의되지만, 실질 생산성(actual productivity)은 항상 잠재적 생산성(potential productivity)보다 낮습니다. 그 차이가 프로세스 손실입니다.
백엔드 관점의 신호
- 머지 충돌이 잦음: 팀원들이 동일한 코드를 수정하면서 서로의 작업을 방해하고 있다는 징후입니다.
- 회피책: 병렬 처리할 수 있는 영역을 찾아 팀원들이 각각 다른 서비스나 애플리케이션 영역에서 작업하도록 분리합니다. 마이크로서비스가 매력적인 이유 중 하나입니다.
다원적 무지 (Pluralistic Ignorance)
모든 사람이 마음속으로는 어떤 규범을 거부하지만, 남들이 다 아는 명백한 무언가를 자신만 모른다고 생각해서 그 규범에 동의하는 현상입니다.
한스 크리스티안 안데르센의 동화 벌거벗은 임금님 이 대표 사례입니다. 벌거벗은 임금에게 “옷이 멋지다”고 모두가 칭찬한 것은, 자격 없는 사람에게는 옷이 보이지 않는다고 들었기 때문입니다.
백엔드 관점의 사례
대규모 팀이 두 원격 서비스 사이에 메시징을 쓰자고 결정했다고 합시다. 보안 방화벽이 있어서 이게 어리석은 아이디어라고 생각하는 팀원도 있지만, 모두 동의하니 자신만 잘못 알고 있는 것 같아 입을 다뭅니다. 더 작은 팀이었다면 이의를 제기해 REST 같은 다른 프로토콜을 채택했을 것입니다.
해법은 아키텍트가 회의 중 표정과 몸짓을 관찰해 의심을 숨기는 사람을 찾고, 회의를 잠시 멈춰 그 사람의 의견을 끌어내는 것입니다. 그가 틀렸더라도 발언을 지지해 주어야 안전한 환경이 만들어집니다.
책임 확산 (Diffusion of Responsibility)
팀이 커질수록 의사소통이 나빠집니다. 누가 무엇을 책임지는지 혼란스럽고 업무가 누락되면, 팀이 너무 크다는 신호입니다.
시골길에서 고장 난 차를 본 사람은 멈춰 도와줄 가능성이 높습니다. 하지만 도시 고속도로에서는 수천 대가 지나가도 아무도 멈추지 않습니다. “다른 누군가가 이미 도와줬겠지”라고 생각하기 때문입니다.
체크리스트 활용
체크리스트(checklist)는 모든 작업이 빠짐없이 처리되었는지 확인하는 훌륭한 수단입니다. 항공기 조종사와 외과의처럼 생사가 걸린 직업에서 검증된 도구입니다.
다만 핵심은 언제 활용하고 언제 사용하지 말아야 할지 를 아는 것입니다.
체크리스트로 만들면 안 되는 것
- 절차적 순서가 있는 의존적 작업: 양식이 제출되지 않으면 테이블을 검증할 수 없는 식의 흐름은 체크리스트가 아닙니다.
- 단순하고 익숙한 프로세스: 거의 실수 없이 실행할 수 있는 일은 체크리스트로 만들 필요가 없습니다.
체크리스트로 만들기 좋은 것
정해진 절차적 순서나 의존이 없고, 사람들이 단계를 자주 건너뛰거나 실수하는 프로세스입니다.
| 체크리스트 종류 | 목적 | 변동성 |
|---|---|---|
| 개발자 코드 완성 | ’done의 정의’ 공식화 | 낮음 |
| 단위/기능 테스트 | 포괄적 테스트 보장 | 중간 |
| 소프트웨어 릴리스 | 빌드/배포 실패 방지 | 가장 큼 |
개발자 코드 완성 체크리스트 예시
자동화 도구에 포함되지 않은 코딩·포매팅 표준, 자주 간과되는 항목(무시된 예외 등), 프로젝트별 표준, 팀의 특별 지침 등을 담습니다.
[ ] 코드 정리 및 코드 포매팅 기능 실행
[ ] 커스텀 소스 유효성 점검 도구 실행
[ ] 모든 갱신에 대해 감사(audit) 로그가 기록되었는지 확인
[ ] 무시된 예외가 남아 있는지 확인
[ ] 하드코딩된 값들을 찾아서 상수로 변환
[ ] 퍼블릭 메서드들만 setFailure()를 호출하는지 확인
[ ] 서비스 API 클래스들에 @ServiceEntrypoint 적용
자동화 가능한 항목은 자동화 후 체크리스트에서 제거해야 합니다. 신호 대 잡음비를 개선하기 위해서입니다.
체크리스트가 무용지물이 되는 이유
가장 어려운 부분은 개발자가 실제로 사용하게 만드는 것입니다.
항목 논리를 팀이 납득하게 하고, 포함·제외 항목을 팀이 직접 결정해 주인의식을 심는 게 1차 방법입니다.
그래도 안 되면 호손 효과 를 적용해볼 수 있습니다.
호손 효과 (Hawthorne effect)
“검증하겠다”고 공지만 해도 행동이 바뀌는 현상을 활용합니다. 일일이 확인할 필요 없이 가끔 불시에 점검하는 정도로 충분합니다.
지침 제공
아키텍트가 팀을 더 유능하게 만드는 또 다른 방법은 설계 원칙 을 통해 지침을 제공하는 것입니다.
설계 원칙은 개발자가 어떤 결정은 자기 권한으로 내려도 되고 어떤 결정은 아키텍트와 합의해야 하는지를 가르는 기준선이 됩니다. 이 기준선을 잘 전달하는 일이 성공적인 팀을 만드는 비결 중 하나입니다.
라이브러리 도입 전 두 가지 질문
개발 팀은 보통 어떤 라이브러리는 괜찮고 어떤 것은 안 되는지, 결정을 직접 내려도 되는지를 궁금해합니다. 이런 질문에 답하는 첫 단계는 개발자가 제안한 라이브러리에 다음 두 질문을 던지는 것입니다.
- 제안된 라이브러리와 시스템의 기존 기능성 사이에 중복되는 부분은 없는가?
- 제안된 라이브러리를 사용해야 하는 타당한 이유 는 무엇인가?
첫 질문은 새 라이브러리가 제공하는 기능을 기존 라이브러리나 코드로 충족할 수 있는지 확인하게 합니다. 건너뛰면 기능 중복이 쌓이고, 대규모 프로젝트일수록 부채가 됩니다.
둘째 질문은 새 라이브러리가 정말 필요한지 자문하게 합니다. 개발자에게 기술적 명분 과 비즈니스적 명분 을 모두 요구하는 것이 좋습니다. 비즈니스 관점을 인식하는 계기가 됩니다.
비즈니스 정당화의 효과
한 자바 프로젝트에서 스칼라(Scala)를 도입하자고 강하게 주장하는 개발자가 있었습니다. 그의 주장이 너무 거세서 핵심 팀원 두 명이 떠나겠다고 할 정도였습니다. 아키텍트는 두 사람을 설득해 남게 한 뒤 스칼라 애호가에게 한 가지를 요구했습니다. “교육과 재작성에 드는 비용·예산·일정을 비즈니스적으로 정당화한다면 지지하겠다.”
다음 날 그는 “감사합니다”라고 말하며 두 가지를 깨달았다고 했습니다. 첫째, 스칼라 도입 시 비용·예산·일정은 늘지만 이득은 전혀 없다는 것. 둘째, 자신이 팀의 화합을 깨뜨리고 있었다는 것. 그 후 그는 팀에서 가장 뛰어난 구성원 중 하나가 되었고, 떠나려던 두 핵심 개발자도 남았습니다.
비즈니스 명분을 요구하는 것만으로 비즈니스 요구사항에 대한 인식이 높아지고, 더 나은 개발자가 되는 부수 효과까지 따라옵니다.
결정 권한을 그림으로 — 계층형 스택 예시
설계 원칙을 전달하는 또 하나의 방법은 개발 팀이 내릴 수 있는 결정과 내릴 수 없는 결정을 그림으로 보여주는 것입니다. 다음은 서드파티 라이브러리를 세 범주로 나눠 결정 권한을 차등 부여한 예시입니다.
flowchart TD SP[특수 목적<br/>PDF 렌더링, 바코드 스캔 등] --> D1[개발자가 결정함] GP[범용<br/>Apache Commons, Guava 등] --> D2[아키텍트가 승인함] FW[프레임워크<br/>Hibernate, Spring 등] --> D3[아키텍트가 결정함] style SP fill:#888,color:#fff style GP fill:#444,color:#fff style FW fill:#000,color:#fff
| 범주 | 정의 | 결정 절차 |
|---|---|---|
| 특수 목적 | PDF 렌더링, 바코드 스캔처럼 맞춤 개발할 정도는 아닌 특정 작업용 | 아키텍트와 상의 없이 개발 팀이 직접 결정 |
| 범용 | 언어 API를 감싼 래퍼(Apache Commons, Guava 등) | 개발자가 중복 분석과 추천 이유를 제시할 수 있고, 최종 승인은 아키텍트 |
| 프레임워크 | 영속성(Hibernate), 제어 역전(Spring) 등 애플리케이션 전체 계층/구조를 구성하는 매우 침습적(invasive) 라이브러리 | 전적으로 아키텍트의 책임. 개발 팀은 분석조차 수행하지 않음 |
세 범주는 어디까지나 예일 뿐 필요하면 더 세분화할 수 있습니다. 핵심은 아키텍트가 팀이 제안한 라이브러리를 적절한 범주에 분류해 승인 또는 기각하는 절차 자체를 명확히 해 두는 것입니다. 이렇게 하면 어느 결정이 자기 권한인지 개발자가 헷갈릴 일이 없어지고, 아키텍트는 침습도가 높은 결정에 시간을 집중할 수 있습니다.
비교 / 트레이드오프
통제 vs 자율의 스펙트럼
| 축 | 통제광 (+100) | 유능함 (0) | 탁상공론 (-100) |
|---|---|---|---|
| 결정 수준 | 메서드 길이까지 | 컴포넌트 경계까지 | 거의 없음 |
| 개발자 자율성 | 낮음 | 적절 | 과도 (혼란) |
| 팀 만족도 | 낮음 (이탈) | 높음 | 낮음 (좌절) |
| 적합 상황 | 거의 없음 (예외: 매우 미숙한 팀) | 대부분의 상황 | 거의 없음 |
체크리스트 적합도 매트릭스
| 작업 특성 | 체크리스트가 적합한지? |
|---|---|
| 절차적 의존 있음 | ❌ (프로세스 다이어그램) |
| 단순·익숙·실수 없음 | ❌ (불필요) |
| 항목이 많고 누락 잦음 | ✅ |
| 자동화 가능 | 자동화 후 제거 |
내 생각
프로세스 손실의 가장 가시적인 신호는 머지 충돌
브룩스의 법칙은 추상적이지만, 백엔드 팀에서는 한 리포지토리의 머지 충돌 빈도로 정량화할 수 있습니다. 충돌이 잦아지는 시점이 마이크로서비스 분리나 모노레포 내 모듈 분리를 검토할 신호입니다.
라이브러리 결정 계층은 사내 의존성 관리 정책으로 직결됨
특수목적·범용·프레임워크 분류는 그대로 의존성 도구의 정책으로 떨어집니다. Renovate나 Dependabot이 PR을 만들 때 카테고리에 따라 자동 머지 / 아키텍트 리뷰 필수 / 거버넌스 검토로 라우팅하면 추상 원칙이 자동화 가능한 형태가 됩니다.
더 알아볼 것
- Roy Osherove의 『Elastic Leadership』 읽기
- 사내 라이브러리 카테고리(특수목적/범용/프레임워크) 분류 기준 문서화
- PR 머지 충돌 빈도를 측정하는 GitHub Actions / 메트릭 대시보드 구축
- ADR 템플릿에 “반대 의견·우려” 섹션 추가
- 호손 효과를 체크리스트 운영에 어떻게 자연스럽게 녹일지 팀 회의
관련 개념
출처
- 소프트웨어 아키텍처 The Basics, Ch24 유능한 팀 만들기