AX에서 '무엇을 만들 것인가'보다 중요한 것은 '무엇을 안 만들 것인가'

AX에 대한 관심이 뜨겁다. 어느 한 쪽에선 열정을 다해 모든 것을 AX하고 있는 모양새고, 어느 한 쪽에서는 굉장한 회의감을 느끼는 모양새다.

얼마 전 친구와 친친(친구의 친구분)을 포함해 개발자 3명과 커피챗을 가졌다. 프론트엔드 엔지니어 2명, 백엔드 엔지니어 1명이었는데 다들 AX의 생산성과 효율성에 대해 말하면서도 회의감을 가지고 있었다. 모두가, 굳이 만들 필요 없는 것을 만드느라 리소스만 낭비한 경험, 이미 좋은 서비스가 있음에도 AX를 하고 동료에게 적응을 강요해서 오히려 생산성과 팀워크가 저해된 경험, 그로 인한 수습을 누군가가 해야만 했던 경험 등 AX의 폐해를 보거나 들은 적이 있다고 했다.

아빠와도 요즘 AX에 대한 대화를 많이 하고 있는데, 아빠 또한 비슷한 얘기를 한다. (아빠는 고등학교 시절 집에서 손코딩한 종이를 들고 세운상가의 컴퓨터 가게를 오가며 코드를 돌려보다가 결국 전산학과(...)에 진학해 지금은 AI 기술 PO로 일하고 있는 진성 개발자다) 물론 아빠는 AX를 적극적으로 하는 주체의 입장이다보니 살짝 다른 관점이었다. '[만들 수 있으니까 만드는 거]는 집에서 하면 되고, 회사에서는 [만들어야 해서 만드는 거]를 해야 한다'(...)

아무튼 주변 개발자들의 이런 이야기들을 계속 접하다 보니 기획자로서는 상당히 생각이 깊어질 수밖에 없는 와중, 마침 오늘 또 한 스타트업의 전사적 AX 사례를 인상깊게 읽은 후 이에 대한 개발자의 신랄한 비판글까지 보게 되어 메모 겸 정리해 본다. 글 링크는 첨부하지 않고 따로 메모해두었다.

AX를 할 때 고려해야 할 것

What 이전에 Why

비판글은 사례에 '무엇을 했는지'는 있는데 '왜 그렇게 했는지'가 없다고 지적했다.AI로 며칠 만에 인증 프록시를 제작했고 몇 시간 만에 에디터 동기화 플러그인을 제작했다고 적혀 있었는데, 기존에 잘 만들어진 검증된 오픈소스나 솔루션을 충분히 비교한 뒤에 커스텀을 결정한 것인지 궁금하다고 했다.

제작 비용이 낮아지면 대안 탐색이 상대적으로 비싼 일처럼 느껴진다. "AI로 금방 만들 수 있는데 왜 찾아봐?"가 되는 순간, 검색 30분이면 끝났을 일에 며칠의 시간과 토큰을 태우게 된다는 것이다. 직접 봤다는 기기괴괴 사례도 언급돼 있었다:

- 디자인 툴의 무료 기본 플러그인으로 해결되는 기능을 워크플로우 설계도 없이 며칠간 토큰 십만 원어치를 소모해서 애매한 품질로 재구현함.
- 이 AI slop이 내놓은 산출물들의 뒤처리는 담당 디자이너가 부담함.
- 그런데 그 디자이너는 "AI를 못 쓴다"는 타박을 들음.

→ 대안 탐색 시간은 아무리 AI가 바로 서비스를 만들어줄 수 있다고 해도 절대 줄이면 안 되는 고정 비용이고, '만들 수 있다'는 '만들어야 한다'의 근거가 될 수 없다.

 

ROI를 계산할 것

사례 글은 업무 시간을 몇십 퍼센트 절감했고, 계획 대비 몇십 퍼센트나 적은 리소스를 사용한 것이 성과라고 적고있었다. 이에 대해, 비판글을 작성하신 분은 '그래서 토큰당 ROI는 계산했는지' 궁금해했다. 분자 즉 절감량만 있고 분모(총비용)이 없는데, 어떻게 이게 덮어놓고 성과가 될 수 있느냐는 것이다. 

• 소모한 토큰 비용
• 산출물을 사람이 수정·뒤처리한 시간
• 자체 제작 도구의 유지보수 비용 (만든 순간부터 부채)

