AI가 코드를 쓰는 회사에 필요한 개발 하네스 — AI 주도 개발(AIDD) 가드레일·국내외 동향·기업 도입 5단계

PART 01 · Answer제 앱과 웹 서비스도 AI 주도 개발이었습니다

AI 주도 개발(AIDD, AI-Driven Development)은 AI가 분석·설계·코딩·시험의 대부분을 수행하고, 사람이 방향과 승인을 맡는 개발 방식입니다. 자동완성을 보조 도구로 쓰는 단계와는 다릅니다. 에이전트가 여러 파일을 고치고, 시험을 돌리고, 빌드까지 이어 가는 단계입니다.

이 기준으로 보면 제 개발은 AI 주도 개발이었습니다. 대상은 아래와 같습니다.

표 전체가 보이지 않으면 좌우로 이동해 보세요.

네 앱은 각자 저장소를 갖지만 개발 규칙은 한 곳에서 옵니다. 공통 화면 골격은 ‘결(Gyeol)’이라는 공통 코드로 두었습니다. 제품군의 기준은 실록의 운영 절차와 온톨로지에 두고, 제품 기능과 사용자 데이터와 앱 시험은 각 앱 저장소가 맡습니다. 에이전트는 Claude Code와 Codex 두 엔진을 씁니다. 실록은 두 엔진에 같은 지침·기억·검사를 붙입니다.

실록은 앱을 실행하는 런타임이 아닙니다. 개발이 어떤 순서와 증거로 진행되는지를 통제하는 제어면입니다. 그래서 질문을 바꿔야 했습니다. 하네스가 있었는지보다, 하네스가 무엇을 막아 냈는지가 중요했습니다.

PART 02 · EvidenceAI는 개발 조직을 비추는 거울이자 증폭기입니다

구글 클라우드의 DevOps 연구·평가 프로그램(DORA)은 2025년 보고서에서 기술 전문가 약 5,000명을 조사했습니다. 소프트웨어 개발 전문가의 AI 도입률은 90%였고, 지난해보다 14% 늘었다고 밝혔습니다. 응답자의 80% 이상이 생산성이 올랐다고 했고, 59%는 코드 품질에 좋은 영향이 있었다고 했습니다.

신뢰는 다른 이야기였습니다. AI를 많이 신뢰한다는 응답은 24%였고, 조금 신뢰하거나 전혀 신뢰하지 않는다는 응답이 30%였습니다. DORA는 AI를 조직의 ‘거울이자 증폭기’라고 불렀습니다.

한 해 전 결과는 더 조심스러웠습니다. 2024년 보고서는 AI 도입이 25% 늘 때마다 배포 처리량이 1.5%, 배포 안정성이 7.2% 줄어드는 것으로 추정했습니다.

2025년에는 AI 도입과 배포 처리량의 관계가 긍정으로 바뀌었습니다. 그러나 배포 안정성과는 여전히 음(−)의 관계였습니다. DORA는 자동화된 시험, 성숙한 버전 관리, 빠른 피드백 같은 통제 체계가 없으면 늘어난 변경량이 불안정으로 이어진다고 설명합니다. 속도는 도구가 올려 주지만, 안정성은 따로 챙겨야 한다는 뜻입니다. 두 해의 조사는 표본이 달라 직접 비교하지는 않습니다.

비영리 AI 평가 연구소 METR의 2025년 7월 무작위 대조 실험은 체감과 실측의 차이를 보여 줍니다. 숙련된 오픈소스 개발자 16명이 익숙한 저장소의 실제 과제 246개를 풀었습니다.

표 전체가 보이지 않으면 좌우로 이동해 보세요.

이 결과는 2025년 초의 도구와 숙련자의 익숙한 저장소라는 조건에서 나왔습니다. 지금 도구에 그대로 옮길 수는 없습니다. 그래도 교훈 하나는 분명합니다. 사람은 AI가 자기를 얼마나 빠르게 하는지 잘 재지 못합니다. 그래서 도입의 첫 단계는 도구 선정이 아니라 기준선 측정입니다.

PART 03 · Landscape국내외 기업은 승인과 시험을 남긴 채 범위를 넓히고 있습니다

