이번 글은 Software engineer로서 최근의 급격한 AI 기술 발전에 따른 개발자로서의 역할 변화에 대해 제가 느끼는 점을 설명합니다.

AI를 software 개발에 적용하는 것을 부르는 다양한 언어가 있습니다.

• AI-Assisted Development
• AI-Driven Development
• Vibe Coding
• AI Augmented Coding

이 글에서는 AI dev 라는 축약어로 설명하겠습니다. 그리고 이러한 개발 방법론을 도와주는 서비스를 AI coding service 라고 명명하겠습니다.

이 글은 기술적인 내용을 다루지 않습니다. AI 코딩 툴이나 서비스를 간략하게 언급은 하겠지만 상세한 사용 방법이나 노하우를 공유하는 글은 아닙니다.

---

나의 AI dev 경험

Github Copilot

AI가 되긴 되는구나?

저의 첫 AI coding service 사용은 Github Copilot부터 시작되었습니다. 이때는 아직 LLM 기술도 지금같은 성능이 아니었고 특히나 Reasoning model이 없던 상황이었습니다. 그래서 간단한 코드 snippet을 자동완성 해주는 기능을 주로 사용했습니다.

AI에 대해 특히나 LLM에 대해 아직은 반신반의 할 때였는데, 자동완성 되는 코드를 보고 상당히 놀랐던 기억이 납니다. 지금이야 자동완성, 코드 추천이 흔하게 사용되기 때문에 그렇지만 이때까지만 해도 내가 코드를 몇 글자 적지도 않았는데 화면에 완성된 형태의 코드가 (내가 작성하지 않았는데) IDE에 추천되는 것을 보면서 와 세상이 정말 바뀌긴 하겠구나 하면서 놀랐던 것입니다.

내가 작성하고자 하는 코드를 머릿속에 그리고 한글자씩 타이핑 해나갈 때, 이것을 신기하게 읽어내고(물론 이것은 확률 기반 다음 글자 생성이겠지만요) 추천해주면 저는 단지 Tab 키를 눌러서 완성합니다. 그 자체로 코드 작성을 끝낼 때도 있고 완성된 전체 코드 중에서 몇 부분만 수정하기도 합니다. 이 과정이 꽤 즐거운 과정이 되었습니다. 코드 구현을 빠르게 할 수 있기 때문입니다.

ChatGPT

사람의 말로 코드를 구현하는 첫번째 경험

ChatGPT가 출시되고 나서 한 동안은 사용하지 않다가 대략 2023년 말~2024년 초부터 사용해보기 시작했었습니다. 브라우저를 통한 채팅 인터페이스의 한계가 있기 때문에 복잡한 기능이나 정밀한 코드 보다는 간단한 함수 단위의 코드 작성을 주로 ChatGPT와 같이 했었습니다.

프롬프트로 코드가 작성되는 것을 실시간으로 보면서 굉장히 놀랐던 기억이 있습니다. 지금은 이러한 것에 무뎌졌습니다만 이때는 신기하기도 했고 어설픈 측면이 있어서 조금은 안도하기도 했던 경험이었습니다. 그 이후로도 사실 ChatGPT는 아주 가끔씩 개발할 때 사용하곤 합니다. 잘 모르는 분야(ex: shell script)의 아주 간단한 스크립트를 작성할 때 유용하게 사용하고 있습니다.

Cursor

일 하는 방식을 바꿔야겠다고 생각한 첫번째 서비스

ChatGPT나 Claude(Web) 같은 채팅 인터페이스를 통해 코드를 생산하더라도 어쨌건 기능을 구현하기 위해서는 IDE로 해당 코드를 가져와야 합니다.

이 불편함을 약간이나마 해소해줬던 것이 사실은 VS Code+Cline 조합이었습니다. VS Code에 Cline plugin을 설치하고 OpenAI나 Gemini API key를 설치하면 자연어로 코드를 실시간으로 만들고 관리할 수 있기 때문입니다. 이때서야 비로소 AI coding service 라고 부를 수 있는 서비스가 나왔다고 생각했습니다. 한 곳에서 모든 작업을 완성할 수 있기 때문이었습니다. 하지만 이 조합이 저에게는 잘 맞지 않았습니다. 인터페이스 측면에서도 사용하기 좋지는 않았고 자연어로 만든 코드의 품질도 썩 뛰어나지는 않았기 때문입니다.

하지만 IDE와 LLM을 바로 연결해서 사용한다는 아이디어 자체는 훌륭한 것이었고 시장에 이미 몇몇 서비스들이 출시되고 있었습니다. Cursor는 제가 선택한 IDE+LLM 조합의 두번째 AI coding service였습니다.

