목차

목차를 생성하는 중...

2.2. AI 에디터 활용 사례 및 개발 생산성

개발은 단순한 코딩을 넘어 도메인을 분석하고 문제를 정의한 뒤, 그에 대한 해법을 설계하는 일련의 프로세스를 뜻합니다. 그러나 설계된 솔루션을 실제로 구현하기 위해서는 수만 줄에 이르는 코드를 작성해야 했고 언제나 반복적인 작업, 장황한 설정, 그리고 끝없이 이어지는 검색과 시행착오가 뒤따랐습니다.

결국 개발이라는 프로세스의 대부분은 아이러니하게도 ‘코드를 짜는 일’에 집중될 수밖에 없었고, 그 안에는 본질적으로 비생산적인 시간들이 숱하게 포함되어 있었습니다. 이처럼 누구나 한 번쯤은 겪었을 이 비효율의 시간은 오랫동안 어쩔 수 없는 현실로 받아들여져 왔습니다.

그러나 이제 그 전제가 흔들리고 있습니다. AI의 등장이 개발 생태계를 바꿔놓고 있기 때문입니다. 개발자는 더 이상 혼자 모든 코드를 타이핑하거나, 웹을 뒤져가며 해결책을 찾아다닐 필요가 없어졌습니다.

AI는 작성 중인 코드의 맥락을 이해하고, 다음에 이어질 코드를 제안하며, 필요한 주석과 테스트 코드까지 생성해주는 지능적인 페어 프로그래머로 진화하고 있습니다. 더 나아가 코드 작성이라는 행위뿐 아니라 코드 리뷰와 피드백 과정까지도 AI가 주도적으로 처리하려는 시도들이 현실화되고 있습니다.

이 변화는 단순히 도구의 편리함을 넘어, 개발 생산성의 패러다임 자체를 전환시키고 있습니다. 이 파트에서는 AI 도구들이 코드 생산성에 어떤 영향을 미치고 있는지 다각도로 살펴보려 합니다. 동시에, 현재 AI 도구가 어떤 식으로 개발자의 작업을 지원하고 있는지 살펴보고 이 변화의 흐름 속에서 개발자는 어떻게 대응해야 진정한 생산성 극대화를 이룰 수 있는지도 함께 고민해보고자 합니다.

2025년 AI 에디터 분류 유형

AI가 개발 현장에 본격적으로 도입되기 시작한 것은 2021년, GitHub Copilot의 등장이었습니다. 당시만 해도 AI는 코드의 다음 줄을 예측하거나, 간단한 함수 수준의 자동 완성 기능을 제공하는 데 그쳤지만, 이 초기 모델은 개발자의 생산성을 획기적으로 높일 수 있다는 가능성을 널리 알리는 데 성공했습니다. 이후 다양한 기업과 커뮤니티가 이 가능성에 주목하면서 AI 기반 개발 도구들이 우후죽순 등장하게 됐습니다.

특히 이 변화를 가속화한 것은 LLM의 급속한 발전이었습니다. 현재의 LLM은 단순한 자연어 처리 기술이 아닙니다. ‘추론’ 능력을 지닌 사고 모델입니다. 덕분에 AI는 이제 단순한 코드 조각 생성기를 넘어, 전체 문제의 맥락을 이해하고 그에 맞는 실행 계획을 세우며, 결과에 대한 자가 피드백까지 수행할 수 있는 수준에 이르렀습니다. 요컨대 AI는 더 이상 개발자를 보조하는 도구만이 아니라, 업무 수행을 스스로 주도하는 에이전트로 진화한 것입니다.

이러한 변화를 목도하며 누군가는 ‘개발의 종말’이라는 과격한 화두를 꺼냅니다. 실제로 현재의 AI 도구들은 단지 코드를 자동 완성하는 것을 넘어서, 프로젝트 구조를 분석하고, 이슈를 감지하고, 필요한 수정을 제안하는 수준에 도달했습니다. 그래서 이러한 화두가 나오는 것이 전혀 맥락없는 것은 아니라는 생각이 듭니다.

하지만, 아직 일어나지 않은 일에 대해 미리 불안을 느끼고 과도한 걱정과 부정적 미래를 상상하는 것 역시 인간의 본성이기 때문에, AI와 관련되어 지나치게 디스토피아적인 미래만 생각하는 것도 경계해야 합니다.

그렇기 때문에 불확실성이 높은 지금의 개발 시장에서 택할 수 있는 가장 현명한 태도는 현재를 아는 것입니다. 따라서 이번 파트에서는 현재 주목받는 다양한 AI 개발 도구들을 살펴보고, 이를 4가지 분류로 나눠, 각 도구가 추구하는 방향과 특징을 살펴보고자 합니다. 더불어 이러한 도구들이 개발자의 생산성을 향상시키는 데 어떤 기여를 하고 있으며, 이러한 도구들을 효과적으로 활용하기 위해서는 어떤 전략이 필요한지도 함께 고민해보고자 합니다.

[2025년 AI 에디터 4분류]

  • A. 소극적인 개발 보조형
  • B. 적극적인 개발 보조형
  • C. 대화형을 지향하는 개발 주도형
  • D. 노코드를 지향하는 개발 주도형

