두 개의 문, 하나의 게이트

온보딩 가드레일 (Onboarding guardrails)과 파워 유저의 마찰 (power-user friction)은 동일한 문제처럼 보이지만, 실제로는 그렇지 않습니다.

2026년 6월 · 7분 읽기 · Karl-Heinz Reichel

목차

• 설정 (The Setup)
• 우리가 이미 한 번 저질렀던 범주 오류 (The Category Error We Already Made Once)
• 하나의 문서가 아닌 두 개의 레이어 (Two Layers, Not One Document)
• 데이터가 임계값을 설정하게 하기 (Letting the Data Set the Threshold)
• 배지 대신 책임 (Accountability Instead of a Badge)
• 맺음말 (Closing Thought)

몇 주 전 우리는 왜 한 명 대신 두 명의 개발자와 함께 AI 코딩 세션을 진행하는지에 대해 작성했습니다. 트리플렛 프로그래밍 (Triplet programming)은 과도기적 구조로서 효과적으로 작동합니다. 즉, 에이전트 주도의 코드베이스 전반에 걸친 변경 위험이 여전히 높은 동안 공통된 유창성을 구축하는 방법입니다.

하지만 40명의 개발자와 함께하는 규모에서는 유지될 수 없습니다.

팀 규모에서는 모든 사람을 무기한으로 트리플렛에 묶어둘 수 없으며, 그렇게 해서도 안 됩니다. 어떤 개발자들은 최근에야 에이전틱 코딩 (agentic coding)에 도달했습니다. 반면 다른 이들은 이미 몇 달 동안 혼자서 기술과 멀티 에이전트 (multi-agent) 설정을 운영해 오고 있습니다. 합리적인 본능은 이 모든 것을 문서화하는 것입니다. CLAUDE.md, copilot-instructions.md, 그리고 공유된 규칙 세트 — 코드를 변경하기 전에 계획할 것, 작업 범위를 벗어난 파일은 건드리지 말 것, 행동하기 전에 추론 과정을 설명할 것 등 말입니다.

우리는 정확히 그렇게 시도했습니다. 그 결과, 신입 개발자들에게는 필요하지만 거의 인지되지 못하고, 숙련된 개발자들에게는 한 번 자세히 읽은 뒤 즉시 완화하고 싶어지는 문서가 만들어졌습니다.

그러한 반응은 조급함이 아니었습니다. 그것은 실제로 서로 맞지 않는 두 가지 작업을 하나의 문서에 맡겼을 때 나타나는 예측 가능한 결과였습니다.

우리가 이미 한 번 저질렀던 범주 오류

우리는 사실 이와 유사한 형태의 문제에 직면한 적이 있습니다. 단지 파이프라인의 다른 시점이었을 뿐입니다.

The Last Mile Problem과 EDD Closes the Loop — But Only Half of It에서 우리는 AI 지원 개발 (AI-assisted development) 과정에서 끊임없이 혼동되는 두 가지 종류의 도구 사이의 차이점을 설명한 바 있습니다.

**인지 도구 (Awareness tools)**는 누군가가 _알고 있는 것_을 변화시킵니다. 린팅 (linting) 경고, AI 리뷰 코멘트, 다른 팀을 참여시키라는 제안 등이 이에 해당합니다. 이러한 도구들은 이를 받는 사람이 행동에 옮기고자 할 때만 작동합니다. 우리는 이를 접수원 (receptionist)이라고 불렀습니다. 접수원은 상황을 인지하고 무언가를 말하지만, 누군가 멈춰 설지 여부는 전적으로 그들이 듣고 있었는지에 달려 있습니다.

**거버넌스 도구 (Governance tools)**는 누군가가 _할 수 있는 것_을 변화시킵니다. 브랜치 보호 (Branch protection), 필수 리뷰어 (required reviewers), 혹은 아예 열리지 않는 머지 게이트 (merge gate) 등이 있습니다. 이것은 회전식 문 (turnstile)입니다. 이것은 협상하지 않습니다.

여기서 범하기 쉬운 실수는 회전식 문이 필요한 상황에 접수원을 배치하는 것입니다. 예를 들어, 위험한 인터페이스 변경을 정확하게 지적한 AI 리뷰가 있었음에도 개발자가 그대로 머지(merge)를 해버리는 경우입니다. 강제성이 없는 올바른 권고는 여전히 단순한 권고에 불과하기 때문입니다.

