[AI 툴 활용법 ③] 리더는 자신이 아는 것을 말하지 못합니다: AI 시대의 폴라니 역설

원고 제공 | 김혜련 이노핏파트너스 파트너 강사
편집 | 이노핏파트너스 사업기획팀

📜Contents

1. 쓰는 AI와 검토하는 AI 나누기

2. 코덱스가 짚어낸 문제 확인하기

3. 코덱스의 지적도 따져보고 반영하기

4. 한 도구로 안 풀리면 다른 도구에 넘기기

5. 비개발자가 직접 확인할 세 가지 정하기

'AI 툴 활용법' 시리즈 3편입니다. 1편 구글 워크스페이스, 2편 클로드에 이어, 이번 호는 클로드 코드와 코덱스를 함께 쓴 활용법을 다룹니다.

→ 이전 호 보기: AX는 누구 일일까요? 허브와 스포크 사이 회색지대 (111호)

철학자 마이클 폴라니는 이를 "우리는 말할 수 있는 것보다 더 많이 안다"고 표현했습니다.(마이클 폴라니, 『암묵적 영역』, 1966) 경제학자 데이비드 오터는 이 통찰을 자동화 논의에 가져와, 기계가 대신하기 어려운 일의 본질을 설명했습니다. 규칙으로 적을 수 있는 일은 기계가 맡지만, 숙련자의 판단 대부분은 규칙으로 적히지 않는다는 것입니다. 이른바 '폴라니의 역설'입니다. (David Autor, "Polanyi's Paradox and the Shape of Employment Growth", NBER Working Paper No. 20485, 2014.9.)

AI 시대에 이 역설은 리더의 자리로 옮겨 왔습니다. 만드는 비용이 낮아진 지금 중요해진 것은 얼마나 빨리 만드느냐가 아니라, 무엇이 끝난 것인지를 말로 쓸 수 있느냐입니다. 베테랑 리더일수록 좋은 결과물은 한눈에 알아보지만, 그 기준을 적어 달라면 막힙니다. 그런데 AI는 적힌 것만 합니다.

이번 112호는 이 간극을 직접 겪은 기록입니다. 이노핏파트너스의 파트너 강사이자 개발자가 아닌 필자가 한 달간 AI로 기업 홈페이지를 만들며, 스크롤 모션을 수정할 때마다 숫자만 바뀌고 느낌은 그대로이던 반복, 지시서 마지막 줄에 올리기까지 해야 작업 완료를 적어 넣게 된 과정, AI의 지적을 받아들일지 정하고 그 이유를 남긴 판단들이 담겨 있습니다. 결국 필자가 한 일은 머릿속 기준을 글로 옮기는 일이었습니다.

AI로 웹사이트를 만들다 보면 묘한 순간이 옵니다. 화면은 그럴듯하게 완성됐고, AI도 작업을 마쳤다고 합니다. 그런데 이걸 고객에게 보여줘도 되는지 묻는 순간, 선뜻 답하기 어렵습니다. 직접 코드를 짠 사람도 아닌데 무엇을 보고 괜찮다고 판단해야 할까요.

저는 최근 한 달 동안 한 기업의 웹사이트를 구축하면서 이 질문을 자주 마주했습니다. 방문자가 보는 화면뿐 아니라 담당자가 내용을 등록하고 수정하는 관리자 화면도 만드는 작업이었습니다. 개발을 본업으로 해 온 사람은 아니지만, 원하는 기능을 설명하고 AI와 함께 구현했습니다. 코드는 주로 클로드 코드(Claude Code)가 쓰고, 코덱스(Codex)에게는 그 코드를 검토하는 일과 막힌 작업을 넘겨받는 일을 맡겼습니다.

