<div id="readability-page-1" class="page"><article id="post-5481">

 
 <div>
 
챗GPT가 세상에 나온 지 벌써 2년이 훌쩍 넘었습니다. 그동안 AI, 특히 생성형 AI는 우리 일상과 업무 방식에 엄청난 변화의 바람을 몰고 온게 사실입니다. 제가 몸담고 있는 소프트웨어 개발 분야가 아마도 그 첫 타깃이 되지 않을까 하는 생각이 점점 확신이 되고 있네요. 



AI 코딩 도구들이 등장하면서 “개발자 없이도 코딩하는 시대가 온다!”는 장밋빛 전망부터 “아직은 멀었다”는 신중론까지, 정말 다양한 목소리가 나오고 있습니다. 마치 뜨거운 감자처럼 말이죠!



오늘은 이 주제에 대해 좀 더 깊이 파고들어 보려고 합니다. 최근 애디 오스마니(Addy Osmani)가 기고한 “<a href="https://newsletter.pragmaticengineer.com/p/how-ai-will-change-software-engineering" data-type="link" data-id="https://newsletter.pragmaticengineer.com/p/how-ai-will-change-software-engineering"></a><a href="https://addyo.substack.com/p/the-70-problem-hard-truths-about">The 70% problem: Hard truths about AI-assisted coding(70% 문제: AI 지원 코딩에 대한 어려운 진실</a>)”라는 글이 아주 현실적이고 통찰력 있는 분석을 내놓았는데요. 이 글의 내용을 중심으로, 기존 저의 블로그에서 다루었던 AI 기술에 대한 관점과 스타일을 녹여내 AI 코딩의 현재와 미래, 그리고 개발자로서 우리는 무엇을 고민해야 할지 이야기해 보도록 하겠습니다.



<h2>1. AI 코딩, 지금 누가 어떻게 쓰고 있나? – “부트스트래퍼” vs “이터레이터”</h2>



애디 오스마니는 현재 개발자들이 AI 코딩 도구를 활용하는 방식을 크게 두 가지 유형으로 나눕니다.



<ul>
<li>부트스트래퍼 (Bootstrappers): 제로에서 MVP까지 빠르게!
<ul>
<li>이들은 주로 새로운 프로젝트를 시작할 때 AI를 활용합니다. Bolt, v0, 스크린샷-투-코드 AI 같은 도구들을 사용해 디자인이나 대략적인 컨셉만으로 초기 코드베이스를 순식간에 만들어내죠. 몇 주 걸릴 작업을 며칠, 심지어 몇 시간 만에 프로토타입으로 구현하여 빠르게 사용자 피드백을 받는 데 집중합니다. 아이디어 구상부터 실행까지의 간극을 혁신적으로 줄여주는 방식입니다.</li>
</ul>
</li>



<li>이터레이터 (Iterators): 일상 개발 업무의 페어 프로그래머
<ul>
<li>이들은 Cursor, Cline, Copilot, WindSurf 같은 도구를 일상적인 개발 워크플로우에 통합하여 사용합니다. 코드 자동 완성, 복잡한 리팩토링, 테스트 및 문서 생성 등 마치 똑똑한 페어 프로그래머와 함께 일하는 것처럼 AI를 활용하죠. 화려하진 않지만, 어쩌면 더 근본적인 변화를 가져올 수 있는 방식입니다.</li>
</ul>
</li>
</ul>



흥미로운 점은, 이 두 가지 접근 방식 모두 개발 속도를 극적으로 높일 수 있지만, 눈에 보이지 않는 숨겨진 비용이 따른다는 것입니다.



<h2>2. 마법 뒤에 숨겨진 “70%의 벽” – AI 학습 곡선의 역설</h2>



<figure><img fetchpriority="high" decoding="async" width="1024" height="474" src="https://freesearch.pe.kr/wp-content/uploads/2025/05/image-1024x474.png" alt="" sizes="(max-width: 1024px) 100vw, 1024px"></figure>



최근 위와 같은 트윗이 개발 현장의 목소리를 정확히 짚어냈다고 하는데요. 비 엔지니어들이 AI로 코딩을 시도할 때, 놀랍도록 빠르게 70% 지점까지는 도달하지만, 나머지 30%를 완성하는 데 엄청난 좌절감을 느낀다는 것입니다. 마치 눈앞에 다 왔는데 보이지 않는 벽에 가로막힌 느낌이랄까요? 근데 이 언급에 해당하는 대상이 과연 비엔지니어 만일까요? 예를 들어 3D 게임 개발 관련 경험이 전무한 시스템 엔지니어를 보자면 3D 게임엔진에서 태양의 위치에 따른 지표면의 밝기를 조절하는 법선벡터 설정의 의미를 모르고 있을 가능성이 있을겁니다. 생성형 AI가 이런 코드를 작성한다면 이후 더 많은 코드를 스스로 혹은 생성형 AI를 기반으로 작성해 낼 수 있을까요? 오류를 고칠 수 있을까요? 아마도 여기서 막힐것이고 다시 3D 그래픽스 책을 공부해야 될 것입니다(이 사례는 딱 저의 경험이였습니다 ㅎㅎ). 



