AI 시대의 일하는 법 — 생산은 AI에게 넘기고 사람은 검증에 집중한다

AI에게 코드를 시키면 분명히 빨라질 줄 알았는데, 어느 순간부터 더 지치기 시작한다. 손으로 짜던 시절에는 내가 한 줄씩 쓰면서 동시에 맞는지 확인했다. 그런데 AI가 한 번에 수백 줄을 쏟아내자, 그 많은 양을 일일이 들여다보며 "이게 맞나" 따지는 일만 남았다. 생산이 거의 공짜가 되니, 이번엔 검증이 병목이 된다.

한 개발자 설문(Sonar의 State of Code 조사)이 이 장면을 숫자로 보여준다. AI 코딩 도구를 쓰는 개발자가 84%, 그런데 그 결과물을 완전히 신뢰하지는 않는다고 답한 비율이 96%다. 그러면서도 커밋 전에 항상 검증한다는 사람은 48%에 그친다. 믿지는 않지만 다 확인하지도 못하는 상태 — 이 간극을 그 조사는 검증 격차(verification gap, 신뢰하지 않는 정도와 실제로 검증하는 정도의 차이)라고 부른다.

이 글의 결론을 먼저 적는다. AI 전환의 핵심은 사람의 주된 일을 생산에서 검증으로 옮기는 데 있다. 단, 모든 걸 검증하려 들면 격차에 깔려 죽는다. 검증할 대상을 잘 골라야 격차가 좁혀진다.

과거의 일꾼과 미래의 일꾼은 일하는 부위가 다르다

과거의 일꾼은 생산과 검증을 한 몸으로 했다. 코드를 직접 짰고, 짜면서 머릿속으로 검산했고, 다 만든 다음 또 검토했다. 생산과 검증이 같은 사람의 같은 손에서 붙어 있었다.

미래의 일꾼은 이 둘을 분리한다. 생산은 AI에게 맡기고, 자신은 검증에 집중한다. Andrej Karpathy가 정리한 관점이 이 분업을 잘 설명한다. 전통적인 컴퓨터는 사람이 명세(specification, 무엇을 어떻게 할지 미리 코드로 적은 것)할 수 있는 것을 자동화하지만, 거대 언어 모델은 사람이 검증할 수 있는 것을 자동화한다는 것이다. 다르게 말하면, 결과가 맞는지 사람이 판별할 수만 있으면 그 앞단의 생산은 통째로 기계에 넘길 수 있다.

다이어그램 설명. 사람이 손대는 자리가 바뀌었다는 걸 보여준다. 사람은 "작업 목표와 검증 기준 설계"에서 시작해, 무엇을 만들지와 무엇을 합격으로 칠지를 먼저 정한다. "AI가 생산"하는 코드와 중간 산출물은 그 다음에 흘러나오고, 사람이 직접 짜지 않는다. 흐름의 무게중심은 마지막 "검증 통과?" 판단에 실린다. 통과하면 "세부 구현 몰라도 신뢰"로 끝나고, 미통과면 검증 기준을 다시 손보는 첫 단계로 되돌아간다. 핵심은 사람의 노동이 만드는 일에서 판별하는 일로 옮겨졌다는 점이다. 흔한 오해 하나를 짚자면, 검증에 집중한다는 게 검증을 더 많이 한다는 뜻은 아니다 — 오히려 다음 절처럼 검증 대상을 줄여야 이 구조가 굴러간다.

함정 — 다 검증하려 하면 도로 지친다

생산을 AI에 넘겼다고 끝이 아니다. 여기서 대부분이 빠지는 함정이 있다. AI가 내놓는 모든 것을 다 검증하려 드는 것이다. 최종 코드뿐 아니라 그 과정에서 나온 중간 산출물, 임시 스크립트, 로그 한 줄까지 전부 들여다보면, 손으로 짤 때보다 오히려 인지 부담이 커진다. 이걸 인지 부하(cognitive load, 머리로 떠안고 추적해야 하는 대상이 쌓여 생기는 부담)라고 부를 수 있다. 이건 정보가 있는데도 이해를 못 하는 이해부채와는 다르다 — 이해의 문제가 아니라, 한꺼번에 좇아야 할 대상이 너무 많아 생기는 부하다. 검증 격차가 좁혀지기는커녕 더 벌어진다.

해법은 검증 대상을 나누는 데 있다. AI가 어떤 경로로 만들었는지가 아니라, 마지막에 내놓은 최종 결과물만 철저히 검증한다. 중간에 무엇을 시도했고 어떤 임시 파일을 거쳐 왔는지는 신경 쓰지 않는다. 그러면 머리가 추적해야 할 대상 자체가 줄어, 인지 부하도 함께 준다.

▲ 전부 검증하는 방식 — 인지 부하가 쌓인다

다이어그램 설명. AI가 내놓은 걸 가리지 않고 다 확인할 때 무슨 일이 벌어지는지 보여준다. "AI 산출물 전부"에서 출발해 코드, 중간 산출물, 로그와 임시파일로 검증 갈래가 셋으로 벌어지고, 그 갈래가 모두 "검증 대상 폭증" 한 곳으로 모인다. 신경 쓸 대상이 곱하기로 늘어나는 구조라, 생산을 위임해 아낀 시간을 검증이 도로 가져간다. 이 그림만 보고 "그럼 검증을 대충 하라는 거냐"로 읽으면 안 된다 — 줄이는 건 검증의 깊이가 아니라 검증의 대상 범위다.

▲ 최종 결과물만 검증하는 방식 — 인지 부하가 준다

