한 엔지니어가 PR 페이지를 네 번째로 새로 고쳤다. 새로운 댓글이 달리고, 추가 검토자가 태그됐다. 변경 사항은 며칠 전부터 준비됐지만 승인 과정은 멈춰 있다.

산업 전반에서 흔히 볼 수 있는 장면이다. 코드는 15분 만에 작성되지만 승인까지 15일이 걸린다. 이 과정의 불만은 품질이나 안전성에 대한 이견에서 비롯되지 않는다. 엔지니어는 단순한 기능을 배포하려 하지만, 댓글 조율, 검토, 정렬 회의, 상태 스레드 사이에서 길을 잃는다.

PR이 기능 개발보다 논의에 더 많은 시간을 소비하는 장면을 본 경험이 있다면, 대규모 기업에서 절차가 조용히 만들어내는 비용을 목격한 것이다. 거버넌스는 ‘좋은 의도’에서 출발한다. 명확성을 확보하고 품질을 보호한다. 그러나 일정 수준을 넘어서면 소유권이 희석되고 실행 속도가 느려지며 사기가 떨어진다.

소프트웨어 기업은 구성원이 무관심해졌기 때문에 느려지는 것이 아니다. 소유자, 검토자, 위원회로 책임이 확산되고, 어떤 작업이든 추진하는 데 필요한 부담이 분기마다 커지기 때문에 느려진다. 리더가 직면한 과제는 명확성과 속도를 동시에 높일 수 있도록 거버넌스를 지속적으로 조정하는 일이다.

확대되는 소유권의 함정

엔지니어 규모가 수백 명을 넘기 시작하는 기업에서 비슷한 패턴이 반복된다. 초기에는 소유권이 명확해 속도가 빠르다. 그러다 규모가 커지면 새로운 압력이 생긴다. 배포로 장애가 발생하면 리더십은 감독 단계를 추가한다. 보안 취약점이 프로덕션에 유입되면 모든 변경에 보안 검토가 요구된다.

각 대응은 개별적으로 보면 합리적이다. 문제는 기업이 제거 없이 계속해서 새로운 단계를 추가할 때 발생한다. 아키텍처 검토 위원회와 출시 준비 체크리스트는 정비 없이 축적되며 주요 시니어 인력이 모두 포함되는 방식으로 확장된다. 근본적인 원인은 종종 감정적 요인이다. 눈에 띄는 사고가 발생하면 불안을 완화하기 위해 여러 승인 단계를 추가하는 과도한 대응이 발생한다. 품질팀은 속도를 높이는 것보다 위험을 차단하는 데 보상을 받는다. 절차를 보유하는 것이 관리 역량의 상징이 된다.

약 2,000개의 고활성 오픈소스 저장소에서 50만 건 이상의 깃허브 기록을 분석한 학술 연구에서는 눈에 띄는 결론이 나타났다. 소유자가 10명 이상인 저장소는 소유자가 1~2명인 저장소보다 변경 병합에 3배 이상 더 오래 걸렸다. 소유권이 넓어질수록 책임은 얇아진다. 각 검토자는 다른 사람이 문제를 발견해줄 것이라 가정한다. 병합 시간은 악화하지만 품질은 그대로다.

운영 준비 검토가 열릴 때 시니어 엔지니어와 기술 리더가 모두 초대돼 10~15명이 참석하는 정례 회의가 되는 상황을 떠올려보면 된다. 회의가 커질수록 의사결정은 더 느려진다. 그러나 실제 승인 책임을 가진 한 명의 시니어 엔지니어로 축소하면 아무 문제도 발생하지 않는다. 책임이 명확할 때 신중한 판단이 나오지만, 책임이 분산되면 ‘누군가가 대신 챙기겠지’라는 가정이 생긴다.

절차는 진화해야…굳어져서는 안 된다

팀은 한때 유용했던 규칙이 전통이 되고, 결국 장벽이 되는 함정에 빠진다. 특정 승인 절차가 왜 존재하는지 물으면 대답이 순환적이다. ‘원래부터 그렇게 해왔기 때문’이다.

