신입 개발자의 AI 주도 개발 생존기

취업 전 다양한 프로젝트와 프리랜서 활동, 그리고 네이버 부스트캠프와 우아한테크코스를 거치며 나만의 개발 철학을 차곡차곡 쌓아왔다고 자부했다. 하지만 현업의 문을 열고 마주한 가장 큰 변화는 내가 배운 '코딩' 그 자체가 아니라, 바로 AI 주도 개발(AI-Driven Development)이라는 거대한 흐름이었다.
이번 글에서는 신입 개발자로서 AI와 함께 협업하며 느낀 당혹감과 깨달음, 그리고 우리가 앞으로 가져야 할 태도에 대해 이야기해보려 한다. 정답을 제시하기보다는, "아, 이 사람은 요즘 이런 생각을 하며 개발하고 있구나" 하는 마음으로 편하게 읽으면 좋을 것 같다.

AI, '정답지'에서 '파트너'로

대학생 시절부터 ChatGPT나 뤼튼 같은 AI를 종종 활용해왔다. 하지만 당시의 나에게 AI는 '모르는 문제를 풀어주는 선생님'에 가까웠다. 학습이 목적이었던 내게 질문하자마자 정답을 툭 던져주는 방식은 오히려 독이 된다고 느꼈고, 급한 상황이 아니라면 공식 문서와 구글링이라는 정석적인 길을 고집하곤 했다.
그러던 중, 현업에서 개발자로 활동 중인 형들에게 "금전적인 여유가 된다면 Cursor AI, Claude Code와 같은 AI 도구를 적극적으로 활용해 봐라." 라는 조언을 듣게 되었다. 실제 면접에서도 AI 활용 역량에 대한 질문을 자주 받았기에, 밑져야 본전이라는 마음으로 Cursor AI를 통해 KMP와 CMP 프로젝트를 진행해 보았다.
결과는 놀라웠다. 성능은 확실했고, 개발 속도는 비약적으로 상승했다. 그때 깨달았다. 이제는 '얼마나 코드를 잘 짜느냐'만큼이나 'AI를 얼마나 영리하게 활용하느냐'가 개발자의 새로운 핵심 역량이 될 것임을 말이다.

'백화점' 속에 '방' 하나를 만든다는 것

현재 우리 팀에서는 AI 주도 개발 프로세스를 도입해 테스트와 디벨롭을 반복하고 있다. 하지만 직접 업무에 적용해 보니 기대만큼 매끄럽지만은 않았다. 가장 큰 장벽은 바로 '컨텍스트(Context)의 부재'였다.
이해를 돕기 위해 비유를 하나 들어보자면, 우리가 거대한 '백화점' 안에 새로운 '방' 하나를 만든다고 가정하는 것이다.
백화점에는 수많은 방이 있고, 각 방의 컨셉과 지어진 시기(Legacy)가 모두 다르다. AI는 비용과 효율 문제로 백화점 전체 구조를 완벽히 파악하지 못한 채, 설계자가 준 정보와 연관되어 보이는 몇 개의 방만을 참고해 새 방을 만든다. 여기서 문제는 '반드시 참고해야 할 방'과 '절대 따라 해서는 안 되는 방'을 구분하는 것은 오직 그 시스템을 꿰뚫고 있는 설계자(개발자)만의 영역이라는 점이다. 설계자의 의도와 맥락을 모르는 AI가 만든 방은 겉보기엔 멀쩡해 보일지 몰라도, 보이지 않는 곳에서 전체 구조를 뒤흔드는 치명적인 결함을 품고 있을 수 있다.
이러한 비유는 실제 개발 현장에서도 그대로 적용된다. 단순히 코드를 생성하는 속도에 감탄하기엔, AI가 놓치는 '우리만의 맥락'이 너무나 많기 때문이다.

AI와 함께하며 마주한 '삐끗'의 순간들

실제로 AI와 협업하며 겪었던 몇 가지 시행착오를 공유하자고 한다.
피그마 MCP를 활용해 UI 코드를 생성할 때였다. AI는 시각적인 요구사항은 잘 잡아냈지만, 정작 우리가 공들여 구축해둔 사내 디자인 시스템 컴포넌트나 테마 토큰을 적절히 활용하지 못했다. 결국 생성된 코드를 다시 우리 시스템에 맞게 일일이 리팩터링을 해야 하는 번거로움이 발생했다.
AI는 코딩 기술은 뛰어나지만, 우리 서비스만의 특수한 비즈니스 로직이나 도메인 지식은 알지 못한다. 특정 로직에서 반드시 지켜야 할 예외 처리를 생략하거나, 반대로 기획서에도 없는 기능을 '창의적'으로 덧붙여 구현해버리는 바람에 디버깅에 더 많은 시간을 쏟기도 했다.
AI가 코드를 짜주는 시간은 짧지만, 그 코드가 안전한지 검토(Confirm)하는 시간은 결코 짧지 않다. 명확하지 않은 요구사항은 결국 '잘못된 결과물 → 긴 검토 시간 → 재작업'이라는 비효율의 굴레를 만든다.

