🎆 소프트웨어 3.0이 오고 있습니다: AI 매니저 시대의 도래

TL;DR

저는 소프트웨어 개발의 진짜 미래가 어떤 모습일지 궁금해서, Claude Code를 사용해 처음부터 macOS 앱을 만들어 보았습니다. 이 직접적인 테스트를 통해 오늘날 소프트웨어 개발을 위한 AI가 어떤 수준인지 명확하게 파악할 수 있었습니다. 요점은 다음과 같습니다.

좋은 점: AI는 프로젝트를 시작하는 데 정말 환상적입니다. 지루한 모든 보일러플레이트를 처리해 주었고, 몇 년간 사용하지 않았던 프레임워크를 배우는 데 도움을 주었으며, 새로운 아이디어를 놀랍도록 빠르게 시도해 볼 수 있게 해주었습니다.

어려운 점: 상황이 조금만 복잡해지자 AI는 상당한 감독을 필요로 했습니다. AI는 기억력이 전혀 없는 극도로 빠른 주니어 개발자처럼 행동했습니다. 같은 버그에 계속 걸려 넘어지고, 이미 잘 작동하던 것을 '도와주겠다'며 망가뜨리고, 프로젝트 목표에 대해 끊임없이 상기시켜 줘야 했습니다.

핵심 역량: 제가 얻은 가장 큰 교훈은 이것입니다. '영어는 새로운 프로그래밍 언어가 아니다. 뛰어난 판단력이 핵심이다.' 개발자의 역할이 단순히 코드를 작성하는 것에서 'AI 매니저'가 되는 것으로 바뀌고 있습니다. 여러분의 역할은 방향을 설정하고, 테스트 같은 것으로 '완료'의 기준을 정의하며, 최종적인 품질 검사를 책임지는 것이 됩니다.

우리에게 의미하는 것: AI는 개발자를 쓸모없게 만드는 대신, 여러분의 경험과 큰 그림을 보는 능력을 더욱 가치있게 만듭니다. 가장 중요한 기술은 얼마나 빨리 타이핑하는지가 아니라, 얼마나 잘 생각하는지입니다.

저는 AI 분야에서 스타트업을 만들고 있으니, 이 기술에 대해 낙관적이라고 해도 과언이 아닐 겁니다. 하지만 솔직히 말해, 현실에 비해 기대가 조금 앞서 나간 면이 있습니다. Andrej Karpathy의 '소프트웨어 3.0' 비전에서 빌려온 한 아이디어는 '영어가 새로운 프로그래밍 언어다'라는 그럴듯하지만 불완전한 슬로건으로 단순화되었습니다.

새로운 소프트웨어 패러다임에 접어들었다는 점에는 동의하지만, 제 경험에 따르면 이는 훨씬 더 미묘한 문제입니다. 물론 영어를 사용해 작업을 처리할 수는 있지만, 진짜 기술은 단순히 기계와 대화하는 것이 아니라 제가 '에이전트 엔지니어링(agent engineering)'이라고 부르는 새로운 분야입니다. 이로 인해 저는 이런 의문을 갖게 되었습니다. 이 새로운 기술이 과연 깊이 있는 엔지니어링 전문 지식의 필요성을 얼마나 대체할 수 있을까?

이를 알아보기 위해, 저는 전통적인 IDE를 전혀 사용하지 않고 오직 Claude Code와 ChatGPT만을 이용해 네이티브 macOS 앱을 만들기로 했습니다. 데스크톱 앱을 마지막으로 만들어 본 것은 Firefox 확장 프로그램을 위해 XPCOMM을 사용하던 10년 전이었습니다. 제 목표는 여러 모델 제공업체의 에이전트를 관리 및 비교하고, 워크플로우를 조율하며, 실행 기록을 추적하는 '에이전트 워크스페이스(Agent Workspace)'를 만드는 것이었습니다.

허니문 단계: Claude Code를 이용한 신속한 프로토타이핑

처음 며칠은 환상적이었습니다. 오랜만에 소프트웨어를 그저 생각만으로 만들어내는 순수한 즐거움을 경험했습니다. 보일러플레이트 설정, 문법과의 씨름, 불분명한 문서 탐색과 같은 개발 과정의 일반적인 마찰이 전혀 없었습니다. Claude Code는 SwiftUI에 대한 제 지식 격차를 즉시 메워주었습니다.

이는 단순히 더 빨리 움직이는 것 이상의 의미였습니다. 창의적인 추진력을 계속 유지할 수 있었습니다. '어떻게'에 얽매이지 않고 '무엇을'에 집중할 수 있었죠. Claude Code가 기계적인 작업을 처리해주면서, 전문적인 코딩의 고된 일상 속에서 때때로 잃어버리기 쉬운 재미를 되찾을 수 있었습니다.

가장 중요한 것은, 반복 작업의 비용이 믿을 수 없을 정도로 저렴해졌다는 점입니다. 시간 낭비라는 침울한 기분 없이 방향을 바꾸고 다양한 사용자 경험을 탐색할 수 있었습니다. 이렇게 신속하게 프로토타입을 만들 수 있는 능력은 이전에는 불가능했던 속도로 문제 영역을 탐색하게 해주는 강력한 힘입니다.