A. 소극적인 개발 보조형

AI 개발 도구의 초창기를 이끈 주인공은 단연 GitHub Copilot과 Tabnine이었습니다. 이들은 기존 개발 환경에(예: VSCode나 IntelliJ) 플러그인으로 탑재되어, 코드 작성 중 자동 완성 기능을 제공하며 개발자의 손을 덜어주는 데 주력하는 것으로 개발됐습니다. 혹은 부수적인 기능으로 AI 채팅을 제공하기도 했습니다.

플러그인으로 설치할 수 있는 copilot

이런 도구들은 GPT의 동작 방식과 마찬가지로 코드의 문맥을 부분적으로 이해하고, 다음에 이어질 코드를 예측하는 방식으로 작동했습니다. 예컨대 개발자가 비즈니스 로직이 담긴 주석을 남기거나 함수의 시그니처를 작성하면 그 뒤에 나오는 내부 구현을 LLM이 만들어주는 방식으로 동작한 것입니다. 당시만 해도 이는 상당한 혁신이었고 반복 작업으로 피로감을 느끼고 있던 개발자들에게 이 소식은 큰 환영을 받았습니다.

하지만 LLM이 고도화됨과 함께 더 적극적인 개입이 가능한 도구들이 등장하면서, 혁신을 주도했던 도구들은 이제 상대적으로 ‘소극적인’인 개발 도구가 됐습니다. 그래서 이런 도구를 ‘소극적인 개발 보조형’이라는 이름으로 분류했습니다. 이 유형의 도구들은 ‘개발자가 개발하고 AI 도구가 보조하는 형태’를 주된 컨셉으로 삼고 있습니다.

이 유형의 아쉬운 점이라면 기능이 제한적이거나 개발자의 명시적인 입력에만 반응하는 구조라는 것입니다. 또한 코드의 전반적인 흐름보다는 국소적인 코드 블록 단위로 작동한다는 점에서 확장성에 한계를 보이고 있다는 점입니다. 그럼에도 불구하고 Copilot 같은 도구들은 안정성과 여러 ‘Copilot과 생산성 향상’이라는 보고 사례들로 입증된 탄탄한 기반을 무기로 널리 사용되고 있습니다.

참고: 현재 Copilot은 강력한 경쟁자인 Cursor의 등장으로 경쟁력을 강화해 점차 이 분류에서 벗어나고 있습니다.

B. 적극적인 개발 보조형

‘소극적인 보조’의 한계를 극복하기 위해 등장한 것이 Cursor, Windsurf, Trae, Void¹ 등과 같은 AI 에디터²들입니다. 이 유형의 도구들은 ‘개발자가 개발하고 AI 도구가 적극적으로 보조하는 형태’를 띄는 경우가 많습니다.

이 도구들은 단지 자동 완성을 넘어서 코드 리팩토링, 문맥 기반 제안, 규칙 관리 등 다양한 방식으로 개발 과정을 지원합니다. 예전처럼 단순한 플러그인으로 부분적인 기능을 제공하는 것이 목표가 아니라 에디터 자체에 AI가 녹아들어 있는 것입니다. 그렇기 때문에 ‘AI 기능을 중심으로 재설계된 IDE’라 할 수 있습니다.

적극적인 코드 리팩토링을 제안하는 Cursor AI

많은 개발자들이 여러 AI 도구들 중에서도 이 유형의 도구를 좋아하며, 특히 Cursor를 애용하고 있는 것으로 생각됩니다. 많은 AI 에디터 중에서도 특히 Cursor를 사용하는 이유는 단지 기능적 이유 외에도 현재 가장 널리 사용되는 AI 에디터라는 점에서 얻는 생태계의 이점이 크기 때문입니다. 그래서 이번에는 Cursor 사용 경험을 바탕으로 이 유형의 도구들이 어떤식으로 ‘A. 소극적인 개발 보조형’ 도구들과 다른 기능을 제공하는지 몇가지 짚어 보겠습니다.

Cursor가 제공하는 주요 기능 중 하나는 ‘인라인 코드 제너레이션(Inline Code Generation)³’과 ‘터미널 제너레이션(Terminal Generation)’입니다. Cmd + k를 이용해 사용할 수 있는 기능인데, 주된 사용 상황은 코드를 입력하다가 AI가 필요한 시점에 Cmd + k를 눌러 AI에게 코드 작성을 지시하는 경우입니다.

이 외에도 터미널에서도 마찬가지로 Cmd + k를 눌러 자연어로 CLI 명령을 작성하라 지시할 수 있습니다. 이제는 복잡한 CLI 명령어를 외우고 직접 입력할 필요가 없는 것입니다. 그저 원하는 것을 AI에게 적확하기 지시내리기만 하면 됩니다.

또 하나 주목할 기능은 ‘RAG(Retrieval-Augmented Generation)⁴ 기반 채팅 기능’입니다. 기존 에디터에 연결된 AI 채팅 기능은 채팅할 수 있는 LLM을 그대로 가져와서 “ChatGPT에서 할 수 있는 질문을 에디터에서도 할 수 있다” 정도의 기능이라 쓰임이 마땅치 않았습니다. 튜닝이 거의 불가능해서 도메인 정보나 인트라넷에 있는 내용을 질문하면 맥락없는 소리를 하는 경우도 많았습니다.

