AI Native 팀 빌딩 여정, 이해라는 병목 - (2)

지난 편에서 드러냄과 판별의 루프 이야기를 했습니다. 시작은 디자이너 채용으로부터 시작했지만 본 편에서는 AI-native 라는 것이 일을 하는데 어떤 의미를 갖는지 좀 더 깊이 적어 보도록 하겠습니다. 이번 편의 주제는 "판별하는 일"에 대한 이야기입니다.

4개월 동안 만든 것

올해 4월에 채용 공고를 올린 같은 달에 다른 일도 시작했습니다. 그 전에 만들어둔 PoC 소스를 열어놓고, 클로드 코드로 어드민을 다시 구축했습니다.

그 뒤로 4개월 동안, 흩어져 있던 프론트와 데이터 처리를 위한 백엔드를 하나로 통일하고 캐릭터 비주얼 모델을 연동하였습니다. 디자이너와 함께 새로운 모델 스타일을 붙였고, 라이브 방송에서 행동과 tts가 연동 되면서 데이터가 쌓이게 만들었습니다. 캐릭터 발화 구조를 다이나믹 프롬프팅으로 바꾸고, TTS를 스트리밍으로 연결했습니다. 영상·이미지 생성 모델을 CLI에서 다루는 미디어 작업 환경을 만들었고, 디자인 판단을 쌓기 위한 RLHF 웹을 따로 세웠습니다.

대부분의 작업을 claude code와 codex를 번갈아 혹은 동시에 사용하고, 중간에 로컬 서버에서 돌리는 모델로 실험을 진행헀습니다. 개발 과정에서의 에이전틱 루프를 만드는 것은 PM의 경험을 갖고 있는 저로서는 비교적 수월했습니다.

경계를 긋는 것

4개월 동안 제 작업의 대부분은 경계를 긋는 일이었습니다. 무엇을 하나의 구조로 볼지 정하고, 서로 무엇을 주고받을지 정하고, 어디까지가 한 세션이 감당할 범위인지 가늠하는 일이 고민의 대부분 이었습니다.

경계가 서면 세션을 여러 개 띄웠습니다. 한쪽이 백엔드를 읽는 동안 다른 쪽은 프론트를 읽고, 또 한쪽은 붙일 모델의 규격과 디테일을 파는 식으로요. 각자 자기 몫을 물고 들어가고, 저는 그 사이에서 결과를 받아 다음 경계를 다시 그었습니다.

한 번 쓰고 마는 세션은 그냥 띄웠다 닫습니다. 그런데 계속 돌아야 하는 일에는 이름을 붙이기로 했습니다. "에드"는 그 이름대로 연금술에 가까운 일을 합니다. 팀의 업무와 생활 전반에서 나오는 잡다한 것들을 들여다보다가, 알려주고 뜯어보고 다음을 제안합니다. "코베니"는 바깥 데이터를 필요한 형태로 가져오고 성실히 서빙합니다. "알폰소"는 라이브 방송과 엔진에서 나온 것을 에드의 도움을 받아 여러 각도로 수치적 분석을 합니다. "픽시스"는 X와 웹을 리서치해 정리하고 리포트로 냅니다.

이름을 붙인 게 취향 문제만은 아니었습니다. 이름이 붙으려면 그게 무엇을 맡고 무엇을 안 맡는지가 명확히 구분되어야 정체성이 생기고, 세션 루프의 역할이 명확해 졌습니다. "경계를 긋는 일이 곧 이름을 짓는 일" 이였다고 느낍니다.

나름대로 순조롭게 역할을 분리할 수 있었고, 혼자 순서대로 했으면 이 기간동안 수행할 수 없었던 결과물들을 이들의 도움을 받아 비교적 빠르게 결과물들을 받아들 수 있었습니다.

병목이 옮겨간 것

PM의 경험에 비추어 보았을 때, 구체화된 기획서를 바탕으로 제품이 만들어지는 건 마법과도 같은 속도였습니다. 이전에는 많은 메이커들과 여러번의 리뷰와 논의를 통해 검토하고 개선해야 했던 부분들이 단 하루 이틀만에 동작하는 결과를 눈앞에 보여줬습니다.

하지만 린 개발 방법론에 따른 제품 개발 이터레이션은 에이전틱 개발의 속도와는 묘하게 맞지 않았습니다. 어느정도 러프하게 큰 구조를 잡고 단계적으로 메이커와 디테일을 잡아나가는 방식은 에이전트가 만들어내는 결과물의 빠른 속도 대비 그 디테일을 잡아야하는 시간을 불필요하게 늘어나게 만들었고, 상세하게 잡아둔 스펙은 중간 개발 과정에서 어떤 리뷰와 방향 점검을 통해 개선을 해나가야할지 모호하게 만들었습니다.
오히려 구체적인 스펙을 상세하게 만들면, 그 결과물를 보고 점진적으로 개선하는 것이 아니라 결과물을 체크하고 설계를 다시 잡고 제로부터 재구현 하는 것이 오히려 만족스러울 정도였습니다.

지난 에이전틱 구현의 경험에서 느꼈던 병목은 개발 속도와 설계 속도의 어긋남이 기존 제품팀의 리듬과 전혀 다르다는 것이였습니다.

이해가 검증을 위한 게 아니라는 것

최근에 가장 인상적으로 보았던 발표는 노션 엔지니어인 Geoffrey Litt의 「Understanding is the new bottleneck」이 였습니다.

