나를 뭐라고 불러야 하나 했는데, 채용 공고에 이름이 붙기 시작했다

나의 코딩 메이트

졸업 즈음에 스타트업에 합류할 기회가 있었다. 일반적인 개발자 채용은 아니었다. 면접에서 “단순한 개발자로서의 능력을 보고 뽑는 건 아니다”라는 이야기를 들었고, 직함을 정할 때 한참 고민하다 토스의 Technical Product Owner를 참고해 PO라는 이름을 가져오셨다.

대기업이나 SI 기업에서 안정적으로 커리어를 시작하는 것과, 뭔지 아직 잘 정의되지 않은 이 자리에서 시작하는 것 — 고민을 많이 했다. 결국 이쪽을 선택했는데, 가끔 이 길이 맞는 건지 확신이 서지 않을 때가 있었다. 주변에서는 “그게 앞으로 뜰 거다”, “선두주자 아니냐”라고 해줬지만, 정작 나를 설명할 수 있는 이름이 없으니 불안보다는 답답함에 가까운 감정이었다.

막상 일을 시작하니 PO도 딱 맞는 이름은 아니었다. 토스의 TPO는 “사일로 5명 내외 조직에서 기술 기반의 프로덕트 성공을 이끈다”고 정의되어 있다. 나는 그 5명을 혼자 한다. 제품 방향을 정하고, 직접 설계하고, 백엔드·프론트·모바일을 다 만들고, 필요하면 납땜도 한다. 주변에 같은 일을 하는 사람이 없으니, 내가 잘 가고 있는지 비교할 대상도 없었다.

그러다 최근에 흥미로운 채용 공고 두 개를 봤다.

두 개의 공고

하나는 Across라는 회사의 “Agentic Generalist”.

반복 업무를 제거하고 시스템화하세요. AI 툴 체인, 템플릿, 봇, 파이프라인을 만드세요.

“프론트엔드 개발자”, “백엔드 개발자” 같은 익숙한 이름이 아니었다. 직군 구분이 없다. “개발”이라는 단어조차 없다. “문제를 AI로 시스템화하는 사람”을 찾고 있었다.

다른 하나는 무신사의 “AI Native Engineer” 신입 채용.

3시간 안에 대학교 수강신청 시스템을 만드는 코딩테스트였는데, Claude와 Codex 사용이 허용이 아니라 사실상 전제였다. 흥미로웠던 건 평가 비중이었다.

무신사가 코드보다 중시한 것

무신사 코테의 제출 구조를 보면:

project-root/
├── README.md          # 빌드 및 실행 방법
├── CLAUDE.md          # AI 에이전트 지침 ← 필수
├── docs/
│   ├── REQUIREMENTS.md  # 요구사항 분석 및 설계 결정 ← 필수
│   └── (API 문서)       # API 명세 ← 필수
├── prompts/            # AI에 입력한 프롬프트 이력 ← 필수, 누락 시 감점
└── src/               # 소스 코드

4개가 필수다. 그 중 3개가 문서다.

평가 기준에도 명시되어 있다:

AI 활용: 프롬프트에 담긴 사고 과정과 에이전트 지침의 품질을 중점 평가. “코드 품질보다 큰 비중”

코드를 잘 짜는 게 아니라, AI를 어떻게 활용했는지, 의사결정을 어떻게 문서화했는지를 본다. CLAUDE.md가 필수 제출물이라는 것 자체가 시대가 변했다는 증거다.

코테를 본 친구가 이런 말을 했다: “평소에 AI 개발을 많이 해봐서, 코딩은 AI에 맡기고 문서화에 집중할 수 있었다.”

맞는 전략이다. 하지만 내가 생각한 건 조금 달랐다 — 그 문서화조차 시스템화해 두면 되는 것 아닌가?

문서화를 시스템화한다는 것

나는 현재 교육 도메인 B2B SaaS를 혼자 개발하고 있다. 백엔드, 프론트, 모바일, 하드웨어 연동까지. 이걸 지속 가능하게 하려면 AI에게 “이 함수 짜줘”라고 시키는 수준으로는 부족하다.

대신 개발 프로세스 자체를 시스템으로 설계했다.

CLAUDE.md — 3개월 전 의사결정을 오늘의 AI가 따르게 하는 장치

# 시간 처리: UTC 저장, 프론트에서 KST 변환
# 권한: {RESOURCE}_VIEW, {RESOURCE}_MANAGE 쌍으로만
# API URL: /api prefix 사용 금지 (도메인에 이미 포함)
# 에러 코드: RESOURCE_ACTION_REASON 형식

