제1원리에서 출발하는 AI-first 소프트웨어 설계: 실무자 가이드

대부분의 팀은 그 아래 있는 가정을 하나도 수정하지 않고 AI를 도입했다 — 그래서 산출물은 빨라지고 시스템은 나빠졌다.

대부분의 엔지니어링 팀이 아직 소리 내어 말하지 않은 질문이 여기 있다. 모델이 코드를 쓸 수 있다면, 우리는 이제 정확히 무엇을 잘해야 하는가?

내가 듣는 답은 대체로 방어적이다. 프롬프트 엔지니어링. AI 산출물 검토. 어떤 도구를 집어야 할지 아는 것. 모두 진짜 기술이고, 모두 실제 전환의 하류에 있으며, 그중 어느 것도 내가 실무에서 계속 보는 것을 설명하지 못한다 — 같은 도구를, 같은 분기에, 같은 모델로 도입한 팀들이 완전히 다른 곳에 도달한다. 한 그룹은 더 빨리 배포하고 소프트웨어가 버틴다. 다른 그룹은 더 빨리 배포하고 다음 분기를 자기가 무엇을 망가뜨렸는지 알아내는 데 쓴다.

같은 도구. 반대의 결과. 그 차이는 모델에 관한 것이 아니다.

아무도 계산에 넣지 않은 증폭기

DORA의 2025년 《State of AI-assisted Software Development》가 이것에 숫자를 붙였다. 기술 전문가의 90%가 이제 업무에서 AI를 쓰고, 80% 이상이 그것이 자신의 생산성을 높였다고 믿는다. 둘 다 놀랍지 않다. 중요한 발견은 세 번째다. 더 높은 AI 도입은 소프트웨어 배포 처리량의 증가와 소프트웨어 배포 불안정성의 증가와 동시에 연관된다.

다시 읽어 보라. 그것이 논증 전부다. 그 도구는 팀을 배포에서 더 빠르게, 계속 돌아가게 하는 일에서 더 나쁘게 만들었다. 둘 중 하나가 아니다. 둘 다.

DORA의 표현은 AI가 증폭기라는 것이다 — 그것이 착지한 어떤 실천이든 확대한다. 강한 시스템은 더 강해진다. 약한 시스템은 더 빠르게 약해진다.

즉 흥미로운 질문은 애초에 「어떻게 AI를 도입할까」가 아니었다. 「AI가 우리에게서 무엇을 증폭할까」였다. 그리고 그것에 답하려면 어떤 도구 결정보다 더 뒤로 돌아가야 한다.

도구가 아니라 문제로부터 추론하라

제1원리 사고는 의미를 잃을 정도로 반복된 표현 중 하나이므로, 내가 무엇을 뜻하고 무엇을 뜻하지 않는지 구체적으로 말하겠다.

유추에 의한 추론은 대부분의 AI 도입이 보였던 모습이다. 우리에게 개발 워크플로가 있었다. 새 역량이 도착했다. 우리는 그 역량이 워크플로의 어디에 들어맞는지 물었고, 저항이 가장 적은 지점 — 보통 코드 작성 — 에 그것을 넣고 나머지 전부는 그대로 두었다. 스탠드업, 티켓, 스프린트, 리뷰 모두 보존되었다. 워크플로는 주어진 것으로 취급되고 도구가 그것에 맞춰졌다.

제1원리에서 추론하는 것은 더 어려운 질문을 한다. 소프트웨어를 만드는 일에 관해 실제로, 물리적으로 사실인 것까지 과정을 벗겨 내라. 그다음 그 진실들 중 모델이 무엇을 바꿨고 무엇을 건드리지 않았는지 물어라. 살아남은 것으로부터 다시 세워라.

정직하게 해 보면, AI가 정확히 한 가지를 바꿨음을 발견한다 — 그리고 그것은 이 카테고리가 팔아 온 그것이 아니다.

코드를 생산하는 비용이 거의 0으로 갔다. 코드가 무엇이어야 하는지 결정하는 비용은 움직이지 않았다.

유용한 모든 것이 이 하나의 비대칭에서 흘러나온다. 아래는 어떤 실무자든 기억에서 진술할 수 있어야 한다고 내가 생각하는 네 가지 결과다.

하나: 데이터 모델이 곧 제품이다

화면은 어떤 애플리케이션에서든 가장 변덕스러운 부분이고, 시작하기에 가장 유혹적인 곳이다. 볼 수 있는 부분이기 때문이다. 동시에 버리기에 가장 저렴해야 하는 부분이다.

데이터 모델은 그 반대다. 그것은 무엇을 물을 수 있는지, 무엇을 인덱싱할 수 있는지, 모두를 겁먹게 하는 마이그레이션 없이 나중에 무엇을 바꿀 수 있는지를 결정한다. 하류의 모든 역량은 그 계층에서 내려졌거나 즉흥적으로 만들어진 선택에 의해 제약된다.

