TLDR
- AI 코딩 도구로 '개발 리소스'라는 병목이 사라지고 있다
- 희소성이 '구현 능력'에서 '정의 능력'으로 이동하는 중
- 개발자는 "왜 만드는가"를, 비개발자는 "어떻게 만드는가"를 건드리기 시작했다
- 이걸 '고지전'이라고 부르고 싶은데, 충돌일지 융합일지는 아직 모르겠다
- 확실한 건: 코딩 지식보다 디버깅 마인드셋이 더 중요해 보인다는 것
요즘 흥미롭게 지켜보는 현상이 있다.
2024년까지만 해도 마케터가 A/B 테스트 하나 돌리려면 PM을 설득하고, 스프린트 우선순위 회의에서 개발팀 눈치를 봐야 했다. 그런데 2025년의 마케터는 Claude에게 "랜딩페이지 변형 3개 만들어줘"라고 말하고 30분 뒤 테스트를 시작한다.
기술의 장벽은 확실히 낮아졌다. 그런데 소통의 문제는 여전하다. 개발자와 비개발자는 지금도 서로 다른 언어를 쓴다. "API 엔드포인트 최적화"와 "전환율 개선"은 같은 목표를 가리키면서도 번역이 필요하다.
달라진 건 뭘까? 내가 보기엔 '구현'이라는 병목이 사라지고 있다는 점이다.
개발 리소스가 희소하지 않으면 뭐가 희소해질까?
과거에 "개발 리소스"는 조직 내 가장 귀한 자원이었다. 모든 아이디어는 개발팀의 스프린트에 들어가기 위해 줄을 섰고, 비개발 직군은 그 줄에서 우선순위를 얻기 위해 끊임없이 협상해야 했다. 좋은 아이디어가 6개월 뒤에야 구현되는 일은 예외가 아니라 표준이었다.
AI 코딩 도구가 이걸 바꾸고 있다. ChatGPT는 "로그인 페이지 만들어줘"라는 요청에 즉시 코드를 뱉는다.
그런데 "우리 서비스의 이탈률을 줄이는 온보딩 플로우"를 설계하려면? 고객이 어디서 막히는지, 어떤 가치를 먼저 보여줘야 하는지, 경쟁사 대비 차별점이 무엇인지를 알아야 한다. 이건 AI에게 프롬프트로 위임하기 어렵다.
가치의 중심이 'How'에서 'What'과 'Why'로 옮겨가는 게 아닐까? 아직 확신은 없지만, 그런 방향으로 움직이는 것 같다.
양쪽에서 일어나는 묘한 움직임
흥미로운 건 이 변화가 일방적이지 않다는 점이다.
개발자 쪽에서는 코드 작성의 가치가 희석되면서, 상류(upstream)로 이동하려는 움직임이 보인다. "이거 왜 만들어요?"라는 질문이 더 이상 반항이 아니라 당연한 참여가 되고 있다. 제품의 방향성을 정의하고, 기술적 제약 안에서 최적의 해법을 설계하는 것—이게 새로운 개발자의 역할로 부상하는 것 같다.
비개발자 쪽에서는 반대 방향의 움직임이 있다. 내 경험을 예로 들면:
기존에는 PM을 설득하고, PM이 개발팀에 요청하고, 스프린트 우선순위에서 밀리고... 아이디어가 실현되기까지 평균 3-4주가 걸렸다. AI 도구로 직접 구현하기 시작하니, 협상에 쓰던 시간이 사라졌다. 체감상 5배는 빨라진 느낌이다.
이걸 **'고지전(The Battle for High Ground)'**이라고 부르고 싶다. 개발자는 "왜 만들어야 하는가"라는 고지로, 비개발자는 "어떻게 만들 것인가"라는 고지로—서로 상대방의 영역을 향해 올라가고 있다.
비개발자가 AI 코딩을 잘 활용하려면 뭐가 필요할까?
여기서 재미있는 관찰이 있다. AI 도구로 직접 뭔가를 만드는 비개발자들을 보면, 성공하는 사람들에게 공통점이 있다. 그리고 그건 '코딩 지식'이 아니다.
1. 개념적 이해 (입으로 설명할 수 있는 수준)
코드를 작성할 필요는 없지만, API가 뭔지, 데이터베이스가 어떻게 동작하는지 정도는 개념적으로 알아야 한다. AI에게 올바른 지시를 내리려면 그 정도 맥락은 필요하다.
2. 디버깅 마인드셋
이게 가장 중요한 것 같다. 처음부터 완벽한 결과물은 안 나온다. "안 되면 왜 안 되는지 추적하고, 가설을 세우고, 다시 시도한다"는 사고방식—이게 프로그래밍 지식보다 더 중요해 보인다.
3. 멘탈 모델 레퍼토리
다양한 문제 해결 패턴을 알고 있으면 AI에게 더 정확한 방향을 제시할 수 있다. "이건 캐싱 문제 같은데"라는 감이 없으면 AI도 엉뚱한 방향으로 달린다.
결국 메타 러닝 능력이 중요하다는 건데, 이건 개발자들이 수년간 쌓아온 역량이기도 하다. 비개발자가 이걸 단기간에 습득할 수 있을까? 아직 지켜보는 중이다.
이게 어디로 갈지는 솔직히 모르겠다
이 변화가 어떤 결과를 낳을지, 두 가지 시나리오를 상상해본다.
충돌 시나리오: 개발자는 "기획도 못하면서 코드 건드리지 마세요"라고 하고, 비개발자는 "이제 개발 필요 없어요"라고 응수한다. 조직은 새로운 형태의 사일로에 갇힌다.
융합 시나리오: 개발자는 도메인 이해를 깊게 하고, 비개발자는 기술적 사고방식을 습득한다. 경계가 아닌 그라데이션이 생기고, 역할이 "문제 해결자"로 재정의된다.
어떤 시나리오가 현실이 될지는 조직마다 다를 것 같다. 다만 한 가지 추측을 해보자면, Why-What-How를 모두 사고할 수 있는 '풀스택 사고방식'을 가진 사람이 유리한 위치에 있지 않을까 싶다. (풀스택 개발자가 아니라, 사고방식 차원에서.)
고지전의 승자는 상대방의 언덕을 넘는 사람이 아니라, 두 언덕 사이의 다리를 놓는 사람이 아닐까.
앞으로 어떻게 전개될지 계속 지켜보면서 기록해볼 생각이다.
💬 AI 도구로 마케팅 실행 속도를 높이고 싶으신가요?
10년 차 CRM 마케터가 직접 겪은 시행착오와 실전 노하우를 공유합니다.
- 📧 문의하기
- 📅 30분 커피챗 예약