목차

목차를 생성하는 중...

3.1. 생산성 혁신의 실험: AI 마일리지 프로그램

에이전틱 코딩을 통한 1인 프로토타입 제작의 가능성을 확인하고 개인과 단일 조직의 다양한 에이전틱 코딩 업무 활용 사례를 수집한 이후, 기술전략은 ‘AI 마일리지 프로그램’을 기획했습니다. AI 마일리지 프로그램에 참여한 개발자를 대상으로 다양한 상용 AI 도구(예: 코드 생성 AI, 디자인 프로토타이핑 AI 등)를 자유롭게 사용해볼 수 있는 크레딧(마일리지)을 지원했습니다.

AI 마일리지 프로그램 시범 운영의 핵심 목적은 다음과 같습니다. 첫째, 현업의 전체 워크플로 중 개발자들이 어떤 단계에서 AI 개발 도구를 활용하는지, 그리고 전체 워크플로를 얼마나 개선하는지를 검증하는 것입니다. 둘째, 효과적인 AI 도구 활용법과 AI 도구 이용 비용 최적화 등 실제 운영에 필요한 노하우를 확보하는 것입니다.

약 3개월의 시범 운영에 100여명의 개발자가 참여했습니다. 이들은 30여개 조직에 소속되어 40여개의 과제를 진행하며, 월 소정 금액의 마일리지 내에서 다양한 AI 개발 도구를 자유롭게 조합하여 사용했습니다. 참여자들은 적극적으로 도구를 활용하고 설문조사, 인터뷰, 사례 공유 등 다양한 형태의 피드백에 참여했습니다.

AI 도구 도입에 대한 근본적인 고민

시범 운영 1개월만에 참여자들을 인터뷰하면서 한 가지 뜻밖의 패턴을 발견했습니다. 많은 참가자들이 공통적으로 현재 AI 도구 사용의 편리함에 적응했기 때문에, 만약 이 도구가 없어진다면 심한 역체감과 불편을 느끼게 될 것이라는 솔직한 이야기를 한 것입니다.

그 순간 문득 어린 시절 읽었던 ‘원숭이 꽃신’이라는 동화가 떠올랐습니다. 동화 속의 원숭이는 신발이 없어도 잘 살고 있었습니다. 하지만 어느 날 오소리가 굳이 필요하다고 하며 꽃신을 선물로 건네주었습니다. 꽃신의 편안함에 익숙해진 뒤로는 오소리가 꽃신의 값을 요구했고, 원숭이는 그렇게 서서히 오소리에게 종속되어 갔습니다.

‘혹시 이들에게 불필요한 원숭이 꽃신을 주는 못된 일을 하고 있는 것은 아닐까?’

이 고민은 단순한 우려를 넘어 AI 도구 도입에 대한 근본적인 질문을 던졌습니다. AI 마일리지 프로그램이 개발자들의 진정한 역량 강화로 이어지는 것일까요, 아니면 단순히 편의성에 의존하게 만드는 함정일까요?

거스를 수 없는 흐름인가, 불필요한 의존성인가

이 질문에 대한 답은 또 다른 참여자와의 인터뷰를 통해서 얻었습니다. 몇 분의 참여자께서 공통적으로 말씀하신 것이 실마리가 되었습니다.

“AI를 이용한 개발은 이제는 거스를 수 없는 흐름입니다.”

AI 개발 도구가 정말 거스를 수 없는 흐름이 맞다면, 이것은 불필요한 꽃신을 주는 것이 아니라 꼭 필요한 변화의 과정을 돕는 일이라고 생각할 수 있었기 때문입니다.

그렇다면 이것이 정말 ‘거스를 수 없는 흐름’인지 어떻게 판단할 수 있을까요?

저의 결론은, AI 도구가 실제로 업무 생산성에 도움이 된다는 것이 허상이 아니라 실체가 있어야 한다는 것이었습니다. 실제로 개발을 AI와 함께 했을 때 실체가 있다고 느껴질 만큼 좋은 부분이 있다면, 그것을 경험한 사람들이 많아지면 많아질수록 이 흐름이 분명히 미래의 대세가 될 것이기 때문입니다.

