AI 코딩 시대의 개발자 역할 변화: 코딩 실행자에서 맥락·검증·제품화 설계자로

baeba · 2026-07-06T10:13:13+09:00

요약 개요 핵심 주장 AI가 코드를 직접 작성·수정·테스트하는 수준에 도달하면서, 개발자의 역할은 단순 코딩 중심에서 문제 정의, 작업 설계, 검증, 맥락 관리, 제품화 지원으로 이동하고 있다. 구조적 원인 AI는 코드 생산 속도를 크게 높였지만, 코드가 곧바로 좋은 제품이 되는 것은 아니다. 요구사항, 문서, 테스트, 구조화, UX 판단, 유지보수 가능성 같은 비코딩 영역의 중요성이 더 커졌다. 주요 사례 Playwright를 통해 AI가 브라우저 테스트까지 수행하게 만든 경험. 반복 작업을 커맨드·스킬·워크플로우로 명세화한 경험. AI로 만든 프론트엔드 프로토타입이 겉으로는 훌륭하지만 내부 구조는 취약했던 사례. 해결 방향 AI에게 코드만 맡기지 말고, 개발 전 과정의 절차와 기준을 함께 설계해야 한다. 개발자는 AI 산출물을 검토하고, 맥락을 남기며, 지속 가능한 제품으로 이어지도록 구조를 정리해야 한다. 서론 AI 코딩 시대의 전환 게시글은 “사람이 직접 코딩하지 않는 시대에 개발자는 무엇을 해야 하는가”라는 질문에서 출발한다. 작성자는 과거에는 AI가 환각과 실수를 일으키기 때문에 최종 판단은 사람이 해야 한다고 보았다. 그러나 최근 AI 모델의 성능 향상으로 인해, AI가 이슈 파악, 파일 탐색, 코드 수정, 테스트 통과까지 수행하는 수준에 도달했다고 평가한다. 이 변화로 인해 개발자는 단순히 AI를 보조 도구로 쓰는 수준을 넘어, AI가 개발 절차 자체를 수행하도록 만드는 방향을 고민하게 된다. 핵심 문제의식 AI가 코드를 잘 작성하게 되었지만, 이것이 개발자의 역할이 사라진다는 뜻은 아니다. 오히려 코딩이 자동화될수록 개발의 다른 요소들이 더 뚜렷하게 드러난다. 요구사항 정리, 의사결정 기록, 테스트 설계, 코드 구조 관리, 제품 경험 검수 등이 개발자의 핵심 과제로 부상한다. 본론 1. AI는 코드 작성 도구에서 작업 수행 주체로 이동했다 작성자는 AI가 단순 코드 조각을 생성하는 수준을 넘어, 실제 개발 작업 흐름을 처리할 수 있게 되었다고 본다. 과거에는 AI의 결과물을 사람이 계속 감시하고 수정해야 했지만, 이제는 AI에게 작업을 맡기고 결과를 검수하는 방식이 가능해졌다. SWE Bench와 같은 벤치마크 성능 향상은 이러한 변화를 보여주는 지표로 언급된다. 핵심 변화는 “AI가 코드를 작성할 수 있는가”가 아니라, “AI에게 어느 범위까지 작업을 맡길 수 있는가”로 질문이 바뀐 점이다. 2. AI가 실패할 때 문제는 ‘능력 부족’만이 아니다 AI는 여전히 항상 성공하지는 않는다. 에러가 반복되거나, 수정했다고 했지만 실제 화면에서 문제가 남아 있는 경우가 발생한다. 작성자는 처음에는 사람이 에러를 복사해 AI에게 전달하는 방식으로 대응했다. 이후 Playwright를 사용해 AI가 브라우저를 직접 열고 테스트하도록 만들면서, 사람이 하던 검증 절차도 AI에게 맡길 수 있음을 깨달았다. 이 사례는 AI의 한계라고 생각했던 것 중 일부가 실제로는 사용자가 지시하지 않았기 때문에 발생한 한계였음을 보여준다. 3. AI Native 사고는 절차 전체를 위임하는 방식이다 작성자는 AI를 단순 보조 도구로 쓰는 관점에서 벗어나, 자신이 하던 절차 전체를 AI가 수행하게 만드는 방향으로 전환한다. 반복 작업을 커맨드, 스킬, 워크플로우로 만들고, 자신의 암묵지를 명세화하려고 시도한다. 예시로 /plan, /prd, /debug, /refactor, /verify, /retrospect 같은 명령 흐름을 만든다. 중요한 점은 AI에게 단순히 “코드를 짜라”고 하는 것이 아니라, 언제 질문하고, 언제 멈추고, 언제 검증할지까지 규칙화하는 것이다. 이를 통해 개발자는 자신의 작업 방식과 판단 기준을 AI가 재사용할 수 있는 구조로 바꾸게 된다. 4. 개인 노하우는 빠르게 도구 기능으로 흡수된다 작성자가 직접 만들던 커맨드와 워크플로우는 시간이 지나면서 Skill, memory, hooks, orchestration 같은 공식 기능과 개념으로 등장한다. 개인이 발견한 AI 활용 방법론은 효과가 있을수록 빠르게 제품 기능이나 공통 방법론으로 흡수된다. 따라서 AI를 잘 쓰는 특정 프롬프트나 팁만으로는 장기적인 차별화를 만들기 어렵다. 중요한 것은 방법론 자체보다, 그 방법론을 실제 문제에 적용해 어디까지 만들어보고 어떤 한계를 경험했는가이다. 5. AI는 개발자가 다룰 수 있는 문제의 크기를 키운다 AI는 작성자가 과거에는 비용과 시간 때문에 시도하지 못했던 대형 아이디어를 실제로 실험하게 만든다. 예를 들어 코드와 문서를 캔버스처럼 펼쳐보는 도구, MD 뷰어, 코드 분석 도구, 개발 보조 도구 등을 빠르게 만들어본다. 핵심은 AI가 완성품을 즉시 만들어준다는 것이 아니라, 시작의 허들을 낮춰준다는 점이다. 개발자는 “이걸 만들 수 있을까?”에서 “일단 어디까지 만들어볼 수 있을까?”로 사고를 전환하게 된다. 6. 큰 문제를 다루면 코딩 외의 개발 업무가 드러난다 AI로 코드 생산량이 증가하면, 개발자는 모든 코드를 직접 읽고 맥락을 머릿속에 저장하기 어려워진다. 직접 코딩할 때는 자연스럽게 축적되던 맥락, 판단, 구조 이해가 AI에게 코딩을 맡기면 자동으로 남지 않는다. 따라서 문서, 테스트, 이슈, 작업 보고서, 변경 이유 기록이 중요해진다. 이는 관리 업무가 아니라, AI 시대에 개발 맥락을 유지하기 위한 핵심 장치가 된다. 코딩 능력만큼이나 맥락과 판단을 보존하는 능력이 중요해진다는 점이 강조된다. 7. 커밋과 테스트 증가가 곧 제품 개선은 아니다 AI를 활용하면 커밋, 파일, 테스트, 문서의 수는 빠르게 늘어난다. 그러나 수치가 증가한다고 해서 제품이 실제로 좋아지는 것은 아니다. 기능은 추가되지만 UX가 어색하거나, 테스트는 통과하지만 실제 화면 흐름이 불안정한 문제가 발생한다. 작성자는 처음에는 이를 코드 품질과 구조 문제로만 보려 했다. 하지만 코드 구조를 개선해도 제품 경험이 자동으로 좋아지지는 않는다는 점을 경험한다. 결국 코드 생산과 제품 개선은 다른 문제이며, 제품성에 대한 판단이 별도로 필요하다. 8. 프론트엔드는 AI가 특히 흔들리기 쉬운 영역이다 AI는 대시보드, 랜딩 페이지, 관리자 화면처럼 그럴듯한 초기 UI를 빠르게 만들 수 있다. 그러나 실제 제품 수준의 프론트엔드는 디자인 시스템, 상태 관리, 접근성, 키보드 조작, 예외 상태, 사용자 흐름 등 복잡한 기준을 요구한다. 프론트엔드의 많은 요구는 “자연스럽게”, “덜 어색하게”, “선택된 느낌이 나게”처럼 모호한 언어로 표현된다. AI는 이런 모호한 요구를 코드로 바꾸는 과정에서 결과가 쉽게 발산한다. 따라서 프론트엔드에서 AI를 잘 쓰려면, 잘 나온 부분은 고정하고 부족한 부분만 다시 수정하게 만드는 기준과 판단력이 필요하다. 9. 좋은 결과물은 한 번에 나오지 않고 수렴 과정을 통해 만들어진다 작성자는 한 기획자가 AI로 만든 완성도 높은 프로토타입을 보고 인식을 바꾼다. 그 결과물은 특별한 프롬프트 하나로 만든 것이 아니라, “될 때까지” 반복적으로 수정한 결과였다. 이 사례는 AI 활용의 핵심이 단순한 자동 생성이 아니라, 부족한 부분을 계속 보고 다시 요구하는 수렴 과정임을 보여준다. 좋은 결과를 만드는 사람은 AI가 만든 산출물에서 무엇이 부족한지 판단하고, 원하는 수준이 나올 때까지 집요하게 조정한다. AI 시대에도 사람의 기준, 감각, 지속적인 검수가 결과물의 차이를 만든다. 10. 개발자는 가능성 있는 결과물을 제품으로 이어주는 역할을 맡는다 AI로 만든 결과물은 겉보기에는 좋지만 내부 코드 구조가 취약할 수 있다. 상태 관리가 불안정하거나, 컴포넌트 책임이 모호하거나, 테스트가 실제 흐름을 보장하지 못하는 문제가 생긴다. 개발자의 역할은 이런 결과물을 무조건 낮게 평가하거나 폐기하는 것이 아니다. 동시에 그대로 제품화해서도 안 된다. 개발자는 가능성 있는 결과물이 더 멀리 갈 수 있도록 구조를 정리하고, 위험을 표시하고, 테스트 가능한 단위를 만들고, 맥락을 남겨야 한다. 즉, 개발자는 “끝까지 혼자 만드는 사람”에서 “AI와 사람이 만든 결과물을 지속 가능한 제품으로 이어주는 사람”으로 역할이 확장된다. 11. AI 시대의 개발 역할은 하나로 수렴하지 않는다 코딩의 허들이 낮아지면 개발에 참여하는 사람의 유형도 다양해진다. 기획자, 디자이너, PM, 현업 담당자도 AI를 통해 동작하는 프로토타입이나 내부 도구를 만들 수 있다. 이는 개발자의 필요성이 사라진다는 뜻이 아니라, 개발과 관련된 역할이 더 세분화된다는 의미다. 작성자는 이를 유튜브 생태계에 비유한다. 유튜브가 영상 전문가를 없앤 것이 아니라 출연자, 편집자, 기획자, 채널 운영자, 플랫폼 제작자 등 역할을 다양화한 것처럼, AI도 개발 역할을 다양화할 수 있다. 앞으로는 깊은 시스템을 만드는 사람, 프로토타입을 제품으로 다듬는 사람, AI가 잘 작업할 수 있는 레이어를 만드는 사람, 문제를 직접 해결하는 사람이 공존할 가능성이 크다. 결론 개발자는 코딩 이후의 개발을 설계해야 한다 게시글의 결론은 “코딩을 계속해야 하는가, 내려놓아야 하는가”라는 이분법이 아니다. AI가 코딩을 수행할 수 있게 된 만큼, 개발자는 AI에게 무엇을 맡기고 무엇을 직접 판단해야 하는지 경험적으로 익혀야 한다. 특히 다음 역량이 중요해진다. 문제를 더 크게 설정하는 능력 반복 절차를 스킬과 워크플로우로 만드는 능력 요구사항, 문서, 테스트, 이슈를 구조화하는 능력 AI 산출물을 검수하고 부족한 부분을 재지시하는 능력 거친 결과물을 지속 가능한 제품으로 다듬는 능력 코드 밖의 도구와 업무 흐름까지 AI와 연결하는 능력 핵심 메시지 AI는 개발자의 기대만큼 완벽하지는 않지만, 생각보다 훨씬 많은 일을 수행할 수 있다. AI가 못한다고 판단하기 전에, 실제로 어디까지 시킬 수 있는지 실험해야 한다. 반대로 AI가 쉽게 해준다고 해서 결과물을 그대로 신뢰해서는 안 된다. 개발자는 AI가 만든 결과를 판단하고, 수렴시키고, 맥락을 보존하며, 제품으로 이어지게 만드는 역할을 맡아야 한다. 결국 AI 시대의 개발자는 코드를 직접 많이 쓰는 사람이라기보다, AI와 사람이 만든 산출물이 더 나은 결과로 이어지도록 문제·절차·기준·맥락을 설계하는 사람에 가까워진다.

