AI 네이티브 팀 만들기 1편 : 쉽다의 기준이 다르다

이제 진짜 실행을 시작했습니다.

두 달 넘게 하루도 안 빠지고 클코와 살았다.

퇴근하고 몇 시간씩, 주말에는 거의 모든 시간을 쏟았다. 코박 두 달 넘게 하루도 안 빠지고 Claude Code를 켰다. 월 200달러 구독 두 개에 회사 토큰까지, 한 달에 600달러 넘게 썼다. 다른 AI 도구도 썼다. AI에 절여져서 살았다.

AI가 뭔지 설명할 수 있게 됐다. 챗봇과 에이전트의 차이가 뭔지, 에이전트가 Tool을 사용하고 Skill로 만드는 구조가 뭔지, MCP가 AI한테 도구를 연결해 주는 규격이라는 것도 알게 됐다. 우리 서비스의 폴더 구조가 어떤 역할을 하는지, 코드가 빌드를 거쳐 화면이 되는 과정이 뭔지, 깃헙에서 브랜치 따서 푸시하는 흐름이 뭔지 파악할 수 있게 됐다. 남들이 팁을 알려주거나 아티클을 주면 그래도 이해할 수 있게 됐다.

Mac mini를 사서 로컬로 돌려보고, 배포도 해보고, 다양한 에이전트 모델을 만들어보고, 프로젝트에 붙여서 작동하는 걸로 만들어보고, DB를 구성해 보고, 어떤 테이블에 어떤 값이 들어가는지 이해해 보고, 에러가 나면 어떤 에러인지 파악해서 해결해 보고. 개발자들이 쓰는 단어가 들리면 적어놨다가 따로 공부했다. 물론 듣고 이해 안 되고 기억 안 났다. 근데 반복적으로 하다 보면 조금은 나아지더라.

이건 정말 괴롭고 힘들고 어려운 과정이었다. 터미널 화면 보는 것 자체가 스트레스였다.

개발자들이 생각하는 쉽다와 비개발자들이 생각하는 쉽다는 다르다.

이 아티클 참고 해봐.라고 친절하게 말해주는 개발자분들이 계신다.

솔직히 비개발자들은 그거 봐도 어디서부터 해야 되는지 모른다. 코드가 뭔지, 언어가 뭔지, 폴더는 왜 만드는 건지, 폴더 안에 수많은 파일은 도대체 뭘 뜻하는 건지. 터미널이 뭔데. 토큰 생성이 뭔데. 아니 그냥 토큰이 뭔데? 아무것도 모르는 거다.

아무리 비개발자도 할 수 있다고 해도, 그 말을 하는 사람은 이미 코드를 읽을 줄 알고 해석할 줄 아는 사람일 확률이 높다. 나도 깨달았다. 내가 좀 알게 되니까 나도 "터미널 열어보세요, 이것도 해보세요" 하고 있었다. 그러면 안 되는 거다.

쉽지의 기준이 다른 것이다.

아는 사람에게는 이거 되게 쉽지, 이렇게 하면 되지가 자연스럽다. 하지만 그 쉽지의 기준이 전혀 다른 세계에서 온 사람에게는 통하지 않는다. A부터 Z까지 설명해줘야 한다. 이거까지?라고 하는 것까지. 최대한 정확한 것들을 빠르게 알게 해줘야 한다. 숙제 던져주고 "해보세요"가 아니라, 같이 붙어서 어떤 걸 하고 싶은 건지, 어디서부터 접근해야 되는지, 뭘 알아야 되는지를 누군가가 설명해줘야 한다.

나처럼 무식하게 2달 동안 매일 이걸 파는 거 솔직히, 너무 힘든 일이라 하라고 못하겠다.

유토피아를 꿈꾸기 전에 실행하기로 했다.

확신이 들었다. 우리 팀을 나만큼은 쓸 수 있게 만들 수 있겠다.