하지만 이 유형의 도구에서는 LLM 에이전트가 대답을 만들 때 특정 정보를 참조하거나 실시간으로 관련 문서를 검색, 참조할 수 있도록 만들 수 있습니다. 덕분에 사용자는 특정 문서를 프로젝트 내 지식베이스로 추가하고, AI가 대답을 만들 때 참고해야 하는 규칙들을 정의해서 사실상 커스텀한 에이전트를 얻는 효과를 만들 수 있습니다. 특히나 이 기능은 새로운 라이브러리를 도입할 때나 외부 문서를 참고할 필요가 있을 때 사용하면 매우 유용합니다.

더불어 소개하고 싶은 기능은 ‘에이전틱(Agentic) AI⁵’입니다. 에이전틱 AI는 추론 모델로 발전한 LLM을 이용해 AI가 단순히 지시에 맞춰 명령을 수행하는 데 그치지 않고 AI가 스스로 작업 계획을 수립하고, 실행하며, 결과를 피드백하는 순환적 작업 흐름을 수행하는 것을 말합니다.

다시 말해 AI 에디터에 탑재된 에이전트에 “React로 카카오 스타일의 채팅 화면을 만들어줘”라고 명령을 내리면, AI는 이를 해석해 코드를 생성하고, 이를 수정하고, 결과를 피드백하는 순환적 작업 흐름을 수행해 앱 개발 전반을 AI가 직접 수행하는 것입니다.

에이전틱 AI가 동작하는 방식

[에이전트가 동작하는 방식]

  1. Order: 사용자가 명령을 내린다.
  2. Planning: AI가 계획을 수립한다.
  3. Acting: 계획에 따라 코드를 수정하거나 생성한다.
  4. Feedback: 실행 결과를 바탕으로 사용자에게 피드백하거나, 추가 조치를 제안한다.

이 기능 덕분에 근래에는 ‘바이브 코딩’이라는 개발 패러다임이 한창 유행했습니다. 실제로 몇몇 보일러플레이와 단순한 웹 기능들은 바이브 코딩만으로 해결할 수 있는 단계까지 왔기 때문에, 많은 개발자들과 비개발자들이 “정말 코딩 없이 자연어만으로도 개발이 가능해지는 시대가 되는 것인가?”라며 기대감에 가득차 이 기능에 주목했습니다.

에이전틱 AI 기능은 아직은 실험적인 단계일 수 있지만, 그럼에도, AI 에이전트가 점차 안정화되고 사용자 경험이 좋아지고 있기 때문에 분명히 주목해야할 기능입니다.

C. 대화형을 지향하는 개발 주도형

다음으로 등장한 유형은 개발자의 역할을 더 축소하고, AI가 개발자보다 개발을 더 주도적으로 하는 ‘대화형 개발 도구’입니다. Firebase Studio, Bolt.new, Lovable 같은 도구들이 이에 해당합니다. 이 유형의 도구 특징은 “AI가 개발하고, 인간이 지시한다”는 컨셉을 표방하고 있다는 점입니다. 이 유형에서 AI 도구는 사람이 개발 프로세스에 끼어드는 것을 지양하고, 그것보다는 사람이 구체적인 지시를 내리는 데 집중하는 것을 지향합니다.

단순하게 생각해 이 유형은 ‘B. 적극적인 개발 보조형’에서 에이전틱 AI가 부각된 것으로 봐도 무방합니다. 그래서 기술적으로는 B 유형과 큰 차이 없으며, B 유형과 유사하게 VSCode를 기반으로 만들어진 경우가 많습니다.

하지만, B 유형과 다른 점이라면, 에디터 기능이 감춰져 있고 대부분은 앱개발을 위해 대화형 인터페이스를 메인으로 제공한다는 점입니다. 그리고 개발자가 코드를 확인하는 것을 지양합니다. 때문에 이 유형의 도구들은 독자적인 애플리케이션 형태로 개발되기 보다 웹 기반의 SaaS 형태로 개발돼 있는 경우가 많습니다.

참고: 웹 기반으로 서비스 제공할 수 있는 것은 VSCode가 electron 기반의 오픈소스였기 때문에 가능했던 것으로 보입니다.

대화형 인터페이스를 주로 하는 유형의 AI 에디터 (firebase-studio)

이 유형의 도구들은 단순히 코드를 생성하는 것에서 멈추지 않습니다. Firebase, Supabase, Vercel 같은 다양한 클라우드 플랫폼과 연계해 AI가 만든 앱을 실제로 배포할 수 있는 기능까지 지원합니다. 이 덕분에 비개발자들도 명령 몇 줄로 원하는 앱을 만들고, DB까지 연결하며, 자동으로 배포하는 등의 작업을 수행할 수 있는 시대가 됐습니다.

이러한 도구들은 종종 로우코드(low-code)라고도 불리며 노코드라 불리는 도구들과 혼동 되기도 합니다. 하지만 로우코드에 대한 정의는 웹빌더에 가까운 형태로 잡혔고, 이 유형의 AI 도구들은 모든 의사 처리가 채팅 UI/UX에서 시작된다는 의미에서 ‘C. 대화형 개발 주도형’이라는 분류로 엮었습니다.

