지난달에 Claude한테 관리자 대시보드 CRUD를 시켰다. 테이블 컴포넌트, 필터링, 페이지네이션, 생성/수정 모달까지. 10분 걸렸다. 타입도 깔끔했고, 에러 핸들링도 나름 잡혀 있었다. 나 혼자 했으면 3시간은 잡았을 작업이다.

그날 퇴근길에 좀 이상한 기분이 들었다. 위기감이라고 하기엔 너무 구체적이었다. "이거 내 일자리가 줄어드는 거 아닌가?"가 아니라 "내가 이번 주에 한 일 중에 AI가 못 할 게 뭐가 있지?" 하는 생각이었다. 머릿속으로 이번 주 업무를 쭉 돌아봤다. API 연동, 폼 유효성 검사, Storybook 컴포넌트 작성, 버그 수정 두 건. 솔직히 반 이상은 AI가 할 수 있는 일이었다.

AI가 이미 대체하고 있는 것들#

과장이 아니다. 지금 시점에서 AI가 나보다 빠르게 하는 작업 목록은 꽤 길다.

CRUD 보일러플레이트는 말할 것도 없고, REST API 엔드포인트 만들기, 간단한 유틸 함수 작성, 타입 정의, 테스트 코드 생성, 정규식 작성 — 이런 건 프롬프트 한두 번이면 끝난다. 우리 팀에서도 요즘 새 API 연동할 때 "일단 Claude한테 인터페이스 먼저 뽑아" 하고 시작한다. 6개월 전만 해도 없던 워크플로우다.

문서화도 그렇다. JSDoc 주석, README 업데이트, PR description 작성 같은 건 AI가 훨씬 성실하게 한다. 나는 PR description에 "상품 목록 필터 추가"라고만 쓰고 넘어가지만, AI한테 시키면 변경 사항, 영향 범위, 테스트 방법까지 정리해준다. 부끄럽지만 사실이다.

디버깅도 단순한 건 AI가 잡는다. 에러 메시지 복붙하면 원인과 수정 방안을 바로 알려준다. 타입 에러, null 참조, 비동기 순서 문제 같은 패턴화된 버그는 AI가 나보다 빠르게 진단한다.

그런데 이상한 일이 있었다#

2주 전에 우리 서비스의 검색 기능을 개선하는 프로젝트가 있었다. PM이 "검색 결과가 별로라는 피드백이 많아요"라고 슬랙에 올렸다. 나는 Claude한테 이 상황을 설명하고 개선안을 물어봤다. Elasticsearch 쿼리 튜닝, 형태소 분석기 변경, 자동완성 개선 — 기술적으로 그럴듯한 답변이 쭉 나왔다.

근데 그게 아니었다.

실제로 유저 세션 리플레이를 한 시간 동안 돌려보니까, 문제는 검색 알고리즘이 아니었다. 유저들이 검색어를 잘못 입력하는 게 아니라 카테고리 필터를 못 찾고 있었다. 필터 UI가 스크롤 아래에 숨겨져 있어서 대부분의 유저가 존재 자체를 모르고 있었다. 필터 위치를 검색바 바로 아래로 옮기고 기본 3개를 펼쳐두는 것만으로 검색 관련 불만 CS가 40% 줄었다.

AI는 "검색이 별로다"라는 입력을 받으면 검색 알고리즘을 개선하려 든다. 당연하다. 그게 기술적으로 맞는 접근이니까. 하지만 실제 문제가 뭔지 파악하는 건 코드 밖에서 일어나는 일이었다. 유저를 관찰하고, 데이터를 보고, "어 이거 검색 문제가 아니라 UI 문제 아니야?" 하고 방향을 트는 건 사람이 해야 했다.

"뭘 만들어야 하는지" 판단하는 능력#

여기서 내가 요즘 제일 많이 생각하는 주제가 나온다. AI 시대에 개발자의 핵심 역량이 뭐냐고 물으면 나는 문제 정의 능력이라고 답한다.

코드를 짜는 건 "How"다. 뭘 만들어야 하는지 결정하는 건 "What"이고, 왜 만들어야 하는지 이해하는 건 "Why"다. AI는 How를 점점 잘하게 된다. 하지만 What과 Why는 비즈니스 맥락, 유저 이해, 팀 상황에 대한 암묵지가 필요하다.

우리 팀에 있었던 일이다. 신규 기능 기획이 내려왔는데 "판매자 정산 내역 다운로드 기능 추가" 같은 거였다. 스펙대로만 보면 CSV 다운로드 버튼 하나 넣으면 끝이다. AI한테 시키면 30분이면 나온다.

