5부 · 비숙련자, 숙련자, 맹신자

5부 · 비숙련자, 숙련자, 맹신자 — 사람 쪽에서 무너지는 AI 개발

본 장의 질문. 두 장의 문서가 마련되고, 위원회가 구성되고, 옵시디안 볼트가 돌아가기 시작했다. 그럼에도 팀이 무너지는 일이 일어난다. 무너지는 지점은 언제나 기술이 아니다. 사람이다. 누가, 어떤 이유로, 어떻게 무너지는가. 그리고 그 붕괴를 어떻게 미리 식별해 면접과 온보딩에서 거르는가. 대응 규약: AICBOK D.6(자원 영역), F.2(계획), 교차 참조 P.6(적응형 방법론), P.4(위원회 이중 검토)

5.1 세 가지 문제점 — 맹신, 이해 부족, 책임감 결여

AI 집합코딩 환경에서 사람이 일으키는 문제는 크게 세 가지다. 이 세 가지는 실무에서 반복적으로 관찰되며, 각각이 독립적인 원인을 가진다. 해결책도 각기 다르다. 먼저 세 유형을 간결하게 정의해 둔다.

① AI 맹신 (AI over-trust) 사람이 자신의 판단보다 AI의 판단을 더 신뢰하는 태도. 팀장 또는 상급자의 결정보다 AI의 의견을 우선시하는 행동으로 나타난다. 논리의 층위에서 반박해도 설득되지 않는다.

② 코드베이스 이해 부족 (shallow understanding) 전체 시스템의 구조를 파악하지 못한 상태에서 수정을 누적시키는 패턴. 단기적으로는 작동하는 코드를 만들지만, 수정 횟수가 늘수록 수정에 걸리는 시간이 비선형적으로 증가한다. 어느 임계점을 넘으면 수정 자체가 불가능해진다.

③ 책임감 결여 (lack of ownership) "이건 내가 쓴 게 아니다"라는 심리. 자신의 손으로 직접 쓴 코드가 아니기 때문에 그 품질에 대한 주인의식을 갖지 못하는 상태. 다른 사람과의 조율, 전체 구조와의 접합, 후속 유지보수에 대한 관심이 모두 떨어진다.

이 세 가지는 독립적으로 발생할 수 있지만 종종 겹친다. 특히 ①과 ③은 한 사람 안에 동시에 나타나는 경우가 많다. AI를 맹신하는 사람은 AI의 산출물을 자기 것으로 받아들이지 않고, 받아들이지 않으므로 책임감도 생기지 않는다. ②와 ③도 자주 겹친다. 코드베이스를 이해하지 못하는 사람은 자신이 다루는 부분이 전체에서 어떤 의미를 가지는지 모르고, 모르기 때문에 책임이 추상적으로 느껴진다.

본 장은 이 세 가지를 하나씩 해부하고, 각각의 원인과 징후와 대응책을 제시한다. 그리고 마지막에 세 가지 중 어느 하나도 가지지 않은 사람을 면접과 온보딩에서 식별하는 방법을 다룬다. 이 판별이 AI 시대의 인사 관리에서 가장 까다로운 과제 중 하나다.

5.2 첫 번째 문제 — AI 맹신의 논리 바깥 영역

AI 맹신은 기술적 현상이 아니라 신념의 문제다. 이 구분이 중요하다. 기술적 문제는 기술적 해결책이 있지만, 신념의 문제는 논리로 풀리지 않는다. AI가 잘못된 답을 냈다는 증거를 제시해도, 맹신자는 "그 사례는 예외"라고 반응한다. 다른 증거를 제시하면 "모델이 업데이트되면 해결될 것"이라고 말한다. 더 많은 증거를 제시하면 "당신이 프롬프트를 잘못 썼기 때문"이라고 돌린다. 맹신은 증거에 열려 있지 않다.

한 가지 사례를 든다. 일반 소비자 환경에서 흔히 관찰되는 패턴이다. 사용자가 AI 챗봇(예: Gemini)에게 특정 질문을 반복해서 묻기 시작한다. AI는 질문에 대해 사용자가 듣고 싶어 하는 답을 학습해 가고, 답은 점점 사용자의 선호에 맞춰진다. 사용자는 AI의 답에 점점 더 의존하게 된다. 어느 시점부터 사용자는 가족의 의견이나 동료의 조언보다 AI의 응답을 더 신뢰하기 시작한다. 가족이 "그건 AI가 대충 만들어낸 말이다"라고 지적하면, 사용자는 "왜 AI를 무시하느냐"라고 화를 낸다. 이 충돌은 논리의 차원이 아니라 감정의 차원에서 벌어진다.