총비용에는 위의 것들도 포함되어야 하고, 그것에 '대비'해서 계산해야 성과인 것이지, "하루 N분 절약"은 그 자체로 성과가 될 수 없다고 했다. 무엇을 얼마에 주고 샀는지도 파악하라는 얘기...

 

왜 꼭 그 스택이어야만 했는지 설명할 수 있을 것

개발 지식이라 내가 이해를 못한 부분이지만

• 사내 앱 배포에 Kubernetes — 그 규모에 필요한 부하인가? 람다 같은 가벼운 스크립트 실행으로 만족할 사용자도 많지 않았을까?
• 온프레미스인지 클라우드인지조차 글에서 불명확
• 특정 IDE 선택 — 이미 평판이 갈리는 도구인데, 다른 GUI 대안(예: Windows용 Claude 데스크톱류)은 검토했는가? WSL 세팅은 해준 것인가?
• Windows/macOS 환경 차이는 고려했는가?

요지는 "그 선택이 틀렸다"는 아니었고 독자 입장에서 정보가 너무 없다는 거였다. 선택의 근거가 서술되지 않으면 독자는 합리적 선택인지 과잉 설계인지 판단할 수 없고, 그 사례는 재현 불가능한 정보가 된다는 것

개발자가 아니라서 스택에 대한 이해도가 낮으면 적어도 AI와 함께 스택이 왜 꼭 그것이어야만 할지에 대한 검토를 진행한 후에 작업에 들어가야겠다는 교훈을 얻었음. 추가로, 해당 글에서 배운 것: 기술 선택 기록의 최소 구성

1. 제약조건
2. 후보군
3. 탈락 사유
4. 되돌릴 때의 비용

ADR(Architectural Decision Records) 필요.

근데 이 부분은  내가 의도치 않게 개인 플랜을 사용하면서 습관화된 것 같은 게, 무언가 AI를 가지고 만들 때 내가 해당 스펙을 전혀 모르는 것에 대한 공포와 그로 인한 토큰 낭비에 대한 공포도 커서 무언가를 시작하기 전에 항상 스펙적으로 '꼭 그거여야 하는지'를 집요하게 묻는 버릇을 갖게 됐다. 그리고 이걸 나중에 이관하거나 스펙을 변경할 때 비용과 리스크는 어떨지, 유지보수는 어떨지도 꼭 확인한다.

컨텍스트를 모은 후에 어떻게 관리할지에 대한 고민

사례 글에서는 맥락이 조직의 핵심 자산임을 강조하는데, 비판 글에서는 그 방향성에는 동의하면서도 결국 컨텍스트는 모으는 것보다 썩지 않게 관리하는 게 진짜 문제이고, 그 고민도 해봐야 한다고 했다. 즉 갱신 주기와 폐기 규칙이라는 가드레일이 없는 축적은, 나중에 AI 오답의 원료가 된다.

• 필요한 관리 과제:
  • SSOT: 같은 사실이 여러 문서에 흩어질 때 무엇이 원본인가
  • Stale: 낡은 문서가 남으면 AI가 확신을 갖고 틀린 답을 생성
  • Drift: 문서와 실제 시스템이 시간이 지나며 조용히 어긋남
  • 검색 계층: 문서 수천 개 규모에서 그래프 시각화는 감상용. 임베딩/RAG 기반 검색이 필요

검증까지 넣어야 자동화

• 종료 조건: 에이전트 파이프라인에 "제대로 됐는지 검증"의 기준이 명시되지 않으면, 에이전트는 무한 대기하거나 무비판 통과시킴
• 자기 개선 루프: 만든 자동화가 실제로 효율적인지 측정하고 개선하는 순환이 필요함. 버전 관리 역시 필요함.
• 보안 운영: 시크릿 유출 스캐닝은? Node 버전·패키지 매니저 관리 주체는? npm 공급망 공격이 터지면?

→ 자동화 설계 시 성공 판정 기준과 중단 조건을 먼저 정의한다. 이게 없으면 자동화가 아니라 방치다.

도구 사용을 하게 하는 것도 리소스

사례 글에서는 터미널 미경험자에게 CLI 교육이 장애물이어서 GUI로 진입장벽을 낮춘 뒤 단계를 이전했다고 하는데 비판글은 이 문제의식과 해결은 좋았다고 했다. 그러면서 반대 사례의 에피소드를 들었는데 워크플로우 설계 없이 AI만 강요하는 바람에 도구 미숙이 개인 역량 문제로 전가되고, 산출물 뒤처리는 강요당한 쪽이 부담했다는 거였다.