(velog.io/@teo)

6P by baeba 6시간전 | ★ favorite | 댓글과 토론

요약 개요

핵심 주장
- AI가 코드를 직접 작성·수정·테스트하는 수준에 도달하면서, 개발자의 역할은 단순 코딩 중심에서 문제 정의, 작업 설계, 검증, 맥락 관리, 제품화 지원으로 이동하고 있다.
구조적 원인
- AI는 코드 생산 속도를 크게 높였지만, 코드가 곧바로 좋은 제품이 되는 것은 아니다.
- 요구사항, 문서, 테스트, 구조화, UX 판단, 유지보수 가능성 같은 비코딩 영역의 중요성이 더 커졌다.
주요 사례
- Playwright를 통해 AI가 브라우저 테스트까지 수행하게 만든 경험.
- 반복 작업을 커맨드·스킬·워크플로우로 명세화한 경험.
- AI로 만든 프론트엔드 프로토타입이 겉으로는 훌륭하지만 내부 구조는 취약했던 사례.
해결 방향
- AI에게 코드만 맡기지 말고, 개발 전 과정의 절차와 기준을 함께 설계해야 한다.
- 개발자는 AI 산출물을 검토하고, 맥락을 남기며, 지속 가능한 제품으로 이어지도록 구조를 정리해야 한다.

