기술이 아니라 약속이 우리를 묶는다

팀 결성의 첫 번째 실수 — 기술 호환성만 확인했다

슬렉스, slecs, 나. 셋이 처음 함께 일하기로 했을 때 우리가 맞춰본 건 기술 스택이었다. 풀스택 경험이 있는가, 클라우드 배포를 해봤는가, 서로의 코드를 읽을 수 있는가. 세 가지 다 충족됐고 그것만으로 팀이 될 수 있다고 믿었다. 스타트업 초기 팀 구성 글들이 거의 다 그렇게 말하고, 합리적인 판단처럼 보였다.

5개월이 지난 지금 돌아보면 그 판단은 절반만 맞았다. 기술 호환성은 팀을 시작하게 해줬지만 유지시키지는 못했다. 결제와 정산, 자동화 파이프라인을 실제로 운영하면서 진짜로 팀을 묶어준 것이 무엇인지가 점점 분명해졌다. 그건 기술이 아니었다. 그리고 이게 단순한 감상이 아닌 이유를 우리 도메인의 언어로 설명할 수 있게 됐다.

결제·정산 현장에서 팀 신뢰의 실패 비용은 즉각적이다

결제 시스템의 특성을 먼저 짚어야 한다. 정산 파이프라인은 새벽에도 돌고, 자동화 배치 작업은 사람이 없을 때 가장 많이 실패한다. 오류 하나가 복수의 가맹점 정산에 영향을 미치면 파급 범위는 시간이 지날수록 지수적으로 늘어난다. 우리 팀 기준으로 정산 오류를 발생 후 15분 이내에 잡으면 수동 보정 작업이 평균 40분이지만, 2시간을 넘기면 영향받은 트랜잭션 역추적과 재대사 작업에 반나절이 사라진다. 같은 버그인데 발견 시점 하나로 비용이 6배 이상 벌어진다.

이 맥락에서 팀 신뢰의 부재는 단순히 분위기가 나빠지는 문제가 아니다. 새벽 2시에 얼럿이 울렸을 때 지쳐있다고 솔직하게 말하지 못하는 팀원, 실수가 두려워서 오류 원인을 천천히 공유하는 사람, 판단을 번복하면 비난받을까 봐 잘못된 방향을 그냥 밀고 가는 구조 — 이런 것들이 기술 버그보다 더 크고, 더 느린 방식으로 시스템을 망가뜨린다. 초기에 겪었던 자동화 배치 실패 사례 하나가 딱 이 패턴이었다. 한 명이 "이 로직이 엣지 케이스에서 튈 수 있다"는 의심을 갖고도 말하지 않았다. 말하기 어려운 분위기여서가 아니라, 그때까지 우리가 그런 걸 꺼내놓는 습관을 아직 만들지 못했기 때문이었다. 오류는 다음 날 배치 실행 시 터졌고 보정 작업은 오전을 다 썼다.

5개월 동안 실제로 팀을 유지시킨 것들

기술이 아닌 것들이 먼저 보이기 시작한 건 프로젝트가 어려워졌을 때다. 버티게 만든 건 내가 얼마나 지쳐있는지 솔직하게 말할 수 있다는 것, 다른 사람이 막혔을 때 먼저 물어봐주는 것, 결정을 번복해도 서로 탓하지 않는 것이었다. 이것들이 작동하는 팀과 그렇지 않은 팀의 차이는 기술 역량 차이보다 훨씬 빨리 드러난다. 특히 인시던트 대응처럼 시간이 촉박하고 불확실성이 높은 상황에서는 더 그렇다.

구체적으로 우리 팀에서 이게 어떻게 나타났는지 말하면: 코드 리뷰에서 날카롭게 지적하더라도 사람을 문제 삼지 않는다는 규칙은 명문화된 게 아니라 몇 번의 대화를 거치면서 자연스럽게 형성됐다. 결제 로직에서 설계 실수를 찾았을 때 "이 부분 다시 봐야 할 것 같아"와 "왜 이렇게 짰어"는 기술적 내용이 동일해도 팀에 미치는 영향이 전혀 다르다. 전자는 문제를 수면 위로 끌어올리고, 후자는 다음번에 비슷한 의심을 입 밖으로 꺼내지 못하게 만든다. 소규모 팀에서 이 억압이 쌓이면 결국 탐지 지연으로 나타나고, 탐지 지연은 곧 정산 보정 비용으로 나타난다.

암묵적 약속이 운영 안정성으로 번역되는 방식

우리가 명시적으로 계약서에 쓴 건 없다. 그냥 대화 중에, 작업 중에 형성된 규칙들이다. 한 명이 잘 모르는 영역에 끼어들 때 판단하지 않는다. 늦는다고 할 때 이유를 추궁하지 않는다. 의견이 달라도 결론이 나면 그 방향으로 같이 간다.

