코드는 줄고 판단은 남았다: AI 시대 개발자의 일일일
원문 출처: 요즘IT - 핸디 작가
발행일: 2026년 3월 (요즘IT)
분석 작성일: 2026년 3월 26일
키워드: AI 에이전트, 개발자 역할, Claude Code, 페어 프로그래밍, agent.md, 하네스 엔지니어링
목차
- 글의 배경과 문제의식
- 인터뷰 개요
- 첫 번째 인터뷰: 40년 차 미국 빅테크 프린시펄 엔지니어
- 두 번째 인터뷰: 쿠팡 9년 차 프론트엔드 개발자
- 세 번째 인터뷰: 네이버 12년 차 백엔드 개발자
- 세 인터뷰를 관통하는 공통 결론
- 최신 동향: 글로벌·국내 시각에서 본 AI 시대 개발자
- 주요 개념 해설 사전
- 종합 시사점 및 앞으로의 질문
1. 글의 배경과 문제의식
이 글은 요즘IT(위시켓이 운영하는 IT 미디어)에 ‘핸디’라는 필명의 작가가 기고한 인터뷰 기사다. 제목 “코드는 줄고 판단은 남았다”는 AI 시대가 개발자의 일하는 방식을 어떻게 바꾸고 있는지를 함축적으로 담고 있다.
시대적 배경
요즘 개발자들 사이에서 일어나는 변화는 작지 않다. 채팅창에 요구사항을 입력하면 코드가 자동으로 생성되고, 테스트 코드도 함께 따라온다. 수십 년 된 레거시 코드베이스 분석도 몇 분이면 끝난다. POC(Proof of Concept, 개념 검증)는 하루 만에 마무리되고, 위키 문서까지 자동으로 정리된다. 필자는 이를 “딸깍 한 번으로 생성되는 세상”이라 표현한다.
특히 Claude Code(클로드 코드)처럼 터미널 기반으로 동작하는 AI 에이전트 도구가 확산되면서, 개발자들이 IDE(통합 개발 환경)보다 채팅창 또는 터미널을 바라보는 시간이 늘어났다. 즉, 코드를 직접 손으로 치는 시간이 눈에 띄게 줄어들고 있다.
필자가 품게 된 세 가지 질문
필자는 이 현상 앞에서 다음과 같은 질문들을 품게 된다.
첫째, 이게 맞는 방향일까? AI가 코드를 생성해주는 흐름이 개발자에게 긍정적인가, 아니면 어떤 위험을 내포하는가?
둘째, 주니어 개발자는 앞으로 어떻게 성장해야 할까? 기존에는 반복적인 코딩 작업을 통해 실력을 쌓았는데, AI가 그 작업을 대신한다면 성장의 경로가 사라지는 건 아닐까?
셋째, 리드 엔지니어나 시니어 개발자의 역할은 사라지는가, 아니면 오히려 더 중요해지는가?
이 질문들에 답하기 위해 필자는 경력과 회사, 직무가 서로 다른 세 명의 개발자를 직접 만나 인터뷰한다.
2. 인터뷰 개요
| 구분 | 경력 | 소속/직무 | 핵심 관점 |
|---|---|---|---|
| 1번 인터뷰이 | 40년 차 | 미국 빅테크 프린시펄 엔지니어 (전 아마존 등) | AI = 페어 프로그래머. 질문의 질이 결과의 질을 결정한다 |
| 2번 인터뷰이 | 9년 차 | 쿠팡 프론트엔드 개발자 | agent.md를 통한 AI 규칙 관리. AI는 수평 확장에 강하다 |
| 3번 인터뷰이 | 12년 차 | 네이버 백엔드(풀스택) 개발자 / 초보 매니저 | 2개월째 IDE 미사용. 문서화와 맥락 정리가 AI 성능을 결정한다 |
세 사람에게 던진 공통 질문은 단 하나였다. “AI를 어떻게 받아들이고 있으며, 실제 업무에서는 어떻게 활용하고 있나요?”
3. 첫 번째 인터뷰: 40년 차 미국 빅테크 프린시펄 엔지니어
인물 소개
그는 세미나에서 우연히 만난 40년 경력의 개발자다. 1980년대부터 개발을 시작했으며, 아마존을 포함한 여러 미국 빅테크 기업에서 시스템을 설계한 이력이 있다. 현재도 미국 빅테크에서 ‘프린시펄 엔지니어(Principal Engineer)’라는 최고 수준의 개인 기여자(IC, Individual Contributor) 직함으로 재직 중이다. 프린시펄 엔지니어는 보통 매니저 트랙이 아닌 기술 전문가 트랙의 정점에 해당하며, 조직 전체의 기술 방향성을 설정하는 역할을 한다.
AI에 대한 인식: 새로운 것이 아니다
그에게 AI는 처음 보는 개념이 아니다. 그가 개발을 시작한 1980년대에도 AI는 이미 뜨거운 토픽이었다. Smalltalk 머신(당시 객체 지향 언어와 AI 연구에 사용되던 하드웨어)도 존재했다. 다만 그 당시에는 연산 능력과 학습에 필요한 데이터가 절대적으로 부족했기 때문에 이론과 실험의 영역에 머물렀다. 지금의 AI가 근본적으로 다른 점은, 이론을 넘어 실용적인 도구로 현장에서 실제로 작동한다는 것이다.
핵심 비유: AI는 페어 프로그래머다
그는 AI와 일하는 현재 상황을 페어 프로그래밍(Pair Programming) 에 빗댄다. 페어 프로그래밍은 두 명의 개발자가 한 컴퓨터 앞에 나란히 앉아 함께 코드를 작성하는 방식이다. 전통적으로 연차가 쌓일수록 “나와 페어를 하고 싶다”는 사람이 줄어드는 경향이 있다. 하지만 이제는 AI가 그 빈자리를 채워주고 있다.
AI는 페어 프로그래머로서 다음과 같은 역할을 수행한다.
- 코드를 제안하고 작성한다
- 리팩토링 방향을 제시한다
- 테스트 코드를 생성한다
- 코드의 구조를 정리해준다
- 기술 문서를 작성한다
AI 페어 프로그래밍의 결정적 차이점: 비판하지 않는다
하지만 그는 중요한 차이점을 강조한다. 사람과의 페어 프로그래밍에서는 의견 충돌과 반박이 자연스럽게 일어난다. 그 과정에서 더 나은 코드가 탄생하기도 하고, 때로는 코드 컨벤션(convention, 코딩 규칙) 같은 사소해 보이는 문제로 심각한 갈등이 생기기도 한다. 실제로 그는 과거 페어 프로그래밍 파트너와 컨벤션 문제로 크게 충돌했고, 결국 팀이 달라지고 나서야 그 갈등이 해소됐다고 고백했다.
반면 AI는 다르다. 사람이 반박하면 대부분 수용적인 태도로 전환하며, 사람의 의견을 최대한 답변에 반영하려 한다. 이는 AI가 아직은 “내가 질문한 의도대로” 동작하는 경향이 강하다는 의미이기도 하다. 이 점 때문에 최근에는 코드 리뷰 AI 에이전트에게 “무조건 반대하는 입장에서 코드를 리뷰하라”는 역할을 부여하는 방식도 등장하고 있다.
AI 시대에 무엇을 준비해야 하는가
그의 답은 간결하고 명쾌하다.
“AI의 결과물의 퀄리티는 질문과 설계의 퀄리티에 달려 있어. 그 말은 내가 개발을 시작했던 40년 전에도 똑같이 들었던 이야기야.”
40년 전에도 “어떻게 설계하느냐”가 결과를 결정했다. AI의 등장으로 그 도구가 바뀌었을 뿐, 본질은 동일하다는 것이다. 이제 주니어 레벨에서도 단순 구현 속도보다 문제를 올바르게 정의하고 질문하는 능력이 훨씬 중요해졌다.
그가 말하는 “질문하는 법”이란 기술적 질문 스킬만이 아니다. 더 넓은 의미에서, 다음과 같은 시니어급 사고 능력을 말한다.
- 이 문제의 이해관계자는 누구인가?
- 언제까지 해결해야 하는가?
- 어떤 제약 조건이 있는가?
- 성공적인 해결의 기준은 무엇이고, 어떻게 측정할 수 있는가?
이 작업들은 전통적으로 시니어 개발자의 영역이었다. 이제 AI 시대에는 주니어부터 이 역량을 갖춰야 한다는 것이다.
주니어 개발자에 대한 우려: 고통의 부재
그는 한 가지 두려움을 덧붙인다. AI가 반복적이고 어려운 작업을 대신해줌으로써, 주니어 개발자가 초기에 겪어야 할 “고통의 경험”이 사라질 수 있다는 것이다.
버그를 추적하며 스택 트레이스(stack trace, 오류 발생 경로)를 따라 내려가 보는 경험, 잘못된 설계로 서비스 장애를 내보고 복구해보는 경험, 이러한 것들은 자동으로 생기지 않는다. 이 경험들이 축적될 때 시스템의 가용성(availability), 회복성(resilience) 등을 설계에 자연스럽게 반영할 수 있는 감각이 길러진다.
다만 그는 “AI를 쓰지 말라”는 게 아니라고 강조한다. AI와 함께 버그를 추적하고 설계해보는 방식으로 이 경험을 얻으면 된다는 것이다.
실제 AI 활용 사례
그가 직접 경험한 사례는 두 가지다.
첫째, 시간이 없어 주니어에게 위임하곤 했던 간단한 웹사이트를 AI와 함께 주말 동안 직접 완성했다. Figma 디자인 시안을 함께 활용해 빠르게 구현했다.
둘째, 특정 데이터베이스 버그의 스택 트레이스 전문(全文)을 AI에 읽게 했더니, 단 한 번에 오류를 찾아냈다. AI가 제시한 접근 방법과 결론이 자신이 생각했던 것과 거의 일치했다.
이 두 사례의 공통점은, 이전에는 시간이 없어서 하지 못했거나 타인에게 위임했던 일을 AI를 통해 직접, 빠르게 해결했다는 것이다. AI는 그의 판단을 실행으로 전환해주는 강력한 도구로 기능했다.
핵심 명언
“AI는 도구야. 장인은 도구를 탓하지 않는다던데, 실력도 좋은데 도구까지 좋으면 더 빨리, 더 멀리 갈 수 있지 않겠나?”
40년 차 엔지니어에게 AI는 본인의 일자리를 위협하는 경쟁자가 아니라, 만능 도구에 불과했다. 오히려 그 도구를 잘 다루는 사람이 더 강력해진다는 역설이 담겨 있다.
4. 두 번째 인터뷰: 쿠팡 9년 차 프론트엔드 개발자
인물 소개
이 개발자는 여러 스타트업을 거쳐 현재 쿠팡에 재직 중인 9년 차 프론트엔드 전문가다. 커리어 초창기부터 프론트엔드만을 깊이 파고들며 전문성을 쌓아온 인물이다. 인터뷰 당시 쿠팡 입사 6개월 차였으며, 입사 첫날부터 지금까지 매니저와의 1:1 미팅에서 “AI를 업무에 어떻게 활용하고 있는가”라는 질문을 꾸준히 받고 있다고 한다.
AI에 대한 인식: 특정 연차가 아닌 모두에게 주어진 기회
그는 AI가 가져다주는 혜택에 대한 시각이 변했다고 이야기한다. 2~3년 전까지만 해도 AI는 “시니어 개발자에게 주니어 개발자 여럿을 붙여주는 것과 같다”는 인식이 강했다. 즉, 절대적인 코딩 시간이 부족한 시니어에게 특히 유리하다는 관점이었다. 하지만 지금 그의 생각은 다르다. AI는 경력에 관계없이, 모든 개발자에게 엄청난 기회를 제공하고 있다.
쿠팡에서는 대부분의 팀이 AI 도구를 활용하고 있으며, 전사(全社)적으로 할당된 AI 툴 사용권을 선점하기 위해 ‘오픈런’이 벌어지기도 한다고 한다.
agent.md: AI를 위한 규칙서를 만든다
그의 가장 독특하고 인상적인 실천은 agent.md를 지속적으로 관리하는 것이다. agent.md란 AI 에이전트(특히 Claude Code 같은 도구)가 일관된 방향으로 작업할 수 있도록 규칙과 컨텍스트를 정의해 둔 마크다운 문서다.
그는 AI가 코드를 잘못 작성하거나 컨벤션에 어긋나는 부분을 발견할 때마다, 그 내용을 agent.md에 추가한다. 심지어 자신이 작성하는 PR(Pull Request, 코드 변경 요청) 중 10%는 오로지 AI를 위한 수정 사항, 즉 AI가 더 잘 작동하도록 규칙을 업데이트하는 내용이라고 밝혔다.
구체적인 예시는 다음과 같다.
- “테스트 코드는 jest 규칙에 따라 이런 형식으로 작성해야 한다. AI가 이를 누락했으니 규칙에 추가한다.”
- “CSS의 디자인 토큰(design token)은 특정 파일에서만 가져와야 한다. 기존 코드베이스에서 이 규칙이 혼재되어 있어 AI가 잘못된 방식으로 따르고 있으니 수정 규칙을 추가한다.”
이 모습은 마치 AI에게 코드 리뷰를 하는 것처럼 보인다. 그리고 그 리뷰 결과를 다시 AI의 행동 지침으로 반영한다는 점에서, AI와 개발자 사이에 피드백 루프(feedback loop)가 형성되어 있는 셈이다.
재귀적 스킬: 스킬을 만드는 스킬
그는 자신의 업무에서 쌓인 노하우를 AI를 통해 자동화하는 과정을 더욱 발전시켰다. 초기에 입사해서 PR 하나에 30개의 코드 리뷰 코멘트를 받았을 때, 그중 반복적으로 등장하는 피드백을 모아 pr-check라는 자체 스킬(AI 명령어 묶음)을 만들었다. 그리고 최근에는 더 나아가 스킬을 만드는 스킬(/create-skills) 을 커스텀해서 활용하고 있다.
사용법은 간단하다. AI와의 긴 대화가 끝날 때, “이때까지 대화 중에 스킬이나 룰로 만들 수 있는 것이 있으면 만들어줘”라고 명령하면 AI가 스스로 재사용 가능한 규칙을 추출해 스킬 파일로 정리해준다. 필자는 이를 처음 재귀 함수를 봤을 때와 같은 신기함으로 묘사한다.
CMS 구현 사례: AI의 수평 확장 능력
그가 이전 회사에서 경험한 구체적인 사례는 특히 흥미롭다. 당시 회사는 자체 CMS(Content Management System, 콘텐츠 관리 시스템)를 구현해야 했다. 다양한 미디어 파일과 인터랙션을 포함한 데모형 콘텐츠를 관리해야 했기 때문에, Puck Editor라는 오픈소스를 기반으로 드래그 앤 드롭 형태의 콘텐츠 편집기를 만들기로 했다.
핵심은 Puck Editor에서 사용될 컴포넌트들을 회사의 기존 디자인 시스템에서 포팅(porting, 다른 환경에 맞게 변환)하는 작업이었다. 기존 방식이라면 컴포넌트 하나당 며칠씩 걸리는 작업이었을 것이다. 하지만 AI를 활용해 레이아웃용·데모용 컴포넌트 약 30개를 단 3일 만에 완성했다.
이 경험을 통해 그는 AI의 핵심 강점을 다음과 같이 정의했다.
“AI는 수평 확장에 정말 강력하다.”
수평 확장(horizontal scaling)이란 같은 구조나 패턴을 여러 곳에 반복 적용하는 것이다. AI는 하나의 구조가 정해지면 그것을 수십, 수백 개로 복제하고 변형하는 작업을 압도적인 속도로 처리한다. 반면 수직 확장(vertical scaling), 즉 깊이 있는 설계, 아키텍처 결정, 창의적인 방향 설정은 여전히 인간 개발자의 영역이다.
“그렇다면 개발자가 할 일은 수평 확장이 가능하도록, 수직 확장의 토대를 마련하는 것이죠.”
현재 공부 방향: 테스트 코드의 본질을 이해하기
그는 AI 도입 이후 테스트 코드 수가 3배 증가한 서비스를 담당하고 있다. AI가 테스트를 알아서 잘 만들어주는 것처럼 보이지만, 그는 이에 의문을 품는다. AI가 만드는 테스트가 진짜 의미 있는 테스트인지, 아니면 단순히 테스트 개수와 커버리지 숫자를 늘리기 위한 것인지 판단할 수 없다는 것이다.
그래서 그는 테스트 코드에 관한 책 5권을 구매해 4권째까지 읽고 있다. 목표는 이렇게 쌓은 지식을 바탕으로 테스트 코드를 위한 agent.md 파일을 작성하고, AI가 만드는 테스트의 품질을 스스로 통제할 수 있게 되는 것이다.
AI를 신뢰하는 것과 판단을 위임하는 것은 다르다
그가 테스트 코드에 이토록 진심인 이유는 책임의 문제다. 일부 개발자들 사이에서 “코드를 보지 않고 배포한다”는 말이 등장하고 있는데, 그는 이를 다음과 같이 비판한다.
“AI를 신뢰하는 것과 판단을 위임하는 것은 다릅니다. 안 보고 배포한다는 말은 나는 책임질 수 없으니 너희가 책임지라는 의미처럼 들려요.”
실제 제품은 혼자 동작하지 않는다. 팀이 있고, 사용자가 있고, 비즈니스가 있다. 따라서 AI가 생성한 코드라 하더라도 그 결과에 대한 책임은 개발자에게 있다. 그 책임의 근거로 그가 선택한 것이 바로 테스트 코드다.
“테스트를 통과하면 제대로 된 기능이다”라는 말이 유행하고 있는데, 이게 정확한 명제인지는 모르겠지만 현실적인 타협안이라고 생각합니다.
5. 세 번째 인터뷰: 네이버 12년 차 백엔드 개발자
인물 소개
프론트엔드로 커리어를 시작했다가 백엔드를 거쳐 현재는 풀스택으로 일하는 12년 차 개발자다. 네이버에서 근무하고 있으며, 최근 이제 막 매니저 역할을 시작한 초보 매니저이기도 하다. 즉, 기술 전문가와 팀 관리자라는 두 가지 역할을 동시에 수행 중이다.
“올해 IDE를 안 켜봤다”
인터뷰에서 가장 강렬한 첫 발언은 이것이었다.
“갑자기 생각난 건데, 올해(인터뷰 날짜 기준 3월 초)에는 IDE를 안 켜본 것 같아요. 갑자기 소름이 끼치네요.”
그는 Claude Code를 주로 사용하고 있다. 문서와 Jira(프로젝트 관리 도구) 티켓에 상세하게 작성된 PRD(Product Requirements Document, 제품 요구사항 정의서)를 Claude Code가 스스로 가져와서 백엔드 코드를 작성해준다.
단, 그는 이것이 단순히 생산성 10배, 100배 향상으로 이어졌느냐는 질문에 “그런 느낌은 아니다”고 답한다. 그 이유는 코딩 자체가 원래도 업무의 전부가 아니었기 때문이다. 개발자의 시간 중 많은 부분은 컨텍스트를 정리하고 문서화하는 것, R&R(Role & Responsibilities, 역할과 책임)을 정리하는 것이 차지한다.
문서화의 역할이 달라졌다
기존에도 그는 PRD 작성, 스펙 정의, 팀 간 커뮤니케이션 문서화를 중요하게 여겼다. 잘 작성된 문서는 잘못된 개발 방향을 초반에 걷어내고, 불필요한 의사소통 비용을 줄여주기 때문이다. 하지만 이것이 코딩 속도 자체에 직접적인 영향을 주지는 않았다.
그런데 AI가 업무 프로세스에 본격적으로 녹아들면서 상황이 달라졌다.
“제가 만든 문서는 AI가 일을 한 번에, 그리고 제대로 하게 만드는 잘 정리된 Plan 문서로 동작합니다.”
그의 To-do 리스트조차 이제는 AI가 순서대로 실행할 수 있는 작업 계획서 역할을 한다. 즉, 문서화의 수신자가 사람에서 AI로 확장된 것이다. 문서가 잘 작성될수록 AI가 더 정확하게 일한다.
비개발 업무의 자동화: Jira 연동과 성과 관리
그는 AI를 코딩보다 오히려 비개발적인 업무에 활용하는 것이 생산성 향상에 더 크게 기여한다고 말한다.
매니저로서 Jira 티켓과 일정 관리는 필수적이지만 번거로운 작업이다. 개발자들은 일반적으로 작업 시작 시 한 번, 완료 시 한 번, 이렇게 두 번만 티켓 상태를 변경하는 경향이 있다. 그는 Claude Code를 Jira와 연동해 이 프로세스를 다음과 같이 자동화했다.
특정 작업을 시작한다고 선언하면, Claude Code가 자동으로 세 가지를 처리한다.
- 해당 Jira 티켓의 상태를 변경한다
- 티켓 번호가 포함된 브랜치 이름을 설정한다
- 해당 브랜치를 기반으로 GitHub Draft PR을 자동 생성한다
결과적으로 Jira 대시보드와 GitHub PR을 한눈에 보면 “누가 어떤 작업을 진행 중인지” 실시간으로 파악할 수 있게 됐다.
또한 하루에 한 번씩 자동으로 실행되는 크론잡(cron job, 일정 시간마다 자동 실행되는 스크립트)이 있다. 이 스크립트는 Jira, GitHub, 일정 정보를 종합해 진행 상황을 요약 보고한다.
일일 성과 관리 자동화
그는 한 가지 자동화를 더 추가했다. 하루 동안 작업한 내용을 바탕으로 성과 관리 문서를 자동 생성하는 것이다. 이를 주간, 월간, 분기 단위로 쌓아가며 자신의 성과를 관리하고 있다.
인터뷰 당시 이 자동화를 시작한 지 6개월이 채 안 됐지만, 이미 주간·월간·분기 단위 데이터가 쌓이고 있었다. 그의 Claude Code 화면은 터미널 기반이지만 커스텀되어 있어 깔끔한 매니저 대시보드처럼 보였다고 필자는 묘사한다.
공부 방향: AI라는 도구를 제대로 익히는 것
그는 학부 시절 “마우스 없이 코딩하는 날”을 만들어 vim(텍스트 편집기)을 연습하던 이야기를 꺼낸다. 당시에는 vim으로 빠르게 코딩하는 것이 실력의 척도였다. 초등학교 시절 타자 수가 빠르면 컴퓨터를 잘 한다고 인정받던 것처럼.
그 경험에서 그는 교훈을 얻었다. 도구는 시간을 들여 따로 익혀야 한다. AI 도구도 마찬가지다. 자연스럽게 터득되는 것이 아니라, 별도의 시간과 노력으로 마스터해야 한다.
구체적으로 그는 하네스 엔지니어링(Harness Engineering) 과 AI 오케스트레이션(AI Orchestration) 에 관심을 두고 있다.
하네스 엔지니어링이란 LLM(Large Language Model, 대규모 언어 모델)을 감싸서 실전에서 안전하게 제어하고, 외부 도구와 연결해 실제 행동을 수행하게 하는 소프트웨어 프레임워크를 설계하는 일을 말한다. AI 오케스트레이션은 여러 AI 모델과 시스템을 하나의 워크플로 안에서 통합·관리해 복잡한 문제를 해결하는 기술이다.
그는 이 분야들이 너무 빠르게 변해 공부하기도 전에 새로운 방법론이 등장하는 것에 불안함을 느끼면서도, 이렇게 말한다.
“그래도 어쩌겠습니까? 다들 AI라는 비행기를 타고 날아가고 있는데, 저만 뛰어갈 수는 없잖아요.”
필자는 그가 Claude Code를 설명하던 순간을, IDE를 몇 달 동안 켜지 않았음에도 가장 개발자답게 보인 순간이었다고 표현한다.
6. 세 인터뷰를 관통하는 공통 결론
세 명의 인터뷰이는 배경, 경력, 직무, 사용하는 AI 도구가 모두 다르다. 하지만 그들의 이야기는 결국 하나의 방향으로 수렴한다.
개발의 본질은 바뀌지 않았다, 다만 시간 배분이 바뀌었다
AI가 등장했다고 해서 개발이라는 일이 완전히 다른 무언가가 된 것은 아니다. 달라진 것은 시간을 쓰는 방식이다. 코드를 직접 타이핑하는 시간은 줄어들고, 문제를 정의하고, 맥락을 설명하고, 방향을 설정하는 시간이 늘어나고 있다.
세 사람이 각각 다른 방식으로 같은 결론을 말한다
40년 차 엔지니어는 “좋은 결과는 여전히 좋은 질문에서 시작한다”고 말했다. 쿠팡 개발자는 “AI가 잘 일하도록 규칙을 만들고 계속 추가한다”고 했다. 네이버 개발자는 “문서와 맥락을 잘 정리하는 것이 AI의 성능을 끌어올린다”고 했다.
세 가지 모두 다른 표현이지만, 결국 같은 말이다. AI를 잘 쓰기 위해서는 사람이 먼저 명확하게 생각해야 한다.
AI는 도구이고, 판단은 여전히 사람의 몫이다
AI는 일을 더 빠르게 만들어주는 도구다. 하지만 무엇을 만들지 결정하고, 결과물에 책임을 지는 일은 여전히 사람의 몫이다. AI를 신뢰하는 것과 판단을 위임하는 것은 엄연히 다르다.
마지막으로 필자가 남긴 질문
“나는 오늘 AI에게 무엇을 시켰는가”가 아니라, “나는 오늘 어떤 문제를 풀려고 했는가?”
이 질문이 이 글의 핵심을 가장 잘 담고 있다. AI 시대에도 개발자의 정체성은 코드를 얼마나 많이 쓰느냐가 아니라, 어떤 문제를 풀고 있느냐에 있다는 것이다.
7. 최신 동향: 글로벌·국내 시각에서 본 AI 시대 개발자
이 아티클이 다루는 주제는 개인 인터뷰에서 그치지 않는다. 국내외 다양한 자료들이 같은 방향을 가리키고 있다.
채용 시장의 변화
국내 스타트업 채용 플랫폼 그룹바이(GroupBy) 분석에 따르면, 투자 단계가 높아질수록 AI 및 데이터 관련 직군 비율이 15%에서 34%까지 급등한 반면, 웹·앱 중심의 백엔드·프론트엔드·풀스택 포지션은 점차 감소세를 보이고 있다. 기업이 성장할수록 신규 서비스 개발보다 AI 고도화와 운영 자동화에 집중하고 있다는 신호다.
한편 미국에서는 Resume.org가 기업 리더 1,000명을 대상으로 진행한 설문에서, 2026년까지 기업 10곳 중 6곳이 직원 감축을 단행할 가능성이 있으며 10곳 중 4곳은 인력을 AI로 대체할 계획이라고 응답했다. 특히 반복적인 코딩 작업을 담당하는 주니어 개발자 직군이 가장 먼저 구조조정 대상이 될 수 있다는 분석이 나온다.
하지만 동시에, Dilioitte(딜로이트) 분석에 따르면 2025년 하반기 전 세계 IT 지출은 전년 대비 9.3% 증가할 것으로 전망된다. Statista에 따르면 가장 수요가 높은 직종은 여전히 풀스택 및 백엔드 개발자이며, 그 다음으로 AI·ML 전문가, 프론트엔드 엔지니어, DevOps 전문가 순이다.
앤드류 응 교수의 진단
AI 분야 세계적 석학 앤드류 응(Andrew Ng) 교수는 스탠포드 강연에서 이렇게 말했다. AI 덕분에 아이디어를 코드로 구현하는 비용이 거의 0에 수렴하고 있다. 이제는 코드를 잘 짜는 것보다 “무엇을 만들지 결정하는 능력” 과 “사용자의 니즈를 파악하는 공감 능력” 을 갖춘 제품 엔지니어가 주목받는 시대가 됐다고 강조했다. 이는 이 아티클의 세 인터뷰이가 공통적으로 말한 것과 정확히 일치한다.
에이전틱 AI(Agentic AI)의 부상
Gartner는 2026년까지 전체 기업 애플리케이션의 40%가 작업 특화 AI 에이전트를 통합할 것으로 예측했다. 2025년 현재 이 비율이 5% 미만인 점을 감안하면, 단 1년 만에 8배 증가하는 셈이다. 2028년에는 90%의 기업 앱이 AI 에이전트를 통합할 것으로 전망된다.
한 글로벌 컨설팅 펌은 “생성형 AI로 개발자 생산성이 30% 향상됐지만, 에이전틱 AI 도입 후에는 200% 향상됐다”고 보고했다. 이제 AI는 단순히 질문에 답하는 수준을 넘어, 스스로 목표를 세우고 계획을 수립하며 실행까지 하는 방향으로 진화하고 있다.
개발자의 역할 재정의
SK AX의 분석에 따르면, AI 시대 개발자에게 요구되는 핵심 역량은 “얼마나 많은 코드를 직접 작성할 수 있는가”가 아니다. AI가 생성한 결과물을 올바르게 이해하고 평가하며, 전체 시스템 안에서 의미 있게 연결할 수 있는 능력이 핵심이 되고 있다. 반복적이고 소모적인 작업은 AI에게 맡기고, 인간만이 할 수 있는 판단과 책임의 영역에 집중하는 개발자가 살아남는 시대다.
8. 주요 개념 해설 사전
이 아티클에 등장하는 개념들을 보다 상세하게 풀이한다.
페어 프로그래밍 (Pair Programming)
두 명의 개발자가 한 컴퓨터 앞에 나란히 앉아 함께 코드를 작성하는 협업 방식이다. 한 명이 코드를 작성하면(드라이버), 다른 한 명이 실시간으로 리뷰하고 방향을 제시한다(내비게이터). 서로 다른 시각이 부딪히며 코드 품질이 높아지지만, 동시에 의견 충돌이 일어나기도 한다.
프린시펄 엔지니어 (Principal Engineer)
기술 전문가 트랙(Individual Contributor 트랙)의 최상위 직함 중 하나다. 매니저로 승진하는 대신 엔지니어로서의 전문성을 극한까지 쌓는 경로다. 조직 전체의 기술 방향을 설정하고, 복잡한 시스템 설계 문제를 해결하며, 다른 엔지니어들이 어려운 기술 문제를 해결할 수 있도록 가이드한다.
PRD (Product Requirements Document)
제품 요구사항 정의서. 개발할 서비스나 기능의 목표, 타깃 고객, 핵심 기능, 성공 지표 등을 명확하게 정의해 개발팀, 디자인팀 등 이해관계자와 공유하는 문서다. AI에게 이 문서를 제공하면, AI가 요구사항을 이해하고 이에 맞는 코드를 생성할 수 있다.
R&R (Role & Responsibilities)
조직이나 프로젝트 내에서 각 구성원이 맡은 역할과 책임을 의미한다. R&R을 명확히 정리하는 것은 불필요한 중복 업무나 누락을 방지하는 중요한 작업이다.
agent.md
AI 에이전트가 일관된 방향으로 작업할 수 있도록 규칙과 맥락을 정의해 둔 마크다운 형식의 텍스트 파일이다. 프로젝트의 코딩 컨벤션, 아키텍처 결정, 사용해야 할 라이브러리, 피해야 할 패턴 등을 기록한다. Claude Code, Cursor 같은 AI 코딩 도구에서 이 파일을 읽어 작업 지침으로 활용한다.
Claude Code (클로드 코드)
Anthropic이 개발한 터미널 기반 AI 에이전트다. 단순한 코드 자동완성을 넘어, 파일 시스템을 탐색하고, 여러 파일을 동시에 수정하며, 외부 도구(Jira, GitHub 등)와 연동해 복잡한 작업을 자율적으로 수행할 수 있다.
수평 확장 vs 수직 확장 (AI 맥락에서)
이 아티클에서 쿠팡 개발자가 사용한 표현이다. 수평 확장은 동일한 패턴이나 구조를 여러 곳에 반복 적용하는 것으로, AI가 압도적으로 빠르다. 수직 확장은 깊이 있는 설계, 새로운 아키텍처 도입, 창의적 방향 설정 등 더 높은 수준의 판단이 필요한 작업으로, 여전히 인간의 영역이다.
하네스 엔지니어링 (Harness Engineering)
LLM(대규모 언어 모델)을 실전에서 안전하게 활용할 수 있도록 외부에서 감싸는 소프트웨어 프레임워크를 설계·관리하는 것이다. AI 모델 자체를 개발하는 것이 아니라, 모델의 입출력을 제어하고, 외부 도구와 연결하며, 보안과 안전을 확보하는 아키텍처를 만드는 일이다.
AI 오케스트레이션 (AI Orchestration)
여러 AI 모델, 데이터베이스, 외부 서비스를 하나의 워크플로 안에서 통합·관리하는 기술이다. 마치 오케스트라의 지휘자처럼 서로 다른 AI와 시스템이 협력해 단일 모델로는 해결하기 어려운 복잡한 문제를 풀도록 조율한다.
스택 트레이스 (Stack Trace)
프로그램에서 오류가 발생했을 때, 오류가 발생한 지점부터 호출 경로를 역순으로 추적한 정보다. 버그를 디버깅할 때 핵심 단서가 된다. 40년 차 엔지니어는 AI에게 스택 트레이스를 분석시켜 단번에 정확한 원인을 찾아냈다.
크론잡 (Cron Job)
특정 시간이나 주기에 맞춰 자동으로 실행되도록 예약된 스크립트 또는 프로그램이다. 네이버 개발자는 하루에 한 번씩 실행되는 크론잡으로 Jira와 GitHub 정보를 종합한 일정 관리 보고서를 자동 생성했다.
POC (Proof of Concept)
개념 검증. 새로운 아이디어나 기술이 실제로 동작 가능한지 확인하기 위한 초기 시범 구현이다. AI 덕분에 POC를 하루 만에 완성하는 사례가 늘어나고 있다.
Design Token (디자인 토큰)
디자인 시스템에서 색상, 폰트, 간격 등 디자인 값을 일관성 있게 관리하기 위한 변수다. 버튼 색상이나 텍스트 크기를 하드코딩하는 대신 디자인 토큰으로 정의해두면, 디자인 변경 시 한 곳만 수정해도 전체에 적용된다.
9. 종합 시사점 및 앞으로의 질문
시사점 1: 질문의 능력이 곧 개발 능력이다
세 인터뷰이 모두 공통적으로, AI 시대에 가장 중요한 역량으로 “문제를 제대로 정의하고 설명하는 능력” 을 꼽았다. 40년 차 엔지니어의 말처럼, “AI의 결과물 퀄리티는 질문과 설계의 퀄리티에 달려 있다.” 이는 코딩 스킬보다 상위 개념이며, 도메인 이해, 이해관계자 파악, 목표 설정 능력을 포함한다.
시사점 2: 주니어 개발자의 성장 경로를 의식적으로 설계해야 한다
AI가 반복 작업과 디버깅을 대신해줄수록, 주니어 개발자가 자연스럽게 경험을 쌓는 경로가 좁아진다. 따라서 개인 차원에서는 AI와 함께 디버깅하고 설계하는 경험을 의식적으로 만들어야 하며, 조직 차원에서는 주니어의 성장 루트를 재설계해야 한다.
시사점 3: 문서화는 사람을 위한 것에서 AI를 위한 것으로도 확장됐다
네이버 개발자의 사례가 잘 보여주듯, 문서화는 더 이상 팀원 간 커뮤니케이션 도구에만 머물지 않는다. 잘 작성된 PRD와 To-do 리스트는 AI가 작업을 올바르게 수행하게 하는 핵심 인풋이 됐다. 개발자가 문서화를 잘 할수록 AI의 생산성이 더 높아진다.
시사점 4: AI 신뢰와 책임 위임은 엄격히 구분해야 한다
쿠팡 개발자의 표현이 핵심을 찌른다. AI를 신뢰한다는 것은 AI의 결과물을 활용한다는 뜻이지, 그 결과에 대한 책임을 AI에게 넘긴다는 뜻이 아니다. 테스트 코드, 코드 리뷰, 아키텍처 검토 등 책임의 근거를 확보하는 장치들이 더욱 중요해진다.
시사점 5: 도구 자체를 익히는 데 시간을 투자해야 한다
네이버 개발자가 vim 수련에 비유했듯, AI 도구는 자연스럽게 익혀지는 것이 아니다. agent.md를 만들고, 커스텀 스킬을 제작하고, 하네스 엔지니어링을 이해하는 것처럼, AI를 더 잘 다루기 위한 별도의 학습과 실험이 필요하다.
앞으로 우리가 스스로에게 던져야 할 질문들
이 아티클을 읽은 후 개발자라면 한 번쯤 자신에게 물어볼 만한 질문들이 있다.
나는 오늘 어떤 문제를 풀려고 했는가? 단순히 AI에게 코드를 생성시켰는가, 아니면 문제를 먼저 명확히 정의했는가?
내가 사용하는 AI 도구의 특성을 얼마나 깊이 이해하고 있는가? agent.md처럼 AI의 행동을 통제하는 규칙을 만들어보았는가?
AI가 생성한 코드에 대한 책임의 근거를 마련해두었는가? 테스트 코드, 코드 리뷰, 아키텍처 검토 등의 장치가 있는가?
내 조직에서 주니어 개발자는 AI 시대에도 충분한 경험을 쌓을 수 있는 환경에 있는가?
이 문서는 요즘IT의 아티클 「코드는 줄고 판단은 남았다: AI 시대 개발자의 일일일」을 바탕으로, 관련 최신 자료를 종합해 분석한 참고 자료입니다.
원문: https://yozm.wishket.com/magazine/detail/3673/
분석 작성일: 2026년 3월 26일