코드가 비쌌을 때 이 순서는 스스로를 강제했다. 아무도 생각해 보지 않은 스키마에 맞춰 화면 백 개를 손으로 쓰지 않았다. 화면 백 개를 손으로 쓰는 데 한 분기가 걸렸기 때문이다. 생성이 그 자연스러운 관문을 없앴다. 이제 어떤 사람도 검토하지 않은 데이터 모델에 맞춰 인터페이스 전체를 만들어 낼 수 있고, 그것은 완성된 것처럼 보일 것이다.

그러니 이 순서는 의도적인 것이 되어야 한다. 모델 먼저, 다음 계약, 다음 인터페이스. 그것이 전통적이기 때문이 아니라 — 비싼 결정이 아직 바꾸기 저렴한 동안 내려지는 유일한 순서이기 때문이다.

둘: 미룬 결정도 결국 내려진다

이것이 실무자들이 과소평가하는 것이다.

당신이 명시적으로 내리지 않은 모든 결정은 그럼에도 내려진다. 그것은 생성 시점에 생성기에 의해, 당신의 비즈니스와 당신의 규제 표면과 당신의 마이그레이션 이력과 다음 분기 계획을 포함하지 않는 맥락에서 내려진다. 모델은 결정을 거부하지 않는다. 그럴듯한 것을 하나 고르고 계속 간다.

구독이 취소된 사용자는 여전히 무엇을 볼 수 있는가? 두 사람이 같은 레코드를 편집하면 무슨 일이 벌어지는가? 이메일 주소는 유일한가, 그리고 무엇에 걸쳐 유일한가? 아무도 그 질문을 프롬프트하지 않았으니 아무도 답하지 않았다 — 그런데 애플리케이션은 이제 세 가지 모두에 대한 답을 갖고 있다. 추론으로 선택되었고, 프로덕션에서 부딪혀야만 발견되는 답을.

이것이 빌더 커뮤니티가 70% 문제라 이름 붙인 것 뒤의 메커니즘이다. 진전이 멈추는 것은 남은 작업이 어렵기 때문이 아니라, 남은 작업이 수백 세대 전에 조용히 내려진, 전체를 뜯어내지 않고는 더 이상 바꿀 수 없는 결정들에 막혀 있기 때문이다.

이것을 고치는 실천에는 이제 이름이 있다. 명세 주도 개발. 요구사항과 제약과 성공 기준을 먼저 적어라. 그 문서를 사실의 원천으로 대하라. 에이전트가 그것에 맞춰 만들게 하라. GitHub은 Spec Kit을 냈고, AWS는 Kiro를 냈으며, 그 수렴은 우연이 아니다.

셋: 생성이 무료일 때 제약은 반드시 적혀 있어야 한다

수십 년 동안 정확성은 부분적으로 코드를 쓰는 비용에 의해 지탱되었다. 규칙을 구현하는 개발자는 그 규칙을 머릿속에 담고 있어야 했다. 인간의 머릿속 암묵지는 제약을 저장할 만한 장소였다. 사람이 언제나 루프 안에 있었기 때문이다.

그 저장 위치는 더 이상 작동하지 않는다. 제약이 기계가 읽을 수 있는 어딘가에 표현되지 않았다면 — 스키마 제약, 타입, 검증 규칙, 테스트, 명세의 명시적인 한 줄 — 생성기에게 그것은 존재하지 않는다. 그것은 곧 놀라게 될 누군가의 기억 속에만 존재한다.

이것이 AI-first 설계의 실무적 핵심이고, 화려하지 않다. 불변식을 그것을 강제할 수 있는 계층까지 밀어 내려라. 폼 핸들러가 아니라 데이터베이스의 not-null과 unique. 코드 주석이 아니라 경계의 타입. 누군가 엔드포인트에 쓰기를 기억한 조건이 아니라, 시스템이 평가하는 정책으로서의 인가.

당신이 외부화한 모든 제약은 모델이 더 이상 틀릴 수 없는 하나의 결정이다.

넷: 이제 당신은 두 종류의 소비자를 위해 만든다

마지막이 가장 새롭고, 대부분의 팀이 전혀 내재화하지 못한 것이다.

당신의 애플리케이션에는 이제 두 종류의 사용자가 있다. 하나는 화면을 보는 사람이다. 다른 하나는 API를 호출하는 에이전트로, 당신의 인터페이스를 결코 보지 않으며 좋은 디자인으로 설득될 수 없다. 어떤 역량이 당신의 UI에는 있고 당신의 API에는 없다면, 에이전트 경제 관점에서 그것은 존재하지 않는다.