좋은 거버넌스는 과거가 아니라 현재 필요에 맞춰야 한다. 모든 절차적 관문에는 ‘어떤 위험을 줄이기 위한 단계인지’가 명확히 설명돼야 한다. ‘원래 그래왔다’라는 답만 존재한다면 그 단계는 재검토 대상이다.

가장 성공적인 엔지니어링 문화는 절차 폐기 메커니즘을 내장한다. 새로운 절차에는 항상 만료일을 설정한다. 6개월 또는 12개월 이후 자동 폐기되며, 필요성을 입증할 데이터가 있을 때만 재승인된다. 모든 규칙에는 문서화된 소유자와 한 문장의 근거가 필요하다. 현재 팀이 이유를 설명하지 못한다면 그 절차는 폐기해야 한다.

속도와 소유권을 높이는 다섯 가지 실천 방안

다음은 거버넌스를 정교하게 유지하고 절차를 민첩하게 유지하는 실질적 방법이다.

진짜 책임을 지는 사람만 소유자로 지정하기

중요 프로젝트에서는 결과에 실제로 책임을 지는 2~3명만 소유자로 지정한다. 병합 지연과 검토 지연을 거버넌스 건강 지표로 추적한다. 아키텍처 경계를 기업 경계와 일치시키는 방식으로 팀 간 조율이 적은 구조를 설계한다.

저위험 작업이 빠르게 흐를 수 있는 경로 만들기

모든 변경이 동일한 위험을 가지는 것은 아니다. 문서 수정, 테스트 변경, 되돌릴 수 있는 구성 변경 등은 단일 검토 승인, 셀프 서비스 배포, 자동 스캔을 통해 빠르게 진행하도록 허용한다. 고위험 변경의 예외 기준도 명확히 한다.

검토자 범위를 작고 목적 있게 유지하기

대다수 변경은 직접적 맥락을 가진 2~3명만 검토자가 되도록 한다. 광범위한 가시성은 새로운 아키텍처 패턴 도입이나 기업 간 정렬이 필요한 경우에만 예외적으로 적용한다. 이런 경우 아키텍처 결정 기록(ADR) 같은 문서로 정보를 공유해 모두의 승인이 필요하지 않도록 한다. 댓글 기한은 며칠 단위로 설정하고 최종 결정자를 명확히 한다.

변경마다 단일 책임 병합자를 지정하기

여러 검토자가 필요하더라도 병합 결정과 일정은 한 사람이 책임진다. 합의가 아니라 기한 기반 결정 구조를 도입해 무기한 대기 상황을 방지한다.

에스컬레이션을 갈등이 아니라 효율로 다루기

팀의 SLA를 넘겨 검토가 지연되면 리드나 아키텍트에게 즉시 에스컬레이션하도록 장려한다. 에스컬레이션은 비난이 아니라 좋은 운영 습관이다.

불필요한 절차가 사람에게 미치는 문화적 손실

비효율적 거버넌스의 가장 치명적인 영향은 속도 저하가 아니라 사람에게 미치는 피해다.

유능한 엔지니어는 과도한 검토 계층이 쌓인 기업에서 점차 활력을 잃는다. 기능 하나를 출시하는 데 수개월이 걸리고, 여러 이해관계자의 피드백에 의해 초기 아이디어가 사라진다. 코드가 배포될 때는 처음 만든 사람이 알아보지 못할 정도로 변해 있다.

이 지점에서 엔지니어는 더 이상 영향력 최적화가 아니라 ‘승인 통과’를 목표로 일한다. 조율 비용이 너무 높아지면서 세련된 해결책이나 야심 있는 제안을 포기한다. 새로운 것을 만드는 빌더가 아니라 누군가의 설계를 수행하는 하청 구조로 전락한다.

혁신 정신을 가장 빠르게 말살하는 방법은 ‘정렬 과정’을 ‘창의적 성과’보다 더 많이 보상하는 것이다. 엔지니어가 해결책을 만들고 검증하는 시간보다, 사전 회의 준비·이메일 정리·발표 자료 정리에 더 많은 시간을 쓰게 된다면 인센티브 체계가 뒤집힌 것이다. 가장 뛰어난 인력부터 떠난다.

