지난 십수 년간의 개발 현장을 지켜보고 있으면, 어떤 일관된 흐름이 보입니다.

• 데이터베이스의 변경은 수작업 SQL에서 마이그레이션 파일(Flyway / Liquibase / Rails migration)로
• 인프라는 콘솔에서의 클릭 작업에서 IaC(Infrastructure as Code: Terraform / CDK)로
• 앱의 설정도, 파이프라인도, 모니터링 규칙도, 문서조차도 차례차례 코드가 되었다
• 그리고 결정적으로, **도표(아키텍처 도표·시퀀스 도표)**조차 Mermaid나 PlantUML을 통해 "텍스트"가 되었다

이른바 Everything as Code로의 수렴입니다. 그리고 이 흐름을 Git을 통한 이력 관리와 CI/CD가 뒷받침해 왔습니다. "diff를 낼 수 있다", "리뷰할 수 있다", "테스트할 수 있다", "기계가 정확하게 재현한다"——이러한 요소들이 쌓여 지금의 개발 경험이 존재합니다.

여기에 이르러, AI에 의한 코딩, 그리고 코드를 읽고 시스템을 파악·조사하는 작업까지 AI가 해내게 되었습니다.

이것은 이제,

Everything as Code의 완전한 종착점이 온 것이 아닌가?

……라고, 처음에는 생각했습니다. 하지만 조금 멈춰 서서 생각할수록, "종착점"이라는 단어가 의심스러워졌습니다. 이 기사는 그 사고의 기록입니다. 판단은 읽어주시는 여러분께 맡기겠습니다.

솔직하게 정리하자면, 다음과 같이 보입니다.

모든 것이 코드라는 **기계 가독형 텍스트(machine-readable text)**로서 표현되게 되었다. 그렇기에 그 텍스트를 대규모로 읽고 쓸 수 있는 AI가 이 세계의 "마지막 퍼즐"로서 끼워 맞춰졌다——.

특히 효과적인 것이 "코드를 읽어서 파악·조사하는" 부분입니다.

• Terraform으로 작성된 인프라는 인간도 AI도 읽을 수 있다
• 콘솔에서 클릭으로 만든 인프라는 인간도 AI도 추적할 수 없다

시스템이 source of truth로서 코드에 집약되어 있기 때문에 AI가 그것을 해독할 수 있습니다. 이 맞물림은 확실히 "골(Goal)에 도달했다"라고 느끼게 할 만큼의 설득력이 있습니다.

하지만 여기서부터 두 가지 각도에서 흔들어 보겠습니다.

Everything as Code가 추구해 온 본질적인 가치는 무엇이었는가.

**결정성(Determinism)·재현성(Reproducibility)·리뷰 가능성(Reviewability)**입니다.

코드를 공통 언어로 삼은 이유는 diff를 낼 수 있고, 테스트할 수 있으며, 기계가 정확하게 실행할 수 있기 때문입니다. 요컨대 이것은 "모호함과 수작업을 배제하는" 운동이었습니다. 동일한 입력으로부터 동일한 결과가 나온다는 약속 위에 성립되어 있습니다.

그런데 자연어 프롬프트로부터 코드를 생성한다는 행위는, 동일한 입력으로부터 다른 출력이 나올 수 있는 비결정적인(non-deterministic) 층을 그 위에 얹는 행위입니다.

즉 AI 코딩은 방향성 측면에서 지금까지의 "모호함을 깎아내는" 흐름과 어떤 부분에서는 정반대의 성질을 도입하고 있습니다. 따라서 "지금까지의 흐름의 순수한 종착점"이라고 단일하게 파악해 버리면 이 마찰을 놓치게 됩니다. 같은 화살표의 끝단이 아닙니다.

이 부분이 가장 흥미로운 지점이라고 생각합니다.

Everything as Code는 딱히 AI를 목표로 나아온 것은 아닙니다. 하지만 결과적으로, AI가 움직이기 위한 최상의 기반(substrate)을 준비해 버렸다는 관점이 가능합니다.