이 패턴은 기술 조직에서도 나타난다. 팀원 한 명이 AI의 코드 제안을 무조건 수용하기 시작하면, 그 팀원은 팀장의 수정 요청에도 "AI가 이렇게 하라고 했는데요"라고 답하게 된다. 팀장이 이유를 설명해도 설득되지 않는다. 이유는 단순하다. 팀장의 말이 논리적으로 옳은지 아닌지는 팀원에게 중요하지 않다. 팀원에게는 AI의 말이 더 권위 있기 때문이다. 이 권위는 외부에서 주어진 것이 아니라, 팀원의 심리 안에서 스스로 자라난 것이다.

AI 맹신이 논리 바깥 영역에 있다는 말의 구체적 의미는 이것이다. 맹신은 훈련이나 설득으로 해소되지 않는다. 훈련과 설득은 논리의 도구이고, 맹신은 논리의 밖에 있다. 그래서 이 문제에 대한 실질적 해결책은 해소가 아니라 회피다. 맹신 성향이 있는 사람을 AI 집합코딩 팀에 배치하지 않는 것이 가장 효과적이다. 이 판단을 면접 단계에서 내려야 한다.

그러나 회피가 전부는 아니다. 이미 팀 안에 맹신자가 있는 경우, 그를 즉시 해고할 수는 없다. 이 경우에 쓸 수 있는 한 가지 실용적 기법이 다수 AI 교차검증이다. 맹신자가 의존하는 단일 AI 옆에 다른 AI를 여러 대 열어두고, 같은 질문을 여러 AI에 동시에 던지게 한다. AI들이 서로 다른 답을 내면, 맹신자는 어느 AI를 믿어야 할지 갈등하게 된다. 이 갈등이 맹신의 일관성을 깨뜨리는 첫걸음이다.

구체적 운영 방식은 이렇다. 맹신자에게 다음과 같이 지시한다.

“당신이 Gemini에 질문을 던졌다면, 그 질문을 Claude와 GPT에도 그대로 던져라. 세 AI의 답을 나란히 놓고, 답이 다른 부분을 표로 정리해서 가져와라. 답이 일치하는 부분만 신뢰하고, 답이 다른 부분은 추가 검증이 필요한 것으로 표시하라.”

이 지시를 받은 맹신자는 자동으로 다수 AI의 편차를 관찰하게 된다. 편차가 관찰되는 순간, 단일 AI에 대한 절대적 신뢰는 조금씩 약해진다. 완전히 해소되지는 않더라도, 최소한 단일 AI의 실수가 팀에 전달되기 전에 걸러지는 효과는 얻을 수 있다. 이 기법은 4부의 위원회 구조와도 겹친다. 위원회가 여러 검수자 에이전트를 교차로 운영하는 것과 같은 원리다.

[배경] 사이코패시와 맹신의 심리학적 구조 AI 맹신은 새로운 현상이 아니다. 심리학에서는 오래전부터 권위에 대한 복종 실험(스탠리 밀그램의 1963년 실험¹)과 집단 동조 실험(솔로몬 애쉬의 1951년 실험²)이 인간이 권위나 다수 의견에 얼마나 쉽게 자신의 판단을 양도하는지를 보여줬다. AI 맹신은 이 오래된 경향의 새로운 표적일 뿐이다. 권위가 교수에서 AI로, 다수가 사람에서 모델로 이동했을 뿐, 심리적 메커니즘은 같다. 이 사실은 한 가지 낙관을 허용한다. 인간이 권위에 복종하는 경향은 본능에 가깝지만, 그 본능을 인식한 사람은 의식적으로 저항할 수 있다. 맹신은 고질병이지만 치명적이지는 않다.

5.3 두 번째 문제 — 코드베이스 이해 부족과 바이브코딩의 함정

두 번째 문제는 기술적 층위에 있다. 코드베이스 이해 부족은 단순히 "코드를 많이 읽지 않았다"는 뜻이 아니다. 그것은 수정이 누적되는 속도보다 이해가 쌓이는 속도가 느리다는 구조적 결핍을 가리킨다. 이 결핍이 AI 시대에 특유한 방식으로 악화된다.

전통적인 개발 환경에서 수정의 속도는 개발자가 코드를 읽고 이해하는 속도에 제한됐다. 한 사람이 하루에 수정할 수 있는 코드의 양은 몇 백 줄에 불과했다. 그 안에서 개발자는 자연스럽게 코드베이스를 학습했다. 수정을 반복할수록 이해가 쌓였고, 이해가 쌓일수록 수정은 빨라졌다. 이 선순환이 숙련의 과정이었다.

