[AI] 무신사 AI Native Engineer 채용 회고

💬 회고 주제

한 달 전, 무신사의 AI Native Engineering 공고를 보고 지원하게 되었다.

2차 테스트까지 볼 수 있는 기회를 얻었지만, 결과적으로는 불합격했다. 이전 회사에서 경영난으로 권고사직을 받은 뒤, 새롭게 이직을 준비하면서 'AI가 코드를 짜는 시대에 백엔드 엔지니어로서 어떤 경쟁력을 가져야 할까?'라는 고민이 계속 머릿속을 맴돌아, 이력서를 수도 없이 수정했다. 그런 시기에 오랜만에 서류부터 코딩 테스트까지 밟아볼 수 있었기에, 결과와 무관하게 나에게는 값진 경험이었다.

 

사실, 회고를 해야겠다는 생각 자체를 잊고 있었는데, 최근에 EO Korea 채널에 올라온 스탠포드에서 빅테크로 조용히 퍼지는 개발자 생존법 영상을 보고 2차 테스트에서 내가 놓쳤던 것들과 겹쳐 보이면서 생각이 났다.

 

이 글은 채용 후기가 아닌 회고이다. 무신사의 AI Native Engineer 2차 테스트 경험을 통해, 주니어 개발자로서 내가 AI 시대에 어떻게 나아가야 할지 톺아보도록 하자.

🎬 영상 요약

EO Korea - 스탠포드에서 빅테크로 조용히 퍼지는 개발자 생존법

AI 시대에 주목받는 엔지니어상이 바뀌고 있다. 단순히 코드를 잘 짜는 것을 넘어, 다수의 AI Agent를 능숙하게 오케스트레이션하는 역량이 새로운 채용 기준이 되고 있다는 것이다.

 

이를 잘 하려면 두 가지가 필요하다.

• Agent들의 작업 흐름을 설계하는 제어 전략(Multi-Agent Workflow)
  • 점진적인 에이전트 도입
  • 컨텍스트 스위칭 전략
  • 훌륭한 관리자의 자질
• Agent가 혼란 없이 코드를 읽고 기여할 수 있는 코드베이스(Agent-Friendly Codebase)
  • 명확한 컨트랙트(테스트) 제공
  • 문서와 코드의 일관성
  • 일관된 디자인 패턴

 

흥미로운 건 이 변화가 주니어에게 유리하다는 것이다. 기존 방식에 고착되지 않은 주니어는 AI 워크플로우를 빠르게 실험하고, 수용할 수 있어 스타트업 생태계에서 오히려 강점이 된다고 한다.

🕵 나의 문제점 분석 및 회고

2차 테스트는 단일 AI Agent(Gemini CLI)를 활용해 진행했다. 비록 다중 Agent를 동시에 다루지는 않았지만, 영상에서 강조된 AI 네이티브 엔지니어의 핵심 역량인 '워크플로우 설계' 와 'Agent-Friendly 코드베이스 구축' 관점에서, 나는 이 두 가지 역량 모두 부족했다. 하나씩 톺아보도록 하자.

1. 시스템 설계 위임과 컨텍스트 과부하

🔍 분석

표면적인 문제

GEMINI.md 작성에 많은 시간을 투자했지만, 개발물의 품질과 개발 효율이 낮았다.

• 왜? → 요구사항(PROBLEM.md) 문서 분석을 내가 하지 않고, AI에게 전적으로 위임했다.
• 왜? → 제한된 시간 내에 빠르게 구현 단계로 넘어가야 한다는 압박감과 조급함이 있었다.

 

근본 원인

시스템 설계와 컨텍스트 압축은 AI가 아닌 개발자의 영역이다. 영상에서 지적한 것처럼, Agent는 문서와 코드가 불일치하거나 모호할 때, 사소한 오해를 바탕으로 빠르게 오류를 증폭시킨다. 즉, 작업을 지시하기 전, 명확한 도메인과 제약을 정의하는 시스템 설계자 역할을 수행하지 못했다.

↩️ Before

옛 말에 틀린게 없다. "바쁠수록 돌아가라"라는 말을 간과했다. 초기 분석 없이 조급하게 AI가 도출한 제약 사항을 그대로 GEMINI.md에 추가했다. 결과적으로 문서의 컨텍스트는 비대해졌고, 불필요하게 무거워진 제약사항과 핵심 비즈니스 로직 사이에서 Agent는 맥락을 잃기 시작했다. 이는 테스트 하네스 오류와 잘못된 코드 생성으로 이어졌다.