시스템이 기계 가독형 텍스트로 표현되어 있으면 있을수록, AI는 그것을 대규모로 읽어낼 수 있습니다. 뒤집어 말하면, GUI 조작으로 만들어진 "코드가 되지 않은 현실"은 AI에게도 거의 손을 댈 수 없는 영역입니다.

즉,

• as code와 AI는 정점과 바닥의 관계가 아니라, 상보적인 관계
• AI는 "흐름의 정점에 선 왕"이 아니라, "as code가 깔아놓은 레일 위를 달리는 새로운 종류의 이용자"

이 편이 실태에 더 가까운 느낌이 듭니다.

서두에서 살짝 언급한 "도표가 Mermaid / PlantUML로 텍스트가 되었다"는 점은 이 각도 ②의 이야기를 깔끔하게 보강합니다.

과거에 아키텍처 도표라고 하면 Visio나 파워포인트로 그리는 바이너리 결과물이었습니다. diff는 낼 수 없고, 리뷰는 "겉모습을 육안으로 비교"하며, 무엇보다——기계는 그 내용을 읽을 수 없습니다.

그것이 이제는 이렇게 쓸 수 있습니다.

이 도표는 렌더링하면 인간이 읽을 수 있는 도표인 동시에, 그대로 텍스트=코드입니다. Git으로 diff를 낼 수 있고, PR로 리뷰할 수 있으며, 그리고 AI가 읽고 쓸 수 있습니다.

즉 「그림을 코드로 만든다」는 일견 니치(niche)해 보이는 진화는, 단순한 편의성이 아니라, "인간만이 해석할 수 있었던 마지막 영역 중 하나"를 기계 가독성(machine-readable)이 있는 source of truth(신뢰할 수 있는 단일 원천)의 측면으로 끌어들인 사건이었습니다. Everything as Code의 "Everything"이 한 걸음 더 넓어졌고——그만큼 AI가 소화할 수 있는 면적도 넓어졌다는 뜻입니다.

「종착점」을 의심해야 하는 이유를 조금 더 구체적으로 나열해 보겠습니다.

AI는 "그럴싸한" 코드를 내놓습니다. 문제는 그것이 정말로 올바른가 하는 점입니다. 그리고 그것을 잡아낼 장치야말로——테스트(test), 타입(type), CI, 리뷰(review), 이력(history), 즉 Everything as Code가 쌓아온 규율 그 자체입니다.

따라서 AI 시대에 이 규율의 가치는 떨어지기는커녕, 오히려 올라갑니다. 이 점은 상당히 확신을 가지고 말씀드릴 수 있습니다.

그리고 이것은 현장에서 지금 바로 일어나고 있는 생생한 이야기입니다.

AI에 의해 코드를 작성하는 비용은 극적으로 낮아졌습니다. 하지만 그 리뷰(review) 비용은 거의 낮아지지 않았습니다. 오히려 늘어나고 있습니다.

결과적으로 어떤 일이 벌어질까요?

• 생성량이 늘어남 → PR(Pull Request)의 수와 입도(granularity)가 팽창함 - 리뷰어의 인원과 시간은 그렇게 쉽게 늘어나지 않음
• **리뷰가 새로운 병목(bottleneck)**이 되어, 머지(merge) 대기 중인 PR이 쌓임

게다가 까다로운 점은, AI 생성 코드의 리뷰가 질적으로도 무거워진다는 점입니다. 인간이 작성한 코드라면 "이 사람은 이 부분을 이해하고 작성했다"라는 전제가 작동하지만, AI 생성 코드는 "그럴싸하게 동작해 버리는" 만큼, 리뷰어가 정말로 의도대로인지, 함정(pitfall)은 없는지를 더욱 깊게 의심하며 접근해야만 합니다. "언뜻 보기에는 깔끔하지만, 요구사항을 미묘하게 벗어나 있는 것"을 간파하는 부하는 결코 가볍지 않습니다.

당초 이 절은 「현장의 체감」으로서 작성했으나, 확인해 보니 엄연한 조사 결과였습니다.