서론

AI 코딩 시대의 전환

게시글은 “사람이 직접 코딩하지 않는 시대에 개발자는 무엇을 해야 하는가”라는 질문에서 출발한다.
작성자는 과거에는 AI가 환각과 실수를 일으키기 때문에 최종 판단은 사람이 해야 한다고 보았다.
그러나 최근 AI 모델의 성능 향상으로 인해, AI가 이슈 파악, 파일 탐색, 코드 수정, 테스트 통과까지 수행하는 수준에 도달했다고 평가한다.
이 변화로 인해 개발자는 단순히 AI를 보조 도구로 쓰는 수준을 넘어, AI가 개발 절차 자체를 수행하도록 만드는 방향을 고민하게 된다.

핵심 문제의식

AI가 코드를 잘 작성하게 되었지만, 이것이 개발자의 역할이 사라진다는 뜻은 아니다.
오히려 코딩이 자동화될수록 개발의 다른 요소들이 더 뚜렷하게 드러난다.
요구사항 정리, 의사결정 기록, 테스트 설계, 코드 구조 관리, 제품 경험 검수 등이 개발자의 핵심 과제로 부상한다.

본론

1. AI는 코드 작성 도구에서 작업 수행 주체로 이동했다

작성자는 AI가 단순 코드 조각을 생성하는 수준을 넘어, 실제 개발 작업 흐름을 처리할 수 있게 되었다고 본다.
과거에는 AI의 결과물을 사람이 계속 감시하고 수정해야 했지만, 이제는 AI에게 작업을 맡기고 결과를 검수하는 방식이 가능해졌다.
SWE Bench와 같은 벤치마크 성능 향상은 이러한 변화를 보여주는 지표로 언급된다.
핵심 변화는 “AI가 코드를 작성할 수 있는가”가 아니라, “AI에게 어느 범위까지 작업을 맡길 수 있는가”로 질문이 바뀐 점이다.