AI를 이용해서 모든 업무의 사고 과정을 확장할 수 있게 됐고, 배움의 속도가 빨라지는 걸 체감했고, 원하는 결과를 너무 쉽게 도출할 수 있게 됐고, 그걸 작동하는 프로젝트로 만들 수 있게 됐고, 어떤 원리로 만들어졌는지 설명할 수 있게 됐다. 물론 정말 세부적인 것들은 전혀 모른다. 하지만 어떻게 구성되어 있는지는 안다. 그리고 이걸 비개발자의 언어로, 정말 쉽고 재밌게 풀어줄 수 있다.

4시간짜리 미팅을 잡았다. 그것도 일주일에 한 번씩 4번 진행할 예정이다. 내가 아는 것들을 빠르게 나열했고, AI 엔지니어에게 맞는 정보인지 확인을 요청했고, 비개발자가 업무에 적용하기 위해 뭘 더 알아야 하는지 피드백을 받았다. 그렇게 4주짜리 커리큘럼을 만들었다.

1주 차 : 비개발자들끼리 모여서 뭔가를 만들어본다. 이게 어떻게 작동하는지 이해하고 친해지는 시간

2주 차 : 1주 차에 뭘 했는지 발표하고, 개발자들이 본인은 어떻게 쓰는지 보여주는 시간. 그걸 보고 활용을 확장하는 시간

3주 차 : 본 걸 기반으로 실무에 직접 적용해 보는 시간

4주 차 : 이젠 개발자들이 비개발자의 영역으로 넘어오는 시간

근데 이건 비개발자만의 문제가 아니다

여기서 중요한 건 트레이드오프다. 개발자들도 같이 올라와야 한다.

비개발자가 개발 영역으로 들어오고 있다. 개발자가 보기에는 그게 개발이 아니야라고 말할 수 있다. 하지만 비즈니스 관점에서 개발 영역이 맞다. 이미 PM이 프로토타입을 만들고, 디자이너가 코드를 쓰고, 마케터가 자동화를 돌리고 있다면 말이다.

그렇다면 개발자도 비즈니스를 알아야 하고, 마케팅을 알아야 하고, 디자인을 알아야 한다. 같은 수준에서 대화할 수 있어야 한다. 본인의 언어로만 얘기하는 시대는 끝났다.(물론 아직도 난 개발언어를 모르겠음..)

비개발자가 개발을 공부하는 동안, 개발자는 비즈니스와 프로덕트를 공부하고 스터디하는 시간을 갖는다. 서로의 영역을 확장한다. 각자의 R&R 이 허물어진다. 이제 순차적으로 일하는 프로세스도 AI네이티브 팀에서는 파괴될 것이라고 생각한다.

JD에서 이미 시그널은 보내고 있다.

JD에서 직군 경계가 사라지고 있다. Product Engineer, Builder, Problem Solver. 직군 명시 자체가 없는 채용 공고가 나타나고 있다. 엔지니어에게는 PM처럼 사고하라는 요구가, PM에게는 기술적이어야 한다는 기대가 동시에 생기고 있다.

Anthropic도 비기술 직원이 코드의 에러를 직접 고치고, 연구자가 프런트엔드 개발을 해서 데이터 시각화를 직접 만들고 있었다. Claude가 모든 사람을 더 풀스택으로 만들고 있다고 말했다.

Lovable은 아예 채용부터 이렇게 한다. 파트너십 담당자에게 docs 읽고, 스크립트 쓰고, 프로덕션에 배포해 본 경험을 요구한다. 고객 여정 담당자 한 명이 프로덕트, 라이프사이클, 인앱 메시징, 세일즈를 전부 책임진다. 직군이 아니라 빌더를 뽑는 거다.

Lovable 채용 84개 공고를 보면 개발자한테도 경계를 완전히 깨고 있다.

Analytics Engineer - Marketing — 엔지니어인데 마케팅 팀 소속

Analytics Engineer - Finance — 엔지니어인데 재무 팀 소속

Financial Systems Engineer — 엔지니어인데 재무 시스템 담당

Fullstack Growth Engineer — 엔지니어인데 그로스 담당

Forward Deployed Engineer — 사무실이 아니라 고객한테 직접 가는 엔지니어

