TLDR
AI 코딩 도구 확산은 이미 선택지가 아니라 기본값에 가까워졌다. GitHub Octoverse 2024에 따르면 전 세계 개발자의 55%가 AI 코딩 도구를 실제로 사용하고 있고, Stack Overflow Developer Survey 2024에서는 개발자 76%가 AI 도구를 이미 사용하거나 사용 계획이 있다고 답했다. 저는 이 수치를 보면서 "개인이 쓰느냐"의 단계는 끝났고 "조직이 어떤 문제를 더 빨리 정의하느냐"가 다음 경쟁축이 됐다고 느꼈다.
- AI 코딩 도구로 '개발 리소스'라는 병목이 사라지고 있다
- 희소성이 '구현 능력'에서 '정의 능력'으로 이동하는 중
- 개발자는 "왜 만드는가"를, 비개발자는 "어떻게 만드는가"를 건드리기 시작했다
- 이걸 '고지전'이라고 부르고 싶은데, 충돌일지 융합일지는 아직 모르겠다
- 확실한 건: 코딩 지식보다 디버깅 마인드셋이 더 중요해 보인다는 것
요즘 흥미롭게 지켜보는 현상이 있다.
2024년까지만 해도 마케터가 A/B 테스트 하나 돌리려면 PM을 설득하고, 스프린트 우선순위 회의에서 개발팀 눈치를 봐야 했다. 그런데 2025년의 마케터는 Claude에게 "랜딩페이지 변형 3개 만들어줘"라고 말하고 30분 뒤 테스트를 시작한다.
기술의 장벽은 확실히 낮아졌다. 그런데 소통의 문제는 여전하다. 개발자와 비개발자는 지금도 서로 다른 언어를 쓴다. "API 엔드포인트 최적화"와 "전환율 개선"은 같은 목표를 가리키면서도 번역이 필요하다.
달라진 건 뭘까? 내가 보기엔 '구현'이라는 병목이 사라지고 있다는 점이다.
개발 리소스가 희소하지 않으면 뭐가 희소해질까?
AI 시대에 진짜 희소 자원은 코드 작성 시간보다 "정확한 문제 정의"다. GitHub가 2024년에 공개한 연구에서 Copilot 사용 개발자는 과제를 평균 55% 더 빠르게 완료했고 생산성 체감은 88% 높았으며(GitHub, 2024), JetBrains Developer Ecosystem Survey 2024에서도 개발자 78%가 AI 도구가 실무 생산성을 개선한다고 답했다(JetBrains, 2024). 구현 속도가 표준화될수록, 무엇을 만들지 먼저 규정하는 능력이 더 높은 경제적 가치를 갖는다는 결론이 자연스럽다.
과거에 "개발 리소스"는 조직 내 가장 귀한 자원이었다. 모든 아이디어는 개발팀의 스프린트에 들어가기 위해 줄을 섰고, 비개발 직군은 그 줄에서 우선순위를 얻기 위해 끊임없이 협상해야 했다. 좋은 아이디어가 6개월 뒤에야 구현되는 일은 예외가 아니라 표준이었다.
AI 코딩 도구가 이걸 바꾸고 있다. ChatGPT는 "로그인 페이지 만들어줘"라는 요청에 즉시 코드를 뱉는다.
그런데 "우리 서비스의 이탈률을 줄이는 온보딩 플로우"를 설계하려면? 고객이 어디서 막히는지, 어떤 가치를 먼저 보여줘야 하는지, 경쟁사 대비 차별점이 무엇인지를 알아야 한다. 이건 AI에게 프롬프트로 위임하기 어렵다.
가치의 중심이 'How'에서 'What'과 'Why'로 옮겨가는 게 아닐까? 아직 확신은 없지만, 그런 방향으로 움직이는 것 같다.
McKinsey Technology Report 2024는 AI 보조를 받은 개발자가 동일 과업을 55% 빠르게 끝내는 경향을 확인했다고 밝혔고(McKinsey, 2024), Gartner는 2028년까지 엔터프라이즈 소프트웨어 엔지니어의 75%가 AI 코딩 어시스턴트를 사용할 것이라고 전망했다(Gartner, 2024). 저는 이 두 수치를 함께 보면 "개발자가 부족해서 못 한다"는 변명이 점점 통하지 않는 구조로 바뀐다고 본다. 오히려 아이디어를 고객문제, 지표, 우선순위로 해석해주는 사람의 레버리지가 커진다.
양쪽에서 일어나는 묘한 움직임
개발자와 비개발자는 서로의 영역을 침범하는 것이 아니라, 서로의 의사결정 깊이를 공유하는 방향으로 이동 중이다. Stack Overflow Developer Survey 2024에서 76%가 AI 도구를 사용 또는 사용 예정이라고 답했다는 사실(Stack Overflow, 2024)과 GitHub Octoverse 2024의 55% 실사용 수치(GitHub, 2024)는 이 변화가 일부 팀의 실험이 아니라 업계 전반의 구조적 이동임을 보여준다. 저는 이걸 개인 역량 경쟁이 아니라 역할 정의의 재편으로 본다.
흥미로운 건 이 변화가 일방적이지 않다는 점이다.
개발자 쪽에서는 코드 작성의 가치가 희석되면서, 상류(upstream)로 이동하려는 움직임이 보인다. "이거 왜 만들어요?"라는 질문이 더 이상 반항이 아니라 당연한 참여가 되고 있다. 제품의 방향성을 정의하고, 기술적 제약 안에서 최적의 해법을 설계하는 것—이게 새로운 개발자의 역할로 부상하는 것 같다.
비개발자 쪽에서는 반대 방향의 움직임이 있다. 내 경험을 예로 들면:
기존에는 PM을 설득하고, PM이 개발팀에 요청하고, 스프린트 우선순위에서 밀리고... 아이디어가 실현되기까지 평균 3-4주가 걸렸다. AI 도구로 직접 구현하기 시작하니, 협상에 쓰던 시간이 사라졌다. 체감상 5배는 빨라진 느낌이다.
이걸 **'고지전(The Battle for High Ground)'**이라고 부르고 싶다. 개발자는 "왜 만들어야 하는가"라는 고지로, 비개발자는 "어떻게 만들 것인가"라는 고지로—서로 상대방의 영역을 향해 올라가고 있다.
"AI won't replace developers, but developers who use AI will replace those who don't." — Thomas Dohmke, GitHub CEO (2024)
이 문장을 저는 과장된 슬로건으로만 보지 않는다. JetBrains 2024 조사에서 생산성 개선 체감 78%가 확인됐고(JetBrains, 2024), GitHub 2024 연구에서 과업 완료 속도 55% 개선이 재확인되면서(GitHub, 2024), 실제로는 "도구를 쓰느냐"보다 "도구를 써서 어떤 수준의 판단을 하느냐"가 차이를 만든다. 그래서 조직에서 충돌이 생기는 지점도 기술 자체가 아니라 역할 기대치의 업데이트 속도다.
비개발자가 AI 코딩을 잘 활용하려면 뭐가 필요할까?
비개발자가 AI 코딩을 잘 쓰기 위한 핵심은 문법 숙련이 아니라 문제 분해와 검증 루프를 운영하는 능력이다. McKinsey 2024는 AI 보조 개발이 과업 속도를 55% 높인다고 보고했고(McKinsey, 2024), Stack Overflow 2024는 이미 76%가 AI 도구 채택 국면에 들어갔다고 집계했다(Stack Overflow, 2024). 채택률이 높아질수록 차이는 "도구 접근권"이 아니라 "질문 품질과 디버깅 체계"에서 벌어진다는 점이 더 선명해진다.
여기서 재미있는 관찰이 있다. AI 도구로 직접 뭔가를 만드는 비개발자들을 보면, 성공하는 사람들에게 공통점이 있다. 그리고 그건 '코딩 지식'이 아니다.
1. 개념적 이해 (입으로 설명할 수 있는 수준)
코드를 작성할 필요는 없지만, API가 뭔지, 데이터베이스가 어떻게 동작하는지 정도는 개념적으로 알아야 한다. AI에게 올바른 지시를 내리려면 그 정도 맥락은 필요하다.
2. 디버깅 마인드셋
이게 가장 중요한 것 같다. 처음부터 완벽한 결과물은 안 나온다. "안 되면 왜 안 되는지 추적하고, 가설을 세우고, 다시 시도한다"는 사고방식—이게 프로그래밍 지식보다 더 중요해 보인다.
3. 멘탈 모델 레퍼토리
다양한 문제 해결 패턴을 알고 있으면 AI에게 더 정확한 방향을 제시할 수 있다. "이건 캐싱 문제 같은데"라는 감이 없으면 AI도 엉뚱한 방향으로 달린다.
결국 메타 러닝 능력이 중요하다는 건데, 이건 개발자들이 수년간 쌓아온 역량이기도 하다. 비개발자가 이걸 단기간에 습득할 수 있을까? 아직 지켜보는 중이다.
GitHub Octoverse 2024의 55% 도구 사용률(GitHub, 2024)과 JetBrains 2024의 78% 생산성 개선 체감(JetBrains, 2024)은 도구 자체의 유효성을 보여주지만, 저는 현장에서 결과 편차가 매우 크다는 점도 함께 본다. 같은 도구를 써도 어떤 사람은 하루 만에 실험을 끝내고, 어떤 사람은 프롬프트 수정만 반복한다. 차이는 대개 "요구사항을 작게 쪼개고, 에러를 로그 기준으로 해석하고, 다음 가설을 빠르게 세우는 루틴"에 있다. 결국 비개발자에게 필요한 것은 코드를 암기하는 능력이 아니라, 불확실성을 다루는 작업 설계 능력이다.
이게 어디로 갈지는 솔직히 모르겠다
AI 코딩 확산의 종착지는 "개발 대체"보다 "역할 재정의"일 가능성이 높다. Gartner는 2028년까지 엔터프라이즈 엔지니어의 75%가 AI 코딩 어시스턴트를 사용할 것으로 전망했고(Gartner, 2024), Stack Overflow 2024에서 76%가 이미 사용 또는 사용 계획 상태라는 점(Stack Overflow, 2024)은 변화가 예측이 아니라 진행형임을 보여준다. 저는 그래서 누가 코드를 더 많이 치느냐보다, 누가 문제를 더 선명하게 정의하고 협업 구조를 더 빨리 바꾸느냐가 실제 승부라고 본다.
이 변화가 어떤 결과를 낳을지, 두 가지 시나리오를 상상해본다.
충돌 시나리오: 개발자는 "기획도 못하면서 코드 건드리지 마세요"라고 하고, 비개발자는 "이제 개발 필요 없어요"라고 응수한다. 조직은 새로운 형태의 사일로에 갇힌다.
융합 시나리오: 개발자는 도메인 이해를 깊게 하고, 비개발자는 기술적 사고방식을 습득한다. 경계가 아닌 그라데이션이 생기고, 역할이 "문제 해결자"로 재정의된다.
어떤 시나리오가 현실이 될지는 조직마다 다를 것 같다. 다만 한 가지 추측을 해보자면, Why-What-How를 모두 사고할 수 있는 '풀스택 사고방식'을 가진 사람이 유리한 위치에 있지 않을까 싶다. (풀스택 개발자가 아니라, 사고방식 차원에서.)
고지전의 승자는 상대방의 언덕을 넘는 사람이 아니라, 두 언덕 사이의 다리를 놓는 사람이 아닐까.
앞으로 어떻게 전개될지 계속 지켜보면서 기록해볼 생각이다.
McKinsey 2024가 제시한 55% 속도 개선(McKinsey, 2024)과 GitHub 2024의 88% 생산성 체감 향상(GitHub, 2024)은 조직 운영 관점에서 매우 큰 숫자다. 같은 인력으로 더 많은 실험을 돌릴 수 있다는 뜻이고, 같은 기간에 더 많은 학습 사이클을 돌릴 수 있다는 뜻이다. 저는 결국 충돌 시나리오와 융합 시나리오를 가르는 기준이 도구 숙련도보다 "실험-학습-의사결정" 리듬을 팀 전체가 공유하느냐에 있다고 본다.
💬 AI 도구로 마케팅 실행 속도를 높이고 싶으신가요?
마케팅 조직이 AI 코딩 도구를 도입하면 실행 속도와 학습 속도를 동시에 끌어올릴 수 있다. GitHub 2024 연구의 55% 과업 단축과 88% 생산성 체감 향상 수치(GitHub, 2024), JetBrains 2024의 78% 생산성 개선 응답(JetBrains, 2024)은 "도입 자체"보다 "도입 후 운영 체계"가 성과를 만든다는 점을 시사한다. 저는 특히 캠페인 실험 수와 피드백 주기를 KPI로 관리하는 팀에서 체감 개선이 더 크게 나온다고 본다.
10년 차 CRM 마케터가 직접 겪은 시행착오와 실전 노하우를 공유합니다.
- 📧 문의하기
- 📅 30분 커피챗 예약