거기에는 설계상의 결과가 있다. 대등성은 있으면 좋은 것이 아니다. 사람이 인터페이스를 통해 할 수 있는 모든 것은 정의되고 문서화되고 발견 가능한 표면을 통해 닿을 수 있어야 한다. 에이전트 소비에 대해 GraphQL이 REST보다 더 잘 맞아 온 이유도 그것이다 — 자기 서술적 스키마는 사람이 먼저 통합 메모를 쓰지 않아도 기계가 탐색할 수 있는 것이다.

에이전트를 위해 만들면 인간 인터페이스는 부수 효과로 더 단순해진다. 사람만을 위해 만들면 기한 압박 아래 API를 나중에 얹게 되는데, 그것은 API를 설계하기에 가능한 최악의 시점이다.

이것을 건너뛰면 데이터에서 어떻게 보이는가

GitClear는 2023년부터 2026년까지 6억 2,300만 건의 코드 변경을 분석했고, 유지보수성의 그림은 위의 모든 것과 일치한다.

2023년 기준선 대비 중복 코드 블록이 81% 증가했다. 커밋 내 복사·붙여넣기가 2022년 9.4%에서 2026년 상반기 15.7%로 상승했다. 오류를 감추는 구조가 47% 증가했다. 동시에 파일 간 함수 호출 — 코드 재사용의 가장 명확한 신호 — 은 35% 감소했고, 리팩터링 활동은 2022년 변경의 21%에서 2026년 현재까지 3.8%로 붕괴했다.

개발자는 이제 리팩터링할 가능성보다 복사·붙여넣기할 가능성이 대략 다섯 배 높다. 2022년에는 이 비율이 반대였다.

이 중 어느 것도 모델 품질 문제가 아니다. 재사용 대신 중복, 드러내는 대신 삼켜 버리는 오류 처리, 더 이상 일어나지 않는 리팩터링 — 이것들은 생성이 저렴하고 구조가 아무의 명시적인 일도 아닐 때 얻는 것이다. 산출물은 국지적으로는 그럴듯하고 전역적으로는 일관성이 없으며, 그것은 화면부터 시작하는 워크플로가 감지할 수 없는 바로 그 실패 양상이다.

이번 주부터 이렇게 일하는 방법

이 중 어느 것도 조직 개편을 요구하지 않는다. 네다섯 개 습관의 순서를 바꾸기를 요구한다.

1. 첫 화면 전에 데이터 모델을 쓰라. 엔티티, 관계, 카디널리티, 무엇이 행을 유일하게 만드는지, 삭제 시 무엇이 연쇄되는지. 여기서의 한 시간이 프로젝트에서 레버리지가 가장 높은 한 시간이며, 도구들이 적극적으로 건너뛰라고 권하는 바로 그 한 시간이다.
2. diff가 아니라 명세를 리뷰 대상으로 삼으라. 명세가 올바르고 생성이 그것에 충실하다면, 생성된 코드 수천 줄을 리뷰하는 것은 연극이다. 그것을 만들어 낸 문서를 리뷰하라. 논쟁이 아직 저렴한 동안 명세를 두고 논쟁하라.
3. 이름 붙일 수 있는 모든 제약을 외부화하라. 생성하기 전에, 결코 위반되어서는 안 되는 규칙을 나열하고 각각을 시스템이 강제하는 곳에 두어라. 대화 속에 남아 있는 것은 결국 그 대화에 참여하지 않았던 무언가에 의해 위반될 것이다.
4. API를 제품 표면으로 설계하라. 그다음 인간 인터페이스를 그것의 한 소비자로 대하라. 이것은 엔지니어링 선택보다 순서에 관한 선택이며, 그것을 늦게 배치하는 것이 그것을 비싸게 만드는 원인이다.
5. 처리량만이 아니라 불안정성도 계측하라. DORA의 발견은 속도와 취약성이 함께 올랐다는 것이므로, 속도만 측정하면 자기 추세의 좋은 절반만 보게 된다. 변경 실패율과 복구 시간이 증폭기가 당신을 위해 작동하는지 알려 주는 숫자다.

이것이 드는 비용

트레이드오프가 없는 척하기보다 그것에 대해 솔직하고 싶다.

이렇게 일하는 것은 프로젝트의 첫 주에는 더 느리고 그 뒤 모든 주에는 실질적으로 더 빠르다. 그것은 실재하는 비용이며, 앞단에서, 추진력이 가장 가치 있게 느껴지고 경쟁사가 눈에 보이는 무언가를 배포하는 바로 그 순간에 지불된다. 이것을 전부 건너뛴 팀이 이기고 있는 것처럼 보이는 스프린트가 있을 것이다.

