AI 주도 개발(AI-driven development)에 관한 기사는 이미 나올 만큼 다 나온 느낌입니다. "사양을 작성한다", "AI에게 구현하게 한다", "출력을 인간이 리뷰한다", "최종 책임은 인간이 진다" —— 모두 맞는 말이며, 잘 정리된 기사들도 많이 있습니다.

그래서 이 기사에서는 그 이야기는 하지 않겠습니다.

여기서 쓰는 내용은 그 한 걸음 앞의 이야기입니다. 개인이 AI를 잘 사용할 수 있게 된 후, 팀 단위로 그것을 돌리려고 시도하는 순간 나타나는 벽과, 그것을 어떻게 시스템으로서 해결했는지에 대한 기록입니다.

먼저 결론부터 말씀드리겠습니다. AI 활용 능력은 개인 기술로만 남아 있다면 조직 내에서 형식화됩니다. 가드레일(Guardrail)을 개인의 메모가 아닌 "조직의 제도"로 승화시키지 않으면, 인원수만큼의 편차가 쌓일 뿐이었습니다.

처음에는 잘 진행되었습니다.

AI가 같은 실수를 할 때마다 학습 내용을 메모에 기록합니다. 예를 들어 "try-except 안이 print 한 줄로 뭉개져 있었다"와 같은 실패를 기록하여 다음부터 참조하게 합니다. 잘 알려진 접근 방식(CLAUDE.md나 lessons.md의 운용)이며, 개인 차원에서 돌리기에는 완벽하게 기능했습니다.

문제가 발생한 것은 이것을 팀으로 전개했을 때입니다.

• A씨의 메모와 B씨의 메모 내용이 서로 다르다
• "우리 방식"이 사람마다 다르기 때문에 AI의 출력도 사람마다 편차가 생긴다
• 리뷰를 할 때마다 "그거, 전에 A씨와 정한 규칙과 반대잖아"라는 공중전(논쟁)이 일어난다

개인의 메모는 작성한 본인의 "머릿속 맥락"과 세트로만 기능합니다. 암묵지(Tacit knowledge) 상태로 AI에게 전달하기 때문에, 본인이 없으면 재현할 수 없는 것입니다. 이러한 축적은 개인의 자산은 될 수 있어도, 조직의 자산은 되지 못했습니다.

여기서 깨달았습니다. 해야 할 일은 "메모를 공유하는 것"이 아닙니다. 판단 기준 그 자체를 누가 읽어도 동일한 해석이 되도록 글로 써내는 것이었습니다.

그래서 산문으로 메모를 남기는 것을 그만두었습니다. 대신 판단을 **표(Matrix)**로 만들었습니다.

MUST NOT (해서는 안 되는 것)	Why (이유)
확인 없이 구현을 시작함	계획을 사전에 리뷰할 수 없기 때문에
...

산문 형태의 메모와 "표"의 결정적인 차이는 해석의 여지입니다. "에러 핸들링(Error handling)은 정중하게"라는 지시는 사람에 따라 편차가 생기지만, "예외를 뭉개지 않는다"라면 누가 읽어도, AI에게 전달해도 동일한 의미가 됩니다.

그리고 가장 효과가 있었던 것은 금지 이유(Why)를 반드시 한 줄 덧붙이는 것이었습니다. 이유가 명시되어 있으면 규칙은 단순한 "훈계"가 아니라 "과거의 고통에 대한 기록"이 됩니다. 신규 멤버도 AI도 "왜 밟으면 안 되는지" 그 본질을 알 수 있기 때문에 형식화되지 않습니다.

규칙군(Rule set)의 도입부에는 절대로 양보할 수 없는 "Non-Negotiables(절대 사수 규칙)"를 몇 개만 두었습니다. 이곳을 너무 늘리면 아무도 지키지 않게 됩니다. 양보할 수 없는 선은 적기 때문에 오히려 기능합니다.

이렇게 하여 AI의 실패는 개인의 메모에서 팀의 제도가 되었습니다. 누가 요청하더라도 AI는 동일한 가드레일 안에서 움직여 줍니다.

AI 주도 개발의 철칙에는 "모든 것을 곧이곧대로(전부 승인) 믿지 마라, 출력을 읽어라"가 있습니다. 이에 전적으로 동의합니다. 하지만 팀에서 이를 실천하면 다음 문제에 부딪힙니다.

"코드를 읽을 수 있는 사람(안목이 있는 사람)"이 한 명뿐이라면, 그 사람이 팀의 병목(Bottleneck)이 됩니다.

리뷰의 안목이 특정 개인에게 종속되면, 결국 시니어 엔지니어가 모든 풀 리퀘스트(PR)를 정밀 조사하게 되어 AI로 개발을 가속화한 의미가 상쇄됩니다. "읽는 능력"을 개인의 스킬로만 남겨두면 조직의 스케일 속도(Scale speed)는 올라가지 않습니다.

따라서 "읽는 것" 또한 시스템에 포함했습니다. 리스크가 높은 변경에 대해서는 두 가지 축으로 리뷰를 수행하는 제도를 운영하고 있습니다.

• 축 A: 아키텍처 관점 — 레이어의 경계, 의존 방향, 설계의 건전성
• 축 B: 코드 관점 — 버그, 퍼포먼스(Performance), 보안