2. AI가 실패할 때 문제는 ‘능력 부족’만이 아니다

AI는 여전히 항상 성공하지는 않는다.
에러가 반복되거나, 수정했다고 했지만 실제 화면에서 문제가 남아 있는 경우가 발생한다.
작성자는 처음에는 사람이 에러를 복사해 AI에게 전달하는 방식으로 대응했다.
이후 Playwright를 사용해 AI가 브라우저를 직접 열고 테스트하도록 만들면서, 사람이 하던 검증 절차도 AI에게 맡길 수 있음을 깨달았다.
이 사례는 AI의 한계라고 생각했던 것 중 일부가 실제로는 사용자가 지시하지 않았기 때문에 발생한 한계였음을 보여준다.

3. AI Native 사고는 절차 전체를 위임하는 방식이다

작성자는 AI를 단순 보조 도구로 쓰는 관점에서 벗어나, 자신이 하던 절차 전체를 AI가 수행하게 만드는 방향으로 전환한다.
반복 작업을 커맨드, 스킬, 워크플로우로 만들고, 자신의 암묵지를 명세화하려고 시도한다.
예시로 /plan, /prd, /debug, /refactor, /verify, /retrospect 같은 명령 흐름을 만든다.
중요한 점은 AI에게 단순히 “코드를 짜라”고 하는 것이 아니라, 언제 질문하고, 언제 멈추고, 언제 검증할지까지 규칙화하는 것이다.
이를 통해 개발자는 자신의 작업 방식과 판단 기준을 AI가 재사용할 수 있는 구조로 바꾸게 된다.