D. 노코드를 지향하는 개발 주도형

마지막 유형인 ‘D. 노코드를 지향하는 개발 주도형’에는 Claude Code, Goose, Aider 같은 도구들이 있습니다. 이 유형의 도구들은 에이전틱 AI를 구현하기 위해 더욱 급진적인 접근법을 취합니다. 좀 더 본질에 집중하기 위해 에디터같은 UI조차 갖추지 않은 경우가 많기 때문입니다.

이 유형의 대표격인 Claude Code를 예로 들어 설명하겠습니다. Claude Code는 Anthropic에서 개발한 Claude 계열 모델 중 코딩 작업에 최적화된 버전의 모델입니다. 코드 생성, 이해, 리팩토링, 디버깅 등의 작업에 특화되어 있으며, 대규모 맥락 처리 능력(긴 코드 파일이나 프로젝트 전체 구조를 한 번에 이해하는 능력)이 강점인 것으로 잘 알려져 있습니다.

Claude Code는 사용자에게 Claude 토큰을 받아 CLI 형태로 실행할 수 있습니다. 그러한 점에서 이전의 웹이나 앱으로 실행하는 다른 도구들과 대조적입니다. 생각해보면 GUI는 사람이 쉽게 사용하기 위해 만들어진 인터페이스이기 때문에, 어떤 명령을 내리거나 현상을 분석할 때 LLM이 가장 잘 이해할 수 있는 CUI(Character User Interface) 형태의 도구를 만든 것이 참으로 괜찮은 선택처럼 보입니다⁶.

Claude code

Claude CLI를 실행하면 에이전트는 디렉토리 구조를 파악하고 작업을 수행할 수 있는 형태로 정보를 인덱싱합니다. 이후는 여타 다른 에이전틱 AI와 유사합니다. 사용자는 채팅 앱과 유사하게 에이전트에게 명령을 지시해 일을 시킬 수 있습니다. 대신 CLI가 vim이나 nano 같은 에디터를 지원하는 형태는 아니기 때문에 이 유형의 AI 도구를 사용하는 개발자들은 기존에 사용하던 IDE와 이 유형의 도구를 같이 사용하는 경우가 많습니다.

여러 유형의 AI 도구들을 보며 이제는 개발자의 역할이 재정의 돼가고 있음을 느낍니다. 개발자에게 주어진 역할은 기능 구현이 아니라 도메인에 대한 이해를 바탕으로 AI에게 정확한 지시를 내리는 방향으로 발전하고 있습니다. 어떻게 보면 궁극적인 선언형 프로그래밍이 이루어지는 형태라고도 할 수 있을 것 같습니다.

AI가 코드 생산성을 얼마나 높여줄 수 있을까?

2021년 10월 29일 깃허브가 새로운 도구 Copilot을 세상에 공개한 지 벌써 4년이 흘렀습니다. 4년에 가까운 시간동안 Copilot은 “정말로 Copilot을 사용했을 때 개발 생산성이 향상 되는가?”에 대한 질문을 받아왔습니다.

이제는 이 질문에 확실한 대답을 할 수 있을 만큼 충분한 데이터가 쌓인 것 같습니다. 실험적인 기능이었던 Copilot은 이제 일상이 되었습니다. 그리고 개발자들이 일하는 방식 자체를 바꿨습니다. AI 도구가 어떤 식으로 개발자 생태계에 녹아들었고 어떤 식으로 사용할 수 있는지 이야기하기 전에, 먼저 이 도구들이 개발자의 코드 생산성을 얼마나 높여줄 수 있는지 이야기해보고자 합니다.

웹 검색의 종말

초기 Copilot은 단순한 코드 자동 완성 도구처럼 보였습니다. 사용자의 입력을 기반으로 다음 줄의 코드를 추론해 보여주는 방식이었기 때문입니다. 그러나 LLM이 발전하고, 코딩을 전문적으로 수행하는 에이전트들이 나오기 시작하자 이야기는 달라졌습니다.

코딩 에이전트들은 IDE의 채팅 영역에 들어왔고, 이제 Copilot의 채팅 기능은 웹 검색을 대체할 수 있는 수단으로 진화했습니다. 개발 도중 겪는 작은 오류, 문서화가 부족한 라이브러리, 특정 API의 호출 방식 등은 더 이상 구글링으로 시간을 낭비하며 해결할 필요가 없어졌습니다. AI가 맥락을 이해한 채, 그 자리에서 즉시 해답을 제시했기 때문입니다.

즉각적인 코드 예시와 설명은 개발자들의 작업의 흐름이 크게 단순화시켰습니다. 더불어 실제로 한 연구⁷에서는 AI 도구를 도입했을 때 웹 검색 시간이 평균 12%가량 줄어든다는 결과도 보고됐습니다.

이처럼 작은 변화들이 쌓인 탓인지, 얼마 전엔 충격적인 내용의 글이 올라왔습니다⁸. 2025년 5월, 미국의 소셜 커뮤니티 레딧에는 “스택오버플로우가 빈사상태다.”이라는 제목의 글이 올라왔습니다.