대규모 팀이 소규모 팀처럼 움직이 방법

탁월한 기업은 확장하면서도 소규모 팀의 속도를 유지한다. 핵심 원칙은 다음과 같다. 신뢰할 사람을 채용하고, 보안 요구사항·아키텍처 원칙·컴플라이언스 기준 등의 명확한 경계만 설정한 뒤, 그 안에서는 팀이 자율적으로 일하도록 한다.

팀 구조는 조율 비용을 최소화하도록 설계한다. 시스템 경계와 팀 경계를 일치시켜 팀이 독립적으로 빌드·테스트·배포할 수 있도록 한다. 아키텍처 소유권이 기업 소유권과 일치하면 조율이 줄고 배포 속도가 올라간다.

자동화를 통해 가장 안전한 경로가 가장 쉬운 경로가 되도록 만든다. 예를 들어 자동 스캐닝, 감사 로그 등 주요 보안 검사를 배포 과정에 기본 내장해 조용히 실행되도록 한다. 이렇게 하면 보안을 낮추지 않으면서도 속도가 빨라진다.

새로운 승인 절차를 추가하기 전에 문제의 원인이 기술 부채, 약한 테스트, 부서진 아키텍처는 아닌지 먼저 따져야 한다. 시스템이 취약하면 사람은 두려워지고, 두려움은 방어적 절차를 쌓게 만든다. 근본적인 시스템을 고치는 것이 검토 단계를 더 추가하는 것보다 낫다.

거버넌스가 너무 약할 때

목표는 무절차 상태가 아니다. 성숙한 시스템에는 아키텍처 일관성, 고위험 변경에 대한 보안 검토, 규제 환경에서의 컴플라이언스 절차가 반드시 필요하다. 거버넌스 부족의 신호는 동일 사고의 반복, 비일관적 결정으로 인한 기술 부채 축적, 시스템 전반을 고려하지 못한 엔지니어의 독단적 결정 등이다. 팀 성숙도에 따라 거버넌스를 맞추고, 판단 능력이 향상되면 제약을 줄이는 구조로 설계해야 한다.

지속적인 감사

거버넌스 검토는 정례화돼야 한다. 6개월마다 현재 존재하는 모든 승인 단계, 반복 회의, 절차적 관문을 나열한다. 그리고 다음 질문을 던진다. “지금 다시 시작한다면 이 절차를 만들 것인가?” 약 3분의 1은 답이 ‘아니다’가 된다.

무질서한 거버넌스를 인수한 경우, 먼저 고통을 계량화하는 것부터 시작한다. 병합 시간, 검토 지연, 엔지니어가 코딩보다 검토 대기에서 보내는 시간 등을 추적한다. 그런 다음 ‘신호 대비 잡음 비율’이 가장 낮은 절차부터 제거한다. 대부분 문제를 발견하지 않으면서 지연만 만드는 절차다.

규제 환경에서 법적으로 요구되는 절차가 아니라, 재량적 절차를 우선적으로 줄이는 데 초점을 맞춘다.

속도와 형식을 선택하는 기로에서

거버넌스를 적정 수준으로 유지하는 데 가장 어려운 점은 ‘선의로 요구하는 사람’에게 아니라고 말하는 일이다. 데이터베이스 변경을 모두 검토하겠다는 시니어 아키텍트는 데이터 무결성을 정말로 걱정한다. 하지만 ‘걱정’이 항상 ‘가치’가 되는 것은 아니다.

소프트웨어 기업은 살아 있는 시스템이다. 거버넌스는 코드와 문화만큼이나 빠르게 진화하고 축소되고 적응해야 한다. 얼마나 많은 절차를 추가할지 질문하는 것이 아니라, 그 규칙이 지금도 존재할 가치가 있는지를 물어야 한다.

절차는 빌더를 돕기 위해 존재한다. 절차 자체가 일이 되는 순간, 일은 망가지기 시작한다. 효과적인 리더는 거버넌스 시스템의 규모를 자랑하지 않는다. 팀의 속도와 자신감을 자랑한다.

진정한 소유권은 ‘부여되는 것’이 아니라 보호되는 것이다.
dl-itworldkorea@foundryco.com