코딩 에이전트가 12분에 완성하는 시대, 무엇을 잘해야 할까
지난달 Claude Code로 FastAPI 서비스를 만들었어요. 12분 걸렸습니다. 데이터베이스 스키마 설계부터 엔드포인트 6개, 인증 미들웨어까지 전부요. 제가 한 건 "사용자 인증 있는 북마크 API 만들어줘"라고 말한 것뿐이었거든요. 완성본 보면서 든 생각은 "편하다"가 아니라 "내가 3주 걸려 배운 FastAPI 지식이 이제 12분짜리네"였어요. 저는 AI 코딩 도구가 저를 더 생산적으로 만들수록 제 커리어가 덜 안전해진다고 느낍니다. 왜냐면 제가 쌓아온 기술의 반감기가 눈에 보이게 짧아지기 때문이에요.
프레임워크 실력은 더 이상 해자가 아닌가요?
작년 9월부터 6개월간 Next.js를 팠어요. 앱 라우터, 서버 컴포넌트, 메타데이터 API까지 공식 문서를 세 번 읽었죠. 그런데 올해 3월 Claude Code한테 "Next.js 앱 라우터로 블로그 만들어줘"라고 했더니 제가 6개월 걸려 익힌 패턴을 20분 만에 다 구현했습니다. 레이아웃 중첩도, generateMetadata 동적 생성도, 서버 액션도 전부 들어있더라고요.
제가 2023년에 Django로 프로젝트 하나 만들 때는 ORM 쿼리 최적화까지 배우는 데 2달 걸렸거든요. 지금은 Claude한테 스키마 설명하면 마이그레이션 파일부터 뷰 함수까지 30분 안에 나와요. 제가 2달 투자한 학습이 30분으로 압축된 셈이죠. 전통적인 "프레임워크 숙달 → 연차 쌓임 → 시니어" 경로가 작동을 멈춘 겁니다.
그럼 지금부터는 무엇을 잘해야 할까?
Reddit 스레드에서 본 질문이 계속 머릿속을 맴돌았어요. "AI가 이렇게 생산적으로 만들어주는데, 우리는 대체 뭘 잘해야 하나?" 저는 5가지 후보를 떠올렸습니다.
니치 전문성은 특정 도메인의 깊은 이해예요. 제가 작년에 의료 SaaS 프로젝트를 했을 때 HIPAA 규정 암호화를 배웠는데, 올해 Claude한테 물으니까 암호화 방식부터 감사 로그까지 다 나왔어요. 니치도 학습 데이터로 들어가면 자동화되더라고요.
오케스트레이션은 여러 AI 도구를 조합해 복잡한 문제를 푸는 능력이에요. 제가 이번 달에 블로그 자동 발행 파이프라인을 만들 때, Claude로 글 쓰고 게이트 15개로 검증하고 Supabase에 저장하는 흐름을 설계했거든요. 각 단계 연결은 AI가 대신 못 해주더라고요.
저수준 감사는 AI가 만든 코드를 디버깅하고 성능 병목을 찾는 능력입니다. 지난주에 Claude가 생성한 SQL 쿼리가 N+1 문제를 일으킨 걸 발견했어요. 쿼리 로그를 보고 JOIN으로 고쳤죠.
전달력은 기술을 비기술 팀원한테 설명하는 능력이에요. 제가 기획자한테 "왜 이 기능은 2주 걸리는데 저건 3일이냐"를 설명할 때, 기술 복잡도를 업무 언어로 번역해야 했거든요.
윤리와 책임은 AI가 만든 결과물의 사회적 영향을 판단하는 능력입니다. 추천 알고리즘이 편향을 강화하는지, 개인정보 수집이 과도한지 같은 거요.
그래도 기술을 깊게 이해해야 하지 않나요?
"AI 시대에도 기본기는 필요하다"는 말, 맞아요. HTTP가 뭔지 모르고 REST API를 만들 순 없으니까요. 근데 "기본기만 있으면 된다"는 착각이 위험해요. 제가 컴퓨터 네트워크 수업 때 TCP 3-way 핸드셰이크를 배웠는데, 실무에서 쓴 적은 한 번도 없거든요. 대신 "왜 이 API는 타임아웃이 30초인데 저건 5초냐"를 설명해야 할 때가 더 많았어요.
코딩 테스트로 알고리즘 짜는 능력을 평가하지만, 실무에선 "이 라이브러리를 우리 상황에 맞게 어떻게 조합할까"를 묻잖아요. 이해보다 조합과 판단이 더 중요해진 거죠.
"AI는 그냥 도구일 뿐"이라는 말도 자주 들어요. 하지만 전기톱이 등장했을 때 도끼 장인이 "도끼질 실력"으로 경쟁했다면 어떻게 됐을까요? 도구가 바뀌면 전문성의 정의도 바뀝니다. 지금 필요한 건 "어떤 문제를 풀 것인지 정의하고, AI가 만든 해법을 검증하고, 그 결과를 팀에 설명하는" 능력이에요.
기술 쌓기보다 문제 정의와 책임이 중요해진다
제가 내린 결론은 이래요. 앞으로는 "무엇을 잘 만드느냐"보다 "무엇을 만들어야 하는지 정의하고, 만든 결과물이 제대로 작동하는지 책임지는" 능력이 해자가 될 겁니다. 기획자가 "사용자가 북마크를 쉽게 관리하게 해줘"라고 하면, 저는 그걸 "인증 API, 태그 필터링, 검색 엔드포인트"로 분해하고요. Claude가 만든 코드가 엣지 케이스에서 터지는지 테스트하고, 성능 병목을 찾아 고치고, 기획자한테 "태그 필터링 로직 때문에 DB 인덱스를 추가해야 해서 하루 더 걸린다"고 설명하는 거죠.
지난 3개월간 제가 한 일을 세어봤어요. 실제로 코드 친 시간은 전체의 30%였어요. 나머지 70%는 요구사항 정리, 아키텍처 결정, AI가 만든 코드 리뷰, 팀원한테 설명하기였습니다. 코드 치는 시간은 AI가 줄여줬지만, 나머지 70%는 여전히 제 몫이더라고요.
다음 주부터 저는 매일 30분씩 두 가지 연습을 하려고 해요. 하나는 비기술 팀원한테 기술 결정을 설명하는 글 쓰기예요. "왜 PostgreSQL을 선택했나" 같은 거요. 다른 하나는 AI가 만든 코드의 숨은 버그를 찾는 훈련이고요. 프레임워크 튜토리얼 보는 시간은 절반으로 줄였습니다.
자주 묻는 질문
Q. 그럼 코딩 공부는 이제 필요 없나요?
A. 기본 문법과 자료구조는 여전히 필요해요. 다만 프레임워크 숙달에 쏟는 시간을 줄이고, 문제 정의와 코드 리뷰에 더 투자하라는 뜻이에요. 제 경우 튜토리얼 따라하기는 주 5시간에서 2시간으로 줄이고, AI가 만든 코드 디버깅 연습을 주 3시간 추가했습니다.
Q. 니치 전문성도 소용없다면 대체 뭘 해야 하나요?
A. 니치가 무용하다는 게 아니라, 니치만으론 부족하다는 거예요. 도메인 지식에 더해 "그 지식을 어떻게 코드로 옮길지 판단하고, 결과를 검증하는" 능력이 필요합니다. 예를 들어 금융 규제를 아는 것보다, 규제 요구사항을 API 스펙으로 번역하고 AI가 만든 구현이 규제를 준수하는지 감사하는 능력이 더 중요해요.
Q. 오케스트레이션 능력은 어떻게 키우나요?
A. 작은 자동화부터 시작하세요. 저는 블로그 글 하나를 발행하는 과정을 5단계로 쪼개고, 각 단계에 다른 AI 도구를 붙여봤어요. Claude로 초안 쓰고, 게이트 스크립트로 검증하고, Supabase 함수로 저장하는 식이죠. 단계별 입출력을 명확히 정의하는 연습이 핵심입니다.