이 규칙들이 현장에서 어떻게 실제로 작동하는지를 가장 잘 보여주는 사례가 자동화 정산 모듈 리팩토링 방향 결정이었다. 세 명 모두 접근 방식이 달랐고, 논의가 두 시간을 넘겼다. 결론이 난 방향이 내 의견과 달랐다. 그런데 방향이 정해진 이후 나는 이견을 계속 꺼내지 않았고, 실행에 온전히 참여했다. 이게 당연한 것처럼 들리지만, 결론이 났는데도 동의하지 않은 쪽이 소극적으로 참여하거나 실패했을 때 "내가 뭐라고 했어"를 꺼내는 팀을 이전 직장에서 여러 번 봤다. 그런 팀은 기술 스택과 무관하게 느리고, 인시던트 상황에서 특히 취약하다.

기술은 교체되지만 약속이 깨지면 더 오래 걸린다

기술은 계속 바뀐다. 우리가 지금 쓰는 스택도 2년 뒤에는 다를 가능성이 높다. 정산 파이프라인의 언어가 바뀌든, 메시지 큐 솔루션이 교체되든, 클라우드 프로바이더를 이전하든 — 기술 결정은 언제나 번복 가능하다. 번복 비용이 클 수는 있지만 불가능하지는 않으며, 계획을 세울 수 있는 종류의 비용이다.

반면 팀 내 신뢰와 암묵적 약속은 한 번 깨지면 회복하기 훨씬 어렵다. 이것이 핵심 트레이드오프다. 기술 선택에서 우리는 "더 나은 옵션이 나오면 언제든 바꿀 수 있다"는 유연성을 전제로 결정을 내린다. 팀 관계에서는 그 유연성이 훨씬 좁다. 신뢰가 손상된 팀은 코드베이스를 리팩토링하는 것보다 회복이 느리고, 그 느림이 시스템 가용성과 오류 탐지 속도에 직접 영향을 준다. 새 기술을 같이 배우는 분위기, 한 명이 새로운 방향을 제안할 때 우선 들어보는 태도 — 이것들이 기술 선택 자체보다 팀의 장기 적응력을 결정한다. 우리가 내년에 정산 엔진을 다시 짜야 하는 상황이 와도, "이 방향이 맞지 않았다"고 두려움 없이 말할 수 있는 팀이라면 기술 선택 실수는 회복 가능하다. 반대는 성립하지 않는다.

지금 당장 적용할 수 있는 세 가지 실행 원칙

팀을 꾸리거나 함께 일하는 구조를 점검할 사람들에게 우리 5개월이 줄 수 있는 구체적인 시사점은 이렇다.

첫째, 팀을 구성할 때 먼저 물어야 할 질문 하나를 바꿔라. "이 사람과 기술 방향이 맞는가"보다 "이 사람과 잘못됐을 때도 같이 일할 수 있는가"를 먼저 확인해라. 특히 결제·정산처럼 오류가 즉각적인 재무 영향을 만드는 도메인에서는, 인시던트 발생 시 지체 없이 솔직하게 말할 수 있는 사람인지가 기술 역량만큼 중요한 채용 기준이다. 기술은 온보딩으로 맞출 수 있지만 이 질문의 답이 '아니오'라면 기술 호환성은 의미 없다.

둘째, 암묵적 약속을 한 번은 명시화해라. 계약서가 아니어도 된다. 짧은 텍스트 문서 하나, 팀 채널 고정 메시지 하나로 충분하다. "코드 리뷰에서는 코드를 지적하고 사람을 지적하지 않는다", "결론이 난 방향에 이견이 있더라도 실행 단계에서는 함께 간다", "지쳐있다고 말하는 걸 약점으로 취급하지 않는다" — 이런 것들을 한 번이라도 명시해두면, 암묵적으로만 존재할 때보다 지켜질 확률이 높아진다. 말로 꺼낸 약속은 어길 때 마찰이 생기고, 그 마찰이 규범을 유지시킨다.

셋째, 인시던트 사후 회고를 팀 신뢰 점검 도구로 써라. 기술적 원인 분석만 하지 말고, "왜 이 의심을 먼저 말하지 않았는가"를 정기적으로 물어라. 정산 오류를 늦게 잡는 팀은 대부분 기술이 없어서가 아니라 말하기 어려운 분위기 때문에 탐지가 지연된다. 그 분위기를 회고 데이터로 만드는 것이 모니터링 알럿을 추가하는 것만큼 시스템 안정성에 기여한다. 우리가 배치 실패 이후 도입한 것 중 가장 효과적이었던 건 새 얼럿 룰이 아니라, "의심이 들면 바로 올린다, 틀려도 괜찮다"는 한 줄짜리 팀 원칙이었다.

— by mings