40명의 개발자를 위해 단 하나의 온보딩 (onboarding) 문서를 작성하는 것도 이와 동일한 패턴이 거울처럼 반복되는 사례입니다. 계획 요구사항 (planning requirement)은 본질적으로 접수원입니다. 이는 개발자에게 행동하기 전에 잠시 멈춰 생각할 것을 요청합니다. 에이전트 기반 코딩 (agentic coding)을 시작한 지 2주 된 사람에게는 그것이 정확히 적절한 수준의 마찰 (friction)입니다. 하지만 이미 이 과정을 내재화하고 자동화하여 여러 기술을 깊이 있게 다루는 개발자에게 동일한 지침은, 실제 위험과 관련된 이유 없이 매번 이미 모든 권한을 가진 사람을 가로막는 접수원이 됩니다.

반대로, 온보딩 가드레일 (onboarding guardrails)을 마치 선택 사항인 것처럼 — 즉, 자신감 있는 개발자라면 그냥 건너뛸 수 있는 것처럼 — 취급하는 것은, 방 안에서 가장 시니어인 사람이 오늘 자신에게는 이 규칙이 적용되지 않는다고 결정하는 순간, 모두에게 거버넌스를 인지 도구로 조용히 전락시켜 버립니다.

하나의 문서가 동시에 수행할 수 없는 두 가지 역할을 수행하도록 요구받고 있었습니다.

하나의 문서가 아닌 두 개의 계층

이 문제를 이런 방식으로 바라보게 되면, 해결책은 우리가 병합 게이트(merge gate)를 위해 도출했던 것과 동일한 형태를 띠게 됩니다. 즉, 인지(awareness)와 거버넌스(governance)를 동일한 파일 내의 두 단락이 아니라, 진정으로 분리된 별개의 계층으로 유지하는 것입니다.

거버넌스 계층은 작고, 저장소(repository)에 종속되며, 모두에게 동일하게 적용됩니다. 보호된 브랜치(protected branches)에 대한 직접적인 푸시(push)는 허용되지 않습니다. 선언된 작업 범위(task scope)를 벗어난 변경도 허용되지 않습니다. 병합 전에는 반드시 리뷰를 거쳐야 합니다. 이 계층은 숙련도에 따라 조정되지 않습니다. 대신 폭발 반경(blast radius)에 따라 조정됩니다. 에이전트를 조종하는 개발자가 숙련되었다고 해서 에이전트의 폭발 반경이 줄어드는 것은 아니기 때문입니다. 이 계층은 버전 관리 시스템(version control)에 존재하며, 누구의 머신에서 실행되든 저장소와 함께 이동하며, 단순히 프롬프트(prompt)로 요청되는 것이 아니라 구조적으로—브랜치 보호(branch protection), CI 게이트(CI gates), CODEOWNERS 등을 통해—강제됩니다. 시니어 개발자라고 해서 신입 개발자보다 이 규칙을 무시하고 지나갈 수 있는 것은 아니며, 바로 그것이 핵심입니다. 애초에 이것은 신뢰의 문제가 아니었습니다.

스캐폴딩(scaffolding, 비계) 계층은 개인적이며, 축소될 수 있습니다. 변경 전의 명시적인 계획 수립, 루프(loop) 내의 두 번째 인원 참여, 모든 단계에서의 상세한 추론 등이 이에 해당합니다. 이것은 접수원과 같아서, 판단력을 쌓아가는 단계에 있는 사람에게는 의도적으로 높게 설정하고, 이미 판단력을 증명한 사람에게는 의도적으로 낮게 설정합니다. 이것은 저장소가 아닌 개인에게 속한 것이며, 프로젝트 규칙보다는 개인의 코딩 프로필에 더 가깝습니다.

팀을 위한 솔직한 재정의는 다음과 같습니다. 계획 단계는 결코 코드에 관한 규칙이 아니었습니다. 그것은 개발자가 아직 갖추지 못한 판단력을 외부화한 형태였으며, 우리의 3인 체제(triplet setup)에서 두 번째 인원을 대신하는 역할을 했던 것입니다. 일단 그 판단력이 스스로 존재하게 되면, 스캐폴딩은 자신의 임무를 완수한 것이므로 뒤로 물러날 수 있습니다. 이것은 예외를 허용하는 것이 아닙니다. 스캐폴딩이 스스로를 불필요하게 만드는 데 성공한 것이며, 그것이야말로 처음부터 의도했던 실제 목표였습니다.

이것이 자의적인 것이 아니라 신뢰할 수 있는 이유는, 그 경로가 직함이나 근속 연수에 의해 주장되는 것이 아니라 눈에 보이고 획득 가능한 것이기 때문입니다. 즉, 개발자의 스캐폴딩 (scaffolding)을 줄여주는 것은 서류상으로 얼마나 시니어(senior)인가가 아니라, 실제 세션 전반에 걸친 개발자의 실적 — 범위 위반(scope violations) 없음, 검토 중 보여준 건전한 판단력, 입증된 유창함(fluency) — 입니다.

