Claude Code 1년, 5년차 개발자가 코드 공부 대신 하는 것

“AI가 개발자를 대체한다”는 기사는 2～3년 전부터 꾸준히 나왔어요.

요즘은 개발자뿐 아니라 디자이너·번역가·마케터까지 비슷한 공포감이 번져 있는 느낌이에요. 주변에서 “앞으로 개발자가 필요할까”라는 질문을 종종 받고, 저도 혼자 이런저런 생각을 많이 해요.

저는 현직 5년차 풀스택 개발자예요. Claude Code를 업무에 본격적으로 쓴 지 1년쯤 됐는데, 실제로 일하는 방식이 꽤 바뀌었어요. 다만 제가 느낀 변화의 핵심은 “대체”가 아니라 공부해야 할 것이 바뀌었다는 쪽이에요.

개발자 생태계는 이미 AI 기본값

2025년 Stack Overflow 개발자 설문(응답자 약 4만 9천 명) 기준, 전문 개발자의 약 51%가 AI 툴을 매일 쓰고 있다고 해요. 69%는 특정 작업 시간이 단축됐다고 응답했고요.

GitHub 공식 연구에서는 Copilot 사용 그룹이 동일 과제를 55% 더 빠르게 완료했다고 나왔어요.

저도 체감상 팀에서 AI를 안 쓰는 사람을 찾기가 어려워졌어요. 이제 문제는 도입이냐 아니냐가 아니라, 어디까지 맡기고 어디서 직접 판단하느냐인 것 같아요.

기획·설계·구현까지 거의 전부 AI에 위임했어요

1년 쓰면서 제가 가장 놀란 건 위임 범위였어요.

처음엔 보일러플레이트 정도만 맡겼어요. 지금은 팀원과 공유할 기획 문서 초안, 설계서 정리, 실제 구현, 테스트, 커밋 메시지, PR 설명까지 거의 전부 AI에 일단 돌려요.

제가 하는 일은 세 가지로 좁혀졌어요. 방향을 정확하게 제시하고, 중간에 결과가 맞게 돌아가는지 검증하고, 마지막에 정리하는 일이에요.

이 세 가지를 1년 동안 반복하니 혼자서 팀 하나 몫에 가까운 작업이 돌아가는 느낌이에요. 엄밀한 수치는 아니고 체감이라 저한테만 해당할 수도 있어요.

흥미로운 건 “코드 짜는 속도가 빨라졌다”는 느낌과는 결이 달라요. 오히려 제 시간이 구현에서 빠져나왔다는 쪽에 가까워요.

구현은 AI가 맡고, 저는 그 위에 얹는 판단·검증·정리에 거의 모든 시간을 쓰고 있어요.

그래서 진짜 중요해진 건 — 판단 기본기

AI에 많이 맡길수록 제가 매일 하는 일은 판단이에요.

가장 구체적인 장면은 이래요. AI한테 설계 문제를 던지면 보통 두세 개의 안을 같이 내줘요.

그 순간 현재 팀 규모, 운영 비용, 트래픽, 유지보수 부담을 종합해서 어떤 안이 맞는지 고르는 게 제 일이에요. 잘못 고르면 몇 달 뒤에 그 선택이 고스란히 돌아오니까요.

이 판단을 하려면 코드 문법이 아니라 다른 종류의 기본기가 필요해요. 시스템 설계, 도메인 이해, 인프라·비용 감각, 장애 시나리오 상상력, 데이터 모델링 같은 것들이요.

1년 쓰면서 저도 모르게 공부 우선순위가 바뀌었어요.

공부 시간 분배가 이렇게 달라졌어요

왼쪽은 AI가 거의 대신해 주는 영역이에요. 새 라이브러리 쓸 때 문서 파헤치는 시간, 커밋 메시지 고민하는 시간은 이제 거의 안 써요.

오른쪽은 AI가 대신 못 해주는 영역이자, 제가 이걸 알고 있어야 AI 결과를 검증할 수 있는 영역이에요.

해본 것과 안 해본 것은 검증이 완전히 달라요

판단 기본기가 왜 중요한지는 검증 단계에서 가장 잘 드러나요.

AI가 코드를 뽑아줬을 때, 제가 비슷한 걸 해본 적이 있으면 결과를 보는 순간 “이 부분은 맞고 저 부분은 위험하다”는 감이 바로 와요.

반대로 한 번도 안 해본 영역이면 코드가 아무리 깔끔해 보여도 어디가 틀렸는지조차 모르고 그냥 통과시키게 돼요.

경험이 AI 시대에 오히려 복리로 커지는 이유가 여기에 있다고 느껴요. 도구가 빠르게 뽑아낼수록, 그 결과를 걸러낼 수 있는 사람과 못 걸러내는 사람의 간격이 더 벌어져요.