이게 기획자한테는 좀 다른 의미로 다가왔다. AX라는 게 내부인을 대상으로 하니까 내부인한테 강요까지 가능한 거지, AI로 뭔가를 쉽게 만들 수 있다는 이유로 대충 퉁 만들었다고 해도 고객이 안 쓰면 그만이니까. 

→ 도입 성공 지표는 "몇 명이 쓰는가"가 아니라 "쓰는 사람의 총 작업시간이 줄었는가"

---

마치며

그러니까 정리하면, "무엇을 만들지"도 중요하지만 그보다 더 중요한 것은 "애초에 만들지 않을지" 에 대한 의사결정이라는 것이다. hype에 올라타 "다 되네, 다 해보자"로 가는 건 빠르지만, 그 대가로 비용과 복잡도를 감내해야 할 수도 있다.

나는 예전에 TIL 탐색에 소모됐던 시간을 아끼는 자동화 슬랙봇을 만들면서, 우연찮게 "어떻게 TIL을 편하게 볼까"가 아니라 "왜 우리는 매일 1시간씩 쓰면서도 효율적인 공유와 공부는 못 했는가"가 진짜 문제였다는 것을 깨달았었다. AX도 같을 것이다. "어떻게 AI를 더 쓸까"가 아니라 "왜 이 일에 AI가 필요한가" 부터 고민해야한다.

앞으로 바이브코딩 시 확인하며 진행해야 할 것들

• 제작 전: 기존 대안 후보 3개 + 탈락 사유 기록
• 기술 선택 시: 제약조건 / 되돌리는 비용 기록
• 자동화 설계 시: 성공 판정 기준 / 중단 조건 정의
• 문서 축적 시: 갱신 주기 / 폐기 규칙 설정
• 도입 시: 사용자 학습 비용을 총비용에 포함, 워크플로우까지 설계
• 도입 후: 절감 시간 + 총비용(토큰 + 유지보수 + 뒤처리) 동시 산정

용어 정리

ADR (Architecture Decision Record)	기술 의사결정을 배경·후보·선택 이유·결과로 남긴 문서. "왜 이걸 골랐는가"를 추적하기 위한 기록
AI slop	AI가 대량 생성한 저품질 산출물. 겉보기엔 그럴듯하나 사람이 재작업해야 하는 결과물
하네스(harness)	에이전트를 실행·감시·평가하는 바깥 틀. 검증과 중단 로직을 담당
RAG	질문과 관련된 문서를 먼저 검색해 AI에게 근거로 제공하는 방식. 문서가 많을 때 필수
임베딩	문서를 의미 기반으로 검색 가능하게 수치화한 것. RAG의 기반
SSOT (Single Source of Truth)	하나의 사실은 한 곳에서만 관리한다는 원칙. 사본이 흩어지면 신뢰도 붕괴
Stale (데이터)	갱신되지 않아 낡은 상태의 정보
Drift	문서와 실제 시스템이 시간이 지나며 서로 어긋나는 현상

단일 진실 공급원은 알고 있었는데 그걸 SSOT로 줄여 말하는 것은 처음 알았다...

인프라·배포

Kubernetes (K8s)	여러 서버에 걸쳐 앱을 자동 배치·확장·복구하는 관리 시스템. 규모가 작으면 과잉일 수 있음
람다(Lambda)류 서버리스	서버 관리 없이 함수(스크립트) 단위로만 실행하는 방식. 소규모 자동화에 적합한 경량 대안
CI/CD	코드 변경을 자동으로 검사·빌드·배포하는 파이프라인
온프레미스	외부 클라우드가 아닌 자사 보유 서버에서 직접 운영하는 방식
리버스 프록시	요청을 앱보다 먼저 받아 인증·차단·기록을 수행하는 중간 계층
감사 로그	누가 언제 무엇에 접근했는지 남기는 기록
시크릿 / 시크릿 스캐닝	API 키·비밀번호 등 유출 금지 정보 / 코드에 실수로 포함됐는지 자동 검사하는 도구
공급망 공격	외부 패키지·라이브러리를 경유해 침투하는 공격 방식
패키지 매니저	외부 라이브러리를 설치·버전 관리하는 도구 (npm, pip 등)
WSL	Windows에서 리눅스 환경을 사용하게 해주는 기능