AI 지원 개발의 속도 향상이 18개월 후의 유지보수 비용으로 전가되는 구조에 대해 다른 글에서 작성한 적이 있습니다.
이번 글은 그 연장선상에서 구체적으로 무엇을 만들 것인가에 대한 이야기입니다.
결론부터 말하자면, 거버넌스는 문서가 아닙니다. 강제력이 있는 시스템입니다. '규약을 만들었다'로 끝난다면, 그것은 존재하지 않는 것과 같습니다. 이 점은 보안 업계에서도 유사하게 정리되어 있으며, 거버넌스가 기능하는 것은 리스크 관리가 개발 워크플로우에 직접 내장된 강제 가능한 컨트롤(control)로 번역되었을 때라고 합니다.
저는 이전 직장에서 금융 기관의 프론트 오피스 시스템, 즉 FX 및 주식 거래 시스템을 오래 만들었습니다. 그 세계에서는 자신이 작동 방식을 설명할 수 없는 코드를 운영 환경에 배포하는 일은 없습니다. 그렇게 하면 금전적인 손실로 직결하기 때문입니다. AI 지원 개발에 필요한 규율은 본질적으로 저 세계의 규율과 같다고 생각합니다.
아래 제가 실제로 설계한 5가지 계층을 도입 비용이 낮은 순서가 아니라, 효과가 큰 순서대로 설명하겠습니다.
1. 사양(Spec)을 먼저 작성하기 (Spec-Driven Development)
가장 효과가 크고, 가장 도입이 번거로운 것이 이것입니다.
AI 에이전트에게 '이 기능을 만들어라'라고 지시하면, 에이전트는 요구사항을 추측합니다. 추측된 요구사항은 어디에도 기록되지 않습니다. 그래서 18개월 후에 '왜 이 구현 방식인지'를 아무도 알 수 없게 됩니다.
대책은 간단합니다. 비자명한 기능을 만들기 전에, 승인 조건(acceptance criteria)이 작성된 Markdown 파일을 준비하고, 그것을 에이전트의 컨텍스트에 전달하는 것입니다. Spec Kit이나 Kiro 같은 도구를 사용해도 좋지만, 필수 사항은 아닙니다. 주말 동안 시작할 수 있는 정도의 투자가 필요합니다.
중요한 것은 사양과 코드를 병행시키는 것입니다. 동작을 변경할 때는 사양과 코드 양쪽 모두를 업데이트해야 합니다. 이렇게 하면 '사양이 구현에서 괴리되는' 고전적인 문제가 구조적으로 사라집니다.
규제 산업에서는 더욱 나아간 'Constitutional SDD'라는 방법이 제안되고 있습니다. CWE나 MITRE Top 25에서 도출한 제약 조건을, 버전 관리된 기계가 읽을 수 있는 '헌법(constitution)'으로 내장하는 방식입니다. 은행의 마이크로 서비스를 대상으로 한 케이스 스터디에서는, 제약 조건이 없는 생성과 비교하여 보안 결함이 73% 감소했으며, 헌법상의 원칙부터 구체적인 코드 위치(파일/행 단위)까지 추적 가능성(traceability)이 확보되었다고 보고되었습니다.
이것이 효과를 발휘하는 이유는, 검사 단계에서 나중에 잡아내는 것이 아니라, 사양의 계층에 보안을 짜 넣어 AI 생성 코드가 처음부터 따르도록 하기 때문입니다. EU AI Act의 고위험 시스템(high-risk system) 관련 의무가 2026년 8월부터 시작되고, 벌금이 최대 3,500만 유로 또는 전 세계 매출액의 7%에 달하는 것을 고려하면, 금융/의료 분야에서는 멀지 않아 필수화될 방향이라고 보고 있습니다.
2. 표준 지시 파일(Standard Prompt File)을 '얇게' 유지하기
AGENTS.md, CLAUDE.md와 같은 표준 지시 파일은 이제 사실상의 표준입니다. 다만 2026년의 실무적 합의는 **'너무 많이 쓰지 말라'**는 방향으로 수렴했습니다.
현장의 기준으로 언급되는 것은, 프론티어 모델이 안정적으로 따를 수 있는 표준 지시는 대략 150~200개 정도이며, 이를 초과하면 준수율이 떨어지기 시작한다는 선입니다 (엄격한 보장은 아니며 경험적 규칙입니다). HumanLayer 등에서 권장하는 기준은 300줄 미만입니다.
즉, 자동 생성된 '모든 것을 담은' 에이전트 지시 파일은 근면함이라는 옷을 입은 실패 모드입니다.
실무적인 구성은 다음과 같습니다.
- 구조는 WHAT / WHY / HOW — 기술 스택과 구조, 목적, 빌드 명령어와 규약
- 명시적인 '할 것/하지 말 것' 목록과 권한 경계(boundary)
- 파일 경로는 적지 않는다 (곧 구식이 되기 때문)
- lint 대신 사용하지 않는다 (기계로 강제할 수 있는 것은 기계로 해야 한다)
마지막 한 점이 중요합니다. 지시 파일에 작성된 규약은 '지켜질 수도 있는' 것입니다. CI(Continuous Integration)에 작성된 규약은 '지켜지는' 것입니다.
3. 테스트 설계는 인간, 구현은 AI
AI에게 테스트를 쓰게 하면, 구현에 맞춰진 테스트가 나옵니다. 즉, 버그 그 자체를 고정하는 것입니다.
제가 지키는 순서는 간단합니다.
- 무엇을 보장할지 인간이 결정한다 (승인 조건, 경계값, 실패 모드)
- 테스트 케이스의 설계를 인간이 작성한다
- 테스트의 구현과 프로덕션 코드의 구현은 AI에게 맡긴다
- 테스트가 통과하는지 여부가 아니라, 테스트 자체가 올바른지 인간이 리뷰한다
이는 금융 시스템 개발에서는 당연한 순서입니다. 가격 계산 로직의 테스트를 구현하고 나서 작성하는 사람은 없습니다. AI 지원 개발에서 무너지기 쉬운 부분은, AI가 이 두 가지를 동시에, 게다가 빠르게 내놓기 때문입니다.
4. CI로 기계적으로 막기
이전에 인용한 GitClear의 조사에 따르면, 중복 코드 블록이 81% 증가했고, 커밋 내 복사&붙여넣기가 41% 증가했으며, 에러 포획(error swallowing) 구문이 47% 증가했습니다. 이 세 가지는 모두 CI에서 기계적으로 감지할 수 있습니다.
도입 비용 대비 효과가 가장 명확한 것이 바로 이 단계입니다. 구체적으로는,
- 중복 감지를 필수 체크로 지정한다. 임계값을 초과하면 머지(merge)를 멈춘다.
- 에러 포획을 정적 분석으로 탐지한다. 빈 catch, 포획된 Promise, 무시되는 반환값 등을 확인한다.
- 2주 차터닝(churning)을 시각화한다. 작성하자마자 버려지는 코드의 비율은 설계가 제대로 작동하지 않고 있다는 가장 빠른 지표입니다.
- 정적 분석을 통과시킨다. Sonar가 2025년 8월에 5개의 LLM에게 4,442건의 Java 코딩 과제를 풀게 한 조사에서, 탐지된 취약점 중 최고 심각도(BLOCKER)로 분류된 것이 모델별로 62.5%~70.7%에 달했습니다. 이는 인간의 리뷰만으로는 잡아낼 수 있는 양이 아닙니다.
이러한 것들은 기존 CI에 며칠 만에 추가할 수 있습니다. 거버넌스 중에서 가장 비용 효율성이 높은 부분입니다.
5. 권한 경계를 먼저 정하기
여기는 간과되기 쉽지만, 엔터프라이즈에서는 가장 무거운 논점입니다.
엔터프라이즈에서 최대의 리스크는 에이전트가 코드를 못 쓰는 것이 아니라, 잘못된 권한 경계 내부에서 너무 많이 작성하는 것입니다.
최소한 결정해야 할 것은 아이덴티티와 권한(조직 정책, 사용자 그룹, 레포지토리 권한), 데이터 경계(코드/프롬프트/로그 처리, 학습 이용 가능 여부), 실행 환경(샌드박스, 네트워크 허용 목록, 시크릿 분리), 감사 및 비용(사용자/레포지토리/워크플로우 단위의 사용 현황), 그리고 컴플라이언스 워크플로우(인간 리뷰 요건, 머지 제한)입니다.
AI 코딩 툴, 에이전트, 모델 컴포넌트는 이제 소프트웨어 공급망의 일부입니다. 프로덕션 인프라와 동일한 엄격함으로 관리되어야 합니다.
도입 순서 — 바로 전면 자동화하지 않기
현장에서 합의되고 있는 안전한 도입 경로는 단계적입니다.
- 에이전트에게 테스트 추가와 작은 버그 수정을 시킨다.
- 낮은 리스크의 리팩토링을 시킨다.
- 의존성 업데이트와 문서 동기화를 시킨다.
- 그 후에, 모듈을 넘나드는 기능 개발을 시도한다.
많은 조직이 1~3 단계를 건너뛰고 4단계부터 시작합니다. 그리고 'AI는 쓸 수 없다' 또는 'AI로 빨라졌다'라는 두 가지 결론 중 하나에 도달합니다. 전자는 도입 실패, 후자는 18개월 후에 청구서가 도착하는 패턴입니다.
일본 기업에게 현실적인 논점
마지막으로, 국내 사정을 두 가지 말씀드립니다.
하나는 거버넌스의 성숙도입니다. Deloitte의 State of AI 2026에서는 자율형 AI 에이전트에 대해 성숙한 거버넌스 모델을 가진 기업은 5개사 중 1개사에 그칠 것이라고 합니다. 이는 세계적인 수치이지만, 일본 기업에서는 더 낮다고 보는 것이 타당할 것입니다. 역으로 생각하면, 이곳이야말로 지금 차이가 나는 영역입니다.
또 하나는 계약 구조입니다. 개발을 외부에 위탁하는 경우, 위의 5개 단계를 누가 보장하는지 여부가 계약서에 적혀있지 않은 경우가 대부분입니다. AI 지원 개발을 전제로 한다면, 산출물의 정의에 '사양 파일', '테스트 설계', 'CI 체크 구성'을 명시해야 합니다. 이것을 작성하지 않으면 납품되는 것은 코드만입니다. 18개월 후에 곤란한 건 발주 측입니다.
요약
AI 개발 거버넌스는 AI를 느리게 하기 위한 장치가 아닙니다. 속도를 18개월까지 지속시키기 위한 장치입니다.
5개의 단계 중, 내일부터 시작할 수 있는 것은 제4단계(CI 체크)입니다. 며칠 만에 도입할 수 있고 효과가 숫자로 보입니다. 가장 효과가 큰 것은 제1단계(사양을 먼저 작성하는 것)이지만, 이는 조직의 습관을 바꾸는 문제라 시간이 걸립니다.
저 자신도 속도의 실험과 거버넌스 구축은 동시에 진행했습니다. 순서가 아니라 동시입니다. 빠르게 만드는 것과, 나중에 고칠 수 있는 상태로 유지하는 것은 트레이드오프(trade-off)가 아닙니다.
주식회사 ◯◯에서는 AI 개발 거버넌스의 설계/도입 지원, 기술 자문, 기술 실사(due diligence)를 제공하고 있습니다. [서비스 상세 링크]
출전
논의
