AI가 코드를 짜면 개발자는 뭘 하나

코드를 안 짜는 개발자가 등장했다

2026년 1월, 한 개발자가 X에 글을 올렸다. "지난 한 달간 259개의 PR을 올렸고, 4만 줄의 코드를 추가했다." 놀라운 건 그다음이었다. "직접 코드를 친 건 거의 없다. Claude Code가 다 짰다."

더 이상 농담이 아니다. GitHub Copilot이 코드를 제안하고, Claude Code가 파일을 생성하고, Cursor가 전체 함수를 완성한다. 개발자가 키보드를 두드리는 시간은 줄어들고 있다. AI가 코드를 대신 짜는 세상이 실제로 왔다.

그러면 개발자는 뭘 하나. 코드 짜는 게 개발자의 핵심 역할 아니었나. AI가 그걸 대신하면 개발자는 필요 없어지는 걸까.

결론부터 말하면, 아니다. 개발자는 사라지지 않는다. 역할이 바뀔 뿐이다. 코드를 치는 사람에서 코드를 검증하고 설계하는 사람으로. 실행자에서 감독자로. 프로그래머에서 아키텍트로.

코딩은 개발의 일부였을 뿐이다

개발자의 일을 분해해보자. 코드를 짜는 건 그중 일부다.

요구사항 분석. 무엇을 만들어야 하는지 파악한다. 사용자가 원하는 게 뭔지, 비즈니스 목표가 뭔지, 기술적으로 가능한지 판단한다. 이건 대화와 맥락 이해가 필요한 일이다.

설계. 어떻게 만들지 결정한다. 어떤 아키텍처를 쓸지, 어떤 패턴을 적용할지, 모듈을 어떻게 나눌지. 코드를 한 줄도 안 쓰고도 몇 시간을 쓸 수 있는 단계다.

구현. 실제로 코드를 짠다. 키보드를 두드리고, 함수를 만들고, 로직을 작성한다. 전통적으로 개발자의 시간 대부분이 여기에 들어갔다.

테스트. 코드가 제대로 작동하는지 확인한다. 버그를 찾고, 엣지 케이스를 점검하고, 성능을 측정한다.

리뷰. 다른 사람이 짠 코드를 검토한다. 로직이 맞는지, 버그가 없는지, 더 나은 방법은 없는지 확인한다.

배포와 운영. 코드를 프로덕션에 올리고 유지한다. 장애가 나면 대응하고, 모니터링하고, 최적화한다.

커뮤니케이션. 팀원과 소통한다. PM과 일정을 조율하고, 디자이너와 협업하고, 기획자에게 기술적 제약을 설명한다.

이 중에서 AI가 잘하는 건 구현이다. 코드 작성, 함수 생성, 패턴 적용. 이 영역에서 AI는 이미 인간을 따라잡았거나 능가했다. 반복적인 코드, 보일러플레이트, 표준 패턴 적용은 AI가 더 빠르고 정확하다.

하지만 나머지 영역은 다르다. 요구사항을 이해하고, 설계를 결정하고, 코드를 검증하고, 팀과 소통하는 일. 이건 AI가 대체하기 어렵다. 적어도 아직은.

코드 리뷰어로서의 개발자

AI가 코드를 짜면, 누군가는 그 코드를 검토해야 한다. AI는 실수한다. 환각(hallucination)도 하고, 맥락을 놓치기도 하고, 보안 취약점을 만들기도 한다. AI가 생성한 코드를 그대로 프로덕션에 올리는 건 위험하다.

여기서 개발자의 역할이 바뀐다. 코드를 짜는 사람에서 코드를 검토하는 사람으로.

코드 리뷰는 단순히 "이 코드 맞아?"를 확인하는 게 아니다. 여러 층위가 있다.

정확성 검증. 코드가 요구사항을 제대로 구현했는지 확인한다. AI가 의도를 잘못 이해했을 수 있다. "사용자 이메일을 검증해줘"라고 했는데 형식만 체크하고 실제 존재 여부는 확인 안 할 수 있다.

버그 탐지. AI가 만든 코드에도 버그가 있다. off-by-one 에러, null 체크 누락, 경쟁 조건, 예외 처리 부재. 사람이 직접 짠 코드에 있는 버그와 똑같은 종류의 버그가 AI 코드에도 있다.

보안 점검. AI는 보안에 취약한 코드를 만들 수 있다. SQL 인젝션 가능한 쿼리, XSS 취약점, 하드코딩된 시크릿. AI가 학습한 데이터에 나쁜 패턴이 포함되어 있으면 그대로 재현한다.

