"우리 팀, 뭔가 삐걱대는데 정확히 뭐가 문제인지는 모르겠어요."
이런 느낌, 한 번쯤 받아보셨나요? 솔직히 말하면 저도 그랬습니다. 좋은 팀의 조건을 백 줄로 설명하는 글은 많은데, 막상 우리 팀에 대입하면 잘 안 와닿습니다.
안녕하세요, 자바파커입니다. 그래서 오늘은 방향을 뒤집어 보겠습니다. "어떻게 하면 개발팀을 가장 확실하게 망칠 수 있을까?"
결론부터 말씀드리면 — 아래 7가지는 전부 반어법입니다. 「How to Write Unmaintainable Code」가 그랬듯이, 망치는 방법을 정확히 알면 거꾸로 읽는 순간 그게 곧 좋은 팀 체크리스트가 됩니다. 내 팀에 몇 개나 해당하는지 세어보면서 읽어주세요.
1. 코드 리뷰를 "통과 의례"로 만든다
가장 빠른 방법입니다. 리뷰어는 PR을 열자마자 "LGTM 👍" 만 답니다. 읽지는 않습니다. 반대로 어떤 리뷰어는 들여쓰기와 변수명만 30개씩 지적하고 정작 설계 결함은 그냥 통과시킵니다.
실제로 벌어지는 일: 리뷰가 품질 장치가 아니라 요식 행위가 됩니다. 버그는 그대로 배포되고, 리뷰 시간만 길어지고, 작성자는 "어차피 안 읽을 거" 라며 점점 큰 PR을 던집니다.
반대로 하면 — 리뷰는 "맞고 틀림"이 아니라 "이 코드를 6개월 뒤의 내가 이해할 수 있는가" 를 묻는 자리입니다. 사소한 스타일은 린터·포매터에 위임하고, 사람은 설계와 의도에만 집중합니다. PR은 작게(300줄 이하), 리뷰는 24시간 안에.
2. 모든 결정을 "회의"로만 내린다
캘린더를 회의로 가득 채우세요. 비동기 문서는 쓰지 않습니다. 결정의 근거는 회의실 공기 중에 흩어지게 두고, 회의에 못 들어온 사람은 "왜 이렇게 됐는지" 영원히 모르게 합니다.
실제로 벌어지는 일: 집중 코딩 시간이 사라집니다. 같은 결정이 한 달 뒤 회의에서 다시 논의됩니다. 신규 입사자는 의사결정 히스토리를 따라잡을 방법이 없습니다.
반대로 하면 — 결정은 짧은 문서(ADR, 의사결정 기록) 로 남깁니다. "무엇을, 왜, 어떤 대안을 버렸는지" 다섯 줄이면 충분합니다. 회의는 문서로 안 되는 것만. 기록이 남으면 회의가 줄고, 회의가 줄면 코드를 짤 시간이 생깁니다.
3. 배포를 "영웅 한 명"에게 의존시킨다
배포는 그 사람만 할 수 있게 두세요. 절차는 그의 머릿속에만 있습니다. 자동화 제안이 나오면 "지금도 잘 되는데 굳이?" 라고 답하면 됩니다. 그 사람이 휴가 가면 팀 전체가 멈춥니다 — 이게 핵심입니다.
실제로 벌어지는 일: 버스 팩터(Bus Factor)가 1이 됩니다. 그 한 명이 병목이자 단일 장애점이 되고, 정작 본인은 번아웃됩니다.
반대로 하면 — 배포는 누구나 한 줄로 실행할 수 있는 스크립트/파이프라인이어야 합니다. "신규 입사자가 첫날 배포해볼 수 있는가?"가 좋은 기준입니다. 지식이 사람이 아니라 저장소에 있어야 팀이 무너지지 않습니다.
4. "바쁘다"는 이유로 문서를 안 쓴다
문서 쓸 시간에 코드를 한 줄 더 짜라고 하세요. 설정 방법, 장애 대응 절차, 도메인 용어 — 전부 특정 사람들의 머릿속(트라이벌 날리지)에만 둡니다. 물어보면 알려주니까 괜찮다고 합니다.
실제로 벌어지는 일: 같은 질문이 슬랙에서 매주 반복됩니다. 그 사람이 퇴사하면 지식도 함께 퇴사합니다. "바빠서 문서 못 쓴다"던 팀이 문서가 없어서 더 바빠지는 악순환에 들어갑니다.
반대로 하면 — 문서는 완벽할 필요 없습니다. "같은 질문을 두 번 받으면 답을 문서로 남긴다" 한 가지 규칙이면 충분합니다. README, 트러블슈팅 노트, 용어집 — 짧아도 검색되면 가치 있습니다.
5. 장애가 나면 "범인"부터 찾는다
장애 회고의 첫 질문을 "누가 그랬어?" 로 시작하세요. 책임자를 특정하고, 다음부터 조심하라고 하면 됩니다. 그러면 다음부터 사람들은 실수를 숨기기 시작합니다 — 이게 진짜 효과입니다.
실제로 벌어지는 일: 비난 문화(Blame Culture)가 자리 잡으면 아무도 위험한 작업을 자원하지 않고, 작은 사고도 보고되지 않다가 큰 사고로 터집니다. 심리적 안전감이 0에 수렴합니다.
반대로 하면 — 비난 없는 포스트모템(Blameless Postmortem) 을 합니다. 질문은 "누가"가 아니라 "이 사람이 합리적으로 행동했는데도 왜 시스템이 사고를 허용했는가" 입니다. 사람을 고치는 게 아니라 시스템을 고칩니다.
6. 온보딩은 "알아서 적응"하게 둔다
신규 입사자에게 계정 몇 개 주고 "코드 보면서 익히세요" 라고 하세요. 첫 PR까지 2주가 걸리든 말든 방치합니다. 질문을 많이 하면 "이런 것도 몰라?" 라는 분위기를 풍기면 완벽합니다.
실제로 벌어지는 일: 입사 첫 한 달의 인상이 그 사람의 잔류를 결정합니다. 방치된 신규 입사자는 위축되고, 6개월 안에 떠납니다. 채용 비용이 통째로 날아갑니다.
반대로 하면 — "첫날 PR, 첫 주 배포" 를 목표로 온보딩 체크리스트를 만듭니다. 온보딩 문서는 신규 입사자가 직접 고치게 하세요 — 가장 정확한 문서 검수자는 방금 그 길을 걸은 사람입니다.
7. 기술 부채는 "나중에" 갚는다
리팩터링 제안이 나오면 "일단 기능부터, 그건 나중에" 라고 답하세요. 그 "나중"은 절대 오지 않습니다. TODO 주석만 쌓이고, 아무도 손대기 무서운 코드 영역이 생기면 성공입니다.
실제로 벌어지는 일: 기능 하나 추가하는 데 걸리는 시간이 분기마다 늘어납니다. 어느 순간 팀의 속도는 "현상 유지"에만 쓰입니다. 부채는 이자가 붙습니다.
반대로 하면 — 부채를 백로그에 티켓으로 가시화하고, 매 스프린트 일정 비율(예: 20%)을 상환에 고정 배정합니다. "갚을지 말지"가 아니라 "얼마씩 갚을지" 를 정하는 게 핵심입니다.
한눈에 보는 체크리스트
거꾸로 읽으면 그대로 좋은 팀의 조건입니다.
| # | 망치는 방법 | 좋은 팀은 이렇게 |
|---|---|---|
| 1 | LGTM 도장 찍는 리뷰 | 스타일은 자동화, 사람은 설계에 집중 |
| 2 | 모든 결정을 회의로 | 결정은 짧은 문서로 기록 |
| 3 | 영웅 한 명의 배포 | 누구나 한 줄로 배포 |
| 4 | 머릿속에만 있는 지식 | 두 번 받은 질문은 문서로 |
| 5 | 장애 = 범인 찾기 | 비난 없는 포스트모템 |
| 6 | 알아서 적응하는 온보딩 | 첫날 PR, 첫 주 배포 |
| 7 | 기술 부채는 나중에 | 백로그에 가시화 + 정기 상환 |
내 팀에 3개 이상 해당한다면, 그건 개인의 문제가 아니라 시스템의 신호입니다. 사람을 다그치기 전에 위 표의 오른쪽 칸을 한 줄씩 도입해보세요.
💡 요즘은 이 안티패턴들이 AI 도구와 만나 더 빨라지기도 합니다. 검토 없이 AI가 만든 PR을 LGTM으로 통과시키거나, AI에게 시킨 작업의 결정 근거를 아무도 기록하지 않으면 — 1번과 2번이 동시에 가속됩니다. 도구가 좋아질수록 위 표의 오른쪽 칸이 더 중요해집니다.
FAQ
Q1. 우리 팀은 7개 다 해당하는데, 어디부터 손대야 하나요?
5번(비난 문화)부터입니다. 심리적 안전감이 없으면 나머지 6개를 고치자는 말 자체가 안 나옵니다. 비난을 멈추는 것이 모든 개선의 전제 조건입니다.
Q2. 작은 스타트업이라 문서·프로세스 만들 여유가 없어요.
규모가 작을수록 버스 팩터(3번·4번) 리스크가 치명적입니다. 거창한 문서가 아니라 "두 번 받은 질문은 한 단락으로 남긴다" 한 줄 규칙부터 시작하세요. 비용은 거의 0입니다.
Q3. 리더가 아니라 팀원인데 바꿀 수 있나요?
바꿀 수 있습니다. 회고 때 "누가" 대신 "어떤 시스템이"라고 질문을 한 번 바꾸는 것, 받은 질문의 답을 슬랙이 아니라 README에 적는 것 — 권한 없이 할 수 있는 일부터가 변화의 시작입니다.
마무리
좋은 팀을 만드는 법은 추상적이지만, 팀을 망치는 법은 구체적입니다. 그래서 거꾸로 접근하는 게 때로 더 빠릅니다. 오늘 글에서 딱 하나만 가져가신다면 — "문제가 반복되면 사람을 다그치지 말고 시스템을 의심하라" 입니다.
여러분의 팀에는 위 7가지 중 몇 개가 있나요? 그리고 가장 고치고 싶은 건 몇 번인가요? 댓글로 남겨주시면 다음 글에서 그 항목을 더 깊게 다뤄보겠습니다.
다음에 또 뵙겠습니다. 자바파커였습니다.