표 전체가 보이지 않으면 좌우로 이동해 보세요.

구글은 2026년 4월 클라우드 넥스트에서 새 코드의 75%를 AI가 만들고 엔지니어가 승인한다고 밝혔습니다. 지난가을 50%에서 늘어난 수치입니다. 같은 발표에서, 에이전트와 엔지니어가 함께한 복잡한 코드 이관이 1년 전 엔지니어만 할 때보다 6배 빨리 끝났다고 했습니다. 두 숫자 모두 자사 발표입니다. 눈여겨볼 단어는 ‘승인’입니다. 가장 앞선 회사도 AI가 만든 코드를 사람이 승인하는 구조를 유지합니다.

안전의 기준도 생겼습니다. 오픈 웹 애플리케이션 보안 프로젝트(OWASP)는 2025년 12월 에이전트 애플리케이션의 보안 위험 10대 목록을 냈습니다. 목표 탈취(ASI01), 도구 오용(ASI02), 통제를 벗어난 에이전트(ASI10)가 들어 있습니다. 개발 에이전트에도 그대로 해당하는 위험입니다. 개발 에이전트는 셸 명령을 실행하고 저장소에 직접 쓰기 때문입니다.

국내에서는 KT가 2026년 7월 데모데이에서 AID-X를 발표했습니다. 기존 AI 기반 개발 체계인 AIDD를 IT 업무 전반으로 넓힌 개념이고, 모든 IT 프로젝트에 ‘AID-X Must’를 적용한다고 했습니다. 시험 플랫폼으로 시험 시간 50% 단축, 품질 20% 향상, 시험 범위 80% 확대를 얻었다고도 밝혔습니다. 회사가 밝힌 수치이고, 기사에는 측정 방법이 나오지 않습니다.

LG CNS는 2025년 5월 데브온 AIDD를 내놓았습니다. 분석·설계·코딩·시험·품질 진단에 AI를 넣고, 코딩 에이전트가 생성→시험→수정을 반복하는 구조입니다. 기사에는 생산성 수치가 없습니다. 2026년 1월 22일에는 인공지능 기본법이 시행됐습니다. 생성형 AI 결과물의 표시와 고영향 AI의 의무를 담고 있습니다. 사내 개발 도구에 어떤 조항이 적용되는지는 법률 검토가 필요합니다.

해외는 AI가 만드는 코드의 비율을, 국내는 전사 의무화와 단계 확장을 말합니다. 공통점은 사람의 승인과 시험 단계를 남겨 둔다는 것입니다. 그 승인과 시험을 매번 같은 방식으로 돌리는 장치가 개발 하네스입니다.

PART 04 · Without하네스가 없을 때 무너진 곳은 속도가 아니라 완료였습니다

제 개발에서도 에이전트는 빨랐습니다. 무너진 곳은 속도가 아니라 ‘완료’라는 말의 뜻이었습니다. 아래 다섯 가지는 실제로 겪은 일입니다.

표 전체가 보이지 않으면 좌우로 이동해 보세요.

다섯 가지의 공통점은 에이전트가 거짓말을 한 것이 아니라는 점입니다. 검사가 통과했으니 통과라고 했고, 시험이 성공했으니 성공이라고 했습니다. 문제는 그 검사와 시험이 무엇을 보지 않는지 아무도 적지 않았다는 데 있었습니다.

동기화 검사는 수정 전 시험 6개 중 5개가 실패했고, 수정 뒤 6개가 모두 통과했습니다. 공유 작업 공간의 사고는 9월에만 세 번 났고, 문장으로 쓴 금지는 막지 못했습니다. 실행 직전에 막는 장치를 넣고 시험 14건으로 고정한 뒤에야 멈췄습니다. 에이전트가 빨라질수록 이런 빈틈도 더 빨리 쌓입니다.

PART 05 · GuardrailsPMO가 챙기던 기준과 증거를 하네스가 장치로 챙깁니다