데이터가 임계값을 설정하게 하기

이것보다 한 단계 더 나아간 버전이 있으며, 이는 우리가 반대 방향에서 작성했던 내용과 다시 연결됩니다.

기술 수준 (skill-level)은 하나의 축입니다. 하지만 그것만이 유일하게 중요한 축은 아닙니다. 자신감 있고 빠르게 성장한 개발자가 위험한 요소가 전혀 없었던 파일을 건드리는 것은, 그가 누구인지와 상관없이 낮은 위험 (low-stakes) 이벤트입니다. 반면, 동일한 개발자가 — 저장소(repository) 자체의 이력에 따르면 — 다른 세 팀이 의존하는 코드와 반복적으로 함께 변경되어 온 파일을 건드리는 것은, 그 개발자의 등급(tier)과는 별개로 완전히 다른 상황입니다.

이것이 바로 우리가 라스트 마일 (last-mile) 및 EDD 관련 글에서 설명했던 신호입니다. 즉, 어떤 파일이 "중요"한지에 대한 누군가의 정적인 의견이 아니라, 실제 커밋 이력 (commit history)에서 도출된 변경 결합도 (change coupling)입니다. 신입 개발자가 고립된 유틸리티 함수 (utility function)를 편집할 때는, 단지 그들의 등급이 그렇다는 이유만으로 스캐폴딩의 모든 무게를 감당할 필요가 없습니다. 마찬가지로 숙련된 개발자라 할지라도, 단지 그들의 등급이 그렇다는 이유만으로 결합도가 높은 인터페이스 (interface)를 마찰 없이 통과해서는 안 됩니다.

다시 말해, 특정 변경 사항에 대해 얼마나 많은 거버넌스 (governance)나 스캐폴딩이 적용될지에 대한 임계값은 기술 수준만으로 결정되는 것이 아니라, 두 가지 입력값을 동시에 통해 정보를 얻을 수 있습니다. 즉, 누가 변경을 수행하는가, 그리고 코드베이스 자체의 결합도 이력에 따라 해당 변경이 실제로 무엇을 건드리는가입니다. 이를 통해 게이트 (gate)는 양방향 모두에서 정직함을 유지합니다. 코드의 조용한 구석에서 작업하는 신중한 신입을 처벌하지 않으며, 저장소의 이력이 순수하게 로컬 결정이었던 적이 없다고 말하는 경계에 서 있는 자신감 넘치는 개발자를 그냥 통과시켜 주지도 않습니다.

이 통합은 아직 구축되지 않았습니다. 이는 "이 개발자가 누구인가"와 "이 변경 사항이 실제로 어떤 위험을 초래하는가"가 서로 다른 두 가지 질문이며, 그중 하나만이 인물에 관한 것이라는 점을 받아들일 때 나타나는 자연스러운 다음 단계입니다.

배지(Badge) 대신 책임(Accountability)

계층화(tiering) 문제를 거의 완전히 우회할 수 있는 방법이 있으며, 이는 다른 질문에서 시작됩니다. "이 개발자의 숙련도가 어느 정도인가"를 묻는 대신, "이 변경 사항의 소유권(ownership)이 누구에게 있는가"를 물으십시오.

에이전트(agent)가 디프(diff)를 작성했다고 해서 답이 바뀌지는 않습니다. "AI가 했습니다"라는 말은 "린터(linter)를 통과했습니다"라는 말이 더 이상 변명이 될 수 없었던 것과 마찬가지로, 버그에 대한 방어 논리가 될 수 없습니다. 풀 리퀘스트(pull request)를 여는 개발자가 그 안에 담긴 내용에 대한 소유권을 가집니다. 그리고 그 소유권이 실질적인지 확인하는 간단한 테스트가 있습니다. 리뷰 과정에서 에이전트가 스스로를 설명한 내용에 의존하지 않고, 해당 변경 사항이 무엇을 수행하며 왜 수행하는지를 설명할 수 있는가 하는 점입니다. 만약 설명할 수 없다면, 그 패치(patch)는 병합(merge)되지 않습니다. 이는 개발자의 전반적인 역량에 대한 판결이 아니라, EDD가 설명하는 편집자(editor) 역할이 단순히 형식적인 승인(rubber-stamping)에 그치지 않고 이번 특정 변경 사항에 대해 실제로 수행되었음을 확인하는 절차입니다.

