실제 소프트웨어 팀을 위한 AI 코딩 거버넌스 (AI Coding Governance)

최근 JCon 기조연설에서 제가 가장 중요하게 생각하는 슬라이드에는 단 여섯 단어만이 적혀 있었습니다: 코드는 저렴하지만, 소프트웨어는 그렇지 않다 (code is cheap, software isn’t).

전체 강연을 원하신다면, 녹화 영상은 여기에서 확인하실 수 있으며 슬라이드는 여기에서 찾을 수 있습니다. 이 글은 에이전트(agent)를 실제 저장소(repository)에 풀어놓기 전에 팀에게 전달할 짧은 버전의 글입니다.

AI 코딩의 흥미로운 점은 명확합니다. REST 엔드포인트, 리팩터링 (refactor), 마이그레이션 스케치, 또는 초안 UI를 요청하면 빈 페이지가 사라집니다. 그 부분은 실재합니다. 저 또한 이러한 도구들을 사용합니다. 그것들은 시간을 절약해주고, 지루한 작업 일부를 제거하며, 무언가를 빠르게 시도하는 것을 더 쉽게 만들어 줍니다.

문제는 사람들이 더 쉬워진 코드 생성 (code generation)을 더 쉬워진 소프트웨어 엔지니어링 (software engineering)과 혼동할 때 시작됩니다.

실제 시스템은 숨겨진 계약 (contracts)들로 가득 차 있습니다. 권한 부여 규칙 (Authorization rules), 배포 가정 (deployment assumptions), 오래된 문서 (stale docs), 기묘한 통합 엣지 케이스 (integration edges), 그리고 아무도 기록하지 않았지만 이제는 모두가 의존하고 있는 비즈니스 로직 (business logic) 같은 것들 말입니다. 모델은 주변 코드를 통해 그중 일부를 추론할 수 있습니다. 하지만 프롬프트 (prompt)가 자신감 있게 들린다고 해서 그 모든 것을 추론할 수는 없습니다.

지난 18개월 동안 제가 얻은 주요 교훈은 여전히 이것입니다. AI는 많은 구문 (syntax)을 초안 작성할 수 있습니다. 하지만 주변의 소프트웨어를 자동으로 이해하지는 못합니다.

프롬프팅 (Prompting)이 어려운 부분이 아니다

저는 팀들이 AI 코딩을 프롬프팅 문제로 취급하는 것을 계속 보고 있습니다. 더 나은 프롬프트를 작성하라. 더 많은 세부 정보를 추가하라. 적절한 마법 주문을 찾아라. 그것도 어느 정도 도움이 되지만, 제가 신뢰하는 부분은 아닙니다.

더 큰 지렛대는 컨텍스트 (context)입니다.

만약 에이전트가 당신의 아키텍처 제약 조건 (architecture constraints), 비즈니스 경계 (business boundary), 타협할 수 없는 테스트 (non-negotiable tests), 또는 저장소에서 건드려서는 안 될 부분들을 알지 못한다면, 그것은 무언가를 지어낼 것입니다. 이것은 도덕적 실패가 아닙니다. 그것이 시스템이 작동하는 방식입니다. 통계적 도구 (Statistical tools)는 공백을 그럴듯해 보이는 답변으로 채웁니다.

따라서 저는 영리한 문구를 쫓는 데 시간을 덜 쓰고, 모델이 실제로 사용할 수 있는 컨텍스트를 구축하는 데 더 많은 시간을 할애할 것입니다.

그것은 저장소 규칙 (repository rules)을 의미합니다. ADR (Architecture Decision Records)을 의미합니다. 결정 로그 (decision logs)를 의미합니다. 에이전트 (agent)가 단순한 느낌 (vibes) 이상의 무언가를 가질 수 있도록 동작을 충분히 명확하게 정의하는 테스트를 의미합니다. 또한 선택적이어야 함을 의미합니다. 오래된 내부 문서 더미를 컨텍스트 윈도우 (context window)에 쏟아붓는 것은 컨텍스트 엔지니어링 (context engineering)이 아닙니다. 그것은 단지 모델을 혼란스럽게 만드는 또 다른 방법일 뿐입니다.

진정한 질문은 "얼마나 많은 컨텍스트를 채울 수 있는가?"가 아닙니다. "어떤 컨텍스트가 결정의 품질을 바꾸는가?"입니다.

거대한 작업들은 여전히 익숙한 이유로 실패합니다

AI가 우리를 분해 (decomposition)의 문제로부터 구원해주지는 못했습니다.

만약 어떤 변경 사항이 두세 개의 명확한 문장으로 설명하기에 너무 복잡하다면, 그것은 아마도 에이전트에게 하나의 작업으로 넘기기에도 너무 복잡할 가능성이 높습니다. 도구는 여전히 많은 결과물을 만들어낼 수 있습니다. 하지만 그것이 통제된 결과 (controlled result)를 만들어내는 것과 같지는 않습니다.