다음 고민은 그 실체를 어떻게 확인할 것인가? 입니다. 정량적으로 숫자로 속도가 얼마나 빨라졌는지, 기간이 얼마나 단축되었는지를 분석하고 트래킹하는 것도 물론 중요합니다. 하지만 숫자로 보여드리는 것 이상의 실체가 필요했습니다. 그것은 바로 개발자들의 실제 사례가 모이는 것이라는 결론에 도달했습니다.

어찌 보면 뻔한 결론을 내리기까지 장황한 고민이 있었던 것 같습니다. 하지만 이 성찰의 과정이 중요했습니다. 왜냐하면 이번 장에서 공유할 성과와 사례들이 이러한 고민과 검증을 거쳐 얻어낸 실체들이기 때문입니다.

AI 마일리지 프로그램의 결과는 개발자의 역할 재정의와 조직 문화의 근본적 변화로 이어지고 있음을 보여주는 증거입니다. 그리고 무엇보다, 이것이 ‘원숭이 꽃신’이 아닌 진정한 경쟁력 강화의 발판임을 증명하는 실체적 성과들입니다.

누가 참여했을까?

AI 마일리지 프로그램 시범 운영에 함께한 100여명의 참여자는 전사 다양한 조직의 주니어부터 시니어까지 다양한 연차, 직군별로는 백엔드, 풀스택, 인프라, AI/ML, 데이터 엔지니어링, 프론트엔드 개발자 등으로 구성되었습니다. AI 도구의 효과성을 검증하기 위해서는 다양한 배경과 경험을 가진 개발자들의 참여가 필요했습니다.

어떤 AI 개발 도구를 선택했을까?

인상적이었던 것은 참여자들의 적극적인 도구 활용이었습니다. 인당 평균 3~4개의 AI 도구를 동시에 사용했으며, 이는 단일 도구에 의존하지 않고 각 도구의 장점을 조합하여 활용하려는 접근을 보여줍니다.

가장 많이 선택된 도구는 기존에 많이 쓰이던 IDE인 IntelliJ를 제외하고도 Cursor, Copilot 등이었습니다. ChatGPT, Gemini과 같은 LLM도 많이 사용하였으며, Claude Code는 처음 시작할 때보다 마지막 달에는 약 2배 많은 사용자의 선택을 받으며 대세 개발 도구로서의 면모를 보였습니다. 이 외 API 기반 도구로는 OpenAI API와 Claude API 등도 함께 활용되었습니다.

조합의 경우의 수는 다양했지만 공통적으로 나타나는 패턴도 몇 가지 있었습니다. 첫 달에는 Cursor + JetBrains + Copilot + LLM의 조합을 선택한 개발자가 가장 많았고, 이후 시간이 지나면서 Claude Code를 주요 도구로 사용하는 개발자의 비율이 가장 높아졌습니다.

한 편으로는 주 사용 도구를 기준으로 Cursor + Claude Code를 조합하여 사용하는 패턴도 증가했습니다. 이는 개발자들이 각자의 업무 스타일과 과제 특성에 맞춰 최적의 도구 조합을 찾아가고 있음을 보여줍니다.

업무 단계별 생산성 향상 지표

AI 마일리지 프로그램의 1~3개월 차 설문 결과를 비교하면, 개발자들의 AI 활용 숙련도가 높아지면서 전반적인 효과가 향상되고 있음을 확인할 수 있었습니다. 이는 개발자들이 AI와의 협업 방식을 학습하고 개선해가고 있음을 의미합니다.

업무의 단계를 ‘(1) 설계 (2) 코드 작성 (3) 디버깅/테스트 (4) 코드 리뷰 (5) 문서화 (6) 릴리즈’의 여섯 단계로 구분한 뒤, 각 단계에서 AI 도구 사용을 통해 시간이 단축된 비율을 질문했습니다. 이에 대해 긍정적인 단축을 경험한 사용자의 비율이 다음과 같았습니다.

단축 효과가 명확한 업무 (1개월 차 → 2개월 차 → 3개월 차):

• 코드 작성: 93.5% → 96.7% → 98.0% (4.5%p 향상)
• 디버깅/테스트: 81.5% → 87.0% → 86.3% (4.8%p 향상)
• 설계: 63% → 78.5% → 84.2% (21.2%p 대폭 향상)
• 문서화: 61.9% → 68.8% → 79.5% (17.6%p 향상)

단축 효과가 상대적으로 적은 업무 (1개월 차 → 2개월 차 → 3개월 차):

