엔지니어 출신이 하는 AX는 무엇이 다른가

해결 방식이 다르다

임원에게 처음 받는 질문은 대개 비슷합니다. 우리 조직에서 AI로 무엇을 할 수 있느냐는 것입니다.

답을 하기 위한 해결 방식은 두 가지입니다. 하나는 업무를 인터뷰하고 동종 업계 사례와 대조해 후보 목록과 우선순위를 내놓는 것입니다. 다른 하나는 후보 하나를 골라 그 자리에서 AI에게 맡겨보는 것입니다.

앞의 해결 방식은 다른 조직에서 증명 되었다는 사실에 근거하고, 뒤의 방식은 이 조직 내부에서 직접 돌려본 결과에 근거합니다.

AI 전환(AX)에서는 이 차이가 유독 크게 벌어집니다. 같은 업무명, 같은 도구를 써도 자료의 형태와 판단 기준, 실제로 발생하는 예외가 조직마다 다르기 때문입니다. 다른 조직에서 됐다는 사실이 우리 조직에 그대로 적용되지 않습니다.

이어서 구체적인 사례로 해결 방식의 차이에 대해 자세히 살펴보겠습니다.

---

점수표가 답하지 못하는 것

임원 워크숍에서 실제로 하는 실습이 있습니다. 그 조직의 AX 후보 업무 다섯 개를 뽑아, 다음 기준을 따라 점수를 매겨봅니다.

기준은 기대효과, 실행 난이도, 데이터 준비도, 보안 리스크, 검증 가능성, 확장 가능성입니다. 가중치를 바꾸면 순위가 따라 바뀝니다. 기대효과를 가장 중요하게 볼 때와 단기 검증 가능성을 가장 중요하게 볼 때 무엇이 1순위로 올라오는지를 직접 비교하게 됩니다.

이 실습이 끝나면 리더가 감으로 고르지 않게 되고, 무엇을 왜 골랐는지가 조직 안에 데이터로 남습니다.

그런데 이 표가 답하지 못하는 것이 있습니다.

점수표로는 실현 가능성을 판정할 수 없습니다. 오히려 실험 대기열에 가깝습니다. 1순위로 뽑힌 업무가 막상 돌려보면 안 되는 경우가 있고, 4순위가 일주일 만에 되는 경우도 있습니다. 판정은 맡겨본 다음에 알수 있습니다.

---

그래서 맡겨봅니다

제조·IT 서비스 조직의 후보 목록에서 자주 상위에 오르는 업무가 있습니다. 고객 요구사항을 정리해 제안요청서(RFP) 초안을 만드는 일입니다. 반복적이고, 분량이 크고, 담당자마다 결과가 다릅니다.

이 업무를 쪼개지 않고 통째로 맡겨봅니다. 첫 결과는 형식이 잘나오는 것처럼 보입니다. 목차가 있고 문장이 매끄럽고 분량도 맞습니다. 그런데 세 가지가 어긋납니다.

조건이 빠집니다. 예산 상한, 필수 고지 문구, 금지 조항 같은 것들입니다. 자료 안에 분명히 들어 있는데 결과물에는 없습니다. 잊은 것이 아니라, 문장을 자연스럽게 이어가는 쪽으로 비중이 쏠려서 조건 문장이 빠진 것입니다.

숫자 하나가 틀리면 전파됩니다. 예산을 잘못 읽으면 그 뒤의 사업 규모, 투입 인력, 일정 설계가 전부 틀립니다. 내부적으로 일관되는 것처럼 보이나, 틀린 값이 일관되기 때문에 수정해야 합니다.

초안이 잘 나오면 검증 단계가 생략됩니다. 요구사항 확인, 초안 작성, 사실 검증, 정책 검증이라는 순서를 함께 적어줘도 마찬가지입니다. 그 순서 자체가 지시문 안의 문장일 뿐이라, 초안이 그럴듯하게 나온 지점에서 완료로 처리되고 뒤 단계는 수행되지 않은 채 끝납니다.