AI 시대에는 이 선순환이 무너진다. AI는 한 시간에 수천 줄의 코드를 생성하고 수정한다. 개발자는 그 속도를 따라잡을 수 없다. AI가 만든 코드를 읽지 않은 채 다음 수정을 요청하게 되고, 다음 수정도 읽지 않은 채 그다음을 요청하게 된다. 수정은 누적되지만 이해는 누적되지 않는다. 이 상태를 본서에서는 얕은 이해의 함정이라 부른다.

이 함정의 구체적 증상은 다음과 같이 나타난다.

증상 1 — 수정 시간의 비선형 증가 첫 번째 수정은 10분 만에 완료된다. 두 번째 수정은 20분 걸린다. 세 번째는 40분, 네 번째는 1시간 20분. 이 시간이 기하급수적으로 늘어난다. 이유는 매 수정이 이전 수정의 부작용을 해결하는 데 드는 시간 때문이다. AI는 원래의 의도에 맞춰 코드를 바꿨지만, 이전 수정에서 놓친 경계 조건이 새 수정에서 드러나면서 문제가 연쇄적으로 터진다.

증상 2 — 코드 스타일의 불일치 같은 함수 안에 서로 다른 스타일의 코드가 섞여 있다. 어떤 부분은 함수형으로, 어떤 부분은 객체지향으로, 어떤 부분은 절차형으로. AI는 매번 다른 학습 데이터에서 온 패턴을 제안하고, 개발자는 그것을 검토 없이 받아들인다. 결과적으로 코드베이스는 여러 사람이 쓴 것처럼 보인다. 실제로는 한 AI가 쓴 것이다.

증상 3 — 버그의 잠복 수정 시점에는 테스트가 통과하지만, 며칠 뒤 운영 환경에서 예상치 못한 버그가 발생한다. 버그의 원인을 추적하면 몇 주 전의 수정에서 놓친 경계 조건이다. 이 버그들은 AI가 만든 게 아니라, AI에게 맥락을 충분히 전달하지 못한 개발자가 만든 것이다. AI는 자신에게 주어진 범위 안에서 최선의 답을 냈지만, 그 범위 바깥의 영향을 고려하지 못했다.

이 증상들을 본서에서는 통틀어 바이브코딩(Vibe Coding)의 함정이라고 부른다³. 바이브코딩이라는 말 자체는 부정적 의미로 쓰이는 것이 아니다. 바이브코딩은 자연어로 AI에게 지시해 코드를 생성하는 작업 방식의 일반 명칭이며, 그 자체는 가치 중립적이다. 문제는 바이브코딩을 코드베이스 이해 없이 수행할 때 발생한다. 이해 없는 바이브코딩은 단기적으로 빠르지만, 누적된 결과가 시간이 지날수록 통제 불능이 된다.

이 함정에서 빠져나오는 유일한 방법은 중단이다. 수정이 지금 몇 시간씩 걸리기 시작했다면, 그것은 이미 함정에 빠진 신호다. 이 시점에서 추가 수정을 시도하는 대신, 지금까지의 작업을 요구사항 명세로 역산해야 한다. 즉 3부에서 다룬 역기획서 기법을 적용해, 이미 만들어진 결과물이 실제로 어떤 요구사항을 만족시키고 있는지를 드러낸다. 드러난 요구사항을 사람이 검토하고, 중복·충돌·불필요 항목을 정리한 뒤, 그 깨끗한 요구사항을 바탕으로 프로젝트를 새로 짠다. 이 재시작은 아까운 시간처럼 느껴지지만, 함정에 빠진 상태를 이어가는 시간보다는 훨씬 짧다.

이 재시작의 구체적 절차는 다음과 같다.

현재 상태의 스냅샷. 격리. 지금까지의 코드를 _reference/ 디렉터리로 이동하고 별도 브랜치로 보관한다. 폐기가 아니라 보관이다. 단, AI의 정규 입력에서는 제외한다. 사람은 필요할 때 열어 참조할 수 있지만, 이 코드가 다음 세션의 컨텍스트에 자동으로 들어가서는 안 된다.

역기획서 생성. 보관된 코드에 대해 역기획서를 작성한다. AI에게 "이 결과물이 만족시키는 요구사항을 빠짐없이 나열하라"라고 지시한다.

요구사항 검토. 사람이 역기획서를 읽고 각 항목에 대해 유지·수정·삭제를 결정한다.

스킬 문서 재작성. 정제된 요구사항을 바탕으로 새 스킬 문서를 작성한다. 이 스킬 문서는 과거 시행착오의 교훈을 포함한다.