처음에는 AI가 얼마나 빨리 만들어 주는지가 눈에 들어왔습니다. 작업이 쌓일수록 더 중요해진 것은 다른 부분이었습니다. AI의 지적 중 무엇을 받아들일지, 잘 안 풀릴 때 어떻게 방향을 바꿀지, 완성됐다는 결과를 어떻게 확인할지였습니다. 이 글은 그 기준을 실제 사례로 정리한 것입니다.

🔀1) 쓰는 AI와 검토하는 AI 나누기

자기가 쓴 글은 자기가 교정하기 어렵습니다

이번에 맡은 일은 한 기업의 홈페이지 리뉴얼입니다. 방문자가 보는 공개 사이트와, 담당자가 프로젝트·수상 이력·채용 공고를 직접 올리고 고치는 관리자 화면을 함께 만들었습니다.

코드는 클로드 코드(Claude Code, Anthropic의 AI 코딩 도구)가 씁니다. 저는 무엇을 만들지 문서로 정리해 작업을 지시하고, 결과 화면을 확인합니다. 여기까지는 요즘 많이들 하는 방식입니다.

제가 하나 더 붙인 것은 검토를 다른 AI에게 맡기는 것입니다. 작업 하나가 끝나면 합치기 전에 코덱스(Codex, OpenAI의 AI 코딩 도구)에게 코드 리뷰를 받습니다. 코드 리뷰는 회사에서 문서를 결재 올리기 전에 동료가 한 번 읽고 틀린 곳을 짚어 주는 것과 같습니다. 같은 AI가 쓰고 같은 AI가 검토하면, 사람이 자기가 쓴 보고서의 오타를 잘 못 찾는 것처럼 같은 부분을 또 놓치기 쉽습니다.

실제로 돌아가는 순서

한 번의 작업은 이렇게 흘러갑니다.

1. 제가 작업 지시서를 씁니다 (무엇을, 어떤 기준으로, 무엇은 하지 말 것)

2. 클로드 코드가 코드를 쓰고, 저는 화면을 확인합니다

3. 코덱스가 바뀐 코드를 읽고 문제를 중요도별(P1 반드시 고칠 것, P2 고치면 좋은 것)로 짚습니다

4. 저는 지적 하나하나를 고칠지, 고치지 않을지 정하고 그 이유를 파일로 남깁니다

5. 합치면 2분 뒤 시험용 서버에 자동으로 올라갑니다

작업 하나에 커밋(코드 변경을 저장하는 단위) 네다섯 개, 검토 반영까지 대략 두 시간 반이 걸렸습니다. 이 글에서 말하려는 것은 대부분 4번에서 생겼습니다.

🔎2) 코덱스가 짚어낸 문제 확인하기

사람 눈으로는 조금 좁아 보이는 정도였던 문제

디자인 시안에는 본문 폭이 1760픽셀로 정해져 있었습니다. 그런데 실제로 만들어진 화면은 본문이 1600픽셀이었습니다. 좌우 여백 80픽셀씩이 1760 안쪽으로 들어가 버린 것입니다. 화면으로 보면 "조금 좁은가?" 싶은 정도라 넘어가기 쉬웠습니다.

코덱스는 이걸 코드의 계산 방식 문제로 정확히 짚었습니다. 더 놀라웠던 것은 이전에 쓰던 코드도 같은 문제를 안고 있었는데 아무도 몰랐다는 점입니다. 바깥 폭 1920, 안쪽 본문 1760으로 고쳐서 합쳤습니다.

자바스크립트가 안 돌면 글자가 안 보이는 문제

회사 소개 페이지에는 스크롤을 내리면 문장이 아래에서 위로 떠오르는 모션이 들어갑니다. 코덱스는 이 모션의 "시작 상태", 즉 글자가 투명한 상태가 서버에서 내려주는 HTML에 그대로 박혀 있다고 지적했습니다. 자바스크립트(웹 화면에 움직임을 넣는 프로그래밍 언어)가 늦게 뜨거나 실패하면 그 문장들이 영영 안 보이는 채로 남습니다. 제가 확인해 보니 투명 처리가 14군데 들어 있었습니다.