4. 개인 노하우는 빠르게 도구 기능으로 흡수된다

작성자가 직접 만들던 커맨드와 워크플로우는 시간이 지나면서 Skill, memory, hooks, orchestration 같은 공식 기능과 개념으로 등장한다.
개인이 발견한 AI 활용 방법론은 효과가 있을수록 빠르게 제품 기능이나 공통 방법론으로 흡수된다.
따라서 AI를 잘 쓰는 특정 프롬프트나 팁만으로는 장기적인 차별화를 만들기 어렵다.
중요한 것은 방법론 자체보다, 그 방법론을 실제 문제에 적용해 어디까지 만들어보고 어떤 한계를 경험했는가이다.

5. AI는 개발자가 다룰 수 있는 문제의 크기를 키운다

AI는 작성자가 과거에는 비용과 시간 때문에 시도하지 못했던 대형 아이디어를 실제로 실험하게 만든다.
예를 들어 코드와 문서를 캔버스처럼 펼쳐보는 도구, MD 뷰어, 코드 분석 도구, 개발 보조 도구 등을 빠르게 만들어본다.
핵심은 AI가 완성품을 즉시 만들어준다는 것이 아니라, 시작의 허들을 낮춰준다는 점이다.
개발자는 “이걸 만들 수 있을까?”에서 “일단 어디까지 만들어볼 수 있을까?”로 사고를 전환하게 된다.

6. 큰 문제를 다루면 코딩 외의 개발 업무가 드러난다

AI로 코드 생산량이 증가하면, 개발자는 모든 코드를 직접 읽고 맥락을 머릿속에 저장하기 어려워진다.
직접 코딩할 때는 자연스럽게 축적되던 맥락, 판단, 구조 이해가 AI에게 코딩을 맡기면 자동으로 남지 않는다.
따라서 문서, 테스트, 이슈, 작업 보고서, 변경 이유 기록이 중요해진다.
이는 관리 업무가 아니라, AI 시대에 개발 맥락을 유지하기 위한 핵심 장치가 된다.
코딩 능력만큼이나 맥락과 판단을 보존하는 능력이 중요해진다는 점이 강조된다.

7. 커밋과 테스트 증가가 곧 제품 개선은 아니다

AI를 활용하면 커밋, 파일, 테스트, 문서의 수는 빠르게 늘어난다.
그러나 수치가 증가한다고 해서 제품이 실제로 좋아지는 것은 아니다.
기능은 추가되지만 UX가 어색하거나, 테스트는 통과하지만 실제 화면 흐름이 불안정한 문제가 발생한다.
작성자는 처음에는 이를 코드 품질과 구조 문제로만 보려 했다.
하지만 코드 구조를 개선해도 제품 경험이 자동으로 좋아지지는 않는다는 점을 경험한다.
결국 코드 생산과 제품 개선은 다른 문제이며, 제품성에 대한 판단이 별도로 필요하다.

8. 프론트엔드는 AI가 특히 흔들리기 쉬운 영역이다

AI는 대시보드, 랜딩 페이지, 관리자 화면처럼 그럴듯한 초기 UI를 빠르게 만들 수 있다.
그러나 실제 제품 수준의 프론트엔드는 디자인 시스템, 상태 관리, 접근성, 키보드 조작, 예외 상태, 사용자 흐름 등 복잡한 기준을 요구한다.
프론트엔드의 많은 요구는 “자연스럽게”, “덜 어색하게”, “선택된 느낌이 나게”처럼 모호한 언어로 표현된다.
AI는 이런 모호한 요구를 코드로 바꾸는 과정에서 결과가 쉽게 발산한다.
따라서 프론트엔드에서 AI를 잘 쓰려면, 잘 나온 부분은 고정하고 부족한 부분만 다시 수정하게 만드는 기준과 판단력이 필요하다.

9. 좋은 결과물은 한 번에 나오지 않고 수렴 과정을 통해 만들어진다