현실 점검: Claude Code가 혼란에 빠질 때

결국 앱의 복잡성이 증가하면서 허니문은 끝났습니다. Claude Code는 끊임없는 감독이 필요한, 무한히 빠르지만 순진한 주니어 개발자처럼 느껴지기 시작했습니다. 초기의 몰입감은 디버깅과 방향 수정이라는 지루한 현실에 의해 자주 중단되었습니다.

AI 생성 코드 디버깅: 절망의 마크다운 루프

제 앱은 Markdown을 렌더링해야 했는데, 이는 간단한 작업이어야 했습니다. Markdown 뷰가 숨겨져 보이지 않아서 Claude Code에 디버깅하고 수정해달라고 요청했습니다. 하지만 Claude Code는 네이티브 뷰, WebView, 서드파티 라이브러리 등 그럴듯하지만 틀린 해결책들을 맴돌며 루프에 빠졌습니다. 이것은 문제의 근본 원인을 먼저 이해하지 않고 인터넷에서 찾은 해결책을 시도하는 전형적인 주니어 개발자의 행동입니다.

디버깅 과정 자체가 가장 많은 것을 보여주었습니다. Claude Code는 진단 단계를 제안하고, 디버그 구문을 추가한 다음, 저에게 로그와 스크린샷을 요청했습니다. 그 피드백을 바탕으로 뷰 크기 조정 문제를 정확히 식별하고 왜 실패했는지 이해했습니다. 하지만 디버그 코드를 제거하고 수정 사항을 적용해달라고 요청하자, 근본 원인을 잊어버린 듯했습니다. 단 하나의 필요한 변경 사항인 최소 높이 설정을 하는 대신, 똑같은 잘못된 접근 방식을 다시 제안했습니다.

컨텍스트 관리라는 귀찮은 일

Claude Code에서는 프로젝트 컨텍스트를 위해 Claude.md 파일을 제공할 수 있는데, 이론적으로는 유용한 아이디어입니다. 저는 처음에 앱의 목표, 아키텍처, 제 코딩 스타일 선호도를 자세히 기술하여 설정했습니다. 처음에는 도움이 되는 것 같았지만, 앱이 발전함에 따라 언제 업데이트해야 할지 알기 어려웠습니다.

문서화에 그다지 능숙하지 않은 저에게 이 파일을 최신 상태로 유지하는 것은 계속 미루게 되는 귀찮은 일이었습니다. Claude Code는 이미 진행 중인 대화에서 필요한 컨텍스트를 가지고 있었지만, 그중 어느 것도 장기적인 사용을 위해 저장되지 않았습니다. 이전에 지시했던 방식과 다르게 API를 설계하는 것과 같은 실수가 반복되는 원인이 되었기에, 이는 놓쳐버린 기회처럼 느껴졌습니다.

의욕 넘치는 AI 길들이기: 계획 없는 변경에서 '계획 모드'로

Claude Code는 또한 요청하지 않은 변경을 하는 버릇이 있었습니다. 마치 자기 업무 범위를 벗어난 코드를 '도와주겠다'며 리팩토링하다 다른 것을 망가뜨리는 의욕 넘치는 개발자처럼 말이죠. 잘 작동하던 기능들이 겉보기에는 관련 없는 변경 이후 갑자기 멈추곤 했습니다. 이러한 취약성은 정확성과 QA에 대한 부담을 고스란히 제 어깨에 지웠습니다.

결국 저는 구현하기 전에 변경 사항을 계획하도록 요청하는 법을 배웠고, 이는 도움이 되었습니다. 이를 위한 유용한 팁은 Shift + Tab으로 계획 모드(plan mode)를 활성화하는 것입니다. 그러면 매번 요청할 필요가 없습니다.

최상의 시나리오라는 착각

이 실험이 최상의 시나리오였다는 점을 분명히 해야겠습니다. 이것은 레거시 코드나 복잡한 통합이 없는, 독립적인 그린필드(greenfield) 프로젝트였습니다. 대부분의 실제 제품은 그런 호사를 누리지 못합니다.

제가 겪었던 컨텍스트 관리와 취약성 문제는 15년 된 거대한 모놀리식 시스템에서는 훨씬 더 심각할 것입니다. 깨끗한 환경에서 이 정도 수준의 감독이 필요하다면, 대부분 시스템의 복잡한 현실에서는 상당한 장애물이 될 것입니다. 제 경험은 요구되는 인간 판단력 수준의 천장이 아니라 바닥을 보여줍니다.

진짜 '소프트웨어 3.0': AI 매니저의 부상

이 실험은 저에게 새로운 사고 모델을 형성하는 데 도움을 주었습니다. 미래는 개발자를 대체하는 것이 아니라, 그들을 새로운 역할인 'AI 매니저(AI Manager)'로 격상시키는 것입니다. 이 사람은 AI가 실행 엔진으로서 부족한 아키텍처 비전, 맥락적 판단, 그리고 품질 보증을 제공합니다.