검색엔진에 잘 노출돼야 하는 공개 사이트에서 이건 작은 문제가 아닙니다. 글자는 항상 보이는 상태로 내보내고, 자바스크립트가 돌 수 있을 때만 숨겼다가 떠오르게 바꿨습니다. 코덱스에 다시 검토를 받아 "해결됨"을 확인했습니다.

두 사례 모두 제가 코드를 읽어서 찾을 수 있는 문제가 아니었습니다. 이런 것은 검토 AI에게 맡기는 편이 맞습니다.

⚖️3) 코덱스의 지적도 따져보고 반영하기

"옛 주소를 살려 두세요"라는 지적

상세 페이지 주소를 알아보기 어려운 긴 영문·숫자 조합에서 사람이 읽을 수 있는 이름으로 바꾸는 작업이 있었습니다. 코덱스는 가장 중요한 등급(P1)으로 "기존 주소로 들어오는 사람이 빈 페이지를 보게 되니 옛 주소를 살려 두라"고 했습니다.

일반론으로는 맞는 말입니다. 그런데 이 사이트는 아직 문을 열기 전이었습니다. 새 사이트는 시험용 주소에만 올라가 있었고, 옛 주소가 검색엔진에 등록되거나 밖으로 공유된 적이 없었습니다. 곧 데이터를 새로 넣으면서 옛 주소 자체가 전부 사라질 예정이기도 했습니다. 옛 주소를 살려 두면 오히려 같은 내용이 주소 두 개로 열려 검색 노출에 불리해집니다. 그래서 이 지적은 따르지 않았습니다.

같은 리뷰의 두 번째 지적(P2, 새 주소가 옛 주소 형식과 겹칠 수 있다)은 반영했습니다. 실제로 일어날 가능성은 낮았지만, 고치는 데 조건 한 줄이면 됐고 데이터를 넣기 직전이라 지금 고치는 게 가장 쌌기 때문입니다.

"서버가 여러 대로 늘면 제한이 풀립니다"라는 지적

관리자 화면에서 AI로 이미지를 만드는 기능에 "10분에 6번까지"라는 사용 제한을 걸었습니다. 이미지 생성은 비용이 들기 때문입니다. 코덱스는 "서버가 여러 대로 늘어나면 서버마다 따로 세서 제한이 풀린다"고 지적했습니다.

그런데 배포 설정을 열어 보니 이 서비스는 서버가 최대 한 대까지만 뜨도록 되어 있었습니다. 게다가 이 기능은 담당자 몇 명만 쓰는 관리자 전용입니다. 코덱스는 바뀐 코드만 읽었고, 배포 설정 파일은 보지 않았던 것입니다. 코드는 그대로 두고, 비용 상한은 OpenAI 쪽 예산 한도로 걸기로 했습니다.

코덱스가 모르는 것은 사람이 압니다

두 경우 모두 코덱스의 판단이 틀렸다기보다 코덱스가 볼 수 없는 정보가 있었습니다. 사이트가 언제 열리는지, 서버를 몇 대로 돌리는지, 그 기능을 누가 쓰는지는 코드에 적혀 있지 않습니다. 프로젝트를 진행하는 사람이 압니다. 비개발자가 들어가서 판단할 수 있는 곳이 바로 여기입니다.

반대의 경우도 있었습니다. 첫 주에 코덱스가 "데이터를 못 불러오면 빈 화면이 나간다"고 한 곳을 짚었는데, 실제로 찾아보니 같은 문제가 한 곳이 아니라 여섯 곳이었습니다. 지적을 그대로 옮겼다면 절반도 못 고쳤을 것입니다. 지적은 원래 코드와 맞춰 본 뒤에 받아들입니다.

🔄4) 한 도구로 안 풀리면 다른 도구에 넘기기