개발만 잘하면 되는 공식도 흔들리고 있어요

구현 시간이 빠져나간 자리에 뜻밖에 늘어난 게 있어요.

기획, 사용자 커뮤니케이션, 마케팅에 쓰는 시간이에요.

예전 같으면 주말에 사이드 프로젝트를 하나 시작해도 기획에서 설계, 구현까지 가는 데만 몇 주가 훌쩍 지나갔어요. 지금은 구현 덩어리가 훨씬 가볍게 빠져서, 제가 쥐고 있어야 하는 부분이 오히려 앞뒤로 이동해요.

무엇을 왜 만들고, 누구에게 어떻게 전달할 것인지 쪽이요.

요즘 저는 개발 외에 기획·사용자 인터뷰·간단한 마케팅 채널 공부에도 시간을 쓰고 있어요. 시장에서 개발자에게 기대하는 것도 조금씩 옮겨가는 것 같아요. 코드 잘 짜는 사람에서, 혼자 제품을 만들고 사용자에게 닿게 할 수 있는 사람 쪽으로요.

개발자가 개발만 잘하면 되던 공식이 끝났다고까지는 말 못 하지만, 그 공식이 꽤 흔들리는 건 분명해요. 제 커리어 전략도 그 방향에 맞춰 천천히 조정 중이에요.

그래도 맹신은 절대 금지 — 주니어가 가장 조심해야 할 함정

여기까지 읽으면 “그럼 다 맡기면 되겠네”로 들릴까 봐 꼭 덧붙이고 싶어요.

AI가 뽑아낸 결과가 돌아간다는 것과 맞다는 건 전혀 다른 이야기예요.

저는 1년 쓰면서 AI 결과물이 그럴듯하게 돌아가는데 비즈 맥락상 잘못된 경우를 여러 번 봤어요.

필드 nullable 처리, 트랜잭션 경계, 캐시 무효화 타이밍, 권한 체크 범위처럼 팀 내부 맥락이 있어야만 판단되는 영역에서요. 이걸 잡아내려면 중간에 한 번은 제 머리로 검증해야 해요.

제 결론은 이래요. AI는 생산성을 몇 배로 올려주지만, 그 생산성을 안전하게 쓰려면 검증할 수 있는 경험과 판단 기본기가 반드시 같이 있어야 해요.

기본기 없이 뽑아낸 생산성은 장기적으로 팀에 빚으로 쌓여요.

1년 돌려보고 정착된 제 업무 루틴

1년 동안 정착된 제 루틴이에요. 정답은 아니고, 5년차인 제 맥락에서 가장 잘 맞는 패턴이에요.

반대로, 하지 않으려는 것 하나

AI로 뽑아낸 긴 문서나 결과물을 가공하지 않고 동료에게 그대로 던지는 일이에요.

처음엔 저도 편해서 몇 번 해봤어요. 그런데 반대로 제가 그런 결과물을 받는 입장이 되어 보니 꽤 힘들더라고요. 분량이 과하고 맥락이 정리되지 않은 걸 받으면 판단 자체가 피곤해져요.

내가 받기 싫은 걸 동료한테 건네는 건 아니지 않을까, 그때부터 이 생각을 기준으로 삼았어요.

그 동료가 판단하려고 다시 AI를 돌리면, 중간에서 AI끼리 주고받는 모양이 돼요. 그 과정에 할루시네이션이나 잘못된 방향 제안이 한 번이라도 끼면 오히려 혼란만 키우고, 미스커뮤니케이션도 늘어나요.

그래서 저는 AI 결과를 팀에 전달하기 전에 한 단계를 끼워요. 제가 먼저 읽고 검증한 다음, 핵심만 제 말로 짧게 요약해서 동료의 시간을 줄여주는 쪽으로요.

AI 쓰는 양은 늘었지만, 팀에 꺼내놓는 최종 결과물은 오히려 더 짧고 정돈된 형태가 됐어요.

---

레스덕의 정리

1년 동안 Claude Code를 업무에 섞으면서 제가 얻은 결론은 간단해요.

코드는 AI가 빠르게 잘 짜주는 시대예요. 5년차인 저한테 남는 건 무엇을 만들지 판단하고, 여러 안 중 최선을 고르고, 결과가 진짜 맞는지 검증하는 기본기예요.

공부 우선순위는 설계·도메인·인프라로 옮겼고, 관심 반경은 기획·커뮤니케이션·마케팅까지 넓히는 중이에요. AI가 준 생산성은 반드시 검증할 경험과 한 쌍이라는 걸 잊지 않으려고 해요.