성능 검토. AI 코드가 동작은 하지만 비효율적일 수 있다. 불필요한 루프, 중복 쿼리, 메모리 누수. 코드가 돌아가는 것과 잘 돌아가는 것은 다르다.

일관성 확인. 코드베이스의 기존 스타일과 맞는지 확인한다. AI는 일반적인 패턴을 따르지만, 특정 프로젝트의 컨벤션은 모를 수 있다. 다른 파일에서는 snake_case를 쓰는데 AI가 camelCase로 짰을 수 있다.

아키텍처 적합성. 새 코드가 전체 아키텍처에 맞는지 확인한다. AI는 당장의 문제를 해결하지만, 장기적인 구조를 고려하지 않을 수 있다. 단기 해결책이 기술 부채가 되는 경우가 많다.

코드 리뷰어로서의 개발자는 품질 게이트키퍼다. AI가 생산하는 코드의 양이 늘어날수록, 이 역할의 중요성도 커진다. AI가 하루에 천 줄을 생성해도, 사람이 그걸 제대로 검토하지 않으면 프로덕션 코드 품질은 떨어진다.

아키텍트로서의 개발자

AI에게 "인증 시스템을 만들어줘"라고 하면, 코드를 생성한다. 하지만 그 전에 결정해야 할 게 있다. JWT를 쓸지 세션을 쓸지. 토큰 만료 시간은 얼마로 할지. 리프레시 토큰은 어디에 저장할지. OAuth를 지원할지. 2FA를 넣을지.

이런 결정은 AI가 대신해주지 않는다. AI는 "JWT로 인증 시스템 만들어줘"라고 하면 JWT 코드를 짜고, "세션으로 만들어줘"라고 하면 세션 코드를 짠다. 뭘 만들지 결정하는 건 사람이다.

아키텍트의 역할은 크게 세 가지다.

기술 선택. 어떤 기술 스택을 쓸지 결정한다. 프레임워크, 라이브러리, 데이터베이스, 인프라. 각 선택에는 트레이드오프가 있다. PostgreSQL이냐 MongoDB냐, REST냐 GraphQL이냐, 모놀리스냐 마이크로서비스냐. 이건 비즈니스 요구사항, 팀 역량, 유지보수 비용, 확장성을 종합적으로 고려해야 한다.

구조 설계. 시스템을 어떻게 나눌지 결정한다. 어떤 모듈로 분리할지, 모듈 간 인터페이스는 어떻게 할지, 데이터 흐름은 어떻게 설계할지. 좋은 구조는 변경에 유연하고, 테스트하기 쉽고, 이해하기 쉽다. 나쁜 구조는 기술 부채를 쌓고, 유지보수를 어렵게 만든다.

트레이드오프 판단. 모든 결정에는 장단점이 있다. 성능과 가독성, 유연성과 단순성, 개발 속도와 코드 품질. 어떤 걸 더 중요시할지는 상황에 따라 다르다. 스타트업에서는 빠른 개발이 중요하고, 금융 시스템에서는 안정성이 중요하다. 이 판단은 비즈니스 맥락을 이해하는 사람만 할 수 있다.

AI에게 "이 시스템의 아키텍처를 설계해줘"라고 할 수 있다. AI는 일반적인 패턴을 제안할 것이다. 하지만 그게 이 프로젝트, 이 팀, 이 비즈니스에 맞는지는 알 수 없다. 특수한 규제 요구사항이 있을 수 있고, 레거시 시스템과 통합해야 할 수 있고, 팀에 특정 기술의 전문가가 있을 수 있다.

아키텍처 결정은 맥락 의존적이다. 같은 요구사항이라도 상황에 따라 최선의 해결책이 다르다. 이 맥락을 이해하고 판단하는 건 여전히 사람의 몫이다.

AI와 협업하는 새로운 스킬

AI 시대의 개발자에게는 새로운 스킬이 필요하다.

AI 출력 평가 능력. AI가 생성한 코드를 빠르게 평가하는 능력이다. 코드를 읽고, 의도를 파악하고, 문제점을 찾아내는 능력. 직접 코드를 짜는 것보다 남이 짠 코드를 읽는 게 더 어렵다는 말이 있다. AI 코드도 마찬가지다. 생성은 AI가 하지만, 평가는 사람이 해야 한다.

