Teams · 2026.08.11

AI Native 팀 빌딩 여정의 시작 - (1)

by 동녘

올해 4월에 올렸던 채용 공고를 다시 읽어보며 생각을 정리해 보았습니다.

우리는 회사를 처음 시작할 때부터 AI native 팀 구조를 생각했고, 많은 사람들이 같은 생각으로 팀에 대한 고민을 하고 있었기 때문에 그 고민을 살펴보는건 어렵지 않았습니다.


올해 4월에 우리가 알던 것

AI native 조직에 대한 글은 대개 구조를 먼저 그립니다. 현재 일하는 방식과 구조에 맞춰서 어떻게 바꿀지 고민하기 위해 원칙을 세우고, 역할을 나누고, 그다음 사람을 찾습니다. 저희는 반대로 했습니다. 정확히는 그렇게 할 수 가 없었습니다.

처음 4월 채용 공고 제목은 AI-native Creative Designer 였습니다. 그 때 쓴 문장을 다시 읽어보면 이렇습니다.

"우리는 AI를 단순히 도구가 아니라, 팀 전체의 일하는 방식에 녹입니다. 기존 디자인을 잘하는 사람보다 서브컬쳐를 좋아하고 이해하며, 캐릭터와 콘텐츠를 좋아하고 서비스를 '만들 줄 아는 사람' 을 찾습니다."

지금 봐도 방향은 맞습니다. 디자인 스킬보다 만들 줄 아는게 중요하다는 것도, AI를 도구가 아니라 일하는 방식으로 본다는 것도요.
제품 디자인과 콘텐츠가 결국 다른 일이 될 거라는 감도 있었습니다. 그런데 어디서 갈라지는지는 몰랐고, 일단 하나로 합쳐두었습니다. 솔직히 말하면, AI 네이티브 조직이 어떤 구조여야 하는지를 정해놓고 사람을 뽑을 수 있다고 생각하지 않았습니다. 그림을 먼저 그릴 수 없는 상황 이였으니까요.

만들 것을 몰라서는 아니었습니다. AI 캐릭터가 라이브로 팬을 만난다는 것도, 그걸 위해 뭐가 필요한지도 대체로 알고 있었습니다. 모르던 건 다른 쪽이었습니다. 그 일을 AI 네이티브로 한다는 게 실제로 어떤 모양인지는 실제로 해보면서야 이해가 되었습니다.


4개월 동안 알게 된 것

일단 저희의 방향과 생각에 공감하는 사람들을 만나면서 정리하게 된 건 직무 목록이 아니었습니다. "AI와 일한다는 게 결국 하나의 루프를 도는 일"이라는 거였습니다.

에이전트가 뭔가를 만듭니다. 사람이 그걸 봅니다. 보고 나서 이건 맞고 저건 아니라고 말해줍니다. 그 말이 다음 결과를 바꾸며 반복합니다.

써놓고 보면 당연한데, 실제로 해보면 두 번째에서 막힙니다. 에이전트가 뭘 했는지 잘 안 보입니다.

캐릭터가 방송 중에 왜 저 채팅에 반응하고 이 채팅은 넘겼는지, 100 장 중에 왜 하필 저것들이 나왔는지. 흐름이 안 보이면 판별할 수 없고, 판별할 수 없으면 방향을 줄 수 없습니다. 그러면 남는 선택지는 그냥 받아들이거나 버리는 것 뿐입니다.

그래서 이 루프에는 두 가지가 다 필요했습니다.

- 드러내는 일 : 에이전트가 무엇을 했는지 볼 수 있게 만드는 것

- 판별하는 일 : 본 것을 두고 이건 맞고 저건 아니라고 말하는 것

에이전트가 다 만들고 나서 보여주면 늦습니다. 완성된 걸 뒤집는 건 비싸거든요. 그렇다고 한 걸음마다 물어보면 사람이 먼저 지칩니다. 어느 지점에서 멈춰 세울지, 무엇을 어떤 형태로 보여줄지, 어디서 사람 확인을 받고 어디서 그냥 진행시킬지. 이게 실제로 설계해야 하는 것이었습니다.