다이어그램 설명. 검증 대상을 좁히면 흐름이 단순해진다는 걸 보여준다. "AI 산출물"에서 "최종 결과물만 검증"으로 한 갈래만 이어지고, 그 결과 "추적 대상 감소"로 끝난다. 중간 산출물을 검증 범위에서 덜어냈기 때문에 머리가 좇아야 할 항목이 줄어든다. 이렇게 두 방식을 위아래로 놓고 보면, 같은 AI 산출물을 두고도 검증 범위를 어디에 긋느냐가 부담의 크기를 좌우한다는 게 한눈에 잡힌다.

오리처럼 행동하면 오리라고 믿는다

세부 구현을 안 보고도 어떻게 결과물을 믿는가. 여기서 오래된 경험칙 하나가 답이 된다. 오리 테스트(duck test) — 오리처럼 생기고, 오리처럼 헤엄치고, 오리처럼 운다면, 그건 오리라고 본다는 추론이다. 속을 뜯어보지 않고 겉으로 드러나는 행동만으로 정체를 판단한다.

프로그래밍에는 이미 같은 발상이 덕 타이핑(duck typing, 객체의 타입을 그 이름이 아니라 그 객체가 가진 동작으로 판별하는 방식)이라는 이름으로 자리 잡았다. 결국 신뢰는 속 구현이 아니라 겉으로 드러난 행동에서 온다.

AI가 만든 결과물도 똑같이 다룬다. 그 안의 코드가 어떻게 짜였는지를 한 줄씩 읽어 신뢰를 얻으려 하지 않는다. 대신 사람이 미리 세밀하게 정해 둔 수백 개의 검증을 통과하는지를 본다. 입력에 이렇게 반응하고, 경계값에서 이렇게 동작하고, 실패해야 할 상황에서 제대로 실패한다면 — 오리처럼 행동하니 오리라고 믿는다. 이때 검증은 회귀 테스트(regression test, 바뀐 코드가 기존 동작을 깨뜨리지 않았는지 자동으로 확인하는 테스트) 묶음일 수도, 합격 기준을 적은 평가 항목일 수도 있다. 핵심은 검증이 충분히 촘촘하면, 통과한 결과물은 세부를 몰라도 믿을 수 있다는 점이다. 이 방식이 사람에게 주는 가치는 분명하다 — 코드 한 줄씩 읽느라 쓰던 시간을, 무엇을 합격으로 칠지 설계하는 데 쓰게 된다.

검증 레이어를 만들면 의도부채까지 갚힌다

여기서 한 가지가 더 따라온다. 수백 개의 검증을 짜려면, 먼저 무엇이 옳은가를 스스로 또렷하게 정해야 한다. 어떤 입력에 어떤 출력이 맞는지, 어떤 경계에서 어떻게 동작해야 하는지, 무엇을 실패로 봐야 하는지를 하나하나 적어야 검증이 만들어진다.

이 과정에서 평소 머릿속에만 어렴풋이 있던 "옳음의 기준"이 밖으로 나와 명시적인 형태로 쌓인다. 말로 설명하기 어려웠던 암묵지(暗默知, 몸에 배어 있지만 글로 또렷이 적기 어려운 지식)가 검증 항목이라는 형태로 적힌다. 그래서 검증 레이어를 만드는 일은 의도부채(만들려는 것이 정확히 무엇인지 흐릿한 채 남아 쌓이는 부담)를 갚는 일이기도 하다. 무엇을 원하는지 모호한 상태가 검증을 적는 동안 또렷해진다.

정리하면 이렇다. 우리가 흔히 말하는 부채는 한 종류가 아니다. 코드의 구조가 엉켜 생기는 기술부채(technical debt), 검증 대상이 많아 생기는 인지 부하, 무엇을 만들려는지 흐릿해서 생기는 의도부채가 따로 논다. 그런데 검증에 집중하는 한 수가 이 셋을 한꺼번에 건드린다. 최종 결과물만 검증해 인지 부하를 줄이고, 행동으로 신뢰를 얻어 구현 세부에 매달리는 기술부채를 줄이고, 검증을 적는 동안 옳음의 기준이 또렷해져 의도부채를 갚는다. 부채는 하나씩 따로 갚는 게 아니라, 검증이라는 한 수로 함께 풀린다.

Karpathy는 또 이렇게 말한다. 생각은 위임할 수 있어도 이해는 위임할 수 없다고. 생산을 AI에 넘긴다고 사람이 손을 떼는 게 아니다. 오히려 무엇이 옳은지를 더 또렷이 알아야 검증을 설계할 수 있다. AI 전환에서 사람이 더 중요해지는 자리는 바로 여기, 검증을 설계하는 자리다.

---

참고한 공개 자료:

• Sonar, State of Code Developer Survey — AI 코딩의 현실: https://www.sonarsource.com/blog/state-of-code-developer-survey-report-the-current-reality-of-ai-coding/
• Sonar, AI 코딩의 "검증 격차" 보도자료: https://www.sonarsource.com/company/press-releases/sonar-data-reveals-critical-verification-gap-in-ai-coding/
• IT Pro, 개발자 절반이 AI 코드를 검증하지 않는다: https://www.itpro.com/software/development/software-developers-not-checking-ai-generated-code-verification-debt
• MindStudio, Andrej Karpathy의 검증 가능성 논제: https://www.mindstudio.ai/blog/andrej-karpathy-verifiability-thesis-ai-superhuman-code-fails-car-wash
• Testkube, AI 생성 코드의 신뢰를 지속적 테스트로 쌓기: https://testkube.io/blog/building-trust-in-ai-generated-code-through-continuous-testing
• Wikipedia, Duck test: https://en.wikipedia.org/wiki/Duck_test
• Wikipedia, Duck typing: https://en.wikipedia.org/wiki/Duck_typing

---

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.