AI 코딩 도구는 보일러플레이트와 정형화된 구현을 놀라운 속도로 처리하지만, 엣지 케이스·아키텍처·유지보수성이라는 "마지막 마일"은 여전히 인간 엔지니어의 몫이다. 이 문서는 책의 공개 챕터 두 편 — "The 70% Problem"과 "Beyond the 70%" — 의 핵심을 요약한다.
AI 어시스턴트는 요구사항의 약 70%를 커버하는 초기 구현을 순식간에 만들어낸다. v0나 Bolt 같은 도구로 프로토타입을 얻는 초기 경험은 마법처럼 느껴진다. 그러나 마지막 30% — 엣지 케이스 처리, 아키텍처 정제, 유지보수성 확보 — 는 수확 체감의 늪이 되며, 여기서부터 진짜 엔지니어링이 시작된다.
Fred Brooks의 고전적 구분을 빌리면, AI는 소프트웨어의 우발적 복잡성(반복적·기계적인 부분)을 탁월하게 처리하지만, 문제 자체에 내재한 본질적 복잡성은 여전히 인간의 어깨 위에 남는다. AI는 학습 데이터를 넘어서는 새로운 추상화나 전략을 만들지 못하고, 자기 결과물에 책임을 지지도 않는다.
"70%까지는 놀랍도록 빨리 도달한다. 그러나 마지막 30%는 한 걸음 나아가면 두 걸음 물러나는 좌절의 연속이다. 코드가 어떻게 동작하는지 안다면 직접 고칠 수 있겠지만, 모르기 때문에 내가 정말 배우고 있는지조차 의심스럽다."
Bolt, v0, screenshot-to-code 도구로 아이디어를 수 시간~수 일 만에 동작하는 프로토타입으로 만든다.
Cursor, Cline, Copilot, Windsurf를 일상 개발에 통합한다. 덜 화려하지만 잠재적으로 더 변혁적이다.
시니어 엔지니어가 AI와 일하는 모습은 마법처럼 보이지만, 자세히 보면 그들은 제안을 그대로 수용하지 않는다. 생성된 코드를 끊임없이 작은 모듈로 리팩토링하고, AI가 놓친 에러 처리와 엣지 케이스를 보강하며, 타입 정의를 강화하고 아키텍처 결정에 의문을 제기한다. AI가 구현을 가속하되, 코드를 유지보수 가능하게 만드는 것은 그들의 축적된 전문성이다.
주니어나 비엔지니어가 AI 출력을 그대로 수용하면 겉보기에 완성된 듯하지만 실전 압력에서 무너지는 "카드로 만든 집(house of cards code)"이 된다. 그 뒤에는 예측 가능한 악순환이 따른다.
이 악순환이 특히 고통스러운 이유는 지식의 역설(knowledge paradox) 때문이다. 시니어는 이미 할 줄 아는 일을 가속하기 위해 AI를 쓰고, 주니어는 무엇을 해야 할지 배우기 위해 AI를 쓴다. 코드가 이해 없이 "그냥 나타나면" 디버깅 능력도, 근본 패턴도, 아키텍처 판단력도 길러지지 않으며, 문제를 스스로 해결하는 대신 계속 AI에 되돌아가야 하는 의존성이 생긴다. 자율적으로 계획·실행·반복하는 에이전틱 AI(Cline, Devin, Claude Code 등)의 부상은 이 위험을 더 키운다 — 개별적으로는 타당해 보이는 결정들이 누적되어 프로젝트를 의도치 않은 방향으로 끌고 갈 수 있고, 이를 감사(audit)하고 교정할 전문성이 없으면 불안정한 기반 위에 쌓아 올리게 된다.
AI로 만든 인상적인 데모는 해피 패스에서는 아름답게 동작해 투자자와 소셜 미디어를 감동시키지만, 실제 사용자가 클릭하기 시작하면 무너진다. 이해할 수 없는 에러 메시지, 앱을 죽이는 엣지 케이스, 정리되지 않은 UI 상태, 무시된 접근성, 저사양 기기의 성능 문제 — 이것들은 사소한 버그가 아니라 "참아주는 소프트웨어"와 "사랑받는 소프트웨어"의 차이다. 이런 수준의 폴리시(polish)는 공감, 경험, 그리고 장인정신에서 나오며, AI가 대신 생성해 주기 어렵다.
수십 개 팀을 관찰한 결과, 솔로·팀 워크플로 모두에서 일관되게 작동하는 패턴은 세 가지다. 공통 전제는 하나 — AI 사용을 팀 개발 대화의 정상적인 일부로 취급하는 것이다.
AI가 초기 코드를 생성하고 개발자가 정제·리팩토링·테스트한다. 스탠드업에서 AI 사용 계획을 공유해 중복 생성(예: 두 명이 각자 formatDate 유틸을 생성)을 막고, 팀 코딩 표준을 AI에 먼저 주입한다. 버전 관리가 더욱 중요해진다: AI가 유의미한 코드 덩어리를 만들 때마다 자주 커밋하고, 서로 다른 AI 변경은 분리 커밋하며, "[AI-assisted]" 태그로 추적성을 확보한다.
개발자와 AI가 긴밀한 피드백 루프 안에서 상시 대화한다. 작업 단위마다 새 AI 세션을 시작해 컨텍스트를 명확히 유지하고, 프롬프트를 집중적·간결하게 쓰고, 자주 리뷰·커밋한다. 인간-AI 페어는 반복 작업과 속도에 강하고, 인간-인간 페어는 복잡한 문제 해결과 공동 소유의식에 강하다 — 프로젝트 복잡도와 자원에 따라 선택한다.
개발자가 코드를 쓰고 AI가 검증·테스트·개선을 담당한다. DeepCode·Snyk류 도구가 입력 검증 누락이나 보안 취약점을 탐지하고, Qodo·TestGPT류가 테스트 케이스를 자동 생성한다. AI는 1차 스캔으로 명백한 문제를 걸러내고, 복잡한 기능·UX·윤리적 판단 등 핵심 영역은 인간 리뷰가 우선한다.
정밀한 프롬프트가 정밀한 결과를 낳는다.
기능·로직·적합성을 확인하기 전에는 수용하지 않는다.
출력은 초안이다. 피드백하고 정제하고 품질을 보장한다.
루틴은 자동화하되 문제 해결과 의사결정에는 능동적으로 남는다.
AI 사용 표준·코드 기대치·관행을 사전에 합의한다.
경험·기법·성공·함정을 팀과 정기적으로 공유한다.
리뷰·롤백·추적을 단순하게 만든다.
인간이 썼든 AI가 썼든 같은 엄격함을 적용한다.
이해는 유지보수성과 보안의 전제 조건이다.
AI 생성 코드의 근거와 맥락을 기록해 미래의 기술 부채를 줄인다.
검증된 프롬프트 저장소를 유지해 일관성을 높인다.
과거 경험에서 얻은 통찰로 워크플로를 계속 다듬는다.
Tim O'Reilly의 말처럼, 자동화의 도약은 매번 프로그래밍의 방식(how)을 바꿨을 뿐 숙련된 프로그래머가 필요한 이유(why)를 없애지 못했다. 지금은 "프로그래밍의 종말"이 아니라 "우리가 알던 프로그래밍의 종말"이며, 개발자의 역할은 소멸이 아니라 진화한다.
AI에게 초안을 맡기고, 자신은 솔루션 설계와 출력 정제에 집중한다. 복잡한 요구사항을 효과적인 프롬프트·명세로 번역하고, 생성된 모든 라인을 비판적으로 검토한다. AI는 빠른 타이피스트, 시니어는 두뇌다. 주니어가 검증 없는 AI 출력을 넘겨오면 밀어내고, 스스로 검증하는 프로세스를 정착시킨다.
Steve Yegge의 CHOP(Chat-Oriented Programming: 반복적 프롬프트 정제를 통한 코딩)을 활용하면, 며칠 걸리던 일이 몇 시간으로 줄어 "해보면 좋을 텐데" 수준이던 프로젝트도 시도할 수 있게 된다. 단, 어떤 접근을 채택하고 어떤 조각을 통합할지는 항상 인간이 결정한다.
메모리 누수, off-by-one, 동시성 위험처럼 경험으로만 보이는 함정을 주니어에게 가르치고, AI 산출물을 스스로 검증·테스트하는 문화를 만든다. "AI 사용은 환영하되 성실한 검증은 필수"라는 규범을 팀에 정착시킨다.
회사가 왜 이렇게 만들어졌는지 아는 역사적 맥락이 AI의 실수를 잡아낸다. 코드의 2차·3차 파급 효과를 내다보는 직관을 AI 출력에도 적용한다. 로트 코딩이 쉬워질수록 가치는 "무엇을 만들지 결정하고 복잡계를 지휘하는 일"로 이동한다 — 아키텍처 로드맵, 도구 평가, 조직의 AI 코딩 가이드라인 같은 일에 나선다.
기능 구현, 테스트 작성, 단순 디버깅처럼 미드레벨의 시간을 차지하던 일들이 자동화되고 있다. 이는 도태가 아니라 격상(elevation)을 의미한다.
API 설계, 이벤트 스키마, 데이터 모델 등 컴포넌트 간 경계 관리가 핵심이 된다. 자료구조·알고리즘, 분산 시스템 원리, DB 내부와 쿼리 최적화, 네트워크 프로토콜과 보안 등 CS 기초를 심화한다. AI는 일반 케이스를 풀 뿐이므로 "만약 …라면?"을 묻는 비판적 사고와 예지력 — 널 입력, 네트워크 장애, 비정상 사용자 행동, 시스템 연동 — 을 기른다.
규제가 있는 금융, 프라이버시가 중요한 헬스케어, 엄격한 성능 요건의 실시간 시스템, ML 인프라 등 인간의 이해가 결정적인 복잡 도메인에 전문화한다. 도메인 지식이 AI가 모르는 엣지 케이스를 드러낸다.
모니터링·관측성, 성능 프로파일링, 보안·컴플라이언스, 비용 최적화에 집중한다. AI가 대량의 코드를 쓸수록 엄격한 리뷰와 테스트가 더 중요해진다 — "아무것도 증명되기 전까지는 동작하지 않는다"고 가정하고, 품질 기준에 못 미치는 AI 코드는 주저 없이 다시 쓴다.
한 부분의 변경이 다른 부분에 미치는 영향, 소프트웨어와 비즈니스 목표의 연결을 이해하는 시스템 사고를 기른다. 로드 밸런싱·캐싱, 데이터 파티셔닝·복제, 장애 모드와 복구, 비용·자원 관리 등 아키텍처를 설계한다. 구현 시간이 줄어들수록 비즈니스 요구와 기술 솔루션 사이를 번역하는 크로스펑셔널 커뮤니케이션의 가치가 커진다. UX·프로덕트 감각까지 겸비하면("폴리매스형 인재") 더 강해진다.
"주니어 개발자의 죽음"이라는 헤드라인과 달리 주니어는 사라지지 않는다. 다만 역할의 기준이 올라간다: 튜토리얼을 따라 하는 사람이 아니라, AI와 효과적으로 일하며 가치 사슬을 빠르게 오르는 사람이 되어야 한다.
AI를 정답 자판기가 아닌 튜터로 쓴다. 코드를 받으면 왜 그 접근을 택했는지 묻고 줄 단위로 설명하게 한다. AI 출력이 틀렸을 때 그것을 알아채고 고치려면 자신만의 멘탈 모델이 필요하다.
주기적인 "AI-free day"로 스킬 위축을 막는다. AI 생성 코드에서 버그를 만나면 AI에게 맡기기 전에 디버거로 직접 파고든다. AI가 만든 버그를 잡아냈다면, AI가 못한 일을 해낸 것이다.
LLM이 준 코드를 신뢰하기 전에 도전한다 — 유닛 테스트를 쓰고 엣지 케이스를 확인한다. "돌아가게 만들기"는 AI도 하므로, 읽기 쉽고 유지보수 가능한 코드로 다듬는 눈을 기른다. 50줄짜리 만능 함수는 쪼개고, 불명확한 변수명은 바꾼다 — 동료의 코드를 리뷰하듯 AI 코드를 개선한다.
프롬프트 엔지니어링은 차별화 요소지만, 좋은 프롬프트는 결국 문제를 잘 이해했다는 증거다. AI에게 시키기 전에 해법을 평문으로 먼저 정리해 본다. 시니어에게 "왜 AI 제안과 다른 방식을 선호하는지" 묻고, 코드 리뷰 코멘트("이 함수는 스레드 안전하지 않다" 등)에서 AI가 놓치는 유형의 문제를 배운다. 해법을 소비(copy-paste)하는 데서 이해를 창조하는 쪽으로 마인드셋을 전환한다.
다음 역량들은 프레임워크나 도구가 바뀌어도 만료되지 않는다. 오히려 AI의 부상은 이 스킬들의 가치를 더 도드라지게 만든다. Simon Willison의 지적처럼, AI 지원은 강한 프로그래밍 실력을 덜이 아니라 더 가치 있게 만든다 — "LLM은 파워 유저를 위한 파워 툴"이기 때문이다.
시스템 설계·아키텍처 전문성트레이드오프와 제약을 이해하고 큰 그림을 설계한다
시스템 사고와 맥락 이해변경의 파급 효과와 비즈니스 목표의 연결을 본다
비판적 사고·문제 해결·예지력엣지 케이스를 열거하고 실패를 앞서 대비한다
전문 도메인 지식AI가 갖지 못한 맥락을 제공한다
코드 리뷰·테스트·디버깅·QAAI가 쓴 코드일수록 검증이 인간의 핵심 부가가치다
커뮤니케이션·협업요구를 명확히 하고 트레이드오프를 조율한다
변화 적응력과 지속 학습기초를 단단히 하되 새 도구에 열려 있는다
AI 자체를 능숙하게 사용하는 능력AI를 저항의 대상이 아닌 워크플로의 일부로 삼는다
위대한 소프트웨어 엔지니어링은 언제나 코드 슬링잉이 아니라 문제 해결에 관한 것이었다. AI는 그것을 바꾸지 않는다 — 다만 우리의 문제 해결을 한 단계 끌어올리라고 요구할 뿐이다. 숙련된 파일럿에게 고성능 부조종사가 주어지면 더 빠르고 멀리 갈 수 있지만, 폭풍을 뚫고 안전하게 착륙시키는 것은 여전히 파일럿의 일이다.