Cursor를 사용하면서 특히 깊은 인상을 받았던 것은 VS Code+Cline 조합을 사용하면서 느꼈던 불편함들이 모두 해소되었다는 것이었습니다. 사용자 인터페이스 관점에서 Cursor는 매우 훌륭했고 여기에 더해 자연어로 코드 작성을 지시하고 검토하고 그것을 실제 코드에 반영하는 일련의 과정에서 output의 품질이 상당히 좋았습니다.

다만 한 가지 치명적인 단점이 있었습니다. 저는 Java(Kotlin)을 주로 사용하는 Back-end engineer입니다. 그리고 Cursor는 VS Code 기반으로 만들어졌습니다. VS Code는 Java, Spring Boot와 같은 Back-end 쪽 기술에 아주 특화된 IDE는 아닙니다. 물론 설정을 하면 쓸 수는 있지만 IntelliJ와 같은 전용 툴에 비하면 부족한 점이 많습니다. 그래서 Cursor와 IntelliJ를 동시에 띄워놓고 왔다갔다 하면서 Cursor에서는 자연어로 코드를 만들고 IntelliJ에서는 코드를 검토하거나 제가 직접 작성하는 방식으로 일을 했었습니다. 이것은 상당히 좋지 못한 DX(Developer Experience) 경험이었습니다.

하지만 지금도 여전히 Cursor를 유료로 구독하여 사용하고 있습니다. Cursor는 제가 처음으로 AI dev에 대해 진지하게 생각해준 서비스였습니다. 사내에 도입하는 프로젝트를 진행해서 개발팀 전원을 대상으로 유료 구매도 하고 Cursor 사용 방식에 대한 세미나도 열었었습니다. 그리고 이 과정에서 단순히 IDE나 툴을 구매하는 것에서 벗어나 일 하는 방식 자체를 바꿔야겠다고 생각하게 되었습니다.

Claude Code

드디어 발견한 나의 최종 병기

이 글을 적는 현재 시점(2025년 11월)까지 사용했던 모든 AI Agentic coding 서비스 중에 제일 잘 사용하고 있는 것이 바로 Claude Code입니다.

Anthropic에서 만든 Claude는 모델 자체의 성능도 좋지만 Claude와 연계하여 사용하는 Claude Desktop(Web)과 Claude Code의 사용 경험이 상당히 좋습니다. 사람의 말을 찰떡 같이 알아듣고 답변한다는 느낌이랄까요.

특히 Claude Code는 사용할때마다 정말 잘 만들었다 라는 감탄이 나올 정도입니다. 특히 자유도와 자율성이라는 측면에서 지금까지 사용해왔던 여러 AI dev 경험 중에서 압도적인 강점을 갖고 있습니다. CLI 라는 환경의 특성상 Current working directory 기준으로 거의 모든 작업이 가능합니다.

Claude Code를 사용하면서 제가 느끼기 시작했던 것은 단순히 코딩뿐만 아니라 어쩌면 개발자가 하는 모든 일에 이것을 적용해볼 수 있겠다였습니다. 처음 Claude Code가 출시하자마자 사용하기 시작했는데 첫번째 버전 이후로 엄청나게 빨리 기능이 개선되었습니다. 그리고 그 개선된 기능을 하나씩 사용해보면서 저는 Anthropic이 이 서비스를 통해 무엇을 하고 싶은지 그리고 어떤 미래를 그리는지 조금은 알 것 같았습니다.

인간의 작업을 단순히 옆에서 도와주는 툴이 아니라 일정 부분은 대체하고 어쩌면 완전히 인간을 대체할 수도 있는 AI Agent.

이것이 Claude Code를 사용하면서 제가 느꼈던 이 서비스의 최종 목표입니다. 하지만 Claude Code의 공식 영상이나 문서를 보면 인간을 완전히 대체할 것이다 라는 언급은 전혀 하지 않고 인간을 도와주는 성격이다 라고는 하고 있습니다.

Copilot부터 ChatGPT, VS Code+Cline, Cursor, Cladue Code까지 거쳐오면서 제가 느낀 것은 AI dev 서비스가 일정한 방향으로 발전해오고 있다는 것입니다. 첫 등장이 인간을 도와주는 비서의 느낌이었다면 이제는 인간이 하는 일의 일정 부분을 믿고 맡길 수 있는 co-woker의 느낌입니다.

인간을 완전히 대체하는 시대는 아직 오지 않았고 근미래에도 오지 않는다고 가정한다면, 지금 현재 시점에서 개발자의 역할은 어떻게 변해야 할까요? AI 서비스를 사용해오면서 이 질문이 자연스럽게 머릿속에 생겨나게 되었습니다.