• 코드 리뷰: 51.1% → 62.4% → 61.0% (9.9%p 향상)
• 릴리즈: 26.0% → 31.2% → 43.1% (17.1%p 향상)

‘설계’ 단계에서 21.2%p의 큰 향상은 매우 의미 있는 변화입니다. 이는 개발자들이 AI를 단순한 코드 생성 도구를 넘어 설계 파트너로 활용하는 법을 터득했음을 보여줍니다. 실제로 시니어 개발자들이 “설계는 ChatGPT와 대화하고 구현은 Claude에게 위임”한다고 응답한 예시의 패턴이 전반적으로 확산되고 있음을 시사합니다. 반면 서비스 릴리즈 단계에서의 효과 감소는 기존 배포 파이프라인이 이미 고도로 자동화되어 있고, 보안상의 이유로 AI 도구와의 직접적인 연동이 제한적이기 때문에 나타난 결과입니다.

AI에 대한 개발자 인식: 건전한 파트너십의 형성

신뢰도: 균형 잡힌 접근법

마일리지 시범운영 2개월 차 및 3개월 차 설문조사에서는 참여자들이 AI가 생성한 코드를 얼마나 신뢰하는지 물었습니다. 설문에서 나타난 AI에 대한 개발자들의 신뢰도는 매우 건전한 수준을 보여줍니다. (3개월 차)

• 매우 신뢰: 3.2%
• 어느 정도 신뢰: 51.6%
• 보통: 36.8%
• 불신: 8.4%

대부분의 개발자들이 AI를 맹신하지도, 완전히 불신하지도 않는 건전한 신뢰 관계를 형성하고 있습니다. ‘매우 신뢰’가 3.2%에 불과한 것은 오히려 긍정적인 신호일 수도 있습니다. 이는 개발자들이 AI의 한계를 정확히 인식하고 있음을 의미하기 때문입니다.

16년차 이상 시니어 개발자들은 AI가 생성한 코드가 “아직 고품질까지는 아닌 것 같다”며 반드시 리팩토링을 거친다고 밝혔습니다. 또 다른 시니어 개발자는 AI가 “클린 코드 원칙에 위배되는” 코드를 생성하는 경우가 많아, 사람의 역할이 필수적이라고 강조했습니다.

이들의 ‘불신’은 모순이 아닙니다. 오히려 AI의 한계를 명확히 인지하고 있기에 나오는 전문가적 태도입니다. 이들은 AI의 결과물을 그대로 수용하는 것이 아니라, 자신의 깊은 경험과 지식을 바탕으로 AI의 결과물을 비판적으로 평가하고 개선하는 과정을 거칩니다.

성공적인 AI 협업자들은 자신만의 검증 시스템을 구축합니다. 한 개발자는 AI에게 작업을 시키기 전 “웬만하면 커밋을 한 번씩 해서 체크포인트를 마련”하는 자체 검증 시스템을 만들었습니다. 이는 AI 작업의 각 단계를 추적 가능하게 만들어, 문제가 발생했을 때 빠르게 롤백하고 문제점을 파악할 수 있게 해줍니다.

한편, AI 활용에 익숙해지는 과정에 있는 초기 사용자들은 “AI가 짠 코드를 온전히 믿다가 한번 에러가 났을 때 그걸 찾는데 시간이 오래 걸린다”는 경험을 하며, 이러한 비판적 검증 능력의 중요성을 체감하게 됩니다.

AI 역할 인식: 주니어에서 전략적 파트너까지

같은 설문조사에서 ‘지금의 AI 코딩 에이전트는 당신에게 어떤 존재에 가장 가깝습니까?’라는 질문도 제시했습니다. 이에 대한 응답은 AI와의 협업이 다층적이고 편차가 있음을 보여주었습니다.