효과적인 지시 능력. AI에게 원하는 결과를 얻어내는 능력이다. 프롬프트 엔지니어링이라고도 한다. 하지만 단순히 프롬프트를 잘 쓰는 것 이상이다. 작업을 어떻게 분해할지, 어떤 컨텍스트를 제공할지, 어떤 제약조건을 명시할지 결정해야 한다.

시스템 사고. 전체 시스템을 조망하는 능력이다. AI는 부분을 잘 만들지만, 부분들이 어떻게 연결되는지는 신경 쓰지 않는다. 사람이 전체 그림을 그리고, AI가 각 조각을 채우는 방식이다.

빠른 학습 능력. AI 도구는 빠르게 발전한다. 작년에 쓰던 방식이 올해는 구식이 될 수 있다. 새로운 도구, 새로운 패턴, 새로운 가능성을 빠르게 파악하고 적용하는 능력이 중요하다.

비판적 사고. AI 출력을 맹목적으로 신뢰하지 않는 자세다. AI가 틀릴 수 있다는 걸 항상 인식한다. "AI가 이렇게 했으니 맞겠지"가 아니라 "AI가 이렇게 했는데 진짜 맞나?" 하고 의심한다.

역할 변화의 실제 모습

실제로 AI와 함께 일하는 개발자의 하루는 어떻게 달라질까.

아침. 이메일과 슬랙을 확인한다. PM이 새 기능 요청을 보냈다. "사용자 프로필에 소셜 로그인 추가". 요구사항을 읽고 질문할 게 있으면 정리한다. 어떤 소셜 서비스를 지원할지, 기존 계정과 연동은 어떻게 할지.

오전. PM과 간단히 논의한 뒤 설계를 시작한다. 화이트보드에 인증 흐름을 그린다. OAuth 콜백 처리, 토큰 저장 위치, 기존 인증 시스템과의 통합 방식. 대략적인 구조가 잡히면 Claude Code에 지시한다. "Google OAuth 로그인 기능을 구현해줘. 여기 설계 문서가 있어."

점심 전. AI가 코드를 생성하는 동안 다른 일을 한다. 어제 올라온 PR을 리뷰한다. 주니어 개발자가 AI로 만든 코드다. 로직은 맞는데 에러 핸들링이 빠졌다. 코멘트를 단다. "이 부분에서 네트워크 에러가 나면 어떻게 되지?"

오후. Claude Code가 만든 OAuth 코드를 검토한다. 대부분 괜찮은데, 토큰 저장 방식이 마음에 안 든다. 로컬 스토리지에 저장하게 해놨는데, 보안상 httpOnly 쿠키가 낫다. 수정을 지시한다. "토큰을 로컬 스토리지 대신 httpOnly 쿠키에 저장하게 바꿔줘."

저녁. 수정된 코드를 다시 검토하고, 테스트를 돌린다. 통과. PR을 올린다. 설명을 쓴다. "Google OAuth 로그인 추가. 토큰은 httpOnly 쿠키에 저장. 기존 이메일/패스워드 로그인과 병행 사용 가능."

이 하루에서 직접 코드를 친 시간은 얼마나 될까. 거의 없다. 대부분의 시간은 설계, 검토, 커뮤니케이션에 썼다. 코드 생성은 AI가 했다. 하지만 "개발"은 사람이 했다.

AI가 대체 못 하는 것들

AI가 코드를 잘 짜게 됐다고 해서, 개발의 모든 영역에서 사람을 대체할 수 있는 건 아니다. 몇 가지는 여전히 사람의 영역이다.

책임. AI가 버그를 만들면 누가 책임지나. AI가 보안 취약점을 넣으면 누가 책임지나. 법적으로, 사회적으로, 책임은 사람에게 있다. 코드를 생성한 AI가 아니라, 그 코드를 승인하고 배포한 사람이 책임진다. 이 책임을 지는 역할은 사라지지 않는다.

창의성. AI는 학습한 패턴을 조합한다. 완전히 새로운 것을 만들어내는 건 아직 어렵다. 기존에 없던 아키텍처, 새로운 문제 해결 방식, 혁신적인 접근법. 이런 건 여전히 사람에게서 나온다. AI는 "이렇게 해봐"라고 말해줘야 그렇게 한다.

판단. 여러 선택지 중에서 하나를 고르는 건 판단이다. A안과 B안 중 뭐가 나은지, 이 기능을 지금 넣을지 나중에 넣을지, 리팩토링을 할지 말지. 이 판단에는 비즈니스 맥락, 기술적 맥락, 팀 맥락이 복합적으로 작용한다. AI는 정보를 제공할 수 있지만, 최종 판단은 사람이 한다.