Design Engineer — 디자인 팀 소속 엔지니어

그리고 세일즈 쪽에도 Solutions Architect, Deployment Strategist 같은 기술+비즈니스 혼합 직함이 있다. Lovable은 양방향으로 경계를 깨고 있어. 비개발자한테 기술을 요구하는 것만이 아니라, 개발자한테도 마케팅·재무·세일즈·디자인 영역으로 들어가라고 한다. 공평한 세상이 온 것이다.

그럼 나는 풀스택의 정의를 해보고 싶다. FE, BE, 인프라 개발의 영역만 다한다. 이게 아니다. 그냥 다 하는 것이다. 다 알아야 한다. 물론 주종목은 있겠지만 하나만 이해하고 하라는 게 아니다.

그럼에도 개발자, 그럼에도 마케터, 그럼에도 디자이너라고 말한다면 내 커리어의 version을 아직 업데이트하지 않겠다는 사인이라고 생각한다. 이 시그널을 빨리 읽는 사람이 리딩하고, 늦게 깨닫고 쫓아오면 팔로워밖에 되지 못한다.

AI 네이티브 팀이란

내가 생각하는 AI 네이티브 팀은 이렇다.

모두가 주니어 수준이 아니라 프로 수준이어야 한다. 돈 받는 프로 수준. 물론 경력 1년 차도 있고 연차 차이는 있겠지만, 각자가 AI를 써서 독립적으로 프로 수준의 아웃풋을 내는 사람이어야 한다.

원 플레이어가 아니라 원 챔피언이어야 한다. AI를 쓰되 개발과 비개발의 범위를 넘나들어야 한다.

톱니바퀴로 비유하면 이렇다. 기존 조직은 톱니바퀴가 서로 엉겨 붙어서 돌아간다. 누군가 멈추면 옆도 멈춘다. 누군가의 병목이 누군가의 리소스 블락이 된다. 팀 인원 곱하기 1의 아웃풋밖에 안 나온다.

AI 네이티브 팀은 다르다. 각자의 톱니바퀴가 떨어져서 독립적으로 돌아간다. 각자가 소용돌이를 만든다. 그러다 필요할 때 결합한다. 레고처럼 조립된다. 그러면 팀 인원 곱하기 100배의 임팩트가 나온다.

누군가의 병목이 누군가의 리소스 블락이 되면 안 된다. 각자의 생산성이 곱하기로 풀려나야 한다. 이래야 소수의 인원으로 100억 1000억 버는 서비스를 만든다.

이게 사업 초반일수록 무기가 된다.

개발자들은 처음에 구조를 만들 것이다. 놀 수 있는 플레이그라운드를 만들어줄 것이다. 하지만 그게 잘 작동하기 시작하면 다시 밖으로 나와줘야 한다. 다른 영역까지 침범해줘야 한다. 계속 자기 영역만 지키면 본인의 톱니바퀴 안에서 벗어나지 못하고, 팀은 결국 큰 플라이휠을 그리지 못한다.

자꾸 팀 단위로 해결하려는 경향이 있다. 하지만 AI 네이티브의 기본은 각자가 원 챔피언인 것이다. 그 기본이 깔려 있어야 팀이 진짜 팀이 된다.

그래서 나는 무엇을 준비하는가

4주짜리 커리큘럼을 만들었고, 워크숍 자료도 다 만들었다. 미팅룸에 모두 모여서, 아니 갇혀서, 문제를 해결하고 완료해야 탈출할 수 있다. 숙제를 주고 해 보세요가 아니라 같이 붙어서 끝까지 하는 거다.

먼저 비개발자의 이해 수준을 올린다. AI가 뭔지, 어떻게 시키는지, 뭘 만들 수 있는지 직접 체험하게 한다. 그다음 개발자와의 R&R 확장까지 간다. 서로의 영역을 넘나드는 것. 그게 이 워크숍의 최종 목표다.

유토피아를 꿈꾸기 전에 실행한다. 그리고 그 시작은, 서로의 쉽지가 다르다는 걸 인정하는 것이다.