역할	응답 비율 (3개월 차)	설명
검색 도구	6.3%	주로 모르는 것을 질문하고, 단편적인 코드 예시나 아이디어를 얻는 데 사용합니다. 구글 검색을 보완하는 역할에 가깝습니다.
주니어 개발자	37.9%	정형화된 코드(보일러플레이트), 간단한 함수, 데이터 파싱 등 명확하게 정의된 단순/반복 작업을 맡기는, 보조 개발자의 역할을 합니다.
유능한 동료	27.4%	버그 수정, 테스트 코드 상세 작성, 레거시 코드 리팩토링 등 명확한 목표가 주어진 복잡한 단위 과업을 독립적으로 수행하도록 믿고 맡길 수 있습니다.
전략적 파트너	23.2%	코드 구현을 넘어, “어떻게 만들 것인가”에 대한 설계 방향이나 아키텍처의 장단점을 함께 논의하며 생각을 발전시키는, 지적인 스파링 파트너의 역할을 합니다.
독립적인 에이전트	5.3%	“이 기능을 이런 방향으로 개발해줘”와 같이 높은 수준의 목표와 핵심 컨텍스트만 제공하면, 몇 시간 이상 걸리는 복잡한 작업을 자율적으로 계획하고 수행하는 독립적인 팀원(에이전트)으로 신뢰합니다.

주목할 점은 약 65%의 개발자가 AI를 ‘주니어 개발자’ 이상의 수준(주니어 개발자 + 유능한 동료의 비율)으로 인식하고 있다는 것입니다. 특히 ‘전략적 파트너’로 인식하는 비율이 23.2%에 달하는 것은 AI와의 협업이 단순한 작업 위임을 넘어 의사결정 단계까지 확장되고 있는 가능성을 시사합니다.

의존성: 필수 도구로의 자리매김

“AI 도구 없이 개발이 가능한가?”라는 질문에 대한 응답은 AI 도구가 응답자들의 워크플로에 얼마나 필수적인 존재로 인식되고 있는지를 보여줍니다. (3개월 차)

• 이제는 도구 없이 개발하기 어렵다: 68.4%
• 불편하지만 감수 가능하다: 31.6%
• AI 도구가 없어도 전혀 문제 없다: 0%

2/3에 달하는 개발자가 AI 도구 없이는 개발이 어렵다고 응답한 것은 AI가 이미 필수 도구로 자리 잡고 있음을 보여줍니다. 이는 앞서 살펴본 AI 역할 인식과도 관련이 있습니다. AI를 ‘주니어 개발자’(37.9%) 이상의 수준으로 인식하는 개발자가 65%에 달한다는 점을 고려하면, 이러한 의존성은 자연스러운 결과입니다. 특히 AI를 ‘전략적 파트너’(23.2%)나 ‘독립적인 에이전트’(5.3%)로 인식하는 28.5%의 개발자들에게 AI는 단순한 도구를 넘어 핵심적인 업무 파트너가 되었을 것입니다. 이들에게 AI의 부재는 마치 팀원 중 한 명을 잃는 것과 같은 의미를 가집니다.

하지만 이러한 의존성을 부정적으로만 볼 필요는 없습니다. 오히려 AI를 통해 오히려 근본 실력을 빠르게 축적하는 건전한 의존성으로 전환할 수 있기 때문입니다. 마치 IDE나 검색 엔진에 의존하는 것이 개발자의 능력을 저하시키는 것이 아니라 오히려 더 높은 수준의 사고에 집중할 수 있게 하는 것처럼, AI 개발 도구 역시 개발자가 반복적이고 단순한 작업에서 벗어나 더 창의적이고 전략적인 업무에 집중할 수 있게 해주는 도구로 기능하고 있습니다.

연차별/직군별 조금씩 다른 AI 파트너십

두 차례에 걸친 설문조사에서는 AI 도구 활용 패턴, 도구에 대한 의존성과 전체 개발 프로세스에서의 기여도 인식 등에서 연차, 직군에 따른 유의미한 차이가 일부 나타났습니다.

연차별 AI 의존성: 경험과 신뢰의 상관 관계

AI 도구 활용에 대한 연차별 분석에서 주목할 만한 발견은 고연차 개발자일수록 AI 도구를 더욱 필수적인 존재로 인식한다는 점이었습니다.

16년 이상의 개발자들은 AI 도구를 업무에 필수적인 요소로 인식하는 비율이 가장 높았으며, 전체 개발 프로세스에서 50% 이상의 리드타임 단축 효과를 체감한다고 응답한 비율도 가장 높았습니다. 이는 풍부한 경험을 바탕으로 AI 도구의 진정한 가치를 정확히 판단하고 있음을 의미합니다.

반면 4~6년차 개발자들은 상대적으로 선택적 접근을 보였습니다. 이들은 AI 도구의 유용성을 인정하면서도 도구 없이도 업무 수행이 가능하다는 태도를 동시에 보여주었습니다. 이는 실무 경험이 어느 정도 축적된 상태에서 새로운 도구에 대해 보다 신중하게 접근하는 합리적 태도로 해석됩니다.

