AI 코딩의 냉엄한 진실 — 부트스트래퍼와 이터레이터
구글 엔지니어링 리더 애디 오스마니의 글을 정리했다. AI가 70%까지는 빠르게 데려다주지만 나머지 30%에서 벌어지는 일이 이 글의 핵심이다.

구글 엔지니어링 리더인 애디 오스마니가 쓴 「AI 지원 코딩이 소프트웨어 엔지니어링을 어떻게 바꿀 것인가: 냉엄한 진실」을 정리한 글이다. AI 지원 코딩의 의미와 한계, 그리고 소프트웨어 엔지니어의 역할 변화를 다룬다. 매우 공감되는 내용이 많았다.
2025년 현재, AI 가 소프트웨어 개발에 미치는 영향은 단순한 기술 발전을 넘어 근본적인 변화를 예고하고 있다. 특히 LLM 이 코딩을 보조하며 프로토타이핑부터 일상 개발까지 여러 방식으로 쓰인다. 하지만 이 도구들이 주는 잠재력만큼 한계와 새로운 과제도 함께 나온다.
두 부류의 사용자 — 부트스트래퍼와 이터레이터
AI 코딩 도구는 크게 두 가지 방식으로 쓰이고 있다.
부트스트래퍼(Bootstrappers) 는 초기 아이디어를 빠르게 구현하는 데 특화된 그룹이다. AI 로 몇 시간이나 며칠 만에 기본 MVP 를 만들어 낸다. Bolt, v0 같은 도구가 여기에 맞는다.
이터레이터(Iterators) 는 일상적인 개발 작업에서 AI 를 쓰는 그룹이다. 코드 보완, 리팩토링, 테스트 생성, 문서화에 AI 를 쓴다. Copilot, Cursor 가 이 자리에서 중요한 역할을 한다.
두 그룹 모두 생산성을 얻고 있지만, 동시에 AI 의 한계와 예상치 못한 문제도 만난다.
70% 문제 — 나머지 30%에서 벌어지는 일
AI 도구는 초보자에게도 70% 완성도의 결과물을 빠르게 준다. 문제는 나머지 30% 다. 이것을 “70% 문제” 라고 부른다.
역효과. AI 가 제안한 수정이 다른 문제를 만들고, 그것을 고치다 보면 비효율적인 루프에 빠진다.
작은 버그 수정 요청 → AI 가 변경 사항 제안 → 다른 것이 동작하지 않게 됨 → 다시 문제 해결 요청 → 또 다른 새로운 문제 발생 → (반복)
AI 가 만든, 자신이 완전히 이해하지 못하는 코드로 두더지 잡기 게임을 하게 된다.
AI 속도의 숨겨진 비용. 숙련된 개발자는 AI 가 생성한 코드를 최적화하고 보완하는 데 시간을 써야 하고, 이것이 초보 개발자와 큰 격차를 만든다. AI 코딩 도구를 가장 잘 쓰려면 AI 를 단순한 코드 생성기가 아니라 학습 도구로도 쓸 수 있음을 이해해야 한다. 제안된 프로그래밍 개념을 물어보고 어떻게 동작하는지 이해하는 과정이 필요하다.
지식 격차. AI 도구는 초보자보다 숙련된 개발자에게 더 많은 도움이 된다. 선임 엔지니어는 이미 이해하고 있는 아이디어를 AI 로 빠르게 프로토타입화하고, 생성된 코드를 토대로 빠르게 개선한다. 반면 초보자는 AI 가 만든, 종종 잘못되거나 오래된 해법을 그대로 받아들여 여러 가지를 놓치고, 완전히 이해하지 못한 취약한 시스템을 짓게 될 확률이 높다.
지금의 마지막 30% 는 여전히 실제 엔지니어링 지식을 요구한다. 다만 이 비율은 시간이 지나며 줄어들 것으로 보인다. 현재로서 가장 실용적인 접근은 AI 로 학습을 가속하는 것이지 완전히 대체하는 것이 아니다.
효과적인 활용 패턴
- AI 초안 패턴 — AI 가 만든 코드를 시작점으로 삼고, 리팩토링과 에러 처리는 손으로 더한다
- 지속적 대화 패턴 — 각 작업을 분리된 대화로 진행하며 명확한 컨텍스트를 유지한다
- 신뢰하지만 검증하기 — AI 가 만든 코드를 철저히 검토하고 테스트해 신뢰를 확보한다
AI 지원 개발을 처음 시작한다면 세 가지를 권한다.
1. 작게 시작한다. 격리되고 명확하게 정의된 작업에 AI 를 쓴다. 생성된 코드의 모든 줄을 검토한다. 그러고 나서 점차 더 큰 기능으로 넓힌다.
2. 모듈형으로 유지한다. 모든 것을 작고 집중된 파일로 나눈다. 구성 요소 사이의 인터페이스를 명확히 하고, 모듈 경계를 문서화한다.
3. 자기 경험을 신뢰한다. AI 로 판단을 대체하지 말고 가속한다. 생성된 코드가 이상하게 느껴지면 질문한다. 엔지니어링 표준을 유지한다.
에이전틱 소프트웨어 엔지니어링의 부상
2025년에는 AI 도구가 단순 보조를 넘어, 자율적이면서도 인간의 지도를 받는 에이전틱 소프트웨어 엔지니어링으로 발전할 전망이다. 특징은 세 가지다.
- 응답자에서 협력자로 — 문제를 푸는 데 그치지 않고 계획하고 실행하는 능력을 갖춘다
- 멀티모달 — 코드뿐 아니라 UI, 다이어그램, 음성 대화 등 다양한 입력을 통합한다
- 영어 중심의 개발 환경 — 자연어로 명확히 의사소통하는 능력이 점점 중요해진다
그래서 우리가 할 일은 이렇다. AI 에이전트에 명확한 경계와 가이드라인을 세우고, 에이전트가 작업할 수 있는 강력한 아키텍처 패턴을 확립하고, 인간과 AI 역량 사이에 효과적인 피드백 루프를 만들고, AI 의 자율성을 활용하면서도 인간의 감독을 유지하는 것이다.
코딩은 소프트웨어 만들기의 몇 퍼센트인가
AI 툴링에 대한 이야기는 대부분 코드 생성 기능에 초점을 맞춘다. 당연한 일이다. 프롬프트에서 동작하는 코드를 만들거나 인라인 코드를 제안하는 능력은 인상적이다.
그런데 소프트웨어를 만드는 과정에서 코딩 자체는 얼마나 될까. 약 50년 전 프레드 브룩스는 코딩이 전체 시간의 15~20% 정도라고 봤다. 오늘날 소프트웨어 엔지니어의 시간은 아마 이렇게 쓰일 것이다.
- 계획 20%
- 코딩(코드 + 테스트) 40%
- 코드 리뷰(다른 사람의 코드) 20%
- 프로덕션 준비 및 롤아웃 20%
그 밖에도 뛰어난 소프트웨어를 만드는 데는 할 일이 많다. 소프트웨어 개발의 주요 단계는 다음과 같다.
- 무엇을 만들지 결정(What) — 브레인스토밍, 설계, 사용자 테스트, 제품 매니저·비즈니스 이해관계자와의 협업. 스타트업은 “일단 만들어서 결과를 보자”로 간단히 가고, 대규모 조직은 “기존 고객을 혼란스럽게 하지 않기 위해” 신중하게 간다
- 어떻게 만들지 결정(How) — 아키텍처 설계, 종속성 파악, 테스트 계획
- 구현(Build) — 코드 작성과 기능 구현
- 검증(Verify) — 배포 전 작동 여부 확인. 특히 금융처럼 위험이 큰 환경에서 QA 는 필수다
- 배포(Ship it) — 변경 사항 병합과 릴리즈
- 모니터링·온콜 — 장애 감지와 신속 대응, 유사 장애 방지를 위한 사후 분석
- 유지보수(Maintain) — 고객 피드백 수집, 버그와 기능 요청의 우선순위 결정
- 마이그레이션(Migrate) — 프레임워크 변경 같은 대규모 변화에 따르는 작업
에이전트 — 2025년의 큰 약속이자 큰 미지수
LLM 이 나온 지 2년이 지난 지금, 많은 사람이 LLM 으로 코딩과 엔지니어링 작업을 보강하는 법을 꽤 잘 이해하게 됐다. 프로토타입 제작, 덜 친숙한 언어로의 전환, 그리고 정확성을 검증하고 환각이나 잘못된 출력을 지적할 수 있는 작업에 특히 좋다.
반면 AI 에이전트는 아직 초기다. 대부분은 아직 널리 써 보지 않았다. 일반적으로 쓸 수 있는 에이전트는 Devin 하나뿐이고 월 500달러이며 초기 반응은 엇갈린다.
이 분야에 많은 벤처 자금이 쏟아질 것이다. 더 많은 AI 코딩 에이전트가 나올 것이고 가격도 떨어질 것이다. GitHub Copilot 은 2025년에 Copilot Workspace 와 비슷한 에이전트 방식을 일반 출시할 가능성이 높다.
결론
AI 는 소프트웨어 개발의 속도를 높이고 가능성을 넓힌다. 하지만 코딩 이상의 작업들은 여전히 인간의 경험과 판단을 요구한다. 엣지 케이스 처리, 사용자 경험 개선, 접근성 강화 같은 세부 작업은 AI 가 대체할 수 없는 영역이다. 오히려 AI 가 루틴 작업을 맡아 주면서 개발자는 더 창의적이고 사용자 중심적인 일에 집중할 수 있다.
숙련된 개발자는 AI 로 더 생산적이고 가치 있는 일을 할 수 있고, 초보자는 이 도구를 학습의 기회로 삼아야 한다. AI 는 우리 일을 더 빠르게 만들지만, 더 나은 소프트웨어를 만드는 것은 여전히 우리 몫이다.