공감. 사용자의 불편함을 이해하고, 팀원의 어려움을 파악하고, 비개발자에게 기술을 설명하는 일. 이건 인간관계의 영역이다. AI가 코드를 짜줘도, 그 코드가 해결하는 문제가 진짜 사용자의 문제인지는 사람만 판단할 수 있다.

맥락 유지. 프로젝트의 히스토리를 알고, 과거 결정의 이유를 이해하고, 미래 계획을 고려하는 것. AI는 주어진 컨텍스트 내에서 일하지만, 장기적인 맥락은 사람이 관리한다. "3년 전에 이 방식을 버린 이유가 있어" 같은 지식은 사람에게 있다.

주니어 개발자는 어떻게 되나

많은 사람이 걱정하는 부분이다. AI가 코드를 짜주면, 주니어 개발자는 어떻게 경험을 쌓나. 직접 코드를 짜봐야 실력이 느는 거 아닌가.

걱정이 일리 있다. 하지만 역사적으로 비슷한 일이 있었다.

계산기의 등장. 예전에는 복잡한 계산을 손으로 했다. 계산기가 나오면서 암산 능력이 덜 중요해졌다. 그렇다고 수학자가 사라졌나? 아니다. 수학자는 여전히 있고, 계산기를 도구로 쓸 뿐이다. 대신 암산 훈련에 쓰던 시간을 더 고차원적인 사고에 쓰게 됐다.

IDE의 등장. 예전에는 텍스트 에디터로 코드를 짰다. 자동완성도 없고, 문법 검사도 없었다. IDE가 나오면서 많은 부분이 자동화됐다. 그렇다고 개발자의 역량이 떨어졌나? 아니다. 더 복잡한 시스템을 더 빠르게 만들 수 있게 됐다.

구글의 등장. 예전에는 라이브러리 문서를 책으로 읽었다. 외워야 했다. 구글이 나오면서 "검색하면 되지"가 됐다. 암기력이 덜 중요해졌지만, 좋은 개발자와 나쁜 개발자의 차이는 여전히 있다.

AI도 비슷하다. 코드 작성 능력 자체보다, 코드를 이해하고 평가하는 능력이 중요해진다. 주니어 개발자는 AI가 만든 코드를 읽으면서 배울 수 있다. "AI가 왜 이렇게 짰지?" "이 패턴은 뭐지?" "여기 버그 있는 것 같은데?"

배움의 방식이 바뀌는 거지, 배움 자체가 사라지는 건 아니다. 오히려 AI를 통해 더 많은 예제를 보고, 더 빠르게 피드백을 받고, 더 다양한 패턴을 접할 수 있다.

다만, 의도적인 노력이 필요하다. AI가 만든 코드를 무비판적으로 수용하면 성장하기 어렵다. "왜?"를 계속 물어야 한다. AI에게 설명을 요청하고, 다른 방식으로 해보라고 하고, 두 방식을 비교해보라고 한다. AI를 선생님처럼 활용하는 거다.

조직은 어떻게 바뀌나

개인의 역할만 바뀌는 게 아니다. 조직 구조도 바뀐다.

팀 구성의 변화. 예전에는 개발자 10명이 필요한 프로젝트가 있었다. AI 도구를 쓰면 5명으로 같은 일을 할 수 있을지 모른다. 하지만 그 5명의 역할은 다르다. 코드를 많이 치는 사람보다, 설계하고 검토하고 통합하는 사람이 더 필요해진다.

시니어/주니어 비율. AI가 반복적인 코드를 대신 짜주면, 주니어 개발자의 전통적인 역할이 줄어든다. 하지만 AI 출력을 검토하고 품질을 보장하는 건 경험이 필요하다. 시니어 개발자의 역할이 상대적으로 더 중요해질 수 있다. 팀에서 시니어 비율이 높아질 가능성이 있다.

새로운 역할의 등장. AI 시대에 맞는 새 역할이 생길 수 있다. "AI 트레이너"는 AI에게 회사의 코딩 스타일과 패턴을 가르친다. "품질 엔지니어"는 AI 출력의 품질을 전문적으로 검토한다. "프롬프트 설계자"는 효과적인 AI 지시 체계를 만든다.

프로세스의 변화. 코드 리뷰 프로세스가 달라진다. AI가 만든 코드와 사람이 만든 코드를 구분할 필요가 있을까? 있다면 어떻게 처리할까? CI/CD 파이프라인에 AI 코드 검증 단계를 추가할 수도 있다. 자동으로 보안 취약점을 스캔하고, 코딩 스타일을 검사하고, 테스트 커버리지를 확인한다.