에이전트 기반의 워크플로우 설계

이런 시행착오를 해결하기 위해 우리는 AI를 단순한 챗봇이 아닌, 구조적인 워크플로우 안에서 움직이는 에이전트로 활용하기 시작했다.
우리가 정의한 워크플로우는 다음 단계를 거친다. 

[요구사항 분석 → 도메인 정의 → 비즈니스 로직 개발 → UI 개발 → 디자인 시스템 개발]

특히 특정 텍스트나 키워드가 포함될 경우 해당 업무에 특화된 서브 에이전트가 실행되도록 구조화했다.
예를 들어 '디자인 시스템' 관련 트리거가 감지되면, 사내 컨벤션을 완벽히 숙지한 UI 전용 서브 에이전트가 호출된다. 이렇게 역할을 쪼개면 AI가 처리해야 할 정보량이 줄어들어 정확도가 비약적으로 상승한다.
기획서 분석 단계에서 플랫폼 의존성을 제거해 본질적인 비즈니스 로직을 먼저 설계하고, 도메인 개발 시 TDD를 결합해 로직의 무결성을 검증했다. 단단한 도메인 위에 UI를 입히니 디자인 시스템과의 정합성도 훨씬 통제 가능한 범위 안으로 들어왔다.
각 Feature별로 위 과정을 반복하며 개발자의 검수를 거친다. 에이전트가 초안을 잡고 서브 에이전트가 디테일을 채우면, 우리는 마지막 '컨펌'을 통해 전체 프로젝트 구조와의 조화를 확인한다.

개발자, 작성자에서 '비판적 평론가'로

AI 시대의 개발자에게 필요한 역량은 단순히 프롬프트를 잘 입력하는 기술이 아니다. 전체 서비스의 컨텍스트를 유지하면서, AI가 캐치하지 못하는 디테일을 잡아내는 '비판적 사고'다.
우리는 AI를 100% 신뢰하는 신봉자가 되어서는 안 된다. 오히려 깐깐한 건축 감리사처럼, 혹은 냉철한 평론가처럼 AI가 가져온 구조물과 자재를 하나하나 뜯어봐야 한다. 언젠가는 AI가 서비스 전체의 맥락을 완벽히 이해하는 날이 올지도 모른다. 하지만 지금 이 순간, 확실한 것은 개발자의 역할이 'Code Writer'에서 'Solution Reviewer'로 빠르게 이동하고 있다는 사실이다.

마치며

8개월 차 신입인 나의 생각이 정답은 아닐 수 있다. 시간이 지나면 이 생각 또한 달라질지도 모른다. 하지만 AI로 인해 개발 환경이 빠르게 바뀌는 지금, 한 가지 분명하게 느끼는 점은 있다.

앞으로 개발자의 경쟁력은 단순히 얼마나 많은 코드를 작성했는가가 아니라, AI가 만들어낸 결과를 이해하고 검증하며 올바른 방향으로 이끌 수 있는가에 가까워질 것이라는 점이다.

돌이켜 보면 요즘 내가 회사에서 하고 있는 일들도 조금씩 그 방향으로 이동하고 있었다. AI 에이전트가 초안을 만들고, 우리는 그 결과를 검토하고 맥락을 보완한다. 도구가 코드를 작성하는 속도는 빨라졌지만, 전체 구조와 의도를 판단하는 역할은 여전히 사람에게 남아 있다.

그래서인지 요즘은 이런 생각이 든다. 나는 단순히 AI를 활용하는 개발자가 되기보다, AI와 함께 문제를 구조화하고 결과를 검증하는 개발자가 되어가고 있는 과정에 있는 것 같다는 생각 말이다. 아직 배워야 할 것도 많고 시행착오도 계속될 것이다. 하지만 적어도 지금은, 빠르게 변하는 환경 속에서 조금은 올바른 방향으로 걸어가고 있는 것 같다는 느낌이 든다.