숫자만 바꾸는 수정이 반복될 때

도구를 나눠 쓰는 이유가 검토만은 아닙니다. 회사 소개 페이지에 스크롤 모션 두 가지를 넣을 때였습니다. 하나는 서비스 소개 다섯 칸이 스크롤에 맞춰 차례로 열리는 모션이고, 다른 하나는 왼쪽 제목을 화면 가운데 고정해 두고 오른쪽 문구 세 개("이해하고 · 설계하고 · 구축하고")가 차례로 넘어가는 모션입니다.

클로드 코드로 만든 첫 결과는 느낌이 달랐습니다. 다섯 칸이 너무 늦게 열려서 세 칸쯤 열렸을 때 이미 화면 밖으로 지나가 버렸고, 나머지 두 칸은 볼 수조차 없었습니다. 오른쪽 문구는 가운데에서 한참 멈췄다가 뚝뚝 끊기며 넘어갔습니다. 그대로 설명해 수정을 요청하자 클로드 코드는 숫자를 줄였습니다. 칸이 열리는 스크롤 구간을 절반 이하로 줄이고, 문구가 멈춰 있는 길이도 절반으로 줄였습니다. 더 빠르게 원하면 더 줄이겠다는 제안도 붙었습니다. 그래도 제가 원하던 움직임은 아니었습니다.

같은 요청을 코덱스에 넘겼습니다

같은 요청을 코덱스의 모델 Sol에 넘겼습니다. 코덱스는 먼저 코드를 읽고, 디자인팀이 준 모션 문서의 값이 코드에서 임의로 줄어 있다는 것부터 짚었습니다. 그리고 숫자를 더 줄이는 대신 움직이는 방식을 바꿨습니다. 문서의 값은 되돌려 놓고, 처음에는 첫 칸 하나만 보이다가 다음 영역이 화면을 반쯤 차지할 때까지 나머지 네 칸이 차례로 열리게 했습니다. 오른쪽 문구는 가운데에서 짧게 멈추고, 다음 문구가 오기 직전에 이전 문구가 빠르지만 부드럽게 사라지게 했습니다.

인상적이었던 것은 확인 방식입니다. 코덱스는 브라우저로 페이지를 직접 열어 스크롤하면서 값을 쟀습니다. "스크롤 410픽셀 지점에서 다섯 칸이 모두 열린다", "이전 문구의 진하기가 1.00, 0.96, 0.64, 0으로 줄어든다" 같은 식으로 보고했습니다. 요청을 넘기고 26분 만에 끝났고, 저는 화면을 보자마자 "딱 맘에 들어"라고 답했습니다. 코덱스는 이어서 이 작업 전체를 검토하면서, 회사 지표 숫자가 스크롤하기 전에는 전부 0으로 나가서 검색엔진에는 0으로 보인다는 문제도 찾아냈습니다. 합치기 전에 고쳤습니다.

이 모션은 그 뒤 디자인 시안이 바뀌면서 지금 페이지에는 남아 있지 않습니다. 그래도 이 경험 뒤로 기준을 하나 정했습니다. "수정을 요청할 때마다 숫자만 바뀌고 느낌이 그대로라면, 설명을 더 다듬기보다 다른 도구에 넘겨 봅니다." 그렇다고 어느 AI가 모든 일을 더 잘한다고 결론 내리지는 않았습니다. 이 작업에서는 코덱스가 풀었고, 다른 작업에서는 반대인 경우도 있습니다. 원하는 결과가 무엇인지 설명하고, 나온 결과를 확인하는 일은 어느 도구를 쓰든 제 몫이었습니다.

✅5) 비개발자가 직접 확인할 세 가지 정하기

한 달 동안 코덱스 지적을 스무 건 넘게 따져 보면서 정리한 기준입니다.