---

개발자의 역할은 어떻게 변해야 할까요?

코드 작성자에서 코드 리뷰어로

잘 작성된 PRD.md 문서가 있고 여기에 더해서 현재 Task에 대한 상세한 Prompt를 Claude Code(기타 다른 서비스를 포함하여)에게 전달한다는 가정하에, 현재 개발자가 소스 코드 작성을 하는 방식은 크게 2가지가 있다고 생각합니다.

1. 사람에게 코드 작성의 주도권이 있습니다. AI는 사람이 작성한 코드를 읽고 side effect에 대해 분석하거나 테스트 코드 작성을 담당합니다.
2. 코드 작성의 주도권이 AI에게 있습니다. 비즈니스 로직은 AI가 작성하고 사람이 리뷰합니다.

여기서 중요한 것은 가정 부분입니다. 명확하게 정의된 Spec, PRD 문서가 있어야 합니다. 그리고 내가 지금 작업하는 Task, Story에 대한 상세한 지침이 담겨 있는 프롬프트를 작성할 수 있는 능력이 필요합니다. 이 가정이 충족된 상태에서 개발자는 1번과 2번 중에 하나를 택할 수 있습니다.

그리고 1번이나 2번 방식 중에 어떤 것을 선택하건 간에 실제 코드 작업 이전에 Plan을 세워야 합니다. 이 Plan을 세우는 것은 AI와 사람이 함께 협력해야 합니다. Plan을 세워야 AI가 작업하는 도중에 길을 잃지 않게 할 수 있습니다. 현재의 LLM은 특성상 Stateless 하기 때문에 초반부에 강력한 지침으로서 Plan을 만들고 이것을 따르게 해야 하는 것입니다.

여기까지의 조건이 모두 충족된 상태로 Claude Code와 같은 AI agentic coding service와 함께 개발하게 되면 아무래도 2번 방식으로 진행하게 될 가능성이 높습니다. 이러한 유형의 서비스는 근본적으로 코드를 작성하는 역할을 수행하게끔 만들어졌습니다. 그래서 끊임없이 코드 작성을 시도하고 사람에게는 이것을 허락해달라고 요청합니다.

즉, 애초의 서비스 설계 방향 자체가 코드 작성을 AI가 주도하고 사람에게는 중간 중간 확인을 요청하도록 하게끔 되어 있는 것입니다. 물론 선택에 따라서 아예 중간 확인 절차조차도 생략하고 AI에게 처음부터 끝까지 코드 작성을 하도록 풀어줄 수도 있습니다.

이 지점이 개발자로서 매우 중요한 순간이라고 생각합니다. 이 두가지 방식 중에 하나를 선택해야만 합니다. 물론 하나의 Task를 구현할 때, 이 두가지 방식을 모두 사용할 수도 있습니다. 간단하지만 번거로운 코드는 AI가 작성하게 하고 중요하고 신경써서 작성해야 하는 코드는 사람이 담당하는 것입니다. 그러나 어쨌건 아주 작은 단위의 Task를 작업할 때는 둘 중의 하나를 택해야만 합니다. 그리고 AI 기술의 발전 속도와 방향성을 볼 때 이 작업의 위임은 점점 더 많아질 것이라고 예상합니다.

소스 코드 작성자보다는 AI가 작성한 소스 코드를 리뷰하고 이 산출물이 제대로 되었는지 검증하는 리뷰어로서 보내는 시간이 점점 더 많아지고 있다는 것을 요즘들어 체감하고 있습니다. 조금 더 정확하게 말하자면 Task의 최초 단계에서 AI와 같이 Plan을 만들고 그 이후 소스 코드 작성은 모두 AI에게 일임합니다. AI가 작업을 끝내면 저는 IDE에서 diff 기능을 활용하여 산출물을 읽어가면서 기능이 제대로 구현되었는지 평가합니다. 한번에 Task가 완료되는 경우도 있고 그렇지 못한 경우는 상세하게 어떤 부분을 어떻게 개선해야 하는지 프롬프트를 작성하여 다시 AI에게 작업을 지시합니다.

이렇게 일 하는 방식을 바꾼지 이제 2달 정도 되어가는 것 같습니다. 아직도 완전히 적응했다는 느낌은 아닙니다. 그런데 중요한 것은 확실히 개발 속도가 빨라졌고 Back-end side 작업 뿐만 아니라 Front-end side 작업도 큰 문제 없이 수행하고 있습니다. 이것은 제가 올해 초부터 FE쪽 기술 공부를 꾸준히 해왔기 때문에 지금 와서 빠르게 적응할 수 있다고 생각합니다. 만약 React, Vite, FE Build 등에 관한 지식이나 경험이 없었다면 아무리 AI를 사용했어도 실제 회사 업무까지 제가 FE 개발을 담당하는 것은 쉽지 않았을 것입니다.

