{`클로드 코드를 처음 잡은 팀원이 AI 네이티브 인재로 크는 과정을 지켜보며 발견한 공통 패턴`}

AI 네이티브로 성장하는 3단계: 노가다, 설계자, 그리고 설계자를 설계하는 사람

Lukas

Lukas

Jun 15th 26

5 min Read

AI 네이티브 인재는 어느 날 갑자기 만들어지지 않는다. 클로드 코드(Claude Code)를 한 번도 써보지 않은 팀원이 AI 네이티브로 크는 과정을 옆에서 지켜보면, 직책이 백엔드든 프론트엔드든 PM이든 디자이너든 거의 똑같은 단계를 밟는다. 우리 팀에서 반복적으로 관찰된 그 성장 로드맵을, 집 짓기 프로젝트의 '창문 담당' 에 비유해 정리했다.

여기서 '창문'은 그냥 비유다. 창문 자리에 form, 피그마 컴포넌트, 백엔드 모델을 넣어도 이야기는 똑같이 성립한다.

1단계 — 노가다 단계: AI로 기존 일을 더 빨리 한다

이 단계의 팀원은 이미 난 문제를 AI로 하나씩 처리한다. 집 짓기로 치면 이렇게 일한다.

  • 거실 창문에 금이 간 걸 보고, 거실 창문을 고친다
  • 거실 창문이 너무 작아서, 설계를 다시 들여다본다
  • 화장실엔 환기용 작은 창문이면 되는데 통창이 들어가 있는 걸 발견하고 수정한다
  • 출입문엔 통창이 필요한데 작은 창문이 들어가 있어 바꾼다
  • 침실 방문 쪽 창에 미닫이 기능을 추가한다
  • 창문에 난방이 고려되지 않은 걸 보고 다시 수정한다

이 방 저 방 뛰어다니면서, 그때그때 보이는 문제를 AI로 메운다. 속도는 분명히 빨라진다. 다만 기존 속도가 100이었다면 150 정도. 나아지긴 했지만 일하는 방식 자체가 바뀌진 않는다.

그래도 노가다 단계는 의미가 있다. 이 지겨운 반복이 다음 단계로 가는 필수 과정이기 때문이다. AI를 이렇게 노가다로 쓰다 보면, AI 네이티브로 클 사람은 어느 순간 이런 질문을 던지기 시작한다.

"뭔가 잘못 쓰고 있는 것 같은데, 더 좋은 방법 없을까?"

이 질문이 나오는 순간이 분기점이다.

2단계 — 설계자 단계: 일을 하지 않고, 일하는 방식을 설계한다

설계자 단계의 팀원은 방마다 뛰어다니기 전에 window.md(창문.md) 같은 파일부터 만든다. 여기에 창문의 정의, 역할, '좋은 창문'의 조건을 상세히 적어 둔다.

  • 화장실 창문의 역할은 환기다. 안이 보이지 않도록 각도가 지거나 크기가 작아야 한다.
  • 거실 창문은 클수록 개방감이 좋다. 다만 겨울철 난방을 함께 고려해야 한다.
  • 거실 창문을 설계할 땐 반대편 창문도 같이 설계해 맞통풍 구조를 만든다.
  • 창문 A·B·C에 대한 추가 기준들…

그리고 이 window.md를 기준으로 여러 에이전트를 설계해 운영한다. 창문 제작 agent, 설치 agent, 수리 agent, 유지보수 agent. 각 에이전트는 window.md에 정의된 내용을 참고해 일한다. 이제 이 사람은 창문 자체를 설치하거나 고치지 않는다. window.md와 창문 관련 에이전트를 고친다.

설계자 단계의 핵심은 여기 있다. 노가다 단계에서 수없이 깨지면서 AI가 뭘 잘하고 뭘 못하는지 체득했기 때문에, 본인이 반복적으로 하던 일을 AI 워크플로우 형태로 재설계할 수 있게 된다. 주목할 점은, 노가다 단계 없이 설계자 단계로 바로 점프하는 건 사실상 불가능하다는 것이다. AI와 창문을 수없이 만들고 고쳐 보지 않고서는, 무엇이 가능하고 불가능한지 판단할 수가 없다.

AI 네이티브 조직을 지향한다면, 팀 안에 이 설계자 단계의 인재를 얼마나 많이 키우느냐가 핵심이다.

3단계 — Self-Improving 설계자 단계: 설계자를 설계한다

여기서부터는 매우 소수이고, 솔직히 급진적이다. 넣을지 말지 고민했지만, 한 가지 생각을 더 얹어 본다. 이 단계를 한 줄로 요약하면 '설계자를 설계한다'.

이 단계의 인재는 더 이상 window.mdwindow_fix_agent.md 같은 에이전트를 직접 만들지 않는다. 대신 그것들을 스스로 개선하는 설계자를 설계한다. 마땅한 번역이 떠오르지 않아, 일단 'Self-Improving 창문 에이전트'라고 부르자.

이 에이전트가 하는 일은 이렇다. "어떤 집을 지어야 한다"는 태스크가 주어지면, 그 집에 필요한 창문의 설계·제작·설치·유지보수를 사람 대신 전부 직접 한다. 그런데 더 중요한 건 매번 작업이 끝날 때마다 사람 혹은 또 다른 AI로부터 점수를 받는다는 점이다. 새 집의 창문 작업을 할 때마다 점수가 매겨지고, 그때마다 더 높은 점수를 위해 새로운 가설을 세운다.

"이번 집 창문은 이런 평가를 받았어. 점수를 올리려면 유지보수 에이전트를 하나 더 붙여 보는 건 어떨까?"

이렇게 설계된 Self-Improving 창문 에이전트는 수백 번, 수천 번 집의 창문을 만들고 개선하면서 점점 더 똑똑해진다. 이 단계의 인재는 window.md나 창문 에이전트를 직접 만들지 않는다. 그것들을 만들어 내는 시스템을 설계한다.

이 단계가 일반 회사에서 유독 어려운 이유가 있다. 회사 고위직이 이 개념을 이해하기 어렵고, 회사의 작동 방식 자체를 근본적으로 바꾸는 방향이라 팀원이 주도적으로 끌고 가기가 힘들다. 그래서 소수 정예 스타트업이 아닌 이상 매우 드물다.

정리 — 단계는 건너뛸 수 없다

AI 네이티브로의 성장은 결국 이 흐름이다.

  1. 노가다 — AI로 기존 일을 더 빨리 한다 (필수 통과 의례)
  2. 설계자 — 일하는 방식을 *.md + 에이전트로 재설계한다
  3. Self-Improving 설계자 — 설계자를 만들어 내는 시스템을 설계한다

가장 중요한 메시지는, 단계를 건너뛸 수 없다는 것이다. 노가다의 시행착오가 설계의 직관이 되고, 설계의 경험이 다시 '설계자를 설계하는' 감각으로 이어진다. AI 네이티브 조직을 만들고 싶다면, 도구를 도입하는 것보다 팀원이 이 단계를 밟고 올라갈 시간을 확보하는 게 먼저다.


Potential (포텐셜) 은 한국·아시아의 창업가가 서구 시장으로 확장하도록 돕는 파트너로, AI 네이티브 방식으로 제품을 설계하고 만듭니다. AI 네이티브 팀을 어떻게 키울지 고민 중이라면 상담을 신청해 보세요.

Lukas

Lukas

Founder

Dad of 2 Kids

Follow me:

  • facebook
  • linkedIn
  • instagram
See more blogs