라이브 방송은 더합니다. 개입할 수 있는 창이 초 단위라, 끝나고 보면 이미 지나간 뒤입니다. 그러니까 드러냄과 판별은 정해진 두 가지 일이 아니었습니다. 에이전트와 사람이 어떤 타이밍에 무엇을 주고받을지를 매번 설계하는 일이었습니다.

그리고 이 바퀴가 잘 돌면 두 가지가 같이 올라갑니다. 에이전트가 더 정확한 방향으로 갑니다. 그리고 사람도 더 잘 가려내게 됩니다. 두 번째가 오래 걸려서 알았습니다. 관찰하고 피드백하는 그 과정이 곧 사람이 배우는 과정이더군요. 이 루프를 안 돌리면 에이전트만 제자리인 게 아니라 사람도 제자리입니다.


드러내는 것과 판별하는 것

여기서 오해하기 쉬운 게 있습니다. 이 둘이 역할 분담처럼 보이는데, 그게 아닙니다. "AI와 일하는 사람은 누구나 둘 다 합니다." 다른 건 무엇을 드러내고 무엇을 판별하느냐입니다.

콘텐츠에서는 — AI가 뽑은 백 장을 늘어놓고 비교할 수 있게 만듭니다. 그중 무엇이 이 캐릭터다운지 가려내고 왜 아닌지 말해줍니다. 그 기준을 정리해두면 다음 백 장이 달라집니다.

엔진에서는 — 캐릭터의 판단이 프롬프트 안에만 있으면 아무도 볼 수 없습니다. 코드가 그 판단을 갖고 있어야 밖으로 꺼낼 수 있습니다. 그리고 AI가 내놓은 구조가 맞는 해법인지, 그럴듯하기만 한 건지 가려냅니다.

제품에서는 — 에이전트가 방금 무슨 판단을 했는지 화면에서 읽히게 만듭니다. 그리고 그 화면이 실제로 읽히는지, 사람이 여기서 판단할 수 있는지를 다시 가려냅니다.

전통적인 방식으로 나누면 화면 그리는 사람과 그림 그리는 사람이 됩니다. 스킬로 나누는 거죠. 그런데 그림은 이제 AI가 그립니다. 그래서 기준을 바꿨습니다. 무엇을 만드느냐가 아니라 "에이전트와 무엇을 주고받느냐"로요.

셋 다 같은 두 가지를 합니다. 나뉜 기준은 직군이 아니라 "판별의 재료"입니다.

- 캐릭터 안에서 오래 살아본 감각
- 사람이 화면 앞에서 무엇을 이해하는지 아는 감각
- 흔들리는 출력을 시스템으로 붙잡아본 감각

같은 눈으로 셋을 다 볼 수는 없습니다. 그래서 자리가 셋이 됐습니다. 일을 나눈 게 아니라 눈을 나눈 것에 가깝습니다.

AI 환경에서의 디자인을 정의하는 것

이 구분을 기반으로 공고 내용을 고치던 중에, NN/g의 Sarah Gibbons가 6월에 쓴 포스팅을 읽었습니다. 'AI 디자인'이라는 한 단어가 이미 네 갈래로 갈라졌다는 내용입니다.
1. Designing with AI : AI를 도구로 써서 더 빨리 간다.
2. Designing AI Products : AI를 사람이 쓸 수 있는 제품으로 만든다.
3. Designing for AI Agents : 에이전트가 읽고 움직일 것을 설계한다. 사용자가 사람이. 아니다.
4. Designing the AI : 무엇을 좋다고 볼지, 어디서 선을 그을지를 정한다.

우리 공고에 섞여 있던 게 2번과 4번이었습니다. 제품을 만드는 일과, 무엇을 좋다고 볼지 정하는 일. 자리에 묶여 있으니 아무리 문장을 고쳐도 안 갈라졌던 겁니다.

우리 공고 안의 4번은 모델 파라미터가 아니라 "캐릭터 IP의 세계을 정하는 일"이었습니다. 무엇이 이 캐릭터답고 무엇이 아닌지 기준을 세우고, 그 기준으로 AI가 뽑아낸 것들을 걸러내는 일. 디자인 감각보다 캐릭터를 아는 감각이 필요했습니다.

Gibbons도 이 단서를 열어뒀습니다. "이런 결정을 내릴 수 있는 사람이 디자이너뿐인 것은 아니다. 윤리학자, 카피라이터, 심리학자 각각이 기여할 수 있다."