이 지점은 AI 담론이 때때로 이상할 정도로 비역사적으로 들리는 부분 중 하나입니다. 우리는 이미 대규모 재작성 (big-bang rewrites)이 실패한다는 것을 알고 있습니다. 우리는 이미 "가는 김에 이 구역 전체를 정리해줘"와 같은 광범위한 작업이 팀이 검토할 수 있는 속도보다 더 빠르게 리스크를 확산시킨다는 것을 알고 있습니다. 그렇다면 왜 에이전트가 마법 같은 예외가 될 수 있겠습니까?

여전히 유효한 패턴은 과거의 방식과 동일합니다:

더 작은 작업 단위
엄격한 경계 (tight boundaries)
빠른 검증 (fast verification)
쉬운 롤백 (easy rollback)
명시적인 소유권 (explicit ownership)

이것은 "완전 자율 개발 (fully autonomous development)"보다 덜 화려해 보일 수 있지만, 프로덕션 팀이 제정신을 유지하는 방식에 훨씬 더 가깝습니다.

또한 저는 로컬 git (local git)이 사람들이 인정하는 것보다 더 중요하다는 점을 생각합니다. 에이전트가 궤도를 벗어났을 때, 유용한 실험과 짜증 나는 오후를 가르는 차이는 종종 당신이 차이점 (diff)을 빠르게 조사하고, 그것을 버리고, 더 좁은 요청으로 다시 시도할 수 있는지 여부에 달려 있습니다.

유용한 도구는 텍스트뿐만 아니라 시스템을 노출합니다

제가 MCP 및 유사한 도구 인터페이스 (tool surfaces)에 관심을 갖는 이유 중 하나는, 그것들이 상호작용의 중심을 순수한 추측으로부터 옮겨주기 때문입니다.

모델이 런타임 상태 (runtime state)를 조사하고, 중요한 로그를 읽으며, 실제로 변경 중인 시스템에 쿼리를 날리거나, 반쯤 기억하는 내용을 재진술하는 대신 구조화된 문서 (structured docs)에 접근할 수 있을 때 훨씬 더 유용해집니다. 이것이 모델을 마법처럼 만드는 것은 아닙니다. 그저 모델이 서 있을 수 있는 더 나은 기반을 제공할 뿐입니다.

저에게 있어 이것이 이 레이어 (layer)가 가진 진정한 약속입니다. 데모용 기술로서의 "모델이 도구를 사용할 수 있다"가 아닙니다. 더 나은 약속은 모델이 라이브 시스템을 이해하는 데 텍스트만으로 충분한 척하는 것을 그만둘 수 있다는 점입니다.

하지만 동일한 규칙이 여전히 적용됩니다. 도구가 많다고 해서 자동으로 더 좋아지는 것은 아닙니다. 도구의 확산 (tool sprawl)은 그 자체로 비용 (tax)을 발생시킵니다. 거대한 도구 카탈로그, 방대한 컨텍스트 페이로드 (context payload), 그리고 동일한 작업을 수행하는 10가지의 중복된 방식은 세션을 더 좋게 만드는 것이 아니라 오히려 악화시킬 수 있습니다. 훌륭한 AI 워크플로우 (AI workflows)는 유능한 모델만큼이나 잘 설계된 인터페이스 (shaped surface)를 필요로 합니다.

리뷰 단계에서 청구되는 비용

이 부분은 팀들이 여전히 과소평가하고 있다고 생각하는 지점입니다.

AI 출력물은 생성 속도가 빠르지만, 검증하는 데는 종종 많은 비용이 듭니다. 그 비용은 데모 단계에서는 나타나지 않습니다. 시니어 엔지니어가 깔끔해 보이는 디프 (diff)를 읽고, 시스템을 여전히 신뢰할 수 있는지 결정해야 할 때 비로소 나타납니다.

그 리뷰 부하 (review load)는 실제 업무입니다. 당신은 숨겨진 가정 (hidden assumptions), 엣지 케이스 (edge cases), 실패 경로 (failure paths), 인증 동작 (auth behavior), 운영 리스크 (operational risk), 명명 규칙의 이탈 (naming drift), 그리고 테스트가 유용한 무언가를 증명하는지 아니면 단순히 구현 내용을 그대로 반영하고 있는지를 확인하고 있는 것입니다. 만약 변경 사항이 인프라 (infrastructure), 보안 (security), 또는 비즈니스 규칙 (business rules)을 건드린다면, 인지적 비용 (cognitive bill)은 훨씬 더 높아집니다.