'순진한 주니어 개발자'라는 비유는 좋은 출발점이지만, 완전히 정확하지는 않습니다. 인간 주니어는 세계 모델(world model)을 가지고 있고 실수로부터 배우지만, LLM은 그렇지 않습니다. LLM은 패턴 매칭을 수행하는 통계적 엔진이며, 진정한 인과적 추론(causal reasoning)과 세션 간의 지속적인 기억력이 부족합니다. 이는 매니저의 역할을 더욱 중요하게 만듭니다.

AI가 개발자 워크플로우에 미치는 영향: 비율의 역전

과거에 시니어 개발자는 시간의 60%를 실행(코딩)에, 40%를 아키텍처와 전략에 사용했을 수 있습니다. 제 경험에 따르면 Claude Code와 같은 AI 코딩 어시스턴트는 그 비율을 뒤집고 있습니다. AI는 코드 생성의 첫 90%를 처리하지만, 그 대가로 우리가 인지적 노력의 90%를 감독, 전략, 문제 해결에 쏟도록 요구합니다. 여러분의 가치는 타이핑 속도에서 판단의 질로 이동합니다.

새로운 종류의 페어 프로그래밍

가장 좋은 사고 모델은 부하 직원에게 명령을 내리는 것이 아니라, 상식이나 기억력이 전혀 없는 똑똑하고 번개처럼 빠른 파트너와 페어링하는 것이었습니다. 이 파트너는 코드를 작성할 수 있지만, 방향, 컨텍스트, 판단은 여러분이 제공해야 합니다. 제 워크플로우는 비동기적이 되었습니다. 저는 Claude Code에 작업을 위임하고 다른 일을 하다가, 제 편의에 맞춰 돌아와 완성된 코드를 검토했습니다.

검증 가능한 계약의 힘

제 역할은 구현 코드를 작성하는 것에서 정확성의 증명을 정의하는 것으로 바뀌었습니다. 모호한 영어 지시는 좌절스러운 루프로 이어졌지만, 정확하고 기계적으로 테스트 가능한 명세는 명확한 목표를 만들어주었습니다. 테스트 주도 개발(Test-Driven Development, TDD)은 이를 위한 특히 효과적인 도구임이 증명되었습니다.

먼저 실패하는 테스트를 작성함으로써, 저는 Claude Code에 검증 가능한 계약(verifiable contract)을 제시했습니다. AI의 임무는 더 이상 '이 기능을 만들어'라는 모호한 것이 아니라 '이 테스트를 통과시켜'라는 구체적인 것이 되었습니다. 이것은 Claude Code에 자기 수정 메커니즘을 제공했지만, 완벽한 해결책은 아닙니다. TDD는 제 Markdown 문제에는 도움이 되지 않았습니다. 그럼에도 불구하고, 이는 워크플로우를 자동화된 실행과 검증이라는 개선된 루프로 변화시켰습니다.

결론: 인간의 판단력은 여전히 핵심에 남아있다

이러한 문제들을 오늘날 모델의 일시적인 한계로 치부하기 쉽습니다. 도구는 분명히 개선되겠지만, 이것이 관리자의 필요성을 자동화할 것이라고 가정하는 것은 소프트웨어 개발이 무엇인지 오해하는 것입니다. 소프트웨어 개발이란 모호한 인간의 의도를 정확한 기계 논리로 번역하는 과정입니다.

모델이 아무리 유능해지더라도, 모호함을 해결하고 방향을 설정하기 위해서는 도메인 전문성과 아키텍처에 대한 통찰력을 가진 인간이 항상 필요할 것입니다. 그 감독의 성격은 문법을 수정하는 것에서 전략을 정의하는 것으로 진화하겠지만, 그 필요성 자체가 사라지지는 않을 것입니다.

이는 우리의 전문적인 성장이 코딩 속도보다는 판단의 질에 의해 더 많이 정의될 것임을 의미합니다. AI가 더 많은 보일러플레이트와 기반 작업을 처리함에 따라, 모든 개발자는 훨씬 더 생산적이 될 것입니다. 이는 일자리가 줄어든다는 의미가 아니라, 더 많은 사람이 무언가를 만들 수 있는 힘을 갖게 되고 소프트웨어의 총량이 증가할 것이라는 의미입니다.

진정한 변화는 우리가 조직되는 방식에 있을 것이며, 팀은 더 작아지고 더 큰 레버리지 효과를 내게 될 것입니다. 이러한 미래에 개발자의 주된 역할은 기계가 할 수 없는 전략적 방향과 창의적인 감독을 제공하는 것입니다. 미래에 가장 가치 있는 개발자는 오늘날 최고의 AI 매니저가 될 것입니다.

여러분은 AI 코딩 어시스턴트를 사용해 본 경험이 어떠신가요?

Software 3.0 Is Coming. Long Live the AI Manager.

Why the most valuable skill in the age of AI isn’t coding, but judgment.

Manveer ChawlaManveer Chawla