무신사가 코테에서 CLAUDE.md를 필수로 요구한 이유를 체감한다. 이게 없으면 매번 같은 실수를 반복하고, 매번 같은 맥락을 설명해야 한다.

커스텀 커맨드 — 문서화를 자동화하는 프로세스

/finish를 치면 이런 일이 자동으로 일어난다:

수정된 파일 확인
API 문서가 코드와 일치하는지 검증
에러 코드 문서 업데이트 여부 확인
요구사항 추적 문서 상태 갱신
작업일지 작성
커밋

무신사 코테에서 “docs/에 API 문서 필수”, “REQUIREMENTS.md에 설계 결정 필수”라고 한 것 — 이걸 매번 수동으로 하는 게 아니라, 프로세스로 코딩해 놓은 것이다. 코드를 수정하면 문서 동기화를 빠뜨릴 수 없게 시스템이 체크한다.

Feature 추적 — “이 코드가 왜 이렇게 되어 있는가”의 추적

모든 작업은 Feature ID로 추적된다. 각 Feature에는 구현하는 요구사항 ID가 연결되어 있다. 작업을 중단할 때 /pause를 치면 현재 상태가 기록되고, 다음 날 /resume을 치면 자동 복원된다.

무신사 코테의 REQUIREMENTS.md가 요구하는 “불명확한 부분에 대한 판단과 결정 사항, 설계 의사결정 및 근거” — 이것도 일회성 문서가 아니라 프로젝트 내내 누적되는 시스템으로 돌아간다.

“Agentic Generalist”라는 이름

이런 일을 하면서도 나를 뭐라고 불러야 할지 몰랐다.

“개발자”? — 코드를 짜는 것보다 시스템 설계를 더 많이 한다
“PO”? — 제품 방향만 정하는 게 아니라 직접 다 만든다
“풀스택”? — 기술 스택을 넘어 프로세스까지 설계한다

Across의 채용 공고에서 “Agentic Generalist”라는 이름을 처음 봤을 때, 반가웠다. 내가 하고 있는 일에 누군가 이름을 붙여준 느낌이었다.

Agentic: 스스로 판단하고 시스템을 만들어 실행한다
Generalist: 특정 기술 스택이 아니라, 문제 해결에 필요한 모든 영역을 넘나든다

물론 이 이름이 정착될지는 모른다. 아직 초기 단계겠지만, 적어도 일부 회사에서는 이런 역할을 인식하기 시작한 것처럼 보였다. 무신사가 코테에서 CLAUDE.md를 요구하고, Across가 “시스템화”를 핵심 역량으로 내세우고, 토스가 TPO라는 기술과 비즈니스를 동시에 다루는 역할을 정의한 것 — 이런 공고들이 하나의 방향을 가리키고 있다.

바이브 코딩 그 다음

2025년부터 “바이브 코딩”이 유행했다. AI에게 대충 지시하면 코드가 나오고, 붙여 넣으면 뭔가 돌아간다. 프로토타입을 만들기엔 충분했다.

하지만 실제 서비스에 적용하면 금방 벽에 부딪힌다.

3일 전에 AI가 짠 코드를 수정하려면, 왜 이렇게 짰는지 모른다
기능이 10개를 넘으면, 어디서 뭐가 깨졌는지 추적이 안 된다
요구사항이 바뀌면, 이전 결정의 이유를 알 수 없다

여기서 “바이브 코딩은 장난감”이라고 결론짓는 사람도 있고, AI를 버리고 전통 개발로 돌아가는 사람도 있다.

내가 찾은 건 그 사이의 지점이었다 — AI를 코딩 도구가 아니라 개발 인프라로 쓰는 것. CLAUDE.md로 의사결정을 외부화하고, 커스텀 커맨드로 프로세스를 자동화하고, Feature 추적으로 컨텍스트 유실을 방지한다. 바이브 코딩의 속도는 유지하되, 프로덕션 수준의 구조를 갖추는 방법.

무신사 코테가 CLAUDE.md, REQUIREMENTS.md, prompts/를 필수로 요구한 건 아마 비슷한 결론에 도달했기 때문일 것이다 — 적어도 내가 경험한 범위에서는, AI 시대의 개발 역량은 코드 그 자체보다 설계와 문서화에서 더 드러난다고 느꼈다.

해외에서는 이미

한국에서는 Across와 무신사 두 개가 눈에 띄었을 뿐이지만, 궁금해서 찾아보니 해외에서는 이미 꽤 활발했다.