이 방식이 효과적인 이유는 누구에 대해서도 사전 분류를 요구하지 않기 때문입니다. 이는 신입 사원과 10년 차 베테랑에게 동일하게 적용되는 규칙이며, 사람에게 사전에 적용하는 것이 아니라 변경 사항 자체에 사후적으로 적용됩니다. 이미 CI/CD를 통해 구축된 승인 필수 브랜치 보호(branch protection)와 결합될 때, 이는 진정한 의미의 회전식 게이트(turnstile) 역할을 합니다. 즉, 설명 가능성(explainability)이 있으면 좋겠다는 제안이 아니라, 변경 사항이 통과하기 위해 반드시 갖춰야 할 조건이 됩니다.

이 규칙이 하지 않는 역할은, 개발자가 아직 확신이 없는 상태에서 변경 사항을 자신 있게 설명할 수 있는 단계에 도달하기 위해 어떻게 해야 하는지 알려주는 것이 아닙니다. 바로 그 지점에서 스캐폴딩 (scaffolding)이 여전히 제 역할을 합니다. 다만 온보딩 (onboarding) 시점에 할당되는 티어 (tier)와는 다른 방식으로 제공될 뿐입니다. 시스템이 누가 계획 의식 (planning ritual)을 가져야 하고 누가 필요하지 않은지를 미리 결정하는 대신, 개발자가 작업별로 이를 호출할지 결정합니다. 즉, 누구나 자신의 자격에 대한 선언 없이도 단일 작업을 위해 사용할 수 있는 기술이자 플래그(flag)로서, 에이전트 (agent)를 명시적으로 선언된 범위로 제한하고 인접한 요소에 손을 대기 전에 확인을 요청하는 "더 안전한 모드 (safer mode)"를 사용하는 것입니다.

이러한 재정의는 보기보다 더 중요합니다. 온보딩 시점에 할당된 티어는 상태 (status)입니다. 하지만 오늘의 변경 사항이 생소한 영역을 건드리기 때문에 어느 오후 동안 호출되는 "더 안전한 모드"는 도구 (tool)입니다. 전자는 사람을 낙인찍지만, 후자는 순간을 설명합니다. 그리고 시니어 개발자들 역시 자신이 잘 모르는 코드베이스 (codebase) 부분에서는 이 모드를 사용하며, 이는 바로 그들이 그렇게 해야만 하는 시점입니다.

앞선 섹션에서 다룬 설계 작업이 사라지는 것은 아닙니다. "더 안전한 모드"가 실제로 무엇을 제한하는지, 그리고 변경을 수행하는 주체가 누구든 상관없이 어떤 변경 결합 (change-coupling) 위험이 더 강력한 리뷰를 트리거해야 하는지를 누군가는 여전히 정의해야 합니다. 변화하는 것은 그것을 언제 사용할지 결정하는 주체이며, 마지막 단계의 설명 가능성 (explainability) 게이트 (gate)는 그 선택에 따른 결과를 명확히 합니다. 생소한 변경 사항에 대해 더 안전한 모드를 건너뛴다면, 그 격차는 3주 뒤 운영 환경 (production)이 아니라 리뷰 단계에서 드러나게 됩니다.

맺음말

이 두 가지 이야기 — 머지 게이트 (merge gate)와 온보딩 문서 —의 밑바탕에 깔린 패턴은 동일합니다. 인지 (awareness)와 거버넌스 (governance)는 서로 다른 문제를 해결하며, 한 가지를 위해 만들어진 도구는 다른 일을 맡게 되었을 때 종종 실패를 알리지도 못한 채 조용히 실패한다는 점입니다. 우리는 코드가 저장소 (repository)와 만나는 지점에서 이를 한 번 포착했습니다. 또한 개발자가 에이전트와 처음 만나는 지점에서도 그것은 기다리고 있었습니다.

두 곳 모두에서의 해결책은 동일한 형태임이 드러났습니다. 즉, 거버넌스 계층 (governance layer)은 작고, 보편적이며, 타협 불가능하게 유지하는 것입니다. 즉, 당신이 누구인지와 상관없이 머지 (merge) 시점에 강제되는 소유권 (ownership)과 설명 가능성 (explainability)을 확보하는 것입니다. 반면, 인지 계층 (awareness layer)은 한 번 할당되어 라벨처럼 따라다니는 것이 아니라, 사람들이 작업별로 스스로 선택할 수 있는 영역으로 두어야 합니다.

이 포스트는 AI 지원 개발의 라스트 마일 문제 (last mile problem in AI-assisted development)와 왜 EDD는 루프의 절반만 닫는가 (why EDD closes only half the loop)에 관한 이전 글들을 확장하며, 왜 우리는 개발을 3개 단위로 구조화하는가 (why we structure development in threes)의 후속 내용입니다.

• Ai-Engineering
• Developer Tooling
• Code Governance
• Software Architecture
• Team Practices