첫째, 이 지적이 우리 상황에서도 사실인지 봅니다. 코덱스는 코드에 적힌 것만 봅니다. 오픈 일정, 서버 설정, 쓰는 사람은 사람이 확인해야 합니다. 3장의 두 사례가 여기에 해당합니다.

둘째, 고치는 비용과 안 고쳤을 때의 손해를 비교합니다. 일어날 가능성이 낮아도 조건 한 줄로 막을 수 있으면 지금 고칩니다. 반대로 가능성이 낮고 고치는 데 며칠이 걸리면 기록만 남기고 넘어갑니다.

셋째, 검토한 대상이 맞는지 봅니다. 한번은 코덱스가 이미 고쳐 둔 문제를 다시 지적한 적이 있습니다. 제 컴퓨터에서는 고쳤는데 공유 저장소에 올리지 않아서, 코덱스가 어제 버전을 보고 있었던 것입니다. 리뷰 자체는 정확했지만 하루가 헛돌았습니다. 그 뒤로 작업 지시서 마지막 줄에 "올리기까지 해야 작업 완료"를 적어 둡니다.

🏁 맺으며

이런 경험을 거치며 AI에 일을 맡기는 방식도 달라졌습니다. 이제는 "잘 만들었는지 봐 줘"라는 요청만으로 끝내지 않습니다. 문제가 있다는 답이 오면 어떤 상황에서 생기는지, 사용자는 무엇을 겪게 되는지, 어떻게 확인할 수 있는지 다시 묻습니다. 설명을 읽고 이해한 뒤에는 실제 화면에서 그 조건을 확인합니다. "한 AI의 검토를 받았다는 이유만으로 검증이 끝났다고 여기지는 않습니다."

기업에서 AI를 업무에 적용할 때도 비슷하게 시작할 수 있습니다. 일을 통째로 맡기기 부담스럽다면, 이미 만든 결과물 하나를 AI에게 검토하게 해 보는 것입니다. 견적서의 합계와 조건이 맞는지, 안내문에서 고객이 오해할 부분은 없는지처럼 사람이 확인 기준을 세울 수 있는 일부터 시작하면 됩니다. 지적을 받는 데서 끝내지 말고, 실제 문제인지 확인하고 반영 여부를 정해 그 이유를 적어 두는 데까지 해 보시길 권합니다.

비개발자로서 AI 코딩 도구를 쓰며 얻은 자신감은 "이제 코드를 몰라도 모든 것을 만들 수 있다"는 종류가 아닙니다. 모르는 문제가 나왔을 때 원인을 물어볼 수 있고, 한 도구로 안 되면 다른 도구로 다시 시도할 수 있으며, 확인할 조건을 더 구체적으로 잡을 수 있다는 자신감에 가깝습니다. AI 덕분에 직접 다룰 수 있는 일의 범위는 넓어졌습니다. 그만큼 무엇을 완성으로 볼지도 더 분명하게 말해야 했습니다.

저는 지금도 AI가 작업을 마쳤다고 하면 화면을 다시 열어 봅니다. 고객이 실제로 누를 버튼을 눌러 보고, 글이 잘리는 곳은 없는지 살핍니다. 그런 확인을 거쳐야 비로소 제 작업도 끝납니다.

필자가 한 달 동안 한 일은 머릿속 기준을 지시서의 한 줄로 바꾸는 연습이었습니다. 이는 타고난 감이 아니라 훈련할 수 있는 역량입니다. "개인에게만 맡겨 두면 베테랑의 판단 기준은 그 사람 머릿속에 머물고, 조직 단위로 꺼내 쓰기 시작하면 AI 시대의 자산이 됩니다."

🤝 이노핏파트너스는 이렇게 함께합니다

리더가 머릿속 기준을 '완료 기준'으로 써보는 것부터,
AI가 만든 결과를 보고 받아들일지 판단하는 의사결정까지,
실제 팀 과제로 함께 교육합니다.

→ 리더 AI 활용 역량 실전 과정