그래서 그 선으로 갈랐습니다. 드러냄과 판별을 위한 제품을 만드는 쪽은 프로덕트 디자이너로, 무엇이 좋은지 정하는 쪽은 AI 콘텐츠 빌더로요.

Gibbons의 틀은 디자이너가 AI를 어떻게 다루느냐를 정리한 것이지 팀 전체의 지도가 아닙니다. 저희도 그렇게 쓰지 않았습니다. 다만 우리가 손으로 나눠둔 자리에 이름이 붙으니, 사람을 만날 때 무엇을 물어봐야 할지가 분명해졌습니다.


판단 하기위해 만들어본 경험을 갖는 것

세 자리 모두 경력을 크게 중요하게 생각하지 않기로 했습니다. 대신 조건을 하나 걸었습니다. "끝까지 만들어본 사람."

AI가 만드는데 왜 만들어본 경험을 보느냐고 하면, 답은 이렇습니다. 만들어본 사람만 "에이전트에게 필요한 피드백"을 할 수 있습니다.

"별로예요"도 날카로운 감각이지만 누구나 말합니다. "선이 무거워서 캐릭터가 나이 들어 보여요"는 만들어본 사람이 합니다. 코드도 같습니다. "이거 안 되는데요"는 누구나 하고, "이 구조로 가면 나중에 여기서 막혀요"는 만들어본 사람이 합니다. 에이전트에게 필요한 건 뒤의 피드백 입니다. 그리고 그 말을 할 수 있느냐가 루프가 도는지 에이전트의 지속성을 가릅니다.

4월에 "만들 줄 아는 사람"이라고 썼던 게 이 뜻이었구나를 깊이 깨닫게 되었습니다.


AI Native 팀이라는 것

4개월 동안 에이전틱 시스템을 만들고 AI Native 조직을 고민하면서 도착한 결론은 이렇습니다.

AI 네이티브 팀의 구조는 먼저 그려놓고 시작할 수 없습니다. AI가 우리 일에 어떻게 들어오는지를 실제로 해봐야 자리가 드러납니다.

만들 것을 몰라서가 아닙니다. 만들 것은 알아도, 그걸 AI와 함께 만드는 모양은 해보기 전엔 종이 위에 안 그려집니다. 그래서 이전의 시도는 자리를 채우는 일인 동시에 그 모양을 확인하는 일이었습니다.

대신 드러났을 때 빨리 다시 정할 수 있어야 합니다. 저희는 넉 달이 걸렸는데, 조금 더 짧았으면 좋았겠다고 생각합니다. 미리 못 그리는 건 어쩔 수 없지만, 신호가 왔을 때 못 알아보는 건 다른 문제니까요. 그리고 자리가 정해지고 나서 보이는 게 있습니다. 세 자리가 나뉜 기준은 직군이 아니었습니다. 에이전트가 낸 결과를 보고, 가려내고, 방향을 주는 그 한 바퀴를 무엇에 대해 도느냐였습니다. 콘텐츠에서 돌든, 화면에서 돌든, 엔진에서 돌든 하는 일의 모양은 같습니다.

그래서 AI 네이티브 팀이 뭐냐고 물으면 지금은 이렇게 답합니다. "에이전트의 결과물을 판별하고 방향을 줄 수 있는 사람들이, 각자의 영역에서 그 루프를 돌리고 있는 팀."

도구를 몇 개 쓰느냐가 아니라 그 루프가 돌면서 점차 에이전트의 결과를 개선하면서 일의 범위를 바꿔나가는 것입니다. 안 돌면 에이전트는 계속 그럴듯한 걸 뱉고, 사람은 계속 받아들이기만 합니다. 둘 다 제자리고요.

4월에 "AI를 팀 전체의 일하는 방식에 녹인다"고 썼을 때, 저는 그 말이 무슨 뜻인지 절반만 알고 썼습니다. 말이 먼저 있었고 구조가 뒤늦게 따라왔습니다.

---

다음 편에서는 이 루프의 "판별하는 일"에 대해 상세히 써보겠습니다. 그게 생각보다 훨씬 느리고, 그 느린 속도가 결국 팀 전체의 속도를 정하더군요.

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