스택오버플로우(Stack Overflow)는 개발자라면 모를 수 없는 프로그래밍 관련 질문&답변을 공유하는 세계 최대 개발자 커뮤니티입니다. 장담컨데 스택오버플로우의 도움을 받지 않은 개발자는 없을 것입니다. 그렇기 때문에 이 자극적인 제목의 글은 빠르게 퍼져나갔습니다. 그리고 동시에 누구나 이 게시글이 하고 싶은 말을 이해할 수 있었습니다. 2024년 기준 스택오버플로우의 트래픽은 고점 대비 거의 50% 가까이 감소했으며, 이는 무려 2009년 수준으로 회귀한 수치였기 때문입니다.

스택오버플로우의 위기는 단순한 개발 커뮤니티의 퇴조가 아닙니다. 뚜렷한 상징성과 사실을 내포하고 있습니다. 이제 개발자는 정보를 얻기 위해 굳이 웹을 떠돌지 않습니다. 웹 검색을 하던 시간은 AI와 대화하는 시간으로 변해 있고, AI는 점점 더 정교하게 질문을 이해하며 답을 제시합니다. 보편적인 질문만 잘 응답하던 채팅 기능도 이제는 도메인 정보가 담긴 질문을 해도 괜찮은 대답을 얻을 수 있는 수준으로 올라왔습니다.

그렇기에 이 현상을 단순한 기술의 발전으로 바라봐서는 안됩니다. 이는 개발이라는 행위 자체의 방식이 변화하고 있다는 확실한 시그널입니다.

생산성을 수치로 증명한 깃허브 리서치

GitHub는 여러 차례 Copilot이 실제로 개발 생산성에 어떤 영향을 미치는지 정량적으로 측정하기 위한 연구를 진행한 바 있습니다. 그리고 그 결과는 꽤 인상적이었습니다. Copilot을 사용하는 그룹은 그렇지 않은 그룹에 비해 55% 더 빠르게 작업을 완료했습니다. 평균적으로 약 2시간 41분이 소요되는 개발 업무가 Copilot을 사용할 경우 1시간 11분으로 단축됐다는 것입니다⁹.

물론 이 연구는 GitHub 자체의 자료이므로 일정 부분 AI 도구의 효과를 부각시키기 위한 수치 조정이 있었을 수도 있습니다. 하지만 한 명의 Copilot 사용자로서 실제 사용 경험을 생각해볼 때, 이 수치가 과장이 아니며 체감과 일치한다는 느낌을 받습니다. Copilot을 주기적으로 활용하는 입장에서 보면 적어도 AI 도구의 도입으로 개발 생산성이 30% 이상은 향상됐다고 느낄 때가 많습니다. 이제는 Copilot나 AI 에디터 없이 개발하는 것을 상상하기 싫은 상황입니다.

이제는 논문과 리포트를 통해 AI 도구의 도입이 코드 자동완성 속도, 문서화 효율, 반복작업 감소 등 다양한 영역에서 생산성을 향상시킨다는 증거가 쏟아지고 있습니다. 실제 프로젝트에서 AI 기반 에디터를 사용한 사례에서는 문서화와 자동완성 과정에서 50%가량 시간 절약, 반복작업은 30~40% 감소됐다는 보고도 있습니다¹⁰. 사실 AI 에디터를 사용했을 때 퍼포먼스가 올라간다는 논문은 이제 발에 치일정도로 많아서 모두 언급하기 어려울 정도입니다.

물론 Copilot이 처음 등장했을 당시에는 “AI가 작성한 코드의 품질이 낮다”는 이유로 적지 않은 비판을 받았습니다. AI가 만든 코드에는 예상치 못한 버그가 있었으며, AI가 ‘효율적이지 못한 코드’, ‘이해하기 어려운 네이밍’, ‘기존 코드베이스와 다른 스타일의 코드’ 등을 만드는 문제가 있었기 때문입니다.

이로인해 Copilot이 제안하는 코드들 중 실제로 수락하는 비율인 수락률(Acceptance rate)은 꽤나 낮은 편이었습니다. 하지만 시간이 지나면서 LLM의 비약적인 발전으로 코드 추천의 품질 자체가 개선되며 이러한 비판은 점차 사라지고 있습니다.

2023년에 발표된 한 자료에 따르면, Copilot 사용자 중 85%는 Copilot을 사용한 이후 코드 품질에 더 높은 만족감을 느꼈다고 응답했다고 합니다. 더불어 코드 리뷰 속도도 15% 향상됐다는 결과도 함께 보고됐습니다¹¹.

실무에서 나타난 변화: 카카오의 사례

AI 도구의 효과는 실험적인 공간이나 교육 현장 같은 통제된 환경이 아니라 실제로 현업이 이뤄지는 기업 현장에서도 입증되고 있습니다.

대표적인 사례로 카카오의 Copilot 도입 사례를 들 수 있는데, 카카오는 2023년 4월부터 Copilot을 시범 도입했고 이후 빠르게 효율성을 확인한 뒤 같은 해 7월 정식 전사 도구로 도입했습니다.