그리고 결정적인 문제가 남아있습니다. 모델은 앞에 문제들을 혼자서 해결하지 못합니다. 생성한 주체(모델)가 검토하면 원본 자료와 다시 대조하는 대신, 자기가 만든 결과의 앞뒤가 맞는지만 확인하게 됩니다. 사실 검증이 아니라 일관성 검증인 셈입니다.

여기서, 이 결과를 실패로 보면 도구 탓이나 모델 탓으로 끝납니다. 근본적 해결을 위한 준비로 봐야합니다.

"맡긴다"는 무책임이 아니라 문제 해결의 첫 단계입니다.

이것이 맡·당·쪼의 앞 두 글자가 뜻하는 바입니다. 우선 AI 에게 맡겨보고, 부족한 것을 당연하게 받아들입니다. 부족한 것을 해결하는 과정에서 문제의 본질이 드러나며 구체화 되기 때문입니다.

flowchart LR
    A["맡<br/>업무를 통째로 AI 에게 맡긴다"] --> B["첫 결과<br/>형식은 맞고 조건이 빠진다"]
    B --> C["당<br/>당연히 부족하다. 부족한 점, 즉 한계를 발견한다(문제 구체화)"]
    C --> D["쪼<br/>적당한 단위로 나누어 다시 맡긴다"]
    D --> A
    style A fill:#dbeafe,stroke:#3b82f6,color:#111827
    style B fill:#fee2e2,stroke:#ef4444,color:#1f2937
    style C fill:#fef3c7,stroke:#f59e0b,color:#1f2937
    style D fill:#dcfce7,stroke:#22c55e,color:#111827

---

쪼개면 남는 것

앞에서 발견한 세가지 한계는 각각 다른 해결책이 필요합니다. 조건 누락은 대조 단계를 따로 분리해야 하고, 숫자 오류 전파는 원본과 직접 맞춰봐야 하고, 검증 생략은 통과해야만 다음으로 넘어가는 구조로 해결해야 합니다.

그래서 업무를 동사 단위로 쪼갭니다. RFP 초안 작성이라는 큰 덩어리가 추출·대조·생성·검증으로 나뉩니다. 각 단위에 입력과 통과 기준과 산출물 형식이 붙습니다.

%%{init: {"flowchart": {"subGraphTitleMargin": {"top": 14, "bottom": 14}}}}%%
flowchart LR
    A["요구사항 추출<br/>사내 조건 대조"] --> B["초안 생성"]
    B --> V
    subgraph V["검증 · 생성과 분리된 주체"]
        direction TB
        V1["원본 대조"]
        V2["정책 체크리스트"]
    end
    V -- "미달" --> B
    V -- "통과" --> F["담당자 판단<br/>배점 · 예산 · 법무"]
    F --> G["발송<br/>되돌릴 수 없는 경계"]
    style A fill:#dbeafe,stroke:#3b82f6,color:#1f2937
    style B fill:#dbeafe,stroke:#3b82f6,color:#1f2937
    style V1 fill:#dcfce7,stroke:#22c55e,color:#1f2937
    style V2 fill:#dcfce7,stroke:#22c55e,color:#1f2937
    style F fill:#fef3c7,stroke:#f59e0b,color:#1f2937
    style G fill:#fee2e2,stroke:#ef4444,color:#111827

이 그림에서 중요한 것은 두 가지 기준선입니다. 검증하는 주체가 생성하는 주체와 분리되어 있고, 통과 기준이 지시문 안의 문장이 아니라 모델 밖 문서로 존재합니다. 이 구조를 Harness라고 부릅니다.

그런데 여기서 대개 작업이 멈춥니다. 통과 기준을 적으려는 순간, 좋은 RFP가 무엇인지 조직이 한 번도 합의한 적 없다는 사실이 드러나기 때문입니다.