그런데 실제로 판매자 인터뷰를 들어보니까, 사람들이 원하는 건 다운로드가 아니었다. 매달 세무사한테 보내야 하는 정산 리포트를 만드는 데 2시간이 걸린다는 게 진짜 불만이었다. 그래서 우리가 만든 건 다운로드 버튼이 아니라 세무사에게 바로 메일로 보낼 수 있는 월간 리포트 자동 생성 기능이었다. 이 판단은 AI가 대신 해줄 수 없는 영역이다.

도메인 지식이라는 해자#

요즘 "AI를 잘 쓰는 개발자가 살아남는다"는 말이 많다. 맞는 말이다. 근데 절반만 맞다.

내가 쓰는 프롬프트가 정확한 이유는 내가 프롬프트 엔지니어링을 잘해서가 아니다. 우리 서비스의 도메인을 알고 있기 때문이다. "장바구니에서 쿠폰 적용할 때 중복 할인 방지 로직 짜줘"라고 시킬 수 있는 건, 중복 할인이라는 비즈니스 규칙이 있다는 걸 내가 알고 있어서다. AI는 내가 모르는 걸 대신 파악해주지 않는다. 내가 아는 걸 더 빠르게 구현해줄 뿐이다.

커머스 도메인에서 몇 년을 일하면 쌓이는 게 있다. 정산 주기가 왜 이렇게 복잡한지, 재고 관리에서 왜 "예약 재고"라는 개념이 필요한지, 쿠폰 시스템의 우선순위 규칙이 왜 매번 edge case를 만드는지. 이런 건 코드에 안 적혀 있다. Confluence 문서에도 반쯤만 있다. 사람의 머릿속에 있다.

그리고 이게 바로 AI에 대한 해자(moat)가 된다.

코드 리뷰에서 느끼는 차이#

AI가 코드를 짜는 건 잘하는데, 코드를 "판단"하는 건 아직 어설프다.

며칠 전에 주니어 동료가 올린 PR을 리뷰했다. AI로 생성한 코드라고 솔직하게 말해줬다. 코드 자체는 깔끔했다. 타입도 잘 잡혀 있고, 에러 핸들링도 되어 있었다. 근데 문제는 다른 데 있었다. 이 컴포넌트가 기존의 공통 컴포넌트 ProductCard와 80% 중복이었다. AI는 전체 코드베이스의 맥락을 모르니까 새로 만든 것이다. 우리 팀의 컨벤션에서는 ProductCard를 확장하는 게 맞았다.

이런 판단은 그 팀에서 일해본 사람만 할 수 있다. 기술적으로 틀린 건 아니지만, 팀의 맥락에서 보면 잘못된 결정인 것들. AI가 아무리 발전해도 "우리 팀에서는 이런 경우에 이렇게 한다"를 완벽하게 이해하기는 어렵다. 적어도 당분간은.

주니어 개발자에게 미치는 영향 — 이건 좀 복잡하다#

내가 진짜 걱정되는 건 이거다. 주니어 개발자의 성장 경로가 바뀌고 있다.

예전에는 입사하면 간단한 CRUD부터 시작했다. API 연동하고, 폼 만들고, 테이블 렌더링하고. 이 과정에서 HTTP가 뭔지, 상태 관리가 왜 필요한지, 비동기가 왜 어려운지를 체감했다. 반복적인 코딩을 통해 기본기가 몸에 배는 시간이었다.

근데 지금은? 그 "반복적인 코딩"을 AI가 다 해준다. 주니어한테 CRUD 맡기면 AI로 30분 만에 끝내고 올린다. 결과물은 그럴듯하다. 문제는 그 과정에서 배웠어야 할 것들을 건너뛰게 된다는 거다. useEffect의 cleanup이 왜 필요한지, race condition이 실제로 어떻게 발생하는지, 이런 걸 직접 삽질하면서 배울 기회가 줄어든다.

하지만 동시에 역설적인 면도 있다.

우리 팀에 올해 들어온 신입 한 명이 있는데, AI를 정말 잘 활용한다. 모르는 개념이 나오면 AI한테 "이 코드가 왜 이렇게 동작하는지 중학생한테 설명하듯 알려줘"라고 묻는다. 예전 같았으면 Stack Overflow 답변 10개 뒤져보고도 이해 못 했을 개념을 30분 만에 소화한다. 학습 속도가 확실히 빠르다.

그러니까 상황이 묘하다. 삽질할 기회는 줄었는데, 삽질의 결과를 이해하는 속도는 빨라졌다. 이 두 가지가 상쇄되는 건지, 아니면 한쪽이 더 큰 건지, 나도 아직 잘 모르겠다.