범위 정의, 품질 게이트, 변경 통제, 독립 검증, 출시 결정. 개발 거버넌스의 이 다섯 기능은 AI 주도 개발에서도 그대로 필요합니다. 조직에 따라 PMO가 기준과 증거를 맡기도 하고, 자문만 하기도 합니다. 달라지는 것은 속도입니다. 에이전트가 하루에 수십 번 고치고 빌드하면 회의와 문서로는 따라갈 수 없습니다. 그래서 하네스는 기준 확인과 증거 수집을 장치로 옮기고, 최종 승인은 조직의 결정권자에게 남깁니다.

앱 네 개의 상용화를 검토할 때 이 원칙을 그대로 썼습니다. 배포 신뢰, 재현 가능한 후보, 설치와 제거, 핵심 작업, 데이터 안전처럼 출시 게이트 12개를 세웠습니다. 화면 사용성의 잠정 점수는 10점 만점에 6.5점, 베타 수준이었습니다. 판정은 상용 출시 보류였습니다. 게이트가 하나라도 미확인이면 평균 점수로 상쇄하지 않기로 했기 때문입니다.

에이전트는 점수를 올리는 데 능숙합니다. 그래서 출시는 점수가 아니라 게이트별 증거로 정해야 합니다. OWASP가 꼽은 도구 오용과 통제 이탈도 같은 장치로 줄입니다. 에이전트가 쓸 수 있는 명령과 경로를 좁히고, 위험한 명령은 실행 직전에 막고, 공개·발송·비용은 사람이 승인합니다. 검토도 같은 엔진에게 맡기지 않습니다. 생성한 엔진의 반대편 엔진이 고위험 산출물을 평가합니다.

PART 06 · Difference도입하면 달라지는 것은 숫자보다 ‘완료’의 무게입니다

표 전체가 보이지 않으면 좌우로 이동해 보세요.

정성적으로 가장 큰 차이는 ‘완료’라는 말의 무게였습니다. 하네스가 없을 때 완료는 에이전트의 보고였습니다. 하네스가 생긴 뒤 완료는 관측한 사용자 결과와, 확인하지 않은 범위를 함께 적은 기록이 됐습니다. 출시 보류라는 결정도 이 기록이 있었기에 내릴 수 있었습니다.

정량적으로는 세 곳이 달라졌습니다. 상시 지침의 규칙 중 집행 장치가 붙은 비율은 10월 19일 정리 직후 53.7%였고, 11월 3일 68.2%가 됐습니다. 그사이 규칙 수가 41개에서 110개로 늘었으므로 같은 집합의 비교는 아닙니다. 빌드 쪽에서는 이 Mac을 자가 러너로 붙이자 같은 입력기 빌드가 12.4분에서 8.2분이 됐습니다. 호스티드 macOS로 돌렸다면 그 앱 하나만 월 약 $136어치였고, 예산은 $20이었습니다. 저장소의 CI는 운영체제별로 등급을 나눠 30일 가중 사용량을 4,826분에서 1,262분으로 줄였습니다.

하네스에도 비용이 있습니다. 운영 관측 장치가 221개로 늘어 스스로 정한 예산 215개를 넘었습니다. 그래서 새 장치는 하나를 들이면 하나를 퇴역시키는 규칙을 세웠습니다. 하네스를 들이는 회사도 장치의 수에 예산을 두어야 합니다.

PART 07 · Strategy도입은 측정에서 시작해 출시 게이트에서 끝납니다

표 전체가 보이지 않으면 좌우로 이동해 보세요.

이 순서는 제 경험에서 나온 설계안입니다. 단계별 기간과 인원은 조직 규모에 따라 달라 적지 않았습니다. 첫 단계를 건너뛰지 마십시오. METR의 실험처럼 체감은 실측과 반대로 갈 수 있습니다. 기준선이 없으면 도입 효과를 말할 수 없고, 하네스의 비용도 정당화할 수 없습니다.

두 번째 단계는 범위를 좁히는 일입니다. 저는 ‘중요한 사용자 흐름을 먼저 선정해 구현·시험에 집중한다’는 규칙을 지침에 두었습니다. 흐름 하나를 끝까지 닫으면, 그 흐름의 증거가 다음 흐름의 기준이 됩니다. 전사 의무화는 장치와 증거가 쌓인 다음 단계입니다.