1~3년차 주니어 개발자들은 AI 도구를 학습 가속기와 지식 격차 해소 도구로 적극 활용했습니다. 이들에게 AI는 새로운 기술 습득과 업무 적응을 위한 핵심적인 도구로 자리잡고 있었습니다.

AI 도구를 어떤 수준의 파트너로 인식하는지에 대한 분석에서도 연차별 차이가 나타났습니다.

고연차 개발자들은 AI 도구를 “전략적 파트너” 수준으로 인식하는 비율이 높았습니다. 이들은 단순한 코드 생성을 넘어 설계 논의와 아키텍처 검토에도 AI를 활용하며, 의사결정 과정에 AI를 참여시키는 성숙한 협업 관계를 구축하고 있었습니다.

중견 개발자들은 AI 도구에 대한 인식과 활용 수준이 가장 다양하게 분포했습니다. 이들은 AI 도구의 가능성을 탐색하면서 자신만의 활용 방식을 찾아가는 과정에 있는 것으로 보입니다.

주니어 개발자들은 AI를 “유능한 동료” 수준까지 신뢰하며 상향식 파트너십을 형성해가고 있었습니다.

직군별 활용의 다양성

직군별로는 각 영역의 업무 특성에 맞는 AI 활용 전략이 자연스럽게 형성되고 있습니다.

백엔드 개발자들은 기존의 안정적인 개발 환경(IntelliJ 등)을 유지하면서 AI 기능을 점진적으로 통합하는 접근을 선호했습니다. 이들은 코드 품질과 안정성을 중시하면서도 AI 도구를 통한 생산성 향상을 적극적으로 추구하는 균형 잡힌 접근을 보여주었습니다.

프론트엔드 개발자들은 반복적인 UI 코드 생성과 상태 관리 로직 자동화에 특화된 AI 도구 활용 패턴을 보였습니다.

AI/ML과 데이터 엔지니어링 분야에서는 모델 생성, 테스트 자동화, 데이터 파이프라인 구축 등에서 상당한 효율성 개선을 경험했다고 응답했습니다.

이러한 분석 결과는 AI 네이티브 전환이 단순히 도구 도입의 문제가 아니라, 각 개발자의 경험 수준과 업무 특성에 맞는 맞춤형 접근이 필요한 조직 문화 변화임을 시사합니다. 제도의 확산 과정에서는 이러한 다양성을 염두에 두고 각각의 특성에 맞는 사례를 공유하는 장을 구축하는 것이 성공의 핵심이 될 것입니다.

개발자 역할 재정의

AI 마일리지 프로그램을 통해 확인된 근본적인 변화는 개발자의 역할이 재정의되고 있다는 점입니다. 단순히 도구가 하나 더 추가된 것이 아니라, 개발자가 소프트웨어를 만드는 방식 자체가 변화하고 있습니다.

‘AI와의 협업’이라는 새로운 업무 방식 등장

‘직접 짜기’에서 ‘지시하고 검증하기’로

AI와의 협업이 능숙해질수록 개발자의 역할은 직접 코드를 짜는 ‘코더’에서, 명확한 지시와 컨텍스트를 제공하고 결과물을 검증하는 ‘코치’까지 확장되는 경향이 나타납니다.

한 시니어 개발자는 이러한 변화를 다음과 같이 설명했습니다. “설계는 ChatGPT와 ‘대화’로 진행하고, 구현은 Claude Code에게 ‘위임’합니다. 회의에 들어가면서 AI에게 작업을 시켜놓고, 돌아와서 결과물을 리뷰하는 방식으로 일하고 있어요.”

이는 단순한 작업 분담을 넘어선 근본적인 사고방식의 변화입니다. 개발자는 더 이상 모든 코드를 직접 타이핑하는 사람이 아니라, 무엇을 만들어야 하는지 명확히 정의하고, AI가 생성한 결과물을 전문가적 관점에서 검증하고 개선하는 역할로 변화하고 있습니다.

비동기 병렬 작업: AI를 자율적인 팀원으로 활용

가장 진보된 협업 패턴을 보인 일부 시니어 개발자들은 AI를 단순히 실시간으로 상호작용하는 대상을 넘어, 시간이 소요되는 작업을 독립적으로 수행하도록 위임하는 ‘비동기 파트너’로 활용하고 있었습니다.