이 과정을 통해 본질적인 문제를 발견합니다. 선배마다 다르게 가르치던 것, 결재자에 따라 달라지던 것을 문서화하면 조직의 공통 기준을 세울 수 있습니다. AI 자산화에서 가장 오래 걸리는 구간은 도구 선택이 아니라 이러한 합의와 문서화 입니다.

---

왜 진단과 구축을 나눌 수 없는가

디지털 전환(DX)에서는 나눌 수 있었습니다. 시스템이 결정론적이었기 때문입니다. 요구사항을 문서로 확정하면 구현은 그 문서의 번역 작업이었고, 컨설턴트가 명세를 쓰고 구축 조직이 만드는 분업이 더 수월 했습니다.

AX에서는 나누기 어렵습니다. 앞에서 본 세 가지 한계는 어느 진단 문서에도 적혀 있지 않습니다. 예산 숫자가 뒤 문단으로 전파된다는 사실은 인터뷰로도, 벤치마크로도 나오지 않습니다. 맡겨봐야 나옵니다.

순서가 바뀐 것입니다. DX에서 명세는 실험의 입력이었고, AX에서 명세는 실험의 결과입니다.

%%{init: {"flowchart": {"subGraphTitleMargin": {"top": 14, "bottom": 14}}}}%%
flowchart LR
    subgraph DX["DX · 결정론적 시스템"]
        direction TB
        D1["명세를 확정한다"] --> D2["번역해 구현한다"]
        D2 --> D3["명세대로 동작한다"]
    end
    subgraph AXG["AX · 확률적 시스템"]
        direction TB
        A1["맡겨본다"] --> A2["한계 지점이 드러난다"]
        A2 --> A3["그것이 명세가 된다"]
    end
    DX -- "명세의 위치가 바뀐다" --> AXG
    style D1 fill:#f3f4f6,stroke:#6b7280,color:#1f2937
    style D2 fill:#f3f4f6,stroke:#6b7280,color:#1f2937
    style D3 fill:#f3f4f6,stroke:#6b7280,color:#1f2937
    style A1 fill:#dbeafe,stroke:#3b82f6,color:#1f2937
    style A2 fill:#fef3c7,stroke:#f59e0b,color:#1f2937
    style A3 fill:#dcfce7,stroke:#22c55e,color:#1f2937

MIT Project NANDA는 2025년 조사에서 기업 생성형 AI 프로젝트의 95%가 측정 가능한 손익 효과에 이르지 못했다고 보고했습니다. 이 수치는 논쟁의 여지가 있습니다. 저자들 또한 표본 규모와 파일럿 이후 6개월이라는 측정 기간의 한계를 인정했습니다.

다만 제시한 원인은 참고할만 합니다. 조직의 학습 격차입니다. 학습 격차가 클수록 AX 는 성과를 내기 어렵다는 의미입니다. 여기서 학습은 실험의 결과입니다. 문서로만 진행된 프로젝트에는 실험이 없고, 그래서 학습도 할 수 없습니다. AX에서는 실험부터 해야 합니다.

---

"안 됩니다"를 먼저 말할 수 있는 이유

맡겨본 사람만 경계를 압니다. 그리고 경계를 아는 사람만 된다 안 된다를 말할 수 있습니다. 실험 결과를 토대로 판정했기 때문입니다.

또한 구체적인 판정 기준을 세우기 위해서도 먼저 맡겨봐야 합니다. 판정 기준은 감이 아니라 절차로 세울 수 있습니다.

RFP가 세 번째 경우입니다. 발송은 외부에 공개되고 법적 구속을 만들기 때문에 되돌릴 수 없습니다. 그래서 배점과 예산 범위, 법무 조항 선택은 자동화 대상이 아니라 승인 지점이 필요한 과정으로 설계합니다. 자동화하지 않기로 결정하는 것도 설계입니다.

---

가치의 대부분은 사람과 프로세스에 있다는 반론