카카오는 현재 1,000명 이상의 개발자들이 Copilot을 사용하고 기타 다른 AI도구도 적극적으로 사용하고 있는만큼 지속적으로 AI 도구들에 관심을 보여왔습니다. 그리고 Copilot 도입 이후부터 꾸준한 설문조사를 진행해 AI 도구가 카카오의 개발 문화를 어떻게 바꾸고 있고, 바꿀 수 있는지 추적 관찰해왔습니다.

카카오에서는 내부적으로 총 세 차례의 설문 조사를 진행했습니다. 결과는 96.8%가 Copilot 사용 이후 개발 시간을 줄일 수 있었다고 응답했고, Copilot 도입 이전보다 생산성이 향상됐다고 응답한 비율이 무려 98.9%에 달했습니다.

더불어 서술식 응답에서는 반복적인 작업을 더 빠르게 처리할 수 있었다는 응답이 다수 있었는데, 이는 AI 도구가 단순히 개발자들의 개발 시간을 절약시켜주는 것을 넘어, 개발자들이 보다 창의적이고 고차원적인 작업에 집중할 수 있는 여유를 제공했다고 의미이기 때문에, 카카오에서는 이를 상당히 유의미한 변화로 보고 있습니다.

흥미로운 점은 Copilot의 생산성 향상 효과에 대한 인식이 해마다 상승하고 있다는 점입니다. 이 항목에 대한 카카오 내부의 긍정적인 응답은 2025년 98.9%로 2024년에 조사한 92%보다 무려 6.9% 증가했습니다. 거의 100%에 근접한 수치인 것이 놀랍기도 하지만, 이 수치에 주목하는 이유는 1년이라는 그 짧은 시간동안 AI 도구가 사용자들이 체감할 만한 변화를 만들어왔다는 증거이기 때문입니다. 현재 AI 개발 도구의 성장세는 가히 폭발적입니다.

그리고 이 설문에서 얻을 수 있는 중요한 시사점이 하나 더 있습니다. 단순히 “AI 도구 덕분에 시간이 절약됐다”는 응답보다, “AI 도구 덕분에 전반적인 생산성이 향상됐다”는 응답 비율이 더 높았다는 점입니다. 이는 다시 말해, AI 도구를 코드 작성에만 사용하는 것이 아닌 기타 다른 영역에도 사용하고 있다는 의미입니다.

AI 도구는 이제는 더이상 단순 코드 작성 도구가 아닙니다. 코드 리뷰, 문서 작성, 리팩토링, 심지어 동료와의 토론 역할까지 수행해서 개발자와 함께 일하는 동료에 가깝습니다. 개발 생태계에서 AI 사용은 단순한 선택 항목이 아니라, 더 나은 개발 경험을 위한 필수 항목이 돼가고 있습니다.

AI 에디터 제대로 활용하기

지금까지 AI 도구들이 어떻게 개발자들의 생산성을 변화시키고 있는지를 살펴보고 어떤 유형의 도구들이 있는지 살펴보았다면, 이제는 이러한 도구들을 실제로 어떻게 활용하면 좋을지 이야기해볼 차례입니다.

특히 AI 기반 코드 에디터들은 단순히 코드를 보완하는 수준을 넘어, 개발자의 작업 환경 전반을 재정의하고 있습니다. 이번에는 AI 에디터의 활용 사례를 중심으로, 도구들이 어떻게 개발자의 흐름을 가로막지 않으면서도 동시에 깊이 있는 지원을 제공할 수 있는지를 살펴보고자 합니다.

프로젝트 규칙을 AI에게 맡기기

현대 개발의 중요한 과제 중 하나는 단지 기능을 구현하는 것을 넘어서 팀 단위로 일관된 품질과 컨벤션을 유지하는 것이었습니다. 그래서 그동안 정말 많은 팀이 이러한 규칙들을 위키 문서나 README 파일, 혹은 팀 내부 슬랙, 노션 같은 곳에 흩어져 관리했습니다.

이는 새로 팀에 합류한 개발자나 규칙이 다른 개발자가 임시로 프로젝트에 참여했을 때, 프로젝트 합류를 늦추는 일종의 사일로 역할을 했습니다. 이 규칙들을 숙지하고 적용하는 데만도 적지 않은 시간이 소요됐으며 초기 코드 리뷰의 대부분은 컨벤션 수정으로 시간을 많이 낭비했기 때문입니다. 그러나 최근 등장한 AI 에디터와 AI에게 일관된 규칙을 따르게 할 수 있는 규칙 파일 덕분에 이러한 문제가 해결 될 수 있을 것으로 보입니다.

예를 들어 Cursor의 주요 규칙 파일인 .cursorrules 파일은 Cursor에 탑재된 LLM에 따라야 할 가이드를 제공하는 역할을 합니다. 그래서 도메인 특유의 용어나 API 작명 규칙, 커밋 메시지 템플릿 등을 여기에 명세해 개발 과정 전반에 걸쳐 일관된 톤을 유지할 수 있도록 할 수 있습니다.

또한 팀에서 사용하는 라이브러리 버전이 항상 특정 릴리스를 기준으로 고정되어야 한다면, 이를 추가로 명시해 AI가 그 맥락 안에서 코드를 제안하도록 만들 수도 있습니다.