<ul>
<li>“두 걸음 후퇴” 패턴의 함정: AI가 제안한 수정안이 다른 버그를 만들고, 그걸 고치려다 또 다른 문제를 야기하는 악순환에 빠지기 쉽습니다. 특히 경험이 부족한 경우, 문제의 근본 원인을 파악하지 못하고 AI와 함께 ‘두더지 잡기’ 게임을 하게 될 수 있습니다.</li>



<li>“AI 속도”의 이면: 시니어 개발자가 AI 도구를 쓰는 걸 보면 마법처럼 보입니다. 순식간에 기능을 만들고 테스트까지 완료하죠. 하지만 자세히 보면, 그들은 AI가 생성한 코드를 맹목적으로 수용하는 것이 아닙니다. 끊임없이 리팩토링하고, 엣지 케이스를 추가하며, 아키텍처를 고민하고, 오류 처리를 강화합니다. 수년간 쌓아온 엔지니어링 지혜를 AI의 결과물에 적용하는 것이죠. 반면, 주니어 개발자는 이런 과정을 간과하여 ‘모래성 같은 코드’를 만들 위험이 있습니다.</li>



<li>지식 격차와 역설: AI 도구는 초보자보다 숙련된 개발자에게 더 큰 도움을 준다는 역설이 존재합니다. AI는 마치 열정 넘치지만 경험 없는 주니어 개발자와 같습니다. 코드는 빨리 짜지만, 끊임없는 지도와 수정이 필요하죠. 많이 알수록 AI를 더 잘 이끌 수 있습니다. 결국 AI는 학습을 대체하는 것이 아니라, 학습을 가속하는 도구로 활용될 때 가장 빛을 발합니다.</li>
</ul>



이 “70% 문제”는 현재 AI 코딩 도구가 아직 만능 해결책이 아니며, 소프트웨어를 실제 운영 가능한 수준으로 만드는 마지막 30%에는 여전히 깊이 있는 엔지니어링 지식이 필요하다는 것을 시사합니다.



<h2>3. AI와 제대로 협업하는 법 – 실용적인 패턴 3가지</h2>



그렇다면 이 강력하지만 까다로운 AI와 어떻게 효과적으로 협업할 수 있을까요? 애디 오스마니는 다음과 같은 실용적인 패턴들을 제시합니다.



<ol>
<li>“AI 초안(AI first draft)” 패턴:
<ul>
<li>AI에게 기본적인 구현을 맡깁니다.</li>



<li>생성된 코드를 사람이 직접 검토하고 모듈성을 고려해 리팩토링합니다.</li>



<li>포괄적인 오류 처리, 철저한 테스트, 주요 결정 사항에 대한 문서화를 추가합니다.</li>
</ul>
</li>



<li>“지속적인 대화(Constant conversation)” 패턴:
<ul>
<li>각각의 명확한 작업 단위로 새로운 AI 채팅을 시작합니다.</li>



<li>컨텍스트는 집중적이고 최소한으로 유지합니다.</li>



<li>변경 사항을 자주 검토하고 커밋하며, 짧은 피드백 루프를 유지합니다.</li>
</ul>
</li>



<li>“신뢰하되 검증하라(Trust but verify)” 패턴:
<ul>
<li>초기 코드 생성에는 AI를 활용합니다.</li>



<li>모든 중요한 실행 경로는 반드시 수동으로 검토합니다.</li>



<li>엣지 케이스에 대한 자동화된 테스트를 수행하고, 정기적인 보안 감사를 실시합니다.</li>
</ul>
</li>
</ol>



결국 핵심은 AI를 맹신하지 않고, 인간 개발자의 경험과 판단을 통해 AI의 결과물을 적극적으로 다듬고 검증하는 것입니다.



<h2>4. 그래서 개발자는 이제 뭘 해야 할까? – AI 시대 생존 전략</h2>



이러한 변화의 흐름 속에서 개발자들은 어떤 자세를 가져야 할까요?



<ul>
<li>작게 시작하세요 (Start small): 처음부터 거창한 작업보다는 잘 정의된 작은 작업에 AI를 활용하고, 생성된 모든 코드를 꼼꼼히 검토하며 점진적으로 큰 기능으로 확장해나가세요.</li>