BCG는 AI 전환의 노력 배분을 알고리즘 10, 기술과 데이터 20, 사람과 프로세스 70으로 제시합니다. 엔지니어가 강한 구간은 앞의 30이고, 가치의 대부분은 뒤의 70에 있다는 지적입니다.

기술적인 실험(10과 20)보다 사람과 프로세스(70)를 바꾸는 것이 더 중요하지 않을까?

비중은 맞습니다. 문제는 순서입니다. 70을 바꾸기 위해 제대로 설계하려면 10과 20이 실제로 무엇을 할 수 있는지 알아야 하고, 그것은 맡겨본 사람만 압니다. 돌아가지 않는 시스템을 전제로 한 프로세스 재설계는 잘 쓰여진 소설에 가깝습니다.

다만, 기술적 실험을 해야하니까 먼저 에이전트부터 만드는 것도 잘못된 방향입니다.

AX 대상은 에이전트가 아니라 업무 흐름입니다. 에이전트는 재설계된 업무 흐름의 구성요소일 뿐입니다.

업무 흐름을 그대로 두고 AI만 얹으면 일하는 방식은 그대로고 검수 부담만 늘어납니다. 앞에서 본 RFP 그림이 실제로 바꾼 것도 도구가 아니라 순서였습니다. 대조를 생성보다 앞으로 옮기고, 검증 주체를 생성 주체에서 분리하고, 승인 검토를 발송 앞에 추가 했습니다. 도구를 먼저 만들고 업무를 나중에 도구에 맞추면 시작되지 않는 AX처럼 중단됩니다.

---

그 사람이 빠지면 무엇이 남는가

추가적인 질문은 위 과정을 통해 조직 내부에서 바뀐 사람이 나가면 무엇이 남을까 입니다. 사람이 바뀌고 조직의 생산성이 올라가지만, 그 사람이 나가도 남는게 있어야 변화가 유지됩니다.

변화를 AX 자산으로 남겨야 합니다. 아래 네 가지가 대표적인 AX 자산입니다.

• 재설계된 업무 흐름 — 무엇을 어떤 순서로 하는지 큰 그림이 있습니다.
• 동사 단위 명세 — 각 단위의 입력·기준·산출물 형식이 문장으로 적혀 있습니다.
• 모델 밖 통과 기준 — 무엇을 통과로 볼 것인지가 문서로 있습니다.
• 승인 경계 — 되돌릴 수 없는 행위는 사람이 승인하는 절차가 있습니다.

여기서 거버넌스의 역할이 바뀝니다. 정책 문서는 위반을 사후에 처벌하고, 통과 기준은 미달을 사전에 차단합니다. 엔지니어가 만드는 AI 거버넌스는 규정집이 아니라 검증 Loop입니다. 그리고 검증 기준의 품질이 곧 Loop의 품질이 됩니다.

다만, 회사가 운영되는 한 기준은 바뀝니다. 규정이 개정되고 결재 라인이 달라집니다. 기준이 바뀌었는데 자산이 그대로면 그 자산은 조직을 옛 기준에 맞추려는 부채가 되고, 자동화되어 있기 때문에 사람의 실수보다 빠르고 일관되게 퍼집니다. 그래서 인수인계의 마지막 항목은 자산의 갱신이 되어야 합니다.

---

마치며

정리하면, 엔지니어 출신이 하는 AX는 해결 방식이 다릅니다. 인터뷰와 사례 대조로 후보를 좁히는 대신, 후보 하나를 AI 에게 맡겨보고, 근본적인 한계를 찾아서 명세로 구체화 합니다.

이 첫번째 해결 방식이 끝났을 때 남는 것도 달라집니다. 한쪽에는 로드맵이 남고, 다른 쪽에는 작동하는 것과 아직 안 되는 것의 목록이 남습니다.

시작하는 방법은 간단합니다. 후보 목록에서 업무 하나를 골라 쪼개지 말고 통째로 AI 에게 맡겨봅니다. 한계가 발견된 지점이 그 조직의 시작점입니다.