이름은 아직 통일되지 않았다. 같은 역할이 여러 이름으로 불리고 있었다:

이름	어디서
Vibe Coder / AI Engineer	YC 스타트업 (Domu, Cartage)
AI Native Engineer	대기업 (Ferrovial, Accenture, EUROIMMUN)
AI-Accelerated Full-Stack Engineer	Wellfound 스타트업들
Founding Product Engineer (aka Vibe Coder)	YC — 아예 괄호에 “aka Vibe Coder”
Professional Vibe Coder	Lovable — Lenny’s Podcast에 소개된 풀타임 직군

몇 가지 인상적인 숫자들:

MIT Technology Review가 “Generative Coding”을 2026년 10대 혁신 기술로 선정했다
YC 현재 배치의 25%가 거의 전량 AI 생성 코드베이스라고 한다
AI 직군은 전통 소프트웨어 대비 25% 임금 프리미엄이 붙는다는 조사 결과도 있다
VibeCodeCareers.com이라는 이 직군 전용 잡보드까지 생겼다

그리고 일부 채용 공고에는 이런 요구사항이 명시되어 있었다:

“지금 작성하는 코드의 최소 50%는 AI가 만들어야 합니다. 바이브 코딩 경험은 필수입니다.” — Domu Technology (YC S24)

“AI 에이전트와 함께 개발한 실무 경험 (예: Claude Code)” — Healthpeak Properties

한국에서 “CLAUDE.md를 제출하세요”가 신선하게 느껴졌는데, 해외에서는 이미 “Claude Code 실무 경험”이 채용 요건에 들어가고 있었다.

이 직군이 확립될까

한국에서는 아직 두 개 공고에 불과하지만, 해외에서는 이미 전용 잡보드, 7만 명 규모의 디스코드 커뮤니티, 유료 교육 프로그램까지 만들어져 있다. 이름은 “Vibe Coder”, “AI Native Engineer”, “Agentic Generalist” 등으로 제각각이지만, 가리키는 방향은 같다: “코드를 잘 짜는 사람”이 아니라 “AI와 함께 시스템을 만드는 사람”.

솔직히, 이런 공고가 나오기 시작한 게 기쁘다. 주변에서 “이 분야의 선두주자”라고 말해줄 때마다 고마우면서도, 정작 그걸 증명할 수 있는 건 내 말뿐이었다. 그런데 이제 채용 시장이 이 역할에 이름을 붙이고, 코딩테스트에서 CLAUDE.md를 요구하기 시작했다. 적어도 완전히 엉뚱한 방향은 아니었구나 싶어 조금 안심이 됐다.

그리고 한 가지 더 — 이런 방식으로 일하는 사람들의 커뮤니티가 이미 있다. Threads나 오픈 채팅에서 AI 개발 워크플로우를 공유하는 사람들, 나보다 훨씬 깊이 파고 있는 사람들도 많다. 그동안은 혼자 만들고 혼자 쓰는 데 집중했는데, 앞으로는 그런 곳에서 적극적으로 활동해 보려 한다. 서로의 CLAUDE.md를 공유하고, 워크플로우를 비교하고, 더 나은 방법을 같이 찾아가고 싶다.

이런 방식으로 일하는 사람들에게도 언젠가 자연스러운 이름이 생기면 좋겠다. 최소한 다음에 누가 “뭐 하시는 분이세요?”라고 물었을 때, “그게… PO인데 개발도 하고 납땜도 하고…“보다는 나은 답을 할 수 있을 테니.

핵심 정리

무신사 코테가 CLAUDE.md와 REQUIREMENTS.md를 필수로 요구했다. AI 시대의 평가 기준이 코드에서 설계·문서화로 이동하고 있다.
바이브 코딩만으로는 프로덕션을 운영하기엔 부족하다고 느꼈다. AI를 인프라로 쓰는 구조화된 프로세스가 필요했다.
문서화도 시스템화할 수 있다. 커스텀 커맨드로 프로세스를 코딩하면, 코드 변경 시 문서 동기화를 빠뜨릴 수 없다.
해외에서는 이미 전용 잡보드와 7만 명 커뮤니티가 있다. 한국은 아직 초기지만, 글로벌로 보면 이 흐름은 이미 시작됐다.
“Agentic Generalist”라는 이름이 나왔다. 이름은 아직 통일되지 않았지만, 시장이 이 역할을 인식하기 시작한 건 느껴진다.