작성자는 한 기획자가 AI로 만든 완성도 높은 프로토타입을 보고 인식을 바꾼다.
그 결과물은 특별한 프롬프트 하나로 만든 것이 아니라, “될 때까지” 반복적으로 수정한 결과였다.
이 사례는 AI 활용의 핵심이 단순한 자동 생성이 아니라, 부족한 부분을 계속 보고 다시 요구하는 수렴 과정임을 보여준다.
좋은 결과를 만드는 사람은 AI가 만든 산출물에서 무엇이 부족한지 판단하고, 원하는 수준이 나올 때까지 집요하게 조정한다.
AI 시대에도 사람의 기준, 감각, 지속적인 검수가 결과물의 차이를 만든다.

10. 개발자는 가능성 있는 결과물을 제품으로 이어주는 역할을 맡는다

AI로 만든 결과물은 겉보기에는 좋지만 내부 코드 구조가 취약할 수 있다.
상태 관리가 불안정하거나, 컴포넌트 책임이 모호하거나, 테스트가 실제 흐름을 보장하지 못하는 문제가 생긴다.
개발자의 역할은 이런 결과물을 무조건 낮게 평가하거나 폐기하는 것이 아니다.
동시에 그대로 제품화해서도 안 된다.
개발자는 가능성 있는 결과물이 더 멀리 갈 수 있도록 구조를 정리하고, 위험을 표시하고, 테스트 가능한 단위를 만들고, 맥락을 남겨야 한다.
즉, 개발자는 “끝까지 혼자 만드는 사람”에서 “AI와 사람이 만든 결과물을 지속 가능한 제품으로 이어주는 사람”으로 역할이 확장된다.

11. AI 시대의 개발 역할은 하나로 수렴하지 않는다

코딩의 허들이 낮아지면 개발에 참여하는 사람의 유형도 다양해진다.
기획자, 디자이너, PM, 현업 담당자도 AI를 통해 동작하는 프로토타입이나 내부 도구를 만들 수 있다.
이는 개발자의 필요성이 사라진다는 뜻이 아니라, 개발과 관련된 역할이 더 세분화된다는 의미다.
작성자는 이를 유튜브 생태계에 비유한다.
유튜브가 영상 전문가를 없앤 것이 아니라 출연자, 편집자, 기획자, 채널 운영자, 플랫폼 제작자 등 역할을 다양화한 것처럼, AI도 개발 역할을 다양화할 수 있다.
앞으로는 깊은 시스템을 만드는 사람, 프로토타입을 제품으로 다듬는 사람, AI가 잘 작업할 수 있는 레이어를 만드는 사람, 문제를 직접 해결하는 사람이 공존할 가능성이 크다.

결론

개발자는 코딩 이후의 개발을 설계해야 한다

게시글의 결론은 “코딩을 계속해야 하는가, 내려놓아야 하는가”라는 이분법이 아니다.
AI가 코딩을 수행할 수 있게 된 만큼, 개발자는 AI에게 무엇을 맡기고 무엇을 직접 판단해야 하는지 경험적으로 익혀야 한다.
특히 다음 역량이 중요해진다.
- 문제를 더 크게 설정하는 능력
- 반복 절차를 스킬과 워크플로우로 만드는 능력
- 요구사항, 문서, 테스트, 이슈를 구조화하는 능력
- AI 산출물을 검수하고 부족한 부분을 재지시하는 능력
- 거친 결과물을 지속 가능한 제품으로 다듬는 능력
- 코드 밖의 도구와 업무 흐름까지 AI와 연결하는 능력

핵심 메시지

AI는 개발자의 기대만큼 완벽하지는 않지만, 생각보다 훨씬 많은 일을 수행할 수 있다.
AI가 못한다고 판단하기 전에, 실제로 어디까지 시킬 수 있는지 실험해야 한다.
반대로 AI가 쉽게 해준다고 해서 결과물을 그대로 신뢰해서는 안 된다.
개발자는 AI가 만든 결과를 판단하고, 수렴시키고, 맥락을 보존하며, 제품으로 이어지게 만드는 역할을 맡아야 한다.
결국 AI 시대의 개발자는 코드를 직접 많이 쓰는 사람이라기보다, AI와 사람이 만든 산출물이 더 나은 결과로 이어지도록 문제·절차·기준·맥락을 설계하는 사람에 가까워진다.