이런 상황이라면
AI 도입 과제를 떠안았지만 기술 배경이 없어 회의에서 고개만 끄덕이고 나오는 사람에게 맞는다. 엔지니어의 보고가 맞는지 틀린지 판단이 안 되고, 질문하면 무지가 드러날까 망설인 경험이 있다면 더 맞는다. 반대로 직접 모델을 다루거나 아키텍처를 설계하려는 사람에게는 내용이 얕게 느껴질 수 있다.
한눈에 보기
비개발자가 AI 프로젝트의 책임자가 되는 일이 흔해졌다. 이 책은 그 자리에 앉은 사람이 겪는 구체적인 곤란을 다룬다. 모델 성능 지표를 읽을 줄 몰라 보고를 그대로 믿는 상황, 데이터가 부족하다는 말이 변명인지 사실인지 판단이 안 되는 상황, 일정이 왜 계속 밀리는지 설명을 들어도 납득이 안 되는 상황이다. 저자는 이런 문제를 "기술을 배워서" 해결하려는 시도가 대개 실패한다고 본다. 코드를 조금 아는 팀장은 어설픈 간섭을 하게 되고, 더 많이 아는 팀장은 엔지니어의 일을 대신하려 든다. 대신 필요한 것은 기술을 모르는 상태에서도 작동하는 판단 틀이다. 무엇을 물어야 하는지, 어떤 답이 위험 신호인지, 어디까지가 자신이 결정할 몫인지를 구분하는 능력이다.
기존 AI 입문서는 비개발자에게 기술을 가르치려 한다. 머신러닝의 원리, 신경망 구조, 프롬프트 작성법을 설명한다. 이 책은 그 방향을 뒤집는다. 팀장의 일은 모델을 이해하는 것이 아니라 불확실성을 관리하는 것이다. AI 프로젝트는 "만들면 된다"가 아니라 "될지 안 될지 해봐야 안다"에 가깝다. 그래서 전통적인 일정 관리와 성과 평가가 작동하지 않는다. 책의 무게는 기술 설명보다 의사결정 구조, 실패를 전제한 계획, 엔지니어와의 언어 차이를 메우는 대화 방식에 실려 있다. 모르는 것을 모른다고 인정한 상태에서 어떻게 책임을 지는가에 대한 책이다.
핵심 인사이트
- 01
기술을 배우는 것보다 질문 목록을 갖는 것이 빠르다
비개발자 팀장이 가장 먼저 하는 선택은 보통 공부다. 강의를 듣고 용어를 외운다. 그런데 이 투자는 회수가 느리다. 3개월을 들여도 엔지니어와 대등한 판단은 불가능하고, 어설픈 지식은 오히려 잘못된 개입을 부른다. 반대로 "이 모델의 실패 사례를 10개 보여달라", "지금 정확도가 떨어지면 누가 손해를 보는가" 같은 질문은 기술 지식 없이도 던질 수 있고 즉시 작동한다. 좋은 질문은 답하는 사람을 정직하게 만든다. 팀장이 모든 것을 알 필요는 없고, 중요한 것이 숨겨지지 않게 만들면 된다.
- 02
AI 프로젝트의 일정은 약속이 아니라 가설이다
일반 개발은 만들 것이 정해져 있어 기간을 추정할 수 있다. AI는 데이터를 넣어보기 전까지 성능이 나올지 모른다. 이 차이를 무시하고 전통적인 일정표를 요구하면 엔지니어는 지키지 못할 날짜를 적게 된다. 실제로 많은 AI 과제가 "일정 지연"으로 보고되지만 사실은 애초에 추정 불가능한 것을 추정한 결과다. 그래서 계획은 완성일이 아니라 판단 시점으로 짜야 한다. "4주 뒤 정확도 70%가 안 나오면 접는다"는 식이다. 일정이 바뀌는 게 실패가 아니라, 언제 멈출지 정하지 않은 게 실패다.
- 03
"데이터가 부족하다"는 말은 세 가지 뜻이다
엔지니어가 데이터 부족을 말할 때 팀장은 대개 수집 예산을 떠올린다. 그런데 이 말에는 전혀 다른 상황이 섞여 있다. 양이 모자란 경우, 양은 많지만 라벨이 없거나 엉망인 경우, 현장 데이터와 학습 데이터의 성격이 달라 쓸 수 없는 경우다. 각각의 해법은 수집, 정제 인력, 설계 변경으로 완전히 다르다. 구분하지 않고 "더 모아라"고 지시하면 비용만 늘고 성능은 그대로다. 팀장이 할 일은 데이터를 이해하는 게 아니라 어느 종류의 부족인지 되묻는 것이다. 이 한 번의 되묻기가 수천만 원의 방향을 바꾼다.
- 04
성능 숫자보다 틀렸을 때의 비용을 먼저 본다
정확도 95%는 좋은 숫자처럼 들린다. 하지만 100건 중 5건이 틀릴 때 무슨 일이 생기는지는 숫자가 말해주지 않는다. 고객에게 잘못된 환불이 나가는 것과 추천 상품이 어긋나는 것은 같은 5%가 아니다. 의료나 금융처럼 한 번의 오류가 치명적인 영역에서는 99%도 쓸 수 없다. 그래서 팀장이 정해야 하는 것은 목표 정확도가 아니라 허용 가능한 실패의 모양이다. 이건 기술 판단이 아니라 사업 판단이고, 엔지니어가 대신 내려줄 수 없는 결정이다. 여기서 팀장의 존재 이유가 생긴다.
- 05
모른다고 말하는 것이 권위를 세운다
기술을 모르는 팀장은 무지가 드러나는 순간 리더십이 무너질까 두려워한다. 그래서 알아듣는 척하고, 회의에서 질문을 삼킨다. 결과는 반대다. 엔지니어는 팀장이 이해하지 못했다는 사실을 거의 항상 알아챈다. 모르는 척하는 상사에게는 설명을 생략하게 되고, 중요한 리스크도 보고 대상에서 빠진다. "방금 설명은 절반만 이해했다, 다시 한 번"이라고 말하는 팀장에게는 정보가 모인다. 신뢰는 아는 양이 아니라 정보를 끌어올 수 있는지에서 나온다.
- 06
AI를 쓸 곳을 고르는 것이 가장 큰 기술적 결정이다
실패한 AI 과제의 상당수는 모델이 나빠서가 아니라 애초에 맞지 않는 문제에 붙였기 때문이다. 규칙 몇 줄로 해결되는 일에 모델을 쓰거나, 데이터가 존재하지 않는 영역에 예측을 요구한 경우다. 이 판단은 코드와 무관하고, 오히려 업무를 아는 사람이 더 잘한다. 반복적이고, 과거 기록이 쌓여 있고, 틀려도 복구 가능한 일이 AI에 적합하다. 비개발자 팀장이 가진 현장 감각은 이 선별에서 엔지니어보다 우위에 있다. 기술을 모르는 것이 약점이 아닌 유일한 지점이고, 그래서 여기에 시간을 가장 많이 써야 한다.
이렇게 적용한다
상황엔지니어가 모델 성능 보고를 했는데 숫자가 좋은지 나쁜지 감이 오지 않을 때
숫자를 해석하려 하지 말고 세 가지를 되묻는다. 틀린 사례 다섯 개를 직접 보여달라고 요청하고, 그 오류가 고객이나 매출에 어떻게 닿는지 묻고, 지금 사람이 하면 몇 퍼센트인지 비교 기준을 요구한다. 세 답을 모으면 기술 지식 없이도 이 숫자가 쓸 만한지 판단이 선다.
상황AI 과제의 일정을 위에 보고해야 하는데 엔지니어가 확답을 못 줄 때
완성일 대신 의사결정 지점으로 보고서를 다시 쓴다. "6주 뒤 출시"를 "3주 뒤 실현 가능성 판단, 가능하면 추가 6주"로 바꾼다. 중단 조건을 숫자로 함께 적어 두면 지연이 아니라 설계된 점검으로 읽힌다. 경영진의 불안은 날짜가 아니라 통제 불가능하다는 느낌에서 오기 때문이다.
상황현업 부서가 "우리 업무에도 AI를 넣어달라"고 요청해 왔을 때
기술 검토를 의뢰하기 전에 세 가지를 먼저 확인한다. 그 업무가 반복되는가, 과거 데이터가 기록으로 남아 있는가, 결과가 틀렸을 때 되돌릴 수 있는가. 셋 중 하나라도 아니면 그 자리에서 거절하거나 범위를 좁힌다. 이 선별을 건너뛰고 넘긴 요청이 나중에 엔지니어 몇 개월을 태운다.
ACTION ITEMS
오늘 바로 할 수 있는 것.
- ✓진행 중인 AI 과제에 대해 "틀린 사례 다섯 개"를 오늘 담당자에게 요청한다.
- ✓다음 회의에서 이해하지 못한 설명 하나를 골라 "다시 한 번 설명해달라"고 말한다.
- ✓가장 중요한 과제의 중단 조건을 숫자로 한 문장 적어 팀에 공유한다.
- ✓"데이터가 부족하다"는 보고를 받았다면 양·품질·성격 중 무엇인지 되묻는다.
- ✓담당 과제가 틀렸을 때 생기는 손해를 금액이나 건수로 한 줄 추정해 본다.
- ✓현업 요청 목록을 꺼내 반복성·기록·복구 가능성 세 칸으로 다시 분류한다.
밑줄 그은 문장
“팀장이 알아야 할 것은 모델이 어떻게 작동하는지가 아니라, 틀렸을 때 누가 다치는지다.”
“모른다고 말하지 않는 리더에게는 아무도 중요한 이야기를 하지 않는다.”
이 책이 답하지 않는 것
모델 선택이나 아키텍처 설계처럼 기술 자체를 다루는 내용은 거의 없어, 엔지니어 출신 리더에게는 새로운 정보가 적다. 조직이 이미 AI 인력을 갖춘 상황을 전제하므로, 외주나 1인 단위로 AI를 도입하는 경우에는 그대로 적용되지 않는다.
이 통찰의 근거가 궁금하다면?
원서·번역서 정보와 가격은 판매처에서 확인하세요.
※ 구매 링크는 제휴 활동의 일환이며, 이를 통해 일정액의 수수료를 제공받습니다. 구매자에게 추가 비용은 발생하지 않습니다.
비슷한 주제의 책
NEWSLETTER
매일 아침, 새로운 인사이트
하루의 시작을 도와줄 책 한 권의 핵심과 실천 과제를 보내드립니다.