먼저 **Google의 DORA 리포트(2024)**의 유명한 지견입니다. AI 활용이 25% 증가할 때마다, 딜리버리(delivery)의 처리량(throughput)은 추정 약 1.5% 저하되고, 시스템의 안정성은 추정 약 7.2% 저하된다는 내용입니다. 응답자의 약 40%가 "AI 생성 코드를 거의/전혀 신뢰하지 않는다"라고 답하기도 했습니다. 개인의 생산성은 올라가고 있는데 시스템 전체로는 개선되지 않는다——이 일견 모순된 결과의 한 원인이 바로 하류(downstream)에 쌓이는 리뷰, 테스트, 배포(deploy)의 정체입니다.

그리고 DORA 2025는 이 부분을 더욱 깊게 파고들어, DORA 연구자 스스로가 "코드 리뷰는 오랫동안 병목(bottleneck)으로 남아 있었다. AI로 작성하는 양이 10배, 100배가 되어도, 리뷰하는 능력은 올라가지 않으므로, 리뷰는 오히려 더욱 가혹한 제약이 될 것이다"라는 취지의 지적을 하고 있습니다. DORA는 대책으로서 **작은 배치(small batch, 즉 작은 PR)**와 **강력한 버전 관리(version control)**를 반복해서 권장하고 있습니다.

정량적인 뒷받침으로는, Faros AI가 2025년에 1,000개 이상의 팀과 1만 명 이상의 개발자를 분석한 조사가 이해하기 쉽습니다. AI 활용도가 높은 팀은 태스크 완료는 21% 증가, 머지된 PR은 98% 증가하며 생산성이 올라간 반면, PR 리뷰 시간은 약 91% 증가, 평균 PR 사이즈는 약 154% 증가, 버그는 약 9% 증가했습니다. 게다가 조직 수준의 DORA 지표에는 눈에 띄는 개선이 보이지 않았다는 결과였습니다 (출처: Faros AI, 2025).

※ 수치의 출처는, DORA의 비율값은 Google Cloud / dora.dev의 2024년 공식 발표, PR 관련 정량값은 Faros AI의 2025년 텔레메트리(telemetry) 조사입니다. DORA 자체가 "리뷰 시간 ◯% 증가"라고 수치를 낸 것은 아니라는 점만 정확을 기하기 위해 보충해 둡니다.

즉——AI는 개발의 제약 단계(rate-limiting step)를 작성 공정에서 리뷰 공정으로 이동시켰을 뿐이라고도 할 수 있습니다. 전체 처리량(throughput)을 높이고 싶다면, 다음에 효과적인 것은 "어떻게 하면 빠르고 대량으로 작성할 것인가"가 아니라, "어떻게 리뷰를 빠르고 확실하게 돌릴 것인가"입니다. 여기서도 효과를 발휘하는 것은 테스트, 타입, CI, 작은 PR 분할, 리뷰 관점의 명문화와 같은 Everything as Code의 규율입니다.

이것이야말로 AI가 「골(goal)」이 아니라 「새로운 병목을 만드는 시작」이었다는 점을 보여주는 가장 알기 쉬운 증거라고 생각합니다.

코드에 나타나는 것은 **what(무엇을)**과 **how(어떻게)**입니다. 하지만 why(왜)——요구사항의 배경, 의사결정의 트레이드오프(trade-off), 왜 이 설계가 "아닌" 안을 버렸는지——는 많은 경우 어디에도 적혀 있지 않습니다.

AI는 코드로부터 why(이유)를 "읽을" 수 있는 것이 아닙니다. 조직의 암묵지(tacit knowledge)는 여전히 코드 외부에 존재합니다.

데이터 그 자체: 스키마는 코드로 구현할 수 있어도, 그 내용은 별개의 문제입니다. 실행 시의 상태(runtime state), 보안의 적대적 경계(adversarial boundary), 인시던트 발생 시의 판단, 조직의 프로세스나 정치 등 말이죠.

VCS도, IaC도, CI/CD도, 등장한 순간에는 "이것으로 개발은 완성이다"라고 보였습니다. "완전한 목표"라는 **finality(최종성)**의 감각은, 경험칙상 오히려 의심해 보아야 할 신호일지도 모릅니다.

