AI 도입의 목표를 잘못 잡고 있습니다
"AI 도입 잘 하고 계신가요?"라고 물으면, 대부분 코딩 에이전트 활용 수준을 답하십니다.
Claude Code 잘 쓰는 법, 프롬프트 잘 쓰는 법, 스킬·하네스 구축 여부...
그런데 저희가 정의하는 AX의 목표는 코드 작성 자동화가 아니라 SDLC(Software Development Life Cycle) 전체 자동화입니다. 아이디에이션·기획부터 디자인, 개발, QA, 유지보수·버그 수정에 이르는 전 과정을 뜻합니다. 이 모든 단계를 에이전트 친화적으로 개선해야 합니다.
이 범위를 좁게 잡을 때 반드시 나타나는 실수 세 가지를 소개하겠습니다.
실수 1. 저품질 input 클렌징을 개발자가 담당한다
기획이 모호하고 디자인이 컨벤션을 지키지 않아도, 결국 개발 단계에서 알아서 걸러지고 정리됩니다. 문제는 이 클렌징을 사람인 개발자가 매번 반복해서 수행하고 있다는 것입니다.
AI 에이전트에게 개발을 맡기려면, 애초에 에이전트가 오해할 여지 없는 입력을 받아야 합니다. 저품질 input이 개발 단계까지 넘어와서야 걸러진다면, 에이전트도 사람과 똑같이 헤매고 결국 사람이 다시 개입해야 합니다.
해법은 저품질 input이 생산되는 시점에서 바로 경고하고, 그 삽입 자체를 차단하는 것입니다.
- 기획: 모호한 표현이 없고, Ubiquitous Language(용어 통일)를 따르고 있는가
- 디자인: 컨벤션을 준수하고, 기존 컴포넌트를 적절히 재사용했는가
예를 들어 저희는 AI가 생성한 코드를 평가할 때도 Correctness, Accessibility, Code Quality, Efficiency, Maintainability, Design까지 총 6개 차원으로 나누어 측정합니다. 이 중 5개 차원은 코드 텍스트를 정규식·구문 분석으로 스캔해 '코드 위생'을 자동으로 판별할 수 있지만, Design(디자인 컨벤션 준수 여부)만큼은 자동 측정이 훨씬 까다롭습니다. 그만큼 디자인 단계의 input 품질이 낮으면, 뒷단에서 아무리 정교한 코드 리뷰 체계를 갖춰도 걸러낼 방법이 없습니다.
기획·디자인 단계에도 개발 단계와 동일한 수준의 명확한 기준과 자동 점검 체계가 필요한 이유입니다.
실수 2. 코딩 관련 지표를 KPI로 삼는다
AX 성과를 보고할 때 가장 흔히 등장하는 지표는 커밋 수, PR 수, 코드 라인 수입니다.
문제는 이 지표들이 SDLC 전체가 아니라 구현 단계 하나만 보여준다는 것입니다. 구현이 아무리 빨라져도 기획에 3주, QA에 2주가 걸린다면 조직 전체의 생산성은 거의 개선되지 않습니다.
측정 항목을 고를 때는 항상 목표(Goal)를 먼저 정의하고, 그다음 지표를 고르는 순서를 지켜야 합니다. Google의 「Software Engineering at Google」 7장이 제시하는 QUANTS(Tempo, Quality, Attention, Non-linearity, Satisfaction) 프레임이 이 순서를 잡는 데 참고할 만합니다.
SDLC 자동화 관점에서 봐야 할 지표는 다음과 같습니다.
- 단계별 전환 시간: 기획 → 디자인 → 설계 → 구현 → 리뷰 → QA → 유지보수·버그 수정, 각 단계가 얼마나 걸리는가
- 설계 이후 단계별 인간 개입 횟수와 이유: 구현부터 QA까지 사람이 몇 번, 왜 개입했는가
이 지표들이 쌓여야 비로소 "어느 단계가 병목인가"를 알 수 있습니다.
실수 3. 모든 문제 발견을 리뷰·QA에 의존한다
문제가 생기면 대부분 "리뷰를 더 꼼꼼히 하자", "QA를 강화하자"는 결론으로 흘러갑니다.
하지만 리뷰·QA는 문제가 이미 발생한 뒤 잡아내는 마지막 안전망일 뿐입니다. 근본 원인은 다른 곳에 있을 수 있습니다.
- 입력 품질 (기획·디자인 단계의 모호함)
- 작업자의 AI 리터러시 (프롬프트를 얼마나 명확하게 작성하는가)
- 모델 성능 (해당 작업에 적합한 모델을 쓰고 있는가)
- 하네스 구성 (스킬, 서브 에이전트, 검증 체계가 적절한가)
이 네 가지 관점 중 어디가 원인인지 판단하려면, 앞서 말한 모든 단계에 대한 측정이 선행되어야 합니다. 측정 없이는 리뷰·QA를 강화하는 것 외에 다른 선택지가 보이지 않기 때문입니다.
측정을 실제 업무에 어떻게 적용하는지는 이전 글에서 다뤘습니다.
정리하면
- AX의 목표는 코드 작성 자동화가 아니라 SDLC 전체 자동화입니다.
- 저품질 input은 발생 시점에 바로 차단해야 하며, 개발 단계에서 클렌징하면 안 됩니다.
- KPI는 구현 지표가 아니라 단계별 전환 시간과 인간 개입 횟수로 잡아야 합니다.
- 문제가 생기면 리뷰·QA 강화 이전에 입력 품질, AI 리터러시, 모델, 하네스 네 관점에서 원인을 찾아야 합니다.
결국 세 가지 실수는 모두 같은 원인에서 출발합니다. SDLC 전 과정에 대한 측정이 없다는 것입니다. 측정이 없으면 범위를 좁게 잡을 수밖에 없고, 범위를 좁게 잡으면 코드 자동화 그 이상으로 나아가지 못합니다.