<li>모듈성을 유지하세요 (Stay modular): 모든 것을 작고 집중된 파일로 나누고, 컴포넌트 간 명확한 인터페이스를 유지하며, 모듈 경계를 문서화하세요. 이는 AI가 생성한 코드의 복잡성을 관리하는 데 중요합니다.</li>



<li>당신의 경험을 믿으세요 (Trust your experience): AI는 당신의 판단을 대체하는 것이 아니라 가속하는 도구입니다. AI가 생성한 코드가 뭔가 이상하다고 느껴진다면, 주저하지 말고 의문을 제기하고 엔지니어링 표준을 지키세요.</li>
</ul>



AI는 우리가 이미 알고 있는 패턴을 구현하는 데 뛰어나고, 새로운 아이디어를 빠르게 프로토타이핑하며, 반복적인 작업을 자동화하는 데 강력한 힘을 발휘합니다. 이를 통해 우리는 더 흥미로운 문제에 집중할 수 있게 됩니다.



<h2>5. 코딩을 넘어: 에이전트 기반 소프트웨어 엔지니어링의 부상</h2>



현재의 AI 코딩 도구들이 이미 우리의 작업 방식을 바꾸고 있지만, 2025년을 향해 가면서 우리는 훨씬 더 큰 변화의 문턱에 서 있습니다. 바로 에이전트 기반 소프트웨어 엔지니어링(Agentic Software Engineering)의 등장입니다.



단순히 프롬프트에 응답하는 것을 넘어, 이러한 시스템은 점점 더 자율적으로 해결책을 계획하고, 실행하며, 반복할 수 있게 될 것입니다. 마치 스스로 생각하고 행동하는 디지털 동료처럼 말이죠.



<ul>
<li>응답자에서 협력자로: AI가 단순히 명령을 기다리는 대신, 작업의 의도를 이해하고 문제를 해결하기 위해 주도적으로 행동합니다. 예를 들어, 디버깅 시 잠재적 문제를 스스로 식별하고, 테스트를 실행하며, 해결책을 제안하고 검증까지 할 수 있습니다.</li>



<li>다중 모드(Multimodal)의 미래: 코드뿐만 아니라 UI 스크린샷, 목업, 다이어그램 같은 시각적 정보, 자연어 대화, 브라우저나 터미널 같은 환경과의 상호작용을 통합적으로 이해하고 작업하게 될 것입니다.</li>



<li>자율적이되 유도되는 방식: AI가 자율성을 가지되, 인간의 지도와 전문성을 존중하는 협력 관계가 중요해집니다. 명확한 가이드라인 설정, 강력한 아키텍처 패턴 구축, 효과적인 피드백 루프가 핵심이 될 것입니다.</li>



<li>“언어가 새로운 프로그래밍 언어”: 안드레이 카파시(Andrej Karpathy)가 언급했듯이, 명확하게 생각하고 자연어로 정확하게 소통하는 능력이 전통적인 코딩 기술만큼 중요해질 것입니다.</li>
</ul>



<figure><img decoding="async" width="987" height="397" src="https://freesearch.pe.kr/wp-content/uploads/2025/05/image-1.png" alt="" sizes="(max-width: 987px) 100vw, 987px"><figcaption>저작(writing) 과 엔지니어링이 구분되는 세상.. ..생성형 AI 시대는 두가지 능력을 모두 갖추는 사람을 앞으로 찾게 될지도..</figcaption></figure>



 이러한 에이전트 기반 개발 환경은 우리에게 더 강력한 시스템 설계 및 아키텍처 사고, 더 나은 요구사항 명세 및 소통 능력, 품질 보증 및 검증에 대한 더 깊은 집중을 요구할 것입니다.



<h2>6. AI가 놓치는 것: 소프트웨어 장인 정신의 가치 회복?</h2>



AI 덕분에 소프트웨어를 빠르게 만드는 것은 그 어느 때보다 쉬워졌습니다. 하지만 그 과정에서 우리는 어쩌면 가장 중요한 것, 바로 소비자 수준의 세련된 경험을 만드는 예술을 잃어버릴 위험에 처해 있는지도 모릅니다.



AI로 빠르게 만든 데모는 멋져 보이지만, 실제 사용자가 사용하기 시작하면 허점이 드러나는 경우가 많습니다. 이해하기 어려운 오류 메시지, 예외 상황에서의 앱 충돌, 혼란스러운 UI 상태, 간과된 접근성, 느린 장치에서의 성능 문제 등. 이것들은 단순한 버그가 아니라, 사용자가 소프트웨어를 참고 쓰느냐, 아니면 사랑하게 되느냐를 가르는 결정적인 차이입니다.



