AI와 함께 코드를 쓴다는 것 — 15개 프로젝트를 지나며 배운 것들
저는 요즘 코드를 “짠다”기보다 “대화한다”는 표현이 더 맞는 것 같습니다.
Claude Code 앞에 앉아서 “이 시스템의 아키텍처를 이렇게 잡아볼까?”라고 말하고, 돌아오는 답변을 보면서 “아, 여기는 이렇게 하면 안 되겠다” 하고 다시 방향을 잡고. 그러다 보면 어느새 수만 줄의 코드가 만들어져 있습니다. 지난 몇 달간 이런 방식으로 15개가 넘는 프로젝트를 만들었습니다. 암호화폐 거래소, AI 부동산 분석 플랫폼, 12개짜리 마이크로서비스, 커피머신 키오스크까지. 직접 해보면서 느낀 것들을 솔직하게 나눠보려고 합니다.
개발자는 앞으로 어떻게 바뀌어야 할까
솔직히 말하면, 저도 처음에는 반신반의했습니다. “AI가 코드를 짜준다고? 그래봐야 간단한 스크립트 수준이겠지.” 그런데 직접 써보니까 생각이 완전히 바뀌었습니다.
KoCoin 거래소 를 만들 때였습니다. Spring Boot로 17개 마이크로서비스 — 매칭 엔진, 선물 거래, 지갑, 마켓메이킹 봇까지. 혼자서 이걸 설계하고 구현하려면 몇 달은 걸릴 작업이었는데, Claude Code와 함께하니까 아키텍처 논의부터 Terraform 인프라 코드까지 흐름이 끊기지 않았습니다. 물론 AI가 뱉어낸 코드를 그대로 쓴 건 아닙니다. 중요한 건 내가 방향을 잡고, AI가 속도를 내주는 그 조합이었습니다.
이 경험을 통해 확신하게 된 게 있습니다. 앞으로 개발자에게 필요한 건 “모든 코드를 외우고 있는 능력”이 아니라 “무엇을 만들어야 하는지 정확히 아는 능력” 이라는 거요. 구체적으로 말하면 이렇습니다.
설계 능력이 코딩 능력보다 중요해집니다. Zelotek 프로젝트에서 레거시 PHP 시스템을 12개 MSA로 전환할 때, 진짜 어려웠던 건 코드를 치는 게 아니었습니다. “어떤 서비스를 어떻게 나눌까”, “서비스 간 통신은 동기로 할까 비동기로 할까”, “분산 트랜잭션은 Saga를 쓸까 2PC를 쓸까” — 이런 아키텍처 결정이 훨씬 중요했습니다. AI는 Strangler Pattern으로 점진적 마이그레이션하자는 제안을 해줬고, 저는 그 제안의 타당성을 판단하고 우리 상황에 맞게 조정했습니다. 이게 앞으로 개발자의 역할이라고 생각합니다.
“질문하는 능력”이 새로운 핵심 역량이 됩니다. AI에게 “로그인 기능 만들어줘”라고 하면 평범한 코드가 나옵니다. 하지만 “JWT 기반 인증인데, 리프레시 토큰은 Redis에 저장하고, Rate Limiting은 IP당 10회/15분으로 걸어야 해. XSS랑 NoSQL Injection 방어도 넣어줘”라고 하면 완전히 다른 수준의 결과가 나옵니다. Hunik 홈페이지를 만들면서 보안 점수 98/100을 달성할 수 있었던 건, 제가 “뭘 물어봐야 하는지”를 알고 있었기 때문입니다.
풀스택이 진짜 가능해집니다. 예전에는 “풀스택 개발자”라고 하면 좀 애매한 느낌이 있었잖아요. 백엔드를 깊이 하면 프론트가 약하고, 프론트를 잘하면 인프라는 모르고. 그런데 AI와 함께하면 자기 전문 영역 외의 부분에서도 프로덕션 수준의 코드를 만들 수 있습니다. 저는 DDangZip 프로젝트에서 Spring Cloud Gateway, Eureka, Resilience4j로 MSA 인프라를 만들면서 동시에 Flutter로 모바일 앱까지 개발했습니다. 이전이었다면 최소 2~3명이 필요했을 작업입니다.
프로젝트를 하면서 느낀 것들
“AI가 대신 해주는 게 아니라, 나를 확장시켜주는 것”
가장 크게 느낀 건 이겁니다. AI는 저를 대체하지 않았습니다. 대신 제가 할 수 있는 것의 범위를 넓혀줬습니다.
BUJA 부동산 분석 플랫폼을 만들 때, OpenAI GPT-4o-mini와 Google Gemini를 동시에 돌리는 듀얼 AI 분석 시스템을 설계했습니다. 정부 실거래가 데이터를 끌어와서 선형 회귀로 가격을 예측하고, 카카오맵으로 주변 인프라를 분석하고, 네이버 뉴스에서 부동산 정책을 모니터링하고. 이 모든 걸 Node.js 백엔드, Flutter 앱, React 어드민으로 만들었는데 — 솔직히 저 혼자의 지식만으로는 이 모든 기술을 한 프로젝트에 녹여내기 어려웠을 겁니다.
하지만 그렇다고 제가 아무것도 안 한 건 아닙니다. “부동산 투자 분석에 뭐가 필요한지”, “AI 두 개를 동시에 돌리면 어떤 비교 가치가 생기는지” — 이런 비즈니스 판단은 AI가 해줄 수 없는 영역이었습니다.
“실패에서 배우는 속도가 완전히 달라졌다”
ERP 시스템을 만들면서 경험한 건데, GPT-4 기반 AI 고객 지원 모듈을 처음 설계할 때 구조를 잘못 잡았습니다. 티켓 시스템, 계약 관리, 생산 관리, 설치 관리 — 9개 모듈이 서로 얽혀있는데 의존 관계를 제대로 정리하지 못했거든요. 예전 같았으면 리팩토링에만 며칠을 써야 했을 겁니다. 그런데 AI와 함께하니까 “이 구조의 문제점이 뭔지”, “어떻게 풀어야 하는지”를 빠르게 논의하고, 몇 시간 만에 WebSocket 기반 실시간 알림까지 포함한 새 구조로 전환할 수 있었습니다.
실패 자체가 줄어든 건 아닙니다. 하지만 실패에서 회복하는 속도가 압도적으로 빨라졌습니다.
“하드웨어와 소프트웨어의 경계에서도 AI는 유효했다”
커피머신 키오스크 소프트웨어(M300)와 프로토콜 테스터(TestHunik)를 만들면서 의외의 발견을 했습니다. RS-232 시리얼 통신, HEX/ASCII 패킷 파싱, 0.5초 간격의 폴링 — 이런 로우레벨 하드웨어 연동 작업에서도 AI가 꽤 유용하다는 거였습니다. 물론 실제 기기에 연결해서 테스트하는 건 제가 직접 해야 했지만, 프로토콜 파서를 짜거나 우선순위 기반 명령 큐를 설계하는 과정에서는 AI의 도움이 컸습니다.
“Auto-Claude를 만들면서 한 단계 더 갔다”
가장 재미있었던 프로젝트는 Auto-Claude입니다. AI 에이전트가 소프트웨어를 자율적으로 계획하고, 구현하고, 검증하는 프레임워크를 만든 거예요. 12개 터미널에서 에이전트가 병렬로 코드를 짜고, 각각 격리된 Git Worktree에서 작업하고, QA 루프가 자동으로 돌아가면서 품질을 잡고. 이걸 만들면서 “AI를 쓰는 것”에서 “AI를 만드는 것”으로 한 단계 넘어간 느낌이었습니다.
앞으로 어떻게 개발할 것인가
이 모든 경험을 통해 제가 내린 결론은 하나입니다.
AI와의 협업은 선택이 아니라 기본기가 된다.
마치 Git이 그랬던 것처럼요. 10년 전에는 “Git을 쓸 줄 아는 것”이 스킬이었는데, 지금은 그냥 당연한 거잖아요. AI 협업도 마찬가지가 될 겁니다. 3년 후에는 “AI와 함께 개발한다”는 게 특별한 능력이 아니라, 모든 개발자의 기본 워크플로우가 될 거라고 봅니다.
그래서 제가 앞으로 집중하려는 방향은 이렇습니다.
1. AI 에이전트 시스템을 더 깊이 파겠습니다. Auto-Claude를 만들면서 맛을 봤는데, 멀티 에이전트가 협업하는 구조에는 아직 풀어야 할 문제가 산더미입니다. 에이전트 간 컨텍스트 공유, 충돌 해결, 품질 보증 — 이 영역이 앞으로 소프트웨어 개발의 게임 체인저가 될 거라고 확신합니다.
2. 아키텍처 역량을 계속 넓히겠습니다. KoCoin에서 Kafka와 17개 마이크로서비스를, Zelotek에서 Saga Pattern과 이벤트 기반 아키텍처를 경험하면서, 분산 시스템의 깊이를 느꼈습니다. AI가 코드를 더 잘 짜주게 될수록, “어떤 구조로 만들 것인가”를 결정하는 아키텍트의 가치는 더 올라갈 겁니다.
3. 비즈니스와 기술의 연결고리가 되겠습니다. BUJA에서 부동산 투자 분석을, ERP에서 커피머신 사업의 운영 시스템을 만들면서 깨달은 건, 결국 좋은 소프트웨어는 비즈니스 문제를 정확히 이해하는 데서 출발한다는 겁니다. AI가 아무리 좋아져도, “뭘 만들어야 하는지”를 아는 사람은 여전히 필요합니다. 그리고 그게 제가 되고 싶은 개발자의 모습입니다.
빈 폴더에서 시작해서 80만 줄이 넘는 코드를 AI와 함께 만들었습니다. 암호화폐 거래소의 매칭 엔진부터 커피머신의 시리얼 통신까지. 이 여정에서 가장 크게 배운 건, AI 시대의 개발자에게 가장 중요한 건 “코드를 잘 치는 것”이 아니라 “무엇을 왜 만들어야 하는지 아는 것” 이라는 사실입니다.
항상 자신에게 질문하는 개발자로 함께 나아가요.