함께 관리하는 프로젝트 규칙

또 이 파일은 프로젝트 자체에 저장해서 GitHub와 같은 저장소에 올리고 팀원과 공유할 수 있기 때문에 특히 유용합니다. 왜냐하면 모든 팀원이 AI를 사용해 페어프로그래밍을 했을 때 AI가 만든 결과물에 큰 차이가 있다면 일관성이 깨질 우려가 있는데, AI가 지켜야 할 규칙 파일을 공유함으로써 AI의 결과물을 일관되게 만들 수 있기 때문입니다. 다시 말해 팀 단위의 프롬프트 엔지니어링이 가능해진다는 것입니다.

에디터에서 문서 작업하기

개발은 코드만으로 이루어지지 않습니다. 대부분 기획안, 기술 문서, API 명세서, 회고록 작성 등 많은 텍스트 작업이 병행되어야 합니다. 그래서 개발자 입장에서 이 과정은 종종 업무 효율을 갉아먹는 구간이 되곤 합니다. 특히 글쓰기에 어려움을 겪는 개발자라면 더욱 그렇습니다. 그러나 AI 에디터를 활용하면 이 문서 작업의 패러다임조차 바꿔볼 수 있습니다.

예를 들어 최근 기술 문서 작성을 Google Docs나 Notion, Wiki 같은 공간이 아닌, Cursor와 같은 AI 코드 에디터에서 진행하는 사람들도 늘고 있습니다.

여기에는 몇 가지 분명한 이유가 있는데, 첫 번째 이유는 AI 에디터에서 제공하는 규칙 파일(.cursorrules )에 톤앤매너를 잘 정의하면 모든 글을 일관된 문체로 작성할 수 있다는 점이며, 두 번째 이유는 에디터 내에서 Cmd + K 단축 키를 통해 AI에게 필요한 질문(띄어쓰기, 맞춤법)을 바로바로 할 수 있는 점입니다. 그리고 마지막 세 번째 이유는 AI가 개발자가 작성한 불완전한 문장을 아주 자연스럽게 문맥에 맞는 문장으로 자동 완성해 준다는 점입니다.

글쓰기에 익숙하지 못한 개발자들은 종종 글의 방향은 잡았지만 문장을 정리하지 못해 멈칫하는 경우가 있습니다. 그래서 글을 쓸 때 작성하던 문장을 마무리하기 위해 많은 시간을 허비합니다. 하지만 AI 에디터를 이용해 문서 편집을 하면 이런 시간을 획기적으로 단축할 수 있습니다. 왜냐하면 글을 쓰고 있을 때 AI가 내가 쓰고자 한 의도를 포착하고 거의 실시간에 가까운 속도로 문장의 마무리를 제안해주기 때문입니다.

문서 작업 도구로서 Cursor: 문장을 자동 완성 해주고 있다.

AI 에디터로 문서 작업을 하면 AI가 단순한 편집 보조를 해주는 도구인 것을 넘어, 글쓰기를 함께 이어가주는 동료인 것 같다는 생각이 들 수 있습니다. 이처럼 AI 에디터는 코드 작성을 넘어서 문서 생산의 도구로도 충분히 경쟁력을 갖추고 있으며, 특히 개발자라면 기존 워크플로의 연장선상에서 자연스럽게 도입할 수 있을 것입니다.

MCP를 통한 확장

AI 에디터의 진화는 규칙의 내재화나 문서 편집에서 그치지 않습니다. 최근에는 ‘MCP(Model Context Protocol)’라는 새로운 접근법이 주목받았습니다. 이는 AI가 작업을 수행하기 위해 필요한 도구와 컨텍스트를 정의하고 연결하는 일종의 표준 프로토콜로, 현존하는 대부분의 AI 에디터는 MCP를 지원하고 있습니다. 덕분에 이를 중심으로 다양한 외부 도구와 연동해 AI 에디터가 에이전트처럼 동작하는 만드는 기반을 갖추고 있습니다.

예를 들어 MCP를 이용해 Figma와 연동하면 만들고 싶은 개략적인 디자인을 설명해 AI에게 레이아웃을 설계하거나 컴포넌트를 배치하도록 할 수 있습니다. 또 Jira와 AI 에디터를 연결하면 현재 진행 중인 업무의 상태를 파악하도록 할 수 있고, Jira 이슈 기반으로 작업을 수행하거나 이슈를 업데이트할 수 있습니다. 기존에는 각각의 도구가 독립적으로 운영되었다면, 이제는 이 모든 흐름이 AI 중심의 문맥으로 통합되고 있는 셈입니다.

물론 MCP는 아직 실험적인 단계에 있습니다. 하지만, 이미 여러 에디터들이 이를 적극적으로 수용하며 생태계를 넓혀가고 있습니다. MCP는 단지 기능 확장의 도구가 아니라, 개발자가 AI 에이전트에게 더 풍부한 작업 맥락을 제공할 수 있는 방법이라는 점에서 그 의미가 깊습니다. AI 에디터는 이제 단순한 ‘코딩 도구’를 넘어, 개발자의 전반적인 생산 환경을 지원하는 플랫폼으로 확장되고 있습니다.