개인 플레이어에서 AI Orchestrator로

AI 기술을 Workflow에 적용하는 구체적인 사례 중에 범용적이면서도 어쩌면 많은 효과를 볼 수 있는 것은 하나의 Team을 AI로 대체하는 것입니다. 사람이 전체 Workflow의 부품으로서 작동하는 것 보다는 Team lead 역할만 수행하고 실제 구체적인 세부 작업은 AI가 담당하도록 하는 것입니다.

개발자로서는 일종의 개발 Team을 만드는 것입니다. 이 방식은 AI dev 툴이 최근에 지원하기 시작한 Custom command와 Sub-agent(Claude Code 기준) 같은 기능들을 활용하여 더 효과적으로 적용해볼 수 있게 되었습니다. 단순히 일을 도와줄 수 있는(Supportive) 도구가 아니라 실제로 작업 자체를 완성할 수 있을 정도로 AI 기술이 발전했기 때문에 AI agent로 Team을 만들고 작업을 '위임'할 수 있게 된 것입니다.

이 지점에서 몇가지 생각해볼 것들이 있습니다:

• Team을 잘 만드는 것 자체가 능력이 되었습니다. Team을 효율적으로 구성하고 각 Team member AI에게 명확한 역할과 지침을 부여해야 합니다.
  • 구성을 어떻게 할 것인가부터 고민해야 합니다. FE+BE로 구성된 작은 팀을 만들 수도 있고 PM+FE+BE+QA+Designer로 구성하여 Product을 처음부터 완성 단계까지 모두 담당할 수 있는 팀을 만들 수도 있습니다. 또는 Code reviewer+Refactoring engineer+Test code writer로 구성된 팀을 만들어 놓고 실제 비즈니스 로직은 내가 작성할 수도 있습니다. 아예 팀 구성을 Functional Reviewer+Performance reviewer+Security Code Reviewer+Readability Reviewer로 하여 오로지 코드 리뷰만 담당하도록 할 수도 있습니다.
  • 구성뿐만 아니라 개별적인 작업 담당자 AI를 명확히 정의하는 것도 굉장히 중요합니다. 작업자 AI의 description, 어떠한 상황에서 해당 작업자 AI가 일을 시작해야 하는지, 어떤 Tool을 호출할 수 있는지, 어떤 기준에 의해서 일을 해야 하는지 등등을 정의해줘야 합니다.
• 일 하는 방식 자체를 근본적인 단계부터 바꿔야 합니다.
  • 코드 작성 뿐만 아니라 개발자로서 회사에서 일 하는 모든 단계에 AI를 도입할 수 있어야 합니다. PRD 기반으로 Task를 분석하고 설계를 하고 일정을 산정하고 DB schema를 설계하고 기술적인 의사결정들을 하고 API를 설계하고 비즈니스 로직을 구현하고 테스트 코드를 작성하고 Alpha, QA 환경에 배포하기까지의 이 모든 과정에 AI를 개입시켜야 하는 것입니다.
  • AI에게 작업을 일임하는 것을 자연스럽게 느끼고 이것을 하루하루 일 하는 루틴에 자연스럽게 녹여내야 합니다. 기존과 동일한 방식을 계속 고수한채로 부분적으로만 AI를 도입하는 것은 효과를 체감하는 데 있어서 상당히 제한적입니다.