그는 AI가 만든 걸 우리가 이해해야 하는 이유가 흔히 "검증하려고" 라고 생각하지만 그건 좀 틀린 생각이라고 주장합니다. 제품을 개발하는 속도와 퀄리티가 좋아지는 만큼 검증을하는 능력도 계속 좋아지고 있고, 그것 역시 인간이 하지 않아도 될 것이라고 봅니다.

그는 오히려 이렇게 얘기합니다.

"You can learn what the agent is doing to make sure you can be an active participant in the creative process. (에이전트가 무엇을 하고 있는지 배워두면, 창작 과정에서 능동적인 참여자로 남을 수 있습니다.)"

그리고 이어지는 말을 들으며 저의 지난 4개월 간 구현이 머릿속을 스쳤습니다.

"It's never just one loop! A project is many, many loops with the agent. You need a rich set of concepts in your mind to think creatively and fluently about how to move something forward. (루프는 결코 한 번이 아닙니다! 프로젝트는 에이전트와 함께 도는 아주 많은 루프죠. 프로젝트를 진행하는데 필요한 풍부한 개념들을 머릿속에 갖추고 있어야 창의적이고 유연하게 사고할 수 있습니다.)"

여기서 저는 "검증"과 "판별"을 다른 의미로 명확히 이해하고 정의할 수 있었습니다.

속도 조절기라는 것

Litt이 본 발표에서 제안하는 도구 중에 퀴즈가 있습니다. 에이전트가 코드 변경을 설명하는 문서 아래에 문제 몇 개를 자동으로 붙여두고, 그걸 못 풀면 그 코드를 남에게 넘기지 않는다는 규칙입니다. 통과 못 하면 다시 읽어야 합니다. 그가 퀴즈를 부르는 이름이 정확합니다.

"Working with AI, it's easy for the loop to run faster than the speed of human understanding. A quiz is a speed regulator. (AI와 일하다 보면 루프가 인간의 이해 속도보다 빨리 도는 일이 쉽게 벌어집니다. 퀴즈는 속도 조절기입니다.)"

결과를 빠르게 만들어내는 것에 집중하는 것이 아니라, 그 중간 이해 과정을 에이전트와 속도를 맞춰 나감으로서 마치 메이커들과 중간 리뷰를 거치는 것과 같은 프로세스를 추가하는 아이디어에 깊이 공감하였습니다.

유창해서 넘어간 것

과거 인지심리학 시간에 배웠던 "illusion of learning(학습의 착각)"이라는 개념이 떠올랐습니다. 인지적으로 뇌는 유창성(fluency)을 느끼게 되면 마치 모든 것을 이해한 것처럼 넘어간다는 겁니다. 술술 읽히는 것은 이해했다는 감각을 만듭니다. 실제 이해와는 별개로요. 그런데 보통 에이전트가 내놓는 것은 유창합니다. 문장이 고르고, 구조가 정연하고, 표가 반듯합니다.

병렬로 돌리면 곱해지는 것

세션을 이리저리 오가면서, 동시에 여러개의 구현 결과물들을 검토하면서, 에이전트의 속도에 맞춰서 나아가려고 애씁니다. 그리고 그과정에서 혹시 모를 환각을 잡아내기 위해서 검증에 집중합니다.

그 과정에서 저는 통합적으로 전체의 흐름과 구조를 관장하고 이해하는 핵심적인 부분을 하나라도 놓치지 않아야 그다음 루프에서 개선하고 나아갈 방향을 명확히 잡을 수 있었을 것입니다.

병렬은 만드는 속도를 곱합니다. 그리고 이해해야 할 양도 같이 곱합니다. 앞쪽만 곱해지길 기대할 근거가 없습니다. 그렇다고 세션을 직렬로 돌리는 것은 에이전트의 능력을 의도적으로 너프하는 것입니다. 그래서는 원하는 만족스러운 결과를 만들어갈 수 없습니다.

이해의 속도가 팀의 속도라는 것

Litt은 발표 끝에서 Alan Kay를 이야기합니다. 50년 전에 이미 컴퓨터가 사람을 가르치는 매체가 될 수 있다고 봤다는 이야기고, 결론은 이렇습니다.

"The point was always to augment, not just automate. We don't have to merely take ourselves out of the loop, we can get deeper in the loop too. (목적은 언제나 자동화가 아니라 증강이었다. 우리는 루프에서 빠져나오는 대신, 루프 안으로 더 깊이 들어갈 수도 있다.)"

저의 판단도 AI-native 조직에서는 루프 안으로 깊이 들어가야만 하는 것이고, 그건 단순히 개인 차원이 아니라 팀 전체가 함께 그 루프안에 깊숙히 들어가며 증강을 통해 이해를 높일 수 있는 구조를 만드는 것입니다.

---

다음 편에서는 그 구조에 대해 써보겠습니다. 제가 생각하는 AI Native 조직의 핵심은 두 가지입니다. 여럿이 같이 일할 때 에이전트가 그 맥락과 이해를 알아보고 거들 수 있는 환경, 그리고 혼자 일할 때도 내 이해와 개입과 작업 맥락을 관리할 수 있는 구조요. 도구를 몇 개 쓰느냐가 아니라 이 둘이 있느냐입니다. 지난 편에서 "매번 설계하는 일"이라고만 던져뒀던 게 이 이야기였습니다.

UNX는 AI 캐릭터가 라이브로 팬과 만나는 순간을 만듭니다. 지금 **AI 콘텐츠 빌더 · 프로덕트 디자이너 · AI 풀스택 엔지니어** 세 자리를 열어두고 있습니다. → [채용 공고]