평가 방식의 변화. "코드 생산량"으로 개발자를 평가하기 어려워진다. AI를 쓰면 누구나 많은 코드를 만들 수 있다. 대신 "시스템 기여도", "설계 품질", "코드 리뷰 효과성" 같은 지표가 중요해질 수 있다.

사라지는 개발자, 살아남는 개발자

AI 시대에 어떤 개발자가 살아남을까.

사라지는 유형이 있다. "기능 구현 기계". 주어진 스펙을 받아서 코드로 옮기는 것만 하는 개발자. 요구사항을 질문 없이 받아들이고, 설계 없이 바로 코딩하고, 완료 후 다음 작업으로 넘어가는 유형. 이 역할은 AI가 더 잘한다. 빠르고, 싸고, 24시간 일한다.

살아남는 유형이 있다. 문제 해결자. 요구사항을 분석하고, 진짜 문제가 뭔지 파악하고, 여러 해결책을 비교하고, 최선의 방법을 선택하는 개발자. AI를 도구로 활용하되, 판단은 본인이 한다.

더 잘되는 유형도 있다. AI를 레버리지로 쓰는 개발자. 혼자서 10명분의 코드를 생산하면서도 품질을 유지하는 개발자. AI의 한계를 알고, 그 한계를 보완하면서, 전체 생산성을 극대화하는 개발자. 이런 개발자는 AI 시대에 오히려 가치가 올라간다.

핵심은 대체 불가능한 가치를 만드는 것이다. AI가 할 수 있는 일을 하면 경쟁이 된다. AI가 못 하는 일을 하면 독보적이 된다.

전환을 준비하는 법

지금 개발자라면, 이 전환에 어떻게 대비해야 할까.

AI 도구를 적극적으로 써본다. GitHub Copilot, Claude Code, Cursor, Windsurf. 다양한 도구를 써보면서 뭐가 잘되고 뭐가 안 되는지 파악한다. AI의 능력과 한계를 직접 경험해야 제대로 활용할 수 있다.

시스템 설계 능력을 키운다. 코드 작성 비중이 줄면, 설계 비중이 늘어난다. 아키텍처 패턴, 시스템 디자인, 확장성과 유지보수성을 공부한다. "System Design Interview" 같은 책이 도움이 된다.

코드 리뷰 능력을 기른다. 다른 사람 코드를 많이 읽고 검토한다. 오픈소스 프로젝트에 기여하거나, 회사에서 적극적으로 리뷰에 참여한다. AI 코드를 검토하는 것도 결국 코드 리뷰다.

비즈니스 이해를 높인다. 기술만 알면 도구가 되고, 비즈니스도 알면 파트너가 된다. 내가 만드는 코드가 비즈니스에 어떤 영향을 미치는지, 사용자에게 어떤 가치를 주는지 이해한다.

커뮤니케이션 스킬을 다듬는다. 코드가 줄고 협업이 늘어난다. 요구사항을 정확히 파악하고, 기술적 결정을 설명하고, 팀원과 효과적으로 소통하는 능력이 더 중요해진다.

코드를 넘어서

AI가 코드를 짜주는 세상에서, 개발자의 가치는 어디에 있을까. 코드 자체가 아니라, 코드 너머의 것들에 있다.

문제를 정의하는 능력. 해결책을 설계하는 능력. 품질을 검증하는 능력. 팀을 이끄는 능력. 사용자를 이해하는 능력. 비즈니스를 파악하는 능력.

코드는 수단이다. AI가 그 수단을 대신 만들어줄 때, 목적을 정하는 건 여전히 사람이다.

개발자의 정의가 "코드를 짜는 사람"이라면, 그 정의는 바뀌어야 한다. 개발자는 **"소프트웨어로 문제를 해결하는 사람"**이다. 코드를 직접 짜든, AI에게 시키든, 문제를 해결하면 된다.

그 역할은 사라지지 않는다. 오히려 더 중요해진다. AI가 코드를 만드는 속도가 빨라질수록, 무엇을 만들지 결정하는 사람의 중요성은 커진다. 도구가 강력해질수록, 도구를 쓰는 사람의 판단력이 더 중요해지는 법이다.

출처:

• Boris Cherny — Claude Code 30일 사용기 (X)
• GitHub Copilot 공식 사이트
• Anthropic Claude Code
• OWASP Top 10
• Unsplash — 이미지 출처