규율 면에서도 무료가 아니다. 제약을 적어 두는 일은 인터페이스가 나타나는 것을 보는 것만큼 즐겁지 않다. 명세를 리뷰하는 일은 코드를 리뷰하는 것만큼 만족스럽지 않다. 이 습관들은 기한 압박 아래 부식하며, 그것이 바로 그것들을 중요하게 만드는 같은 압박이다.

그리고 그중 일부는 정말로 적용되지 않는다. 이번 주말에 아이디어를 검증하고 결과를 버릴 생각이라면 버려라 — 수명이 이틀인 소프트웨어에 위의 어느 것도 할 가치가 없다. 여기서의 논증은 자기 데모보다 오래 사는 애플리케이션에 관한 것이다.

결코 자동화될 수 없었던 부분

코드 생산을 중심으로 세워진 일부 역할은 줄어들 것이다. 일부는 사라질 것이다. 아니라고 하는 것은 누구의 준비에도 도움이 되지 않으며, 모든 엔지니어링 일자리가 안전하다고 말하는 사람들은 당신에게 호의를 베풀고 있는 것이 아니다.

하지만 그 비대칭이 실제로 무엇을 했는지 보라. 그것은 결정의 표현을 자동화했고 결정 자체는 전혀 건드리지 않았다. 무엇을 만들 것인가. 무엇을 만들지 않을 것인가. 어떤 불변식이 성립하는가. 시스템이 결코 해서는 안 되는 것은 무엇인가. 경계가 어디에 있고 누가 그것을 넘도록 허용되는가.

그 작업은 언제나 어려운 부분이었다. 그것은 다만 타이핑이라는 노동 아래 묻혀 있었고, 타이핑은 그것이 곧 일처럼 보일 만큼 비쌌다.

타이핑은 결코 일이 아니었다.

더 읽을 거리

이 실천의 심화 버전: 명세 주도 개발. 도구를 고르고 있다면: 2026년 최고의 AI 앱 빌더.

자주 묻는 질문

「AI-first 소프트웨어 설계」는 무슨 뜻인가? 대부분의 코드가 손으로 쓰이지 않고 생성될 것이며, 일부 소비자는 사람이 아니라 에이전트일 것이라는 가정을 중심으로 애플리케이션을 설계하는 것이다. 실무적으로는 데이터 모델과 제약과 API 계약이 앞단에서 명시적으로 정의된다는 뜻이다. 그것들이 생성이 당신을 대신해 내릴 수 없는 결정이기 때문이다.

AI-first 설계는 그냥 AI 코딩 도구를 쓰는 것과 어떻게 다른가? AI 도구를 쓰는 것은 바뀌지 않은 워크플로에 역량을 하나 더하는 것이다. AI-first 설계는 워크플로의 작업 순서를 바꾼다 — 인터페이스보다 모델과 계약을 먼저, 명세를 리뷰 대상 산출물로, 제약을 강제 가능한 계층으로 밀어 내리기. DORA의 2025년 연구는 AI 도입이 처리량과 불안정성을 함께 올렸음을 발견했고, 그것이 바로 도구는 바뀌고 실천은 바뀌지 않았을 때 벌어지는 일이다.

AI 시대 소프트웨어 설계의 제1원리는 무엇인가? 네 가지가 성립한다. 데이터 모델이 제품이고 화면은 그것의 한 뷰다. 당신이 명시적으로 내리지 않은 결정은 생성기가 암묵적으로 내린다. 제약은 누군가의 머릿속이 아니라 기계가 강제할 수 있는 곳에 살아야 한다. 그리고 당신의 애플리케이션은 이제 인간 인터페이스와 에이전트를 향한 API를 함께 섬기며, 그 둘에는 대등성이 필요하다.

이렇게 설계하면 팀이 느려지는가? 그것은 작업을 앞으로 당기고 추가하지는 않는다. 데이터 모델과 명세에 포착된 결정은 어차피 누군가 내리는 결정이다 — 시작할 때 의도적으로, 아니면 나중에 모델이 추측하며 암묵적으로. 두 번째 경로가 재작업이 나오는 곳이고, 재작업은 더 빠르지 않다.

명세 주도 개발과 AI-first 설계는 같은 것인가? 명세 주도 개발은 그 실천이고, AI-first 설계는 더 넓은 아키텍처적 결과의 집합이다. 명세 주도 개발은 명세를 쓰고 그것에 맞춰 생성하는 것을 다룬다. AI-first 설계는 데이터 모델링의 순서, 제약이 강제되는 위치, 인간 소비자와 함께 에이전트 소비자를 위해 설계하는 것도 다룬다.

이 전부를 건너뛰어도 괜찮은 때는 언제인가? 프로토타입, 데모, 내부 일회성 작업, 그리고 버릴 계획인 모든 것. 이 오버헤드는 실제 사용자와 실제 데이터와 시간에 따른 변화를 견뎌야 하는 소프트웨어에만 감당할 가치가 있다.