“세션 세 개를 열어놓고 세 개 프로젝트를 동시에 진행하고 있습니다”라고 한 10-15년차 개발자가 설명한 것처럼, 각기 다른 AI 세션에 작업을 맡겨두고 자신은 그 결과물을 리뷰하거나 다른 업무를 처리하는 ‘멀티 에이전트 병렬’ 워크플로우가 등장했습니다.

또 다른 시니어 개발자는 “거의 24시간 AI는 뭔가를 하고 있어요. 그 시간 동안 저는 CS 처리를 하든지 다른 업무를 병행합니다”라고 말했습니다. 이는 AI를 2~3시간 이상 걸리는 작업을 자율적으로 처리할 수 있는 신뢰할 수 있는 동료로 여기기에 가능한 방식입니다.

새로운 영역으로의 도전과 확장

기술 장벽의 극복: ‘지식의 비대칭성’ 해소

AI는 개발자들이 기존에 전문성을 갖추지 못했던 영역의 진입 장벽을 극적으로 낮추는 역할을 했습니다. 이는 생산성 향상을 넘어, 개발자의 역량 범위 자체를 확장시키는 변화입니다.

낯선 언어와 프레임워크 정복의 사례가 대표적입니다. 한 1-3년차 인프라 엔지니어는 평소 자신 있던 언어는 Python이나 Java였는데, AI 덕분에 Go 언어에 대한 기초 지식만으로도 오픈소스에 컨트리뷰션하고 코드를 수정하는 경험을 했다고 말했습니다. “내 실력이 느는 것 같지가 않다”고 표현할 정도로 극적인 변화였습니다.

비전문 분야의 업무 수행도 일반화되고 있습니다. 백엔드 개발자가 익숙하지 않은 프론트엔드 개발을 AI의 도움으로 수행하며, 특히 “스크린샷을 주고 똑같이 화면을 구성해달라”고 요청하는 방식으로 작업 시간을 크게 단축하는 사례가 늘고 있습니다. 한 10-15년차 시니어 엔지니어는 ‘타입스크립트 웹 UI를 하나도 모르는’ 상태에서 AI의 힘만으로 개발을 성공시킨 경험을 ‘아하 모먼트’로 꼽았습니다.

레거시 시스템 분석의 혁신

시간이 오래 걸리고 번거로운 레거시 코드 분석 작업도 AI를 통해 개선되고 있습니다. 한 4-6년차 백엔드 개발자는 레거시 UI 코드를 AI에게 분석시켜 시간을 절약하고, 그 에너지를 더 복잡한 핵심 로직에 투자할 수 있었다고 말했습니다. 이러한 변화는 개발자가 단순 반복 작업에서 벗어나 더 창의적이고 전략적인 업무에 집중할 수 있게 하는 긍정적 효과를 가져오고 있습니다.

품질 투자 시간의 확보: 효율성의 선순환

기술 부채 해결의 기회

AI 도입의 중요한 성과는 단순히 개발 속도를 높이는 것을 넘어, 그로 인해 확보된 ‘잉여 시간과 에너지’를 소프트웨어의 장기적인 품질 향상에 재투자하는 선순환을 만들어냈다는 점입니다.

한 16년차 이상 시니어 개발자는 AI를 통해 생산성이 높아지면서, 과거에는 “항상 매번 제일 백로그 밑에 밑에 밑에 쌓여 있던” 기술 부채를 해결하고, 통합 테스트까지 충실히 작성할 시간을 확보했다고 밝혔습니다. 그는 이를 통해 생산성도 두 세배 증가했지만 품질도 향상되었다고 평가했습니다.

테스트 커버리지의 대폭 확대

테스트 코드 작성에서도 변화가 나타났습니다. 한 4-6년차 개발자는 “사람이 작성하다 보면 100개, 200개 넘어가는 테스트 코드를 짜기 현실적으로 쉽지 않다”며, AI 덕분에 과거라면 “절대 작성하지 않았을” 수백, 수천 줄의 꼼꼼한 테스트 코드를 작성하여 코드 안정성을 높였다고 말했습니다.

내부 도구의 질적 고도화