AI 에디터와 생산성

AI 도구를 사용하면 코드 작성 속도가 비약적으로 향상된다는 점은 이제 누구나 체감할 수 있는 변화입니다. 반복적인 코드 블록이나 테스트 코드 작성, 보일러플레이트 설정 등에서 AI는 빠르게 대안을 제시하고, 실수의 여지를 줄이며 개발자의 시간을 절약해줍니다. 그러나 그 이면에는 또 다른 현실이 존재합니다. 코드 작성이 빨라졌다고 해서 전체 개발 주기가 반드시 단축되는 것은 아니라는 점입니다.

실제로 여러 팀에서 AI를 도입했음에도 실질적인 업무 능력 향상으로 이어지지 않아 고민이 많은 것으로 압니다. 하지만 대게 그 이유를 들어보면 실제 병목이 되는 지점은 개발 프로세스가 아니라 인간의 의사 결정 과정인 경우가 다수였습니다. 프로젝트의 방향이 정해지지 않은채 개발을 진행해서 막상 모든 개발이 끝난 다음에 갈아엎는다거나, 개발은 일찍 끝났음에도 어차피 모든 일정이 스케줄대로 진행되기 때문에 생산성은 그대로인, 그런 일들이 일어나고 있었던 것입니다.

만약, AI 도입으로 생산성이 올라가지 않는다면, 도구의 문제가 아니라 문화와 프로세스의 문제일 확률이 높습니다. 따라서 AI 시대에 생산성 향상을 도모한다면 이에 걸맞은 조직적 전환도 반드시 병행되어야 합니다.

특히 문제되는 것은 모든 의사결정이 위에서 내려오고 일정에 따라 수동적으로 움직이는 워터폴 방식의 개발 문화입니다. 이러한 문화에서는 AI가 제공하는 속도의 이점을 온전히 누리기 어렵습니다. 개발자의 입장에서 상상할 수 있는 최악의 상황은 AI 에디터 도입으로 관리자가 “이전보다 더 많은 일을 해낼 수 있게 됐으니 촉박한 일정을 부과해도 되겠지?”라고 착각하는 것입니다.

그러나 이는 AI 도입의 본질을 오해한 접근입니다. 중요한 것은 단순히 더 많은 코드를 빠르게 작성하는 것이 아닙니다. 크고 작은 기능들을 실제 사용자에게 전달하고 피드백을 반영해 점진적으로 더 나은 프로덕트를 만들어가는 것입니다.

따라서 지금이야말로 진정한 의미에서 애자일을 다시 고민하고, 실행에 옮길 시기입니다. AI 도구의 생산성을 극대화하기 위해 조직 문화를 재설계해야 하며, 작은 단위의 작업을 빠르게 반복하며 검증하는 실천이 그 어느 때보다 중요해지고 있습니다.

각주

1) Void는 Cursor의 대체재로 등장한 오픈소스 AI 에디터입니다. AI 에디터가 어떻게 만들어지고 있는지 관심이 있는 독자들은 이 도구의 소스코드를 살펴보는 것을 추천합니다.

2) LLM이 주목 받고 AI 개발 도구가 등장한지 몇 년 안 된 시점에서 만들어진 도구들이기 때문에 기반이 되는 에디터로 VSCode를 삼은 경우가 많습니다.

3) 프로그래밍에서 함수 호출이 일어나는 위치에 해당 함수의 코드를 직접 삽입하는 기술. 함수 호출 코드를 함수 본문으로 대체하여 실행 속도를 높이는 최적화 기법

4) RAG는 AI가 외부 문서나 데이터를 참조하여 더 정확하고 맥락에 맞는 응답을 생성하는 기술입니다.

5) Cursor에서는 에이전틱 AI를 ‘Composer’라는 기능으로 소개했습니다. 현재는 채팅의 ‘Agent Mode’에 통합된 것으로 확인됩니다.

6) 이는 이 유형의 도구들이 진정한 의미로 에이전틱 AI를 추구하기 때문이라 생각합니다. 생각해보면, GUI는 사람이 코드를 관리하기 위해 필요한 것입니다. 본질적으로 AI가 이해하기 쉬운 정보는 텍스트와 같은 CUI입니다.

7) [출처] https://arxiv.org/html/2506.10051v1 “The Effects of GitHub Copilot on Computing Students’ Programming Effectiveness, Efficiency, and Processes in Brownfield Programming Tasks” our analysis revealed that, when using Copilot, students spent 11% less time manually writing code (p < 0.05), and 12% less time conducting web searches (p < 0.05), providing evidence of a fundamental shift in how they engaged in programming.

8) [출처] 스택오버플로우가 위험에 처하다

9) [출처] 코드 작성 시간이 11% 가량 줄어들고 웹 검색 시간은 12%가량 줄어든다

10) [출처] AI 에디터를 활용했을 때, 문서화 및 자동완성 과정에서 50%가량 시간이 절약되고 반복 작업이 30~40%정도 절감된다

11) [출처] 깃허브 코파일럿이 개발자 생산성에 끼치는 영향에 대한 연구, 깃허브 코파일럿이 코드 품질에 끼치는 영향에 대한 연구