- AX 프로젝트 담당자가 AI 도구와 API 구조를 깊이 이해하면 할수록, 의사결정의 기준이 '업무 문제가 해결됐는가'에서 '이 구현이 가능한가'로 이동합니다.
- 구현에 매몰되면 원래 해결하려던 문제가 보이지 않게 됩니다. 기능은 완성됐는데 담당 업무에서 실제로 달라진 것이 없는 상황이 이 과정의 결과입니다.
- AX 담당자에게 필요한 역량은 코드 이해가 아니라 업무 문제와 구현 사이의 거리를 유지하는 능력입니다.
기능은 완성됐는데 달라진 것이 없습니다
제조업 중소기업의 AX 프로젝트를 지원했습니다. 목표는 주간 생산 보고서 작성 시간을 줄이는 것이었습니다. 담당자는 두 달 만에 AI 요약 도구를 구축했습니다. 데이터를 불러오고, AI가 요약하고, 정해진 양식으로 출력하는 파이프라인이었습니다.
구축 완료 한 달 뒤 확인했습니다. 담당자는 파이프라인 유지보수에 매주 두 시간을 쓰고 있었습니다. AI 요약 품질이 만족스럽지 않아 출력 후 수작업으로 수정했습니다. 보고서 작성 시간은 줄지 않았습니다. 담당자에게 왜 이렇게 됐다고 생각하느냐고 물었습니다. 답이 인상적이었습니다. '구현하다 보니 이걸 잘 만드는 게 목표가 돼버렸어요.'
구현 매몰은 이렇게 진행됩니다. 처음에는 업무 문제가 목표입니다. 구현이 시작되면 기술적 과제가 나타납니다. 그 과제를 해결하는 것이 점점 더 중요해집니다. 어느 순간 '이 기능이 왜 필요한가'가 아니라 '이 기능을 어떻게 더 잘 만들 수 있는가'가 결정 기준이 됩니다.
코드 이해도가 높아질수록 업무 문제가 흐릿해지는 이유
소프트웨어 공학자 프레드 브룩스는 1987년 논문 'No Silver Bullet'에서 소프트웨어의 복잡성을 두 가지로 나눴습니다. 본질적 복잡성(essential complexity)은 해결하려는 문제 자체의 복잡성이고, 우연적 복잡성(accidental complexity)은 그것을 구현하는 기술의 복잡성입니다. 브룩스의 핵심 주장은, 기술이 발전하면 우연적 복잡성은 줄어들지만 본질적 복잡성은 그대로라는 것이었습니다.
AX 프로젝트에서 구현 매몰이 생기는 이유가 여기에 있습니다. AI 도구의 우연적 복잡성(API 호출 방식, 프롬프트 설계, 출력 파싱)을 이해하고 해결하는 데 인지 자원을 쓰다 보면, 본질적 복잡성(업무 문제가 무엇이고 어떤 상태가 해결된 것인가)에 쓸 공간이 줄어듭니다. 코드 이해도가 높아지는 것과 업무 문제 해결이 가까워지는 것은 다른 방향입니다.
담당자가 AI 도구를 직접 구현하는 구조에서 이 현상이 더 강하게 나타납니다. 구현에 시간을 많이 쓸수록 구현이 목적처럼 느껴집니다. '이 기능이 완성되면 문제가 해결된다'는 믿음이 구현 과정에서 생깁니다. 그 믿음은 틀린 경우가 많습니다.
AX 담당자에게 실제로 필요한 역량
AX 프로젝트에서 담당자가 AI 도구를 전혀 이해할 필요가 없다는 이야기가 아닙니다. 도구의 한계와 가능성을 모르면 잘못된 기대가 생깁니다. 문제는 이해의 깊이가 아니라 이해의 방향입니다.
담당자에게 필요한 이해는 '이 도구가 어떻게 작동하는가'가 아니라 '이 도구가 업무 문제와 어디서 만나고 어디서 분리되는가'입니다. 구현 지식이 업무 문제 정의를 바꾸기 시작하면 매몰이 시작된 것입니다. 업무 문제 정의가 구현 방향을 결정하는 상태가 유지돼야 합니다.
실용적인 방법은 두 가지입니다. 첫째, 프로젝트 시작 전에 '이 프로젝트가 완료됐을 때 업무에서 달라지는 숫자 두 가지'를 문서로 정해두고 구현 기간 내내 그 숫자를 기준으로 씁니다. 구현이 어떻게 되든 그 숫자가 달라지지 않으면 방향을 바꿉니다. 둘째, 구현 담당자와 업무 문제 담당자를 다른 사람으로 두고 주간으로 교차 확인합니다. 같은 사람이 두 역할을 맡으면 둘이 섞입니다.
Ahn Partners 판단: AX 프로젝트 지원 과정에서 관찰한 바에 따르면, 완료 기준을 업무 숫자로 미리 정한 팀은 구현이 중간에 방향을 잃는 경우가 현저히 낮았습니다. 구현 완료 이후 실제 업무 시간 변화를 추적하는 팀과 그렇지 않은 팀 사이에 명확한 차이가 있었습니다. 이는 통제 실험이 아닌 현장 관찰 결과입니다.
한 문장으로 정리하면
AX 프로젝트에서 담당자에게 필요한 것은 코드 이해가 아니라 업무 문제와 구현 사이의 거리를 끝까지 유지하는 능력입니다. 지금 진행 중인 AX 프로젝트에서 업무에서 달라져야 하는 숫자 두 가지가 문서에 없다면, 그것이 먼저입니다.
점검 목록
- AX 프로젝트 시작 전에 완료 기준을 업무 숫자로 정해두었는가
- 구현 과정에서 업무 문제 정의가 변경된 적이 있다면 그 변경 이유가 업무 변화였는가 구현 제약이었는가
- 구현 완료 이후 실제 업무에서 달라진 숫자를 측정하고 있는가