또 다른 16년차 이상 시니어 개발자는 수동 배치 작업을 위한 CLI 도구를 개발하며, 과거라면 “자동화 구현을 하는 것보다 내가 수동으로 배치를 돌리는 게 더 빨리 끝날 것 같아서” 만들지 않았을 법한 고급 기능(자동 재시도 등)까지 구현했습니다. AI가 개발 시간을 단축시켜준 덕분에, ‘적당한 수준’을 넘어 ‘더 높은 수준’의 완성도를 가진 내부 도구를 만들 수 있었던 것입니다.

역할 전환의 핵심: 상호작용 방식의 진화

‘막연한 지시’에서 ‘구체적 분할’로

성공적인 AI 협업을 위해서는 개발자 자신의 업무 접근 방식도 변화해야 합니다. 한 데이터 엔지니어는 초기에 “이런 기능 개발해 줘”와 같이 포괄적으로 지시했다가 AI가 무한 루프에 빠지는 실패를 경험했습니다. 이후 “하나의 큰 업무를 여러 개의 작은 단위로 쪼개어, ‘하나를 시키고 → 검수하고 → 다음 단계를 진행’“하는 방식으로 전환하며 AI 활용법을 터득했습니다.

‘설계 파트너’로서의 대화

가장 성숙한 단계에 이른 개발자들은 AI를 단순한 구현 도구가 아닌 사고의 파트너로 활용하고 있습니다.

한 시니어 개발자는 구현은 Claude에게 맡기지만, 설계 단계에서는 의도적으로 ChatGPT와 “깐깐한 취향에 맞출 수 있는” 깊은 대화를 나눕니다. 그는 이 과정을 통해 “혼자 할 때보다 훨씬 나은” 아이디어를 얻으며, AI를 자신의 생각을 발전시키는 ‘사고의 파트너’로 활용하고 있었습니다.

새로운 역할의 핵심 역량

AI 시대의 개발자에게 요구되는 핵심 역량이 무엇인지도 명확해지고 있습니다.

• 명확한 요구사항 정의 능력: AI에게 정확히 무엇을 원하는지 전달할 수 있는 커뮤니케이션 스킬
• 컨텍스트 제공 능력: AI가 최적의 결과를 낼 수 있도록 적절한 배경 정보를 제공하는 능력
• 비판적 검증 능력: AI가 생성한 결과물의 품질과 적합성을 전문가적 관점에서 판단하는 능력
• 작업 분해 및 조율 능력: 복잡한 문제를 AI가 처리할 수 있는 단위로 나누고 결과를 통합하는 능력
• 비동기 작업 관리 능력: 여러 AI 에이전트와 동시에 작업하며 전체 프로젝트를 조율하는 능력

이러한 역할 전환은 개발자의 가치를 감소시키는 것이 아니라, 오히려 더 높은 수준의 전문성과 창의성을 요구하는 방향으로 발전시키고 있습니다. AI가 반복적이고 구조화된 작업을 담당하게 되면서, 개발자는 문제 정의, 아키텍처 설계, 품질 보증, 사용자 경험 등 더욱 전략적이고 창의적인 영역에 집중할 수 있게 된 것입니다.

이제 중요한 것은 AI 도구 자체가 아니라, 이 도구와 어떻게 협업하느냐에 있습니다.

시행착오의 패턴 분석: 무엇이 AI 효과를 가르는가

AI 마일리지 프로그램에서 기억해야 하는 원칙 중 하나는 AI 도구가 만능이 아니라는 점입니다. 100여명의 참여자들이 경험한 다양한 성공과 시행착오 사례들을 분석해보면, AI 도구의 효과를 결정하는 것은 물론 도구 자체의 성능도 중요하지만, 같은 성능의 도구라도 업무에 어떻게 사용하느냐, 그리고 어떤 상황에서 사용하느냐에 달려있음을 알 수 있습니다.

실패의 근본 원인: 5가지 핵심 패턴

컨텍스트 부족: 맥락 없는 요청의 한계

AI 도구 활용에서 가장 빈번하게 나타나는 실패 원인은 충분한 맥락 정보를 제공하지 않는 것입니다. 참여자들은 “베이스 코드 맥락이 없어서 불필요한 로직이 많았다”거나 “히스토리가 긴 코드에 잘못된 수정이 많아 재요청·검증 시간이 늘었다”는 경험을 공유했습니다. 특히 대형 코드베이스나 레거시 시스템에서는 AI가 전체적인 맥락을 파악하지 못해 부적절한 제안을 하는 경우가 많았습니다. 이는 AI의 근본적 한계라기보다는 사용자가 적절한 컨텍스트를 제공하는 방법을 아직 체득하지 못했기 때문으로 보입니다.