그렇기에, "목표에 도달했다"가 아니라, 다음과 같이 치환하는 것이 정확하다고 생각합니다.

코드가 source of truth(진실의 원천)인 지위는 그대로 유지하되, 그 "저자"가 인간에서 AI + 인간으로 옮겨가는 국면.

이렇게 파악하면, 관점 ①의 마찰도, 남겨진 잔여물도 무리 없이 수렴됩니다.

그리고, 여기서부터 진짜 논점이 있습니다.

코드라는 계층은 이대로 남을 것인가?

아니면, 자연어로 작성된 "의도(spec)"가 진정한 source of truth가 되고, 코드는 어셈블러처럼 "더 이상 리뷰하지 않는 생성물"로 물러나게 될 것인가?

이 부분은 아직 전혀 결론이 나지 않았습니다. 만약 후자로 기울어진다면, 그것은 Everything as Code의 종착점이 아니라, **덮어쓰기(overwrite)**가 됩니다.

참고로, 앞서 언급한 "리뷰가 병목(bottleneck)이 되는" 문제는 이 논점과 맞닿아 있습니다. 생성된 코드를 인간이 한 줄씩 따라갈 수 없게 되었을 때, 우리는 무엇을 리뷰의 source of truth로 삼을 것인가. 코드 그 자체인가, 그것을 구속하는 테스트와 타입(type)인가, 아니면 의도(spec)인가——병목의 위치를 결정하는 것이 곧 "무엇을 진실의 원천으로 간주할 것인가"의 선택이 될 것이라고 생각합니다.

그래서, 이렇게 말하고 싶습니다.

AI 코딩은 목표가 아니라, 시작이었다.

Everything as Code가 마련한 기계 가독형(machine-readable) 세계 위에서, 드디어 다음 게임이 시작된 것이라고 생각합니다.

"Everything" as Code라고 말하면서도, 솔직히 아직 코드에 담지 못했거나(혹은 담기 어려운) 것들을 비망록 삼아 나열해 둡니다. 이견이나 추가는 언제든 환영입니다.

영역	왜 어려운가
의사결정의 "why"	ADR(Architecture Decision Record)로 노력해도, 버린 안이나 역학 관계, 분위기까지는 남지 않음
데이터의 내용	스키마는 작성할 수 있어도, 운영 데이터의 실체·편향·오염은 코드 외부에 있음
운영 시의 "감"	"이 알람은 무시해도 된다"와 같은 현장 지식은 Runbook화 해도 빠져나감
조직·인간관계	승인 프로세스, 책임 분계, 정치. 도표로는 그릴 수 있어도 재현은 불가능함
보안의 적대성	방어하는 측은 코드로 구현할 수 있지만, 공격하는 측의 창의성은 우리의 상상 밖에서 옴
심미적·UX 판단	"왠지 구리다"를 만족시키는 테스트는 아직 작성할 수 없음

코드로 만들 수 있는 영역이 넓어질수록, 코드로 만들 수 없는 영역의 윤곽이 뚜렷하게 보인다는 것——이것이 개인적으로 가장 납득이 가는 감각입니다. Everything as Code의 "Everything"은 아마 앞으로도 완전히 채워지지 않을 것입니다. 하지만 채워지지 않는 부분이 어디인지 알고 있다는 사실 자체가, 이 시대의 엔지니어링일지도 모릅니다.

"AI 코딩은 지금까지의 기술 흐름의 종착점인가?"

저의 잠정적인 대답은, **"종착점으로 보이지만, 사실은 다음의 시작이다"**입니다. 물론 이것은 어디까지나 하나의 관점일 뿐입니다. 같은 흐름을 보더라도 "역시 목표에 가깝다"고 느끼는 분이 있을 것이고, "애초에 전제가 다르다"고 생각하는 분도 있을 것입니다. 다양한 생각이 존재할 수 있는 주제라고 생각합니다.

여기까지 함께해 주셔서 감사합니다. 이 글이 여러분이 스스로의 위치를 고민하는 데 있어 작은 토론의 장(draft)이 된다면 기쁘겠습니다.