• 기업/팀 차원에서 이러한 새로운 방식의 Workflow를 지원해야 합니다.
  • 개인으로서 일을 하는 기존 방식에서 벗어나 한 명의 작업자가 여러 역할을 동시에 수행할 수 있게 되었습니다. 이는 회사 또는 팀 차원에서 직원들의 역할 정의를 다시 해야 한다는 것을 의미합니다.
    • 만약 어떤 Front-end engineer가 본인이 직접 공부도 좀 해보고 경험도 좀 쌓고 해서 FE와 BE 역할을 동시에 해보겠다고 한다고 가정해봅시다. 이는 과거 AI dev가 지금과 같지 않았을 때와 전혀 다른 상황입니다. 실제로 실행해봄직한 상황이 되었다는 것입니다.
    • Engineering team이 있고 하위에 FE, BE 팀이 따로 있는 조직이라면 이와 같은 상황을 어떻게 마주해야만 할까요? 위에 예시로 든 Engineer를 FE, BE팀에 각각 동시에 소속되도록 조치해야 할까요? 아니면 조직 구조 자체를 개편해야 할까요? 지금은 한 명이지만 만약 내일 더 많은 개발자들이 본인의 역할에 대해 기존과 다른 방식으로 접근한다면?
  • Product을 기획하고 만드는 과정도 변해야 합니다. AI가 쉽게 문서를 읽고 후속 문서를 생산할 수 있게끔 해야 합니다. AI에게 Context로 제공하는 문서에 과도한 이미지나 이모지 또는 테이블 구조 같은 것은 지양하는 것이 좋습니다.
    • 의사결정 과정에서 중간 중간 문서 만드는 습관을 들여야 합니다. 특히 회의에서 정한 것들은 꼭 Meeting minutes 문서로 정리해서 공유해야 합니다. 그리고 언제든지 이 문서들이 AI dev 서비스나 툴에서 조회할 수 있도록 사전에 설정을 해놔야 합니다. 최근에는 MCP 기술이 성숙해가고 있습니다. Confluence, Jira, Slack, Notion 등 문서를 다루고 관리하는 서비스에 MCP 설정을 미리 해놓고 작업자들이 쉽게 사용할 수 있도록 내용을 전파하고 지속적으로 관리해야 합니다.

---

그래서 어떻게 변하게 될까요?

역할의 변화

지난 몇년 간 AI 기술을 개발 workflow에 도입하면서 느꼈던 것을을 종합하여 제가 최근에 내린 결론은 다음과 같습니다. 아마 앞으로 크게 3가지 줄기로 개발자의 역할이 분화되지 않을까 싶습니다.

1. 본질에 집중 (전문성 심화)

며칠 전 팀의 다른 Back-end engineer와 Claude Code에 대해 이야기를 나눠볼 기회가 있었습니다. 확실히 생산성 향상을 체감하고 있고 본인의 경우 코딩 하는 시간을 줄이고 그 남은 시간을 좀 더 본질적인 부분에 쏟고 있다고 했습니다. API 설계, DB table schema 구조 설계, 성능이나 보안 측면에 좀 더 신경쓴다는 것이었습니다.

저는 어쩌면 이것이 개발자의 자연스러운 역할 변화의 첫번째 양상이 되지 않을까 생각합니다. 너무나 자연스러운 것이죠. 코드 작성에 시간을 덜 들이게 되면서 우리가 개발이라고 부르는 영역의 나머지 부분에 더 집중할 수 있게 되는 것입니다.

2. Full-stack engineer로 진화

저는 이러한 변화 역시 자연스럽게 다가올 것이라고 생각합니다.

본인의 업무 영역을 더 넓히는 것입니다. Back-end engineer가 Front-end 관련 언어와 기술을 습득하고 약간의 적응 기간을 주고 나서는 본인의 포지션을 Full-stack engineer로 정의하고 일할 수 있게 해주는 것입니다. 또는 다른 방향(Front-end engineer ➡️ FSE, Mobile Engineer ➡️ FSE) 역시 가능할 것입니다.

3. Product Engineer로 진화

마지막 제가 예측하는 한 가지 분화는 Product Engineer로 본인의 경계를 확장하는 것입니다.

What is a Product Engineer?

이것은 기술적인 영역 뿐만 아니라 문제를 정의하고 어떤 방식으로 문제를 풀 것인지 결정하는 것까지를 업무의 영역으로 포함하는 것입니다. 개발자는 이미 정해진 문제를 어떻게 풀 것인지를 결정하는 사람에 가깝습니다. 그러나 Product Engineer는 사고 방식 자체를 전환하여 문제를 정의하는 단계부터 시작해야 합니다. 고객의 어려움을 발굴하고 여기서 문제를 인식하여 최종 Product을 만들기까지의 모든 과정에 관여합니다. 어쩌면 Product을 만든다 라는 개념에 한정했을 때 가장 궁극의 난이도에 도전하는 것이라 볼 수 있겠습니다.

이 3가지 큰 줄기에 대해 조만간 좀 더 자세히 글로 공유할 수 있을 것 같습니다. 아직까지는 제 머릿속에서 추상적으로 맴돌고 있는 것을 글 작성이라는 과정을 통해 좀 더 구체화 할 수 있기를 바랍니다.

---

이 글에서는 AI 시대 개발자(Software engineer)의 역할에 대해 고민해봤습니다. 이 고민은 지난 몇년, 특히 최근 1년 동안에 깊게 해왔던 것입니다. 그리고 앞으로도 이 고민은 계속될 것 같다는 생각이 듭니다.