도구-플랫폼 연동 부족: 격리된 도구의 한계

“특정 도구로 기획하는데 연동된 AI 기능이 없어 도움이 되지 않았다”거나 “회사 배포 시스템과 AI가 연결돼 있지 않아 실수가 우려되어 사용하지 않았다”는 응답에서 보듯이, AI 도구가 기존 업무 환경과 통합되지 않을 때 효과가 제한됩니다. 이는 개별 도구의 성능 문제가 아니라 전체적인 개발 파이프라인 내에서의 통합도 문제로 해석됩니다. 단순히 AI 도구를 도입하는 것을 넘어 기존 워크플로우와의 자연스러운 연결이 중요함을 보여줍니다.

러닝커브와 신뢰 부족: 초기 적응의 어려움

“설문 당시 도구 적응·셋업에 시간이 더 들었다”고 응답하는 이들도 있습니다. 또한 Kotlin 개발자가 기존 IntelliJ 환경에서 Cursor로 넘어가지 못하는 사례 등도 발견되었습니다. 새로운 도구에 대한 초기 학습 비용이 예상보다 높게 존재할 수 있습니다. 특히 기존 개발 환경에 익숙한 개발자들의 경우, 새로운 인터페이스나 작업 방식에 적응하는 데 시간이 걸리며, 이 기간 동안 오히려 생산성이 일시적으로 하락할 수 있습니다. 이는 도구의 문제라기보다는 변화 관리의 문제로 접근해야 할 영역입니다.

검증 비용 증가: 품질 관리의 딜레마

“AI가 만든 코드는 영향 범위 파악이 어려워 리뷰 시간이 늘었다”거나 “실제 수정 작업은 수십 줄인데 AI가 작성한 테스트 코드 수백 줄을 검토해야 해서 부담이 증가했다”는 지적도 있었습니다. 이는 AI가 생성하는 코드의 양과 복잡성이 증가하면서 나타나는 새로운 유형의 문제입니다. 빠른 생성은 가능하지만, 그에 따른 검토 부담이 예상보다 클 수 있음을 보여줍니다.

이미 자동화된 영역: 중복 투자의 비효율

“CI/CD 파이프라인 자체가 이미 자동화 되어서 AI 도움의 여지가 작다”는 응답에서 보듯이, 이미 고도로 자동화된 영역에서는 AI 도구의 추가적 효과가 제한적일 수 있습니다. 이는 AI 도구 도입 시 현재 업무 프로세스의 자동화 수준을 먼저 점검하고, 실제로 개선이 필요한 영역을 식별하는 것이 중요함을 시사합니다.

실험이 알려주는 것

AI 마일리지 프로그램의 결과는 이제는 AI 동료와 함께 일해야 한다는 것을 증명하고 있습니다.

실험적 참여에서 체계적 활용으로

AI 마일리지 프로그램 초기에는 대부분의 참여자들이 개별적이고 실험적인 접근을 보였습니다. 각자 다른 도구를 시도해보고, 자신만의 활용법을 찾아가는 과정이었습니다. 하지만 시간이 지나면서 이러한 개별적 실험들이 점차 패턴을 형성하고, 성공 사례들이 다른 구성원들에게 전파되기 시작했습니다. 서로 도구를 추천하며 입소문을 타는 도구의 선호도가 올라가기도 했습니다.

성공 사례의 자연스러운 확산

설문 결과에 따르면 많은 참여자들이 공식 문서를 참조하면서도 동시에 동료와의 비공식적 소통을 통해 학습했다고 응답했습니다. 개별적으로 발견된 우수 사례들이 팀 내 대화나 코드 리뷰 과정에서 자연스럽게 공유되었음을 시사합니다. 비단 성공 경험 뿐 아니라 다양한 시행착오와 실패 경험에 대한 공유도 함께 이루어졌을 것으로 보입니다.

AI 마일리지 프로그램을 통해 관찰할 수 있었던 것은 단순히 100여명의 개별적 성공이 아니라, 이들의 경험이 팀 단위에서 어떻게 학습되고 공유되며 재생산되는지에 대한 흥미로운 과정이었습니다.