"AI를 잘 쓰는 개발자" vs "AI 없이도 잘하는 개발자"#

요즘 업계에서 이 구분을 많이 한다. AI 도구를 능숙하게 써서 생산성을 극대화하는 사람 vs 기본기가 탄탄해서 AI 없이도 문제를 풀 수 있는 사람.

내 생각에는 둘 다 필요하고, 이상적으로는 한 사람이 둘 다여야 한다.

AI를 잘 쓰기만 하고 기본기가 없으면 위험하다. AI가 틀린 코드를 줬을 때 그걸 알아차릴 수 없다. 지난주에도 GPT가 생성한 코드에 미묘한 메모리 릭이 있었는데, useEffect 안에서 setInterval을 걸어놓고 cleanup을 안 한 거였다. 기본기가 있으면 3초 만에 보이는 문제지만, 없으면 프로덕션에 그대로 올라간다.

반대로, AI를 안 쓰고 모든 걸 직접 하겠다는 것도 현실적이지 않다. 옆 팀 개발자가 AI로 하루에 끝내는 걸 나는 3일 걸린다면, 그건 장인 정신이 아니라 비효율이다. 특히 스타트업에서는 속도가 곧 생존이다.

결국 AI 시대의 이상적인 개발자는 "AI가 짠 코드를 정확하게 판단할 수 있는 실력을 가진 상태에서, AI를 적극적으로 활용하는 사람"이 아닐까.

그래서 구체적으로 뭘 해야 하나#

나 자신한테도 묻는 질문이다. 막연하게 "AI 시대에 대비하자"가 아니라 구체적으로 뭘 하면 되는 건지.

시스템 설계 능력을 키워야 한다. 컴포넌트 하나 만드는 건 AI가 하지만, 서비스 전체의 아키텍처를 잡는 건 사람이 한다. 마이크로 프론트엔드를 도입할지, 모노레포로 갈지, 상태 관리를 어디서 할지 — 이런 큰 그림은 비즈니스 요구사항과 팀 상황을 종합적으로 이해해야 가능하다. 요즘 나는 새 프로젝트가 시작되면 코드를 짜기 전에 설계 문서를 먼저 쓴다. 이 습관이 AI 시대에 오히려 더 중요해진 것 같다.

비즈니스를 이해해야 한다. 개발자가 비즈니스를 모르면 AI한테 시킬 줄도 모른다. "매출을 올려야 한다"가 아니라 "이번 분기 목표인 구매 전환율 2% 개선을 위해 체크아웃 단계를 5단계에서 3단계로 줄이자"라고 말할 수 있어야 한다. 프롬프트의 품질은 기술 지식이 아니라 비즈니스 이해에서 나온다.

글쓰기와 커뮤니케이션. 이건 좀 뜬금없어 보일 수 있는데, 진심이다. AI 시대에 개발자의 커뮤니케이션 능력이 더 중요해진다. 왜냐면 코드를 짜는 시간이 줄어든 만큼, 무엇을 만들지 논의하고, 왜 이렇게 만들었는지 설명하고, 어디가 불확실한지 공유하는 시간이 늘어나기 때문이다. 요즘 내 업무 시간의 60%는 코드 에디터 밖에서 보낸다. Slack, Notion, 미팅. 이 비율은 앞으로 더 늘어날 것 같다.

불편한 진실 하나#

이렇게 써놓고도 나도 확신은 없다.

5년 뒤에 AI가 시스템 설계도 하고, 도메인 이해도 하고, 유저 인터뷰 분석까지 하는 세상이 올 수도 있다. 그때 가면 지금 내가 "이건 사람만 할 수 있다"고 말한 것들이 틀렸을 수도 있다. 2년 전에 "AI가 이렇게 깔끔한 코드를 짤 리 없다"고 말했던 사람들이 있었고, 그 사람들은 틀렸다.

내가 할 수 있는 건 지금 시점에서 합리적이라고 판단되는 방향으로 움직이는 것 뿐이다. 코드를 짜는 기술만이 아니라 문제를 정의하고, 사람과 소통하고, 비즈니스를 이해하는 능력을 키우는 것. 이게 맞는 방향인지는 모르겠다. 근데 적어도 이런 능력은 AI가 대체하든 안 하든 쓸모가 있다는 건 확실하다.

한 가지 분명한 건, "코드만 잘 짜면 된다"는 시대는 이미 끝나고 있다는 거다. 그게 나한테 불안한 건지 기회인 건지는 매일 아침 기분에 따라 다르다. 아마 이 글을 읽는 당신도 비슷하지 않을까.