이런 세심함은 AI가 생성하기 어렵습니다. 공감, 경험, 그리고 장인 정신에 대한 깊은 애정에서 비롯되기 때문이죠. 아이러니하게도, AI 도구가 반복적인 코딩 작업을 처리해 줌으로써 개발자들은 오히려 이러한 ‘폴리싱(polish)’ 작업, 즉 사용자를 진정으로 만족시키는 소프트웨어를 만드는 데 더 집중할 수 있는 개인 소프트웨어의 르네상스가 올 수도 있습니다.



<h2>7. 코딩은 개발의 전부가 아니다 – 소프트웨어 엔지니어링의 큰 그림 (Gergely Orosz의 추가 의견)</h2>



프래그머틱 엔지니어의 거글리 오로즈(Gergely Orosz)는 애디 오스마니의 글에 덧붙여 중요한 점을 지적합니다. AI 코딩 도구에 대한 논의가 주로 코드 생성 능력에 집중되지만, 실제 소프트웨어 엔지니어링에서 코딩이 차지하는 비중은 생각보다 크지 않다는 것입니다. 프레드 브룩스가 1975년에 “미시컬 맨먼스”에서 언급했듯이 계획, 코딩, 테스트, 시스템 통합 등 다양한 과정이 포함됩니다.



거글리 오로즈는 현대 소프트웨어 엔지니어의 시간 분배를 대략 다음과 같이 추정합니다.



<ul>
<li>계획: 20%</li>



<li>코딩 (코드 + 테스트): 40%</li>



<li>코드 리뷰 (타인의 코드): 20%</li>



<li>운영 준비 + 배포 + 수정 + 모니터링/알림: 20%</li>
</ul>



AI 도구는 현재 “구축(Build)”, 즉 코딩 부분에서 큰 도움을 주지만, 무엇을 만들지(What), 어떻게 만들지(How) 계획하고, 검증(Verify)하고, 배포(Ship it)하고, 모니터링 및 장애 대응(Monitoring and oncall)하며, 유지보수(Maintain)하고, 필요에 따라 마이그레이션(Migrate)하는 등 소프트웨어 엔지니어링의 다른 중요한 영역에서는 아직 그 역할이 제한적입니다.



과거 COBOL, Visual Basic, 노코드 운동 등이 “개발자 없는 개발”을 꿈꿨지만, 복잡한 소프트웨어의 세계에서는 여전히 숙련된 엔지니어의 통찰력과 문제 해결 능력이 필수적입니다. AI가 비전문가의 소프트웨어 제작 장벽을 낮출수록, 오히려 유지보수해야 할 소프트웨어는 더 많아질 수도 있습니다.



그리고 중요한 점은, AI 도구를 더 효과적으로 활용하는 것은 숙련된 엔지니어라는 것입니다. 목표를 정확히 알고, AI의 결과물을 비판적으로 검토하며, 언제 개입해야 할지 알기 때문입니다. 따라서 AI 시대에는 오히려 경험 많은 엔지니어에 대한 수요가 증가할 수도 있습니다.







애디 오스마니와 거글리 오로즈의 분석을 종합해 보면, AI 코딩 도구는 분명 소프트웨어 개발의 풍경을 바꾸고 있지만, 개발자를 대체하기보다는 개발자의 생산성을 극대화하고 역할을 변화시키는 방향으로 나아가고 있습니다.



마치 제가 이전 글 “<a href="https://freesearch.pe.kr/archives/5430" data-type="link" data-id="https://freesearch.pe.kr/archives/5430">미래에는 비용 효율적인 AI 기반 지식노동을 해야 된다 – 2027년 소프트웨어 개발비 예측/분석</a>“에서 언급했듯이, AI는 인간 노동 비용의 작은 부분으로 엄청난 생산성 향상을 가져올 수 있는 도구입니다. 개발자는 더 이상 모든 코드를 직접 작성하는 역할에서 벗어나, AI가 생성한 결과물을 검증하고, AI가 해결하지 못하는 복잡한 문제에 집중하는 ‘큐레이터’이자 ‘문제 해결사’로 진화할 것입니다.



또한, “<a href="https://freesearch.pe.kr/archives/5459" data-type="link" data-id="https://freesearch.pe.kr/archives/5459">AI, 인간 데이터 너머 ‘경험’으로: The Era of Experience</a>“에서 논의했던 것처럼, AI가 스스로 경험을 통해 학습하는 시대가 온다면, 우리는 AI가 효과적으로 경험하고 학습할 환경을 설계하고 그 결과를 해석하며 협력하는 능력이 더욱 중요해질 것입니다. “<a href="https://freesearch.pe.kr/archives/5332" data-type="link" data-id="https://freesearch.pe.kr/archives/5332">MCP의 성공과 그 의미</a>“에서 다룬 것처럼, LLM이 컨텍스트를 잘 활용하도록 돕는 프로토콜이 중요했듯이, 미래에는 AI의 현실 경험 데이터 활용을 돕는 새로운 방식들이 고민될 것입니다.