역할도 나눕니다. 개발 리더는 장치를 만들고, PMO는 게이트와 완료 증거를 정의하고, 보안 조직은 권한의 경계를 정합니다. 에이전트의 지침 파일에는 아래 다섯 줄부터 넣어 보십시오.

# AI 주도 개발 — 완료 계약 (에이전트 지침 파일에 붙여 넣기)
1. 작업 전: 이번에 끝낼 사용자 흐름 1개와 관측 가능한 완료 기준을 적는다.
2. 완료 보고: 실행한 시험·검사와, 그 검사가 보지 않는 범위를 함께 적는다.
3. 빌드가 실패한 뒤에는 이전 빌드의 실행 결과를 증거로 쓰지 않는다.
4. 공유 작업 공간에서 남의 변경을 숨기거나 되돌리는 명령을 쓰지 않는다.
5. 공개·발송·비용·삭제·출시는 사람에게 확인받는다.

PART 08 · Limits이 글이 말하지 않는 것

제 기록은 한 사람의 개발 기록입니다. 팀 규모가 크거나 레거시 코드가 많거나 규제 산업이라면 장치의 우선순위가 다를 수 있습니다. 제 앱들은 아직 베타이고, 상용 출시를 보류했습니다. 이 하네스로 상용 제품을 출시한 사례는 아직 없습니다.

하네스의 효과를 DORA 지표로 전후 비교하지 않았습니다. 그림 4의 숫자는 장치 하나하나가 한 곳의 비용이나 위험을 줄인 기록이지, 하네스 전체의 효과가 아닙니다.

외부 수치는 조사 방식이 서로 다릅니다. DORA는 설문, METR는 소규모 무작위 대조 실험, 기업 수치는 자사 발표입니다. 서로 직접 비교하지 않았습니다. 인공지능 기본법의 적용 범위는 법률 검토가 필요하며, 이 글은 법률 판단을 하지 않습니다.

PART 09 · Closing이번 주에 시작할 수 있는 일

세 줄로 다시 정리합니다. AI는 조직의 습관을 키우고, 체감과 실측은 어긋납니다. 그래서 AI 주도 개발에는 PMO가 챙기던 기준과 증거를 장치로 옮긴 개발 하네스가 필요합니다. 도입은 기준선과 핵심 흐름 하나에서 시작하고, 출시는 증거로 정합니다.

이번 주에는 30분만 쓰십시오. 에이전트가 지난주에 ‘완료’라고 보고한 작업 하나를 골라 아래 한 줄을 채웁니다. 이 한 줄이 1단계 기준선 표의 첫 행이 됩니다.

완료 보고: ______ · 실제로 확인한 사용자 결과: ______ · 확인하지 않은 범위: ______

세 번째 칸을 채우지 못했다면, 위 완료 계약의 2번을 지침 파일에 넣으십시오. 그다음 2주 동안 같은 한 줄을 모으면서, 저장소와 CI 기록에서 리드타임과 변경 실패율을 뽑아 기준선 표를 채웁니다. 채운 표가 팀의 첫 완료 증거입니다.

함께 읽으면 좋은 글은 좋은 모델이 아니라 좋은 하네스가 성과를 만든다 — 하네스 엔지니어링과 실록(Sillok) 구조 매핑과 무엇을 위임하고 무엇을 사람이 쥐는가 — 업무 원형 22개에서 나온 하나의 경계선입니다.

경험으로 배운 하네스 운영 교훈

1. AI 에이전트가 느리다는 불만, 모델보다 왕복 수부터 세십시오
2. AI 에이전트 비용은 토큰 총량이 아니라 성공 작업당 비용으로 봅니다
3. AI 가드레일은 지침 문장이 아니라 집행 장치입니다
4. AI 운영 대시보드를 늘리기 전에 ‘끄면 무엇이 달라지는가’를 물으십시오
5. 기업 AI의 기억은 쌓기보다 꺼내는 길이 먼저입니다
6. 특별편: AI가 코드를 쓰는 회사에 필요한 개발 하네스 (이 글)