이남희, 백승현
22시간 전
872
처음에는 초보 수준도 안 되어 보였던 AI의 코딩 능력이 2025년 후반을 기점으로 실무에 적용해도 전혀 손색이 없는 수준에 이르렀고, 2026년인 지금은 모든 영역에서 시니어 레벨의 역량을 보여주고 있습니다. 따라서 사람이 코드를 직접 작성하던 시대에서 AI와 협업하는 시대로, 개발자는 구현자에서 설계자이자 검증자로 진화하고 있습니다. 바로 지금, AI 시대의 개발자에게 필요한 질문은 다음 세 가지입니다.
“작업을 어떻게 분해할 것인가?”
“AI의 출력을 어떻게 검증할 것인가?”
“개발자로서 주도권을 어떻게 유지할 것인가?”
저는 그동안 『개발자 기술 면접 노트』라는 책을 집필하며, ‘더 나은 (코드를 구현하는) 개발자가 되기 위한 고민’을 이어나갔지만 이제는 ‘어떻게 AI와 잘 협업하는 설계자’가 될 수 있을지에 대해 고민하고 있습니다.
개발자가 문제를 정의하고 분석과 설계를 통해 직접 코드를 작성
결과물을 테스트하고 디버깅한 뒤, QA를 거쳐 하나의 제품을 완성
→ 시스템 디자인이나 아키텍처 설계, ERD 설계, 기능 정의를 비롯한 API 명세 같은 세부적인 프로세스와 문서 작성
→ 프런트엔드, 백엔드, 인프라, 디자인, 기획, QA 등의 직군이 모두 협업해야 함
개발자는 전체적인 프로세스를 진두지휘하고 검증하는 역할에 더 집중
단계별로 확인 작업을 수행하고, 의도한 시나리오대로 기능이 제대로 동작하는지 테스트하며, 최종 결정을 내리는 역할
이제 개발자의 역할은 코드 작성이 아닌, 그 외 영역에서 조율하고 지시하는 것으로 전환되고 있습니다. 이 과정에서 개발자의 핵심 역량도 변화할 수밖에 없게 되었죠. 기본적인 개발 언어 문법을 이해한 상태에서 빠르게 요구사항을 분석하고, AI가 정확하게 작업할 수 있도록 업무를 분배하며, 출력물을 검토하고, 테스트의 품질과 정확성을 점진적으로 보정하는 능력이 중요해집니다.
과거의 ‘좋은 개발자’가 문제를 해결하고 빠르고 정확하게 코드를 작성하는 사람이었다면, 지금은 AI 도구를 통해 여러 작업을 지시하고 조율하여 문제를 즉각적으로 수정하는 역할(Orchestrator)이라고 볼 수 있습니다. 즉, AI 시대에 맞춰 새롭게 기대되는 개발자의 역량은 다음과 같습니다.
그럼에도 불구하고 변하지 않는 것들도 있습니다. 문제가 발생했을 때 해당 문제를 해결해나가는 능력과 시시각각 변하는 비즈니스 도메인에 대한 이해, 법적·윤리적 이슈에 대한 판단력은 여전히 필수적인 역량입니다. 부서 간, 역할 간 커뮤니케이션 능력 역시 마찬가지입니다. 여기에 한 가지가 더해진다면 AI 도구와의 커뮤니케이션 능력과 도구의 활용 능력이라고 할 수 있습니다.
개발자라면 누구나 이런 고민을 해본 적 있을 것입니다. “이 기술이 과연 적합한가?”, “이 레거시를 마이그레이션하려면 어디서부터 손을 대야 하지?”, “이 아이디어가 과연 시장에서 통할까?” 과거에는 이런 질문에 답하려면 며칠에서 몇 주의 시간을 투자해야 했죠. 검증 비용이 높으니 검증 자체를 포기하거나, 이미 익숙한 선택만 하곤 했습니다. 큰 회사일수록 더더욱 보수적으로 접근해야 했기에 “일단 한번 해보지 뭐” 같은 표현이 입 밖으로 나오기는 굉장히 어려웠습니다.
AI 도구는 이 검증 비용을 극적으로 낮춥니다. ‘이 아이디어가 과연 시장에서 통할까’와 같은 질문에 스펙만 명확하게 작성하면, 한 시간 안에 동작하는 애플리케이션으로 개념 증명(PoC)을 해볼 수 있습니다. ‘이 기술 스택이 현재 기존 시스템 위에서 제대로 동작할 수 있는가?’와 같은 기술적인 문제도 코드베이스 분석부터 라이브러리의 버전, 런타임 환경을 완벽하게 파악하면, 가능 여부는 물론 일부 모듈들은 순차적으로 변경하면서 먼저 실험해볼 수 있습니다. 또한 프로토타입 우선 접근법을 활용해 빠르게 검증을 해볼 수 있게 되었습니다.
물론 주의할 점도 있습니다. 2025년 9월 미국 비즈니스 매체 패스트 컴퍼니는 “바이브 코딩 숙취(vibe coding hangover)”라는 표현을 쓰며, AI로 빠르게 만든 코드의 유지보수 문제를 지적했습니다. 해외 개발 커뮤니티에서는 AI 생성 코드를 다룰 때 겪는 어려움을 “개발 지옥(development hell)”이라고 표현하기도 했습니다. 그래서 테스트 주도 개발, 명세 작성, 코드 리뷰 같은 검증 체계는 더욱 중요해졌습니다.
예전에는 코드 한 줄마다 모두 비용이었기에 설계를 통해 불필요한 작업을 줄이려 했습니다. 그런데 AI가 코드를 순식간에 생성해주기 시작하자 먼저 코드를 뽑아내는 데 집중하기 시작했습니다. 비개발자들은 말할 것도 없고, 일부 개발자들도 ‘일단 만들어보고 아니면 다시 만들면 되지’라는 생각으로 접근하기 시작했죠. 하지만 여기에 함정이 있습니다. AI는 코드를 빠르게 만들지만, 그 코드가 올바른 방향인지는 알려주지 않고, 보장해주지도 않습니다.
잘못된 방향으로 코드가 나오기 시작하면 무한 수정과 유지보수 지옥에 빠질 가능성이 높습니다. 소프트웨어의 생명력은 초기엔 아이템으로 승부가 나지만 이 시기가 지나면 사용자에게 유용한 기능을 추가하고, 기존 기능들을 원활하게 유지하며 업데이트를 하는 운영의 영역에서 판가름 난다고 해도 과언이 아닙니다. 장애나 버그가 잦으면 사용자는 떠나기 마련입니다.
예를 들어 TODO 앱을 설계 없이 그냥 시도한다고 가정하면 아마 다음과 같은 순서로 작업이 진행될 것입니다.
1일차: "TODO 웹 애플리케이션 만들어줘" → 개인용 웹 애플리케이션 CRUD 생성
3일차: "팀 공유 기능 추가해줘" → 인증/권한 시스템 급조
7일차: "SaaS로 서비스하고 싶어" → 멀티테넌시 구조 전면 재작성
14일차: "온프레미스 설치 옵션도 필요해" → 환경 설정 시스템 재설계
SaaS 기능 확장이나 설치형으로 변경이 되면서 전면적인 기능과 코드 수정을 해야 합니다. 설계없이 진행되는 코드는 반복되는 수정과 리팩터링, 기능의 변경과 오류, 코드 일관성 부족 등 토큰 비용 측면에서도 불필요한 낭비가 일어납니다. 이런 요소를 사전에 방지하고 결과물의 퀄리티를 기대치만큼 구현하기 위해서는 반드시 설계를 해야 합니다.
설계라고 하면 거창한 UML 다이어그램이나 아키텍처 디자인, ERD, 기능 목록, 인터페이스 정의서 등 수백 페이지의 문서를 떠올릴 수 있습니다. AI와 협업하는 맥락에서 설계는 그보다 훨씬 실용적인 의미를 갖습니다. 다음을 살펴봅시다.
AI는 ‘어떻게(How)’ 구현할지는 잘 알지만, ‘무엇을(What)’ 만들어야 하는지는 모릅니다. 물론 명확한 기능과 기술 스택을 바탕으로 어떤 방향으로 설계해야 할지 물어보면 쓸 만한 결과를 보여주지만, 그렇지 않다면 정해지지 않은 요소들 중 무엇을 선택할지 개발자가 선택해야 합니다.
그래서 저는 ‘작은 단위로 쪼개기의 힘’을 강조합니다. 자세한 방법은 도서 『클로드 코드 마스터』에 모두 담았습니다. 설계를 잘 하는 법은 물론, AI 도구와의 협업에 관한 모든 방법론을 프로덕션 수준의 서비스를 직접 만들어보며 익힐 수 있습니다. TDD와 SDD로 AI 출력을 믿을 수 있는 코드로 만들고 CLAUDE.md, Hook, MCP 등 클로드 코드를 내 것으로 만드는 고급 설정을 배웁니다.
위 콘텐츠는 『클로드 코드 마스터』에서 발췌하여 작성하였습니다.
설계 없이 시작한 개발이 결국 더 큰 비용과 복잡도로 돌아온다는 점을 느끼셨다면, 이제는 직접 그 흐름을 바꿔볼 차례입니다. 도서 『클로드 코드 마스터』를 기반으로 한 4주 완독 챌린지에서는 기획부터 설계, 개발, 배포까지 AI와 협업하는 전체 과정을 실제로 경험해볼 수 있습니다. 단순히 코드를 만드는 것을 넘어, AI를 ‘개발 파트너’로 활용하는 실전 감각을 완주를 통해 만들어보시기 바랍니다.
0
1 
댓글