결국, AI 코딩 도구는 만능 해결사가 아니라, 숙련된 개발자의 손에 들렸을 때 그 진가를 발휘하는 강력한 ‘조력자’입니다. 중요한 것은 이 도구를 어떻게 활용하여 ‘더 나은’ 소프트웨어를 만들 것인가에 대한 끊임없는 고민과 학습, 그리고 변화에 적응하는 유연성일 것입니다. 특히 필자의 경우 앞서 이야기한 3D 그래픽스에 대한 공부를 아주 빠른 3D 게임 프로토타이핑을 통한 게임 개발 동기 부여 그리고 이후 개발진행을 위한 학습으로 승화시킬 수 있었습니다. 아마도 왜 이걸 공부해야 하는지 알기 위해서 생성형 AI가 아니었으면 좀더 오려 걸렸을 수도 있을거라 예상합니다. 



끝!
 </div>
 	</article></div>

from __future__ import dream

챗GPT가 세상에 나온 지 벌써 2년이 훌쩍 넘었습니다. 그동안 AI, 특히 생성형 AI는 우리 일상과 업무 방식에 엄청난 변화의 바람을 몰고 온게 사실입니다. 제가 몸담고 있는 소프트웨어 개발 분야가 아마도 그 첫 타깃이 되지 않을까 하는 생각이 점점 확신이 되고 있네요. 
AI 코딩 도구들이 등장하면서 “개발자 없이도 코딩하는 시대가 온다!”는 장밋빛 전망부터 “아직은 멀었다”는 신중론까지, 정말 다양한 목소리가 나오고 있습니다. 마치 뜨거운 감자처럼 말이죠!
오늘은 이 주제에 대해 좀 더 깊이 파고들어 보려고 합니다. 최근 애디 오스마니(Addy Osmani)가 기고한 “The 70% problem: Hard truths about AI-assisted coding(70% 문제: AI 지원 코딩에 대한 어려운 진실)”라는 글이 아주 현실적이고 통찰력 있는 분석을 내놓았는데요. 이 글의 내용을 중심으로, 기존 저의 블로그에서 다루었던 AI 기술에 대한 관점과 스타일을 녹여내 AI 코딩의 현재와 미래, 그리고 개발자로서 우리는 무엇을 고민해야 할지 이야기해 보도록 하겠습니다.
1. AI 코딩, 지금 누가 어떻게 쓰고 있나? – “부트스트래퍼” vs “이터레이터”
애디 오스마니는 현재 개발자들이 AI 코딩 도구를 활용하는 방식을 크게 두 가지 유형으로 나눕니다.
부트스트래퍼 (Bootstrappers): 제로에서 MVP까지 빠르게!
이들은 주로 새로운 프로젝트를 시작할 때 AI를 활용합니다. Bolt, v0, 스크린샷-투-코드 AI 같은 도구들을 사용해 디자인이나 대략적인 컨셉만으로 초기 코드베이스를 순식간에 만들어내죠. 몇 주 걸릴 작업을 며칠, 심지어 몇 시간 만에 프로토타입으로 구현하여 빠르게 사용자 피드백을 받는 데 집중합니다. 아이디어 구상부터 실행까지의 간극을 혁신적으로 줄여주는 방식입니다.
이터레이터 (Iterators): 일상 개발 업무의 페어 프로그래머
이들은 Cursor, Cline, Copilot, WindSurf 같은 도구를 일상적인 개발 워크플로우에 통합하여 사용합니다. 코드 자동 완성, 복잡한 리팩토링, 테스트 및 문서 생성 등 마치 똑똑한 페어 프로그래머와 함께 일하는 것처럼 AI를 활용하죠. 화려하진 않지만, 어쩌면 더 근본적인 변화를 가져올 수 있는 방식입니다.
흥미로운 점은, 이 두 가지 접근 방식 모두 개발 속도를 극적으로 높일 수 있지만, 눈에 보이지 않는 숨겨진 비용이 따른다는 것입니다.
2. 마법 뒤에 숨겨진 “70%의 벽” – AI 학습 곡선의 역설
최근 위와 같은 트윗이 개발 현장의 목소리를 정확히 짚어냈다고 하는데요. 비 엔지니어들이 AI로 코딩을 시도할 때, 놀랍도록 빠르게 70% 지점까지는 도달하지만, 나머지 30%를 완성하는 데 엄청난 좌절감을 느낀다는 것입니다. 마치 눈앞에 다 왔는데 보이지 않는 벽에 가로막힌 느낌이랄까요? 근데 이 언급에 해당하는 대상이 과연 비엔지니어 만일까요?   예를 들어 3D 게임 개발 관련 경험이 전무한 시스템 엔지니어를 보자면 3D 게임엔진에서 태양의 위치에 따른 지표면의 밝기를 조절하는 법선벡터 설정의 의미를 모르고 있을 가능성이 있을겁니다. 생성형 AI가 이런 코드를 작성한다면 이후 더 많은 코드를 스스로 혹은 생성형 AI를 기반으로 작성해 낼 수 있을까요? 오류를 고칠 수 있을까요? 아마도 여기서 막힐것이고 다시 3D 그래픽스 책을 공부해야 될 것입니다(이 사례는 딱 저의 경험이였습니다 ㅎㅎ).    
“두 걸음 후퇴” 패턴의 함정: AI가 제안한 수정안이 다른 버그를 만들고, 그걸 고치려다 또 다른 문제를 야기하는 악순환에 빠지기 쉽습니다. 특히 경험이 부족한 경우, 문제의 근본 원인을 파악하지 못하고 AI와 함께 ‘두더지 잡기’ 게임을 하게 될 수 있습니다.
“AI 속도”의 이면: 시니어 개발자가 AI 도구를 쓰는 걸 보면 마법처럼 보입니다. 순식간에 기능을 만들고 테스트까지 완료하죠. 하지만 자세히 보면, 그들은 AI가 생성한 코드를 맹목적으로 수용하는 것이 아닙니다. 끊임없이 리팩토링하고, 엣지 케이스를 추가하며, 아키텍처를 고민하고, 오류 처리를 강화합니다. 수년간 쌓아온 엔지니어링 지혜를 AI의 결과물에 적용하는 것이죠. 반면, 주니어 개발자는 이런 과정을 간과하여 ‘모래성 같은 코드’를 만들 위험이 있습니다.
지식 격차와 역설: AI 도구는 초보자보다 숙련된 개발자에게 더 큰 도움을 준다는 역설이 존재합니다. AI는 마치 열정 넘치지만 경험 없는 주니어 개발자와 같습니다. 코드는 빨리 짜지만, 끊임없는 지도와 수정이 필요하죠. 많이 알수록 AI를 더 잘 이끌 수 있습니다. 결국 AI는 학습을 대체하는 것이 아니라, 학습을 가속하는 도구로 활용될 때 가장 빛을 발합니다.
이 “70% 문제”는 현재 AI 코딩 도구가 아직 만능 해결책이 아니며, 소프트웨어를 실제 운영 가능한 수준으로 만드는 마지막 30%에는 여전히 깊이 있는 엔지니어링 지식이 필요하다는 것을 시사합니다.
3. AI와 제대로 협업하는 법 – 실용적인 패턴 3가지
그렇다면 이 강력하지만 까다로운 AI와 어떻게 효과적으로 협업할 수 있을까요? 애디 오스마니는 다음과 같은 실용적인 패턴들을 제시합니다.
“AI 초안(AI first draft)” 패턴:
AI에게 기본적인 구현을 맡깁니다.
생성된 코드를 사람이 직접 검토하고 모듈성을 고려해 리팩토링합니다.
포괄적인 오류 처리, 철저한 테스트, 주요 결정 사항에 대한 문서화를 추가합니다.
“지속적인 대화(Constant conversation)” 패턴:
각각의 명확한 작업 단위로 새로운 AI 채팅을 시작합니다.
컨텍스트는 집중적이고 최소한으로 유지합니다.
변경 사항을 자주 검토하고 커밋하며, 짧은 피드백 루프를 유지합니다.
“신뢰하되 검증하라(Trust but verify)” 패턴:
초기 코드 생성에는 AI를 활용합니다.
모든 중요한 실행 경로는 반드시 수동으로 검토합니다.
엣지 케이스에 대한 자동화된 테스트를 수행하고, 정기적인 보안 감사를 실시합니다.
결국 핵심은 AI를 맹신하지 않고, 인간 개발자의 경험과 판단을 통해 AI의 결과물을 적극적으로 다듬고 검증하는 것입니다.
4. 그래서 개발자는 이제 뭘 해야 할까? – AI 시대 생존 전략
이러한 변화의 흐름 속에서 개발자들은 어떤 자세를 가져야 할까요?
작게 시작하세요 (Start small): 처음부터 거창한 작업보다는 잘 정의된 작은 작업에 AI를 활용하고, 생성된 모든 코드를 꼼꼼히 검토하며 점진적으로 큰 기능으로 확장해나가세요.
모듈성을 유지하세요 (Stay modular): 모든 것을 작고 집중된 파일로 나누고, 컴포넌트 간 명확한 인터페이스를 유지하며, 모듈 경계를 문서화하세요. 이는 AI가 생성한 코드의 복잡성을 관리하는 데 중요합니다.
당신의 경험을 믿으세요 (Trust your experience): AI는 당신의 판단을 대체하는 것이 아니라 가속하는 도구입니다. AI가 생성한 코드가 뭔가 이상하다고 느껴진다면, 주저하지 말고 의문을 제기하고 엔지니어링 표준을 지키세요.
AI는 우리가 이미 알고 있는 패턴을 구현하는 데 뛰어나고, 새로운 아이디어를 빠르게 프로토타이핑하며, 반복적인 작업을 자동화하는 데 강력한 힘을 발휘합니다. 이를 통해 우리는 더 흥미로운 문제에 집중할 수 있게 됩니다.
5. 코딩을 넘어: 에이전트 기반 소프트웨어 엔지니어링의 부상
현재의 AI 코딩 도구들이 이미 우리의 작업 방식을 바꾸고 있지만, 2025년을 향해 가면서 우리는 훨씬 더 큰 변화의 문턱에 서 있습니다. 바로 에이전트 기반 소프트웨어 엔지니어링(Agentic Software Engineering)의 등장입니다.
단순히 프롬프트에 응답하는 것을 넘어, 이러한 시스템은 점점 더 자율적으로 해결책을 계획하고, 실행하며, 반복할 수 있게 될 것입니다. 마치 스스로 생각하고 행동하는 디지털 동료처럼 말이죠.
응답자에서 협력자로: AI가 단순히 명령을 기다리는 대신, 작업의 의도를 이해하고 문제를 해결하기 위해 주도적으로 행동합니다. 예를 들어, 디버깅 시 잠재적 문제를 스스로 식별하고, 테스트를 실행하며, 해결책을 제안하고 검증까지 할 수 있습니다.
다중 모드(Multimodal)의 미래: 코드뿐만 아니라 UI 스크린샷, 목업, 다이어그램 같은 시각적 정보, 자연어 대화, 브라우저나 터미널 같은 환경과의 상호작용을 통합적으로 이해하고 작업하게 될 것입니다.
자율적이되 유도되는 방식: AI가 자율성을 가지되, 인간의 지도와 전문성을 존중하는 협력 관계가 중요해집니다. 명확한 가이드라인 설정, 강력한 아키텍처 패턴 구축, 효과적인 피드백 루프가 핵심이 될 것입니다.
“언어가 새로운 프로그래밍 언어”: 안드레이 카파시(Andrej Karpathy)가 언급했듯이, 명확하게 생각하고 자연어로 정확하게 소통하는 능력이 전통적인 코딩 기술만큼 중요해질 것입니다.
이러한 에이전트 기반 개발 환경은 우리에게 더 강력한 시스템 설계 및 아키텍처 사고, 더 나은 요구사항 명세 및 소통 능력, 품질 보증 및 검증에 대한 더 깊은 집중을 요구할 것입니다.
6. AI가 놓치는 것: 소프트웨어 장인 정신의 가치 회복?
AI 덕분에 소프트웨어를 빠르게 만드는 것은 그 어느 때보다 쉬워졌습니다. 하지만 그 과정에서 우리는 어쩌면 가장 중요한 것, 바로 소비자 수준의 세련된 경험을 만드는 예술을 잃어버릴 위험에 처해 있는지도 모릅니다.
AI로 빠르게 만든 데모는 멋져 보이지만, 실제 사용자가 사용하기 시작하면 허점이 드러나는 경우가 많습니다. 이해하기 어려운 오류 메시지, 예외 상황에서의 앱 충돌, 혼란스러운 UI 상태, 간과된 접근성, 느린 장치에서의 성능 문제 등. 이것들은 단순한 버그가 아니라, 사용자가 소프트웨어를 참고 쓰느냐, 아니면 사랑하게 되느냐를 가르는 결정적인 차이입니다.
이런 세심함은 AI가 생성하기 어렵습니다. 공감, 경험, 그리고 장인 정신에 대한 깊은 애정에서 비롯되기 때문이죠. 아이러니하게도, AI 도구가 반복적인 코딩 작업을 처리해 줌으로써 개발자들은 오히려 이러한 ‘폴리싱(polish)’ 작업, 즉 사용자를 진정으로 만족시키는 소프트웨어를 만드는 데 더 집중할 수 있는 개인 소프트웨어의 르네상스가 올 수도 있습니다.
7. 코딩은 개발의 전부가 아니다 – 소프트웨어 엔지니어링의 큰 그림 (Gergely Orosz의 추가 의견)
프래그머틱 엔지니어의 거글리 오로즈(Gergely Orosz)는 애디 오스마니의 글에 덧붙여 중요한 점을 지적합니다. AI 코딩 도구에 대한 논의가 주로 코드 생성 능력에 집중되지만, 실제 소프트웨어 엔지니어링에서 코딩이 차지하는 비중은 생각보다 크지 않다는 것입니다. 프레드 브룩스가 1975년에 “미시컬 맨먼스”에서 언급했듯이 계획, 코딩, 테스트, 시스템 통합 등 다양한 과정이 포함됩니다.
거글리 오로즈는 현대 소프트웨어 엔지니어의 시간 분배를 대략 다음과 같이 추정합니다.
계획: 20%
코딩 (코드 + 테스트): 40%
코드 리뷰 (타인의 코드): 20%
운영 준비 + 배포 + 수정 + 모니터링/알림: 20%
AI 도구는 현재 “구축(Build)”, 즉 코딩 부분에서 큰 도움을 주지만, 무엇을 만들지(What), 어떻게 만들지(How) 계획하고, 검증(Verify)하고, 배포(Ship it)하고, 모니터링 및 장애 대응(Monitoring and oncall)하며, 유지보수(Maintain)하고, 필요에 따라 마이그레이션(Migrate)하는 등 소프트웨어 엔지니어링의 다른 중요한 영역에서는 아직 그 역할이 제한적입니다.
과거 COBOL, Visual Basic, 노코드 운동 등이 “개발자 없는 개발”을 꿈꿨지만, 복잡한 소프트웨어의 세계에서는 여전히 숙련된 엔지니어의 통찰력과 문제 해결 능력이 필수적입니다. AI가 비전문가의 소프트웨어 제작 장벽을 낮출수록, 오히려 유지보수해야 할 소프트웨어는 더 많아질 수도 있습니다.
그리고 중요한 점은, AI 도구를 더 효과적으로 활용하는 것은 숙련된 엔지니어라는 것입니다. 목표를 정확히 알고, AI의 결과물을 비판적으로 검토하며, 언제 개입해야 할지 알기 때문입니다. 따라서 AI 시대에는 오히려 경험 많은 엔지니어에 대한 수요가 증가할 수도 있습니다.
마치며: AI 시대, 개발자의 역할은 진화한다
애디 오스마니와 거글리 오로즈의 분석을 종합해 보면, AI 코딩 도구는 분명 소프트웨어 개발의 풍경을 바꾸고 있지만, 개발자를 대체하기보다는 개발자의 생산성을 극대화하고 역할을 변화시키는 방향으로 나아가고 있습니다.
마치 제가 이전 글 “미래에는 비용 효율적인 AI 기반 지식노동을 해야 된다 – 2027년 소프트웨어 개발비 예측/분석“에서 언급했듯이, AI는 인간 노동 비용의 작은 부분으로 엄청난 생산성 향상을 가져올 수 있는 도구입니다. 개발자는 더 이상 모든 코드를 직접 작성하는 역할에서 벗어나, AI가 생성한 결과물을 검증하고, AI가 해결하지 못하는 복잡한 문제에 집중하는 ‘큐레이터’이자 ‘문제 해결사’로 진화할 것입니다.
또한, “AI, 인간 데이터 너머 ‘경험’으로: The Era of Experience“에서 논의했던 것처럼, AI가 스스로 경험을 통해 학습하는 시대가 온다면, 우리는 AI가 효과적으로 경험하고 학습할 환경을 설계하고 그 결과를 해석하며 협력하는 능력이 더욱 중요해질 것입니다. “MCP의 성공과 그 의미“에서 다룬 것처럼, LLM이 컨텍스트를 잘 활용하도록 돕는 프로토콜이 중요했듯이, 미래에는 AI의 현실 경험 데이터 활용을 돕는 새로운 방식들이 고민될 것입니다.
결국, AI 코딩 도구는 만능 해결사가 아니라, 숙련된 개발자의 손에 들렸을 때 그 진가를 발휘하는 강력한 ‘조력자’입니다. 중요한 것은 이 도구를 어떻게 활용하여 ‘더 나은’ 소프트웨어를 만들 것인가에 대한 끊임없는 고민과 학습, 그리고 변화에 적응하는 유연성일 것입니다. 특히 필자의 경우 앞서 이야기한 3D 그래픽스에 대한 공부를 아주 빠른 3D 게임 프로토타이핑을 통한 게임 개발 동기 부여 그리고 이후 개발진행을 위한 학습으로 승화시킬 수 있었습니다. 아마도 왜 이걸 공부해야 하는지 알기 위해서 생성형 AI가 아니었으면 좀더 오려 걸렸을 수도 있을거라 예상합니다. 
끝!

AI 코딩시대 개발자에게 필요한 역량은?

댓글