이것이 제가 코드 생성 속도에만 국한된 가공되지 않은 생산성 주장들을 신뢰하지 않는 이유입니다. 빠른 초안 작성과 느리고 소모적인 리뷰 루프 (review loop)의 결합은 자동으로 승리가 되지 않습니다. 때로는 승리가 될 수도 있지만, 때로는 그저 다른 대기열 (queue)이 될 뿐입니다.

실패 모드 (failure mode)는 미묘합니다. 지친 리뷰어들이 겉으로 보기에는 여전히 생산적인 것처럼 보이기 때문입니다. 변경된 파일들이 있고, 풀 리퀘스트 (pull request)는 규모가 크며, CI는 통과되었습니다. 모두가 진전이 있다고 느낍니다. 하지만 피로가 곧 확신은 아니며, 추진력이 곧 이해는 아닙니다.

이 모든 과정에서 단 하나의 직업적 규칙을 남겨야 한다면, 그것은 간단합니다. 만약 당신이 AI가 생성한 변경 사항의 실패 모드 (failure mode)를 설명할 수 있을 정도로 충분히 이해하지 못했다면, 그것을 머지 (merge)하지 마십시오.

Java는 과장된 것보다 더 강력한 위치에 있습니다

많은 AI 코딩 관련 논의는 여전히 Python을 기본값으로 설정하는데, 이는 AI 생태계가 Python 우선의 툴링 (tooling)을 중심으로 성장했기 때문입니다. 하지만 이것이 Python 팀이 자동으로 더 나은 엔지니어링 위치에 있다는 것을 의미하지는 않습니다.

Java는 여기서 매우 실질적인 이점을 가집니다. 코드가 명시적입니다. 타입 (Types)이 가시적입니다. 계약 (Contracts)이 더 명확합니다. 프레임워크 컨벤션 (Framework conventions)이 더 강력합니다. 빌드 (Build) 및 런타임 (runtime) 경계는 느슨하게 구조화된 많은 스택보다 따르기 쉽습니다. 이러한 형태는 인간이 더 빠르게 리뷰할 수 있도록 돕고, 모델이 궤도 (rails)를 벗어나지 않도록 도와줍니다.

Java가 AI를 안전하게 만든다는 뜻이 아닙니다. 그렇지 않습니다. 제 말은 Java가 모델과 리뷰어 모두에게 작업할 수 있는 더 많은 구조를 제공한다는 것이며, 이것이 바로 기업용 Java 팀이 대중적인 AI 내러티브 (narrative)가 시사하는 것보다 이러한 전환에 더 유리한 위치에 있다고 생각하는 이유 중 하나입니다.

오히려 Java 팀은 의도적으로 그 이점을 활용해야 합니다. 강력한 테스트 (tests), 타입이 지정된 설정 (typed config), 명시적인 경계, 그리고 지루한 컨벤션 (conventions)은 AI 시대에 무의미해진 오래된 습관이 아닙니다. 그것들은 AI 시대를 살아남게 만드는 요소들입니다.

내가 실제로 팀에게 해줄 말

만약 이 기조 연설 전체를 하나의 짧은 작업 협약 (working agreement)으로 압축해야 한다면, 다음과 같을 것입니다:

단순히 더 긴 프롬프트 (prompts)가 아니라, 모델에게 더 나은 컨텍스트 (context)를 제공하십시오.
검증 (verification) 비용이 저렴하게 유지될 수 있도록 작업을 충분히 작게 유지하십시오.
작업이 실제 시스템 상태에 의존하는 경우, 실제 시스템 상태를 드러내는 도구를 사용하십시오.
리뷰 부하 (review load)를 모델이 작업을 마친 후의 무료 정리 작업이 아니라, 비용의 일부로 취급하십시오.
모든 프로덕션 변경 사항에는 반드시 인간 소유자 (human owner)를 지정하십시오.

이것은 혁명적인 메시지가 아닙니다. 그것은 초안 작성 비용이 저렴해졌다고 해서 소프트웨어 엔지니어링이 사라지기를 거부하는 모습에 가깝습니다.

AI는 우리가 구축하는 방식을 변화시키고 있습니다. 그 부분은 더 이상 논쟁의 여지가 없다고 생각합니다. 사람들이 여전히 계속해서 다시 배워야 하는 부분은, 더 빠른 코드 생성 (Code generation)이 소프트웨어의 값비싼 부분들을 제거하지는 못한다는 사실입니다. 의도 (Intent)는 여전히 비용이 많이 듭니다. 아키텍처 (Architecture)는 여전히 비용이 많이 듭니다. 검증 (Verification)은 여전히 비용이 많이 듭니다. 소유권 (Ownership)은 여전히 비용이 많이 듭니다.

그것이 바로 슬라이드에 있는 문장이 여전히 유효한 이유입니다.

코드는 저렴합니다. 소프트웨어는 그렇지 않습니다.