이 두 가지를 독립적으로 실행하고, 마지막에 인간이 양쪽의 결과를 통합하여 "진행 / 수정 / 중단"을 판정합니다. 중요한 것은 최종 판정 자체를 AI에게 맡기지 않는 것입니다. AI는 어디까지나 관점을 도출하는 역할이며, 결정을 내리는 것은 인간입니다.

핵심은 어떤 변경 사항에 대해 이 리뷰를 필수적으로 적용할지를 리스크 기준 표를 통해 기계적으로 결정하고 있다는 점입니다. "보안 영역을 건드린다", "여러 모듈에 걸친다"와 같은 조건에 부합하면 리뷰 축이 자동으로 필수화됩니다. "리뷰를 해야 할지 말지"를 매번 인간이 고민하는 것 자체를 제도를 통해 배제했습니다.

우리는 역할이 다른 AI를 구분해서 사용하고 있습니다. "태스크를 분석·계획·통합하는 측(오케스트레이터 (Orchestrator))"과 "정의된 스코프를 우직하게 구현하는 측(실행 담당)"입니다.

처음에는 그 당시의 분위기에 따라 구분해서 사용했습니다. 하지만 그렇게 하면 사람마다 "이건 어느 쪽에 맡겨야 하지?"라는 망설임이 생깁니다. 그래서 라우팅 (Routing) 방침도 문서화했습니다.

보안 관련 / 여러 모듈 / 아키텍처 판단 → 계획 측이 직접 담당
명확한 AC (수용 기준) + 단일 스코프 → 실행 담당에게 위임 가능
그 외 → 태스크를 분할하여 재평가

특히 철저히 한 것은, "보안·인증·기밀 정보 취급은 절대로 실행 담당에게 위임하지 않는다"라고 명시한 것입니다. 개발 속도가 빨라진다는 이유로 무엇이든 통째로 맡겨버리면, 본래 인간이 신중하게 판단해야 할 포인트를 그냥 지나치게 됩니다. "위임해도 되는 영역"과 "해서는 안 되는 영역"의 경계선을 처음에 정의해 두는 것이 매우 중요합니다.

모든 규칙을 항상 AI에게 읽게 하려고 하면, 정보량이 너무 많아 AI도 인간도 매몰되어 버립니다. 그래서 규칙을 "문맥에 따라 발동하는 지식"으로 분리했습니다.

"보안 이야기가 나오면 이 입력 검증 방침을 반드시 참조한다", "DB 변경 시에는 마이그레이션 (Migration)의 이 절차를 밟는다" —— 이러한 "그 상황에서야말로 떠올려야 할 것"들을 트리거 (Trigger)별로 나누어 정의해 둡니다. 상시 적용되는 기본 규칙과 문맥 의존적 지식을 분리함으로써, 양쪽 모두 형식화되지 않고 제대로 기능하게 됩니다.

이는 개인 운용 방식인 lessons.md의 정당한 진화형이라고 생각합니다. 실패를 한곳의 메모에 무질서하게 쌓아두는 것이 아니라, "언제, 어느 타이밍에 떠올려야 하는가"라는 트리거와 세트로 저장하는 것입니다.

"개인의 생산성이 올라갔다"는 이야기는 다른 기사에 양보하겠습니다. 이것을 조직에서 운용하기 시작하면서 다음과 같은 변화가 일어났습니다.

신규 멤버의 온보딩 (Onboarding)이 압도적으로 빨라졌습니다. "우리 방식"이 문서로서 시스템화되어 있기 때문에, 암묵지 (Tacit Knowledge) 전달을 기다리는 낭비되는 시간이 사라졌습니다.

리뷰의 편차가 급격히 줄었습니다. 판정 기준이 테이블화되어 있기 때문에, 누가 리뷰를 담당하더라도 동일한 기준으로 제동을 걸 수 있습니다.

AI가 진정한 의미의 "팀의 일원"이 되었습니다. 개인의 취향에 휘둘리지 않고, 조직이 정의한 규칙의 틀 안에서 정확하게 움직여 줍니다.

가장 큰 수확은 판단 기준이 "누군가의 머릿속"에서 "코드처럼 유지보수할 수 있는 문서"가 되었다는 점입니다. 지금까지 정리하지 못했던 "우리 자신이 무엇을, 어떤 기준으로 판단하고 있었는지"를 처음으로 모두 언어화할 수 있었습니다.

만약 당신이 "개인으로는 AI를 잘 활용하고 있는데, 팀으로 확장하자마자 개발이 공중분해 되기 시작했다"라고 느끼고 있다면, 그 원인은 AI의 성능도 멤버의 기술도 아닐지도 모릅니다. 판단 기준이 아직 누군가의 머릿속에 잠들어 있는 것뿐 아닐까요?

AI를 도입해서 가장 변한 것은 구현 속도도, 인간의 역할 분담도 아니었습니다.

"우리 자신이 무엇을, 어떤 기준으로 판단하고 있었는가" —— 그것을 처음으로 머리 밖으로 꺼내어 명문화한 것입니다.

AI가 올바르게 움직이게 하기 위해 언어화한 규칙은, 돌고 돌아 인간 팀을 가장 강하게 만들어 주었습니다.

개인 운용	조직 운용
lessons.md에 실패를 쌓아둠	"MUST NOT 표"로 승화시킴
코드를 읽을 수 있는 사람이 (개인적으로) 읽음	읽는 것을 "2축 리뷰 제도"로 만듦
그 당시의 기분에 따라 AI의 역할을 배정함	라우팅 기준을 명문화함
암묵지를 본인이 떠안음	문서에 판단 기준을 담음