↪️ After

GEMINI.md의 역할을 재정의해야 한다. 많은 정보를 주입하는 것보다, 오해 없이 실행할 수 있는 최소한의 계약서가 되어야 한다.

1. 요구 사항을 내가 먼저 완독하고 핵심 요구사항을 직접 정리한다.
2. 그 중 Agent가 반드시 알아야 할 최소한의 내용만 GEMINI.md에 넣는다.
3. 많을수록 좋은 게 아니라, 정확할수록 좋다.

2. 검증 불가능한 모호한 워크플로우 분리

🔍 분석

표면적인 문제

파이프라인을 Step 1 ~ 4로 나누었지만, 각 단계의 책임과 검증 기준이 크고 모호했다.

• 왜? → 단계를 나누는 것 자체가 목적이 되어, 가장 중요한 완료 기준을 정의하지 않았다.
• 왜? → 단계를 잘 나누기만 하면, Agent가 스스로 잘 소화할 것이라고 과신했다.

 

근본 원인

영상에서 지적한 점진적 오케스트레이션 원칙을 위배했다. 단일 작업의 완전한 수행과 검증 없이 다음 단계로 넘어갔기 때문에, 어디서부터 논리가 어긋났는지 추적 자체가 어려워졌다.

↩️ Before

## Step 1: Prompt Log Generation (`prompts/`)
## Step 2: API Documentation Generation (`docs/`)
## Step 3: Code Implementation (`src/main/`)
## Step 4: Test Implementation (`src/test/`)

겉보기에는 체계적으로 보이지만, 각 단계의 완료 기준이 없는 구조였다. 파일 생성이나 단순 컴파일 성공만으로는 비즈니스 요구사항 충족을 보장할 수 없다. 특히 코드를 먼저 작성하고 테스트를 나중에 구현하는 방식은, 영상에서 말한 '테스트를 통한 명확한 컨트랙트 제공'에 어긋나며 Agent의 논리적 오류를 사전에 차단하지 못한다.

↪️ After

각 단계에 명확한 검증 사이클을 통합해야 한다.

1. 각 단계에서 완수해야 할 단일 기능과 범위 명시
2. 테스트 통과, 엔드포인트 응답 확인 등 검증 가능한 기준 설정
3. 다음 단계로 컨텍스트를 전환하기 전, 개발자가 직접 코드와 논리를 리뷰하는 체크포인트 확보

Agent가 단일 작업을 완벽히 수행했는지 검증한 뒤 다음으로 넘어가는 것. 그것이 점진적 위임이다.

💪🏻 마무리

2차 테스트(2월 8일)이후 약 한 달의 시간이 흘렀다.

 

테스트 직후, 무엇이 부족했는지 바로 회고를 했다. 불합격 결과를 받고 이 시점에서 다시 읽어보니, 한 달 사이에 AI에 대하여 기술적으로나 방법론적으로 유의미한 변화가 있었음을 확인할 수 있었다.

 

가장 큰 변화는 막연했던 AI 활용을 구조화했다는 점이다. oh-my-opencode를 통해 Multi-Agent Orchestration 환경을 직접 경험했고, 이 과정에서 Single-Agent 환경에서도 적용할 수 있는 나만의 프로세스를 수립했다. 이 과정을 통해 Single-Agent 환경에서도 구조적으로 사용할 수 있는 /init, /plan, /work 프로세스를 수립하여 검증 가능하고, 통제 가능한 워크플로우로 발전시킬 수 있었다.

 

영상에서 말한 것처럼, 정답이 없는 AI 생태계에서는 직접 부딪히며 자신만의 워크플로우를 구축하는 실험 정신이 핵심이다. 나는 불합격 이후 한 달 동안 그걸 했다.

 

불합격이라는 결과는 바꿀 수 없다. 하지만 이 결과가 지난 한 달간 내가 경험한 것들의 출발점이 됐다는 건 분명하다.

 

주니어의 강점은 기존 방식에 고착되지 않는다는 것이다. 실패한 방법론은 빠르게 버리고, 더 나은 기술과 프로세스를 스펀지처럼 흡수하는 것. 지금 내가 AI 네이티브 엔지니어로 나아가는 데 있어 가장 강력한 무기는 바로 그 유연함이라고 생각한다.