AI 포트폴리오를 구축하기 위한 5가지 실제 기업 브리프 (뻔한 튜토리얼 복제물 말고)

현재 모든 AI 포트폴리오가 똑같아 보입니다.

RAG 챗봇.
감성 분석기 (Sentiment Analyser).
Hugging Face에서 파인튜닝 (Fine-tuned)한 모델.

채용 담당자들은 매주 수백 개의 이런 포트폴리오를 봅니다.

그들은 감명받지 않습니다. 당신이 따라 했던 그 튜토리얼을 이미 봤기 때문입니다.

그들이 실제로 찾고 있는 것은 당신이 다음과 같은 능력을 갖추었다는 증거입니다:

• 모호한 브리프 (Brief)를 받아서
• 무엇을 만들지 파악하고
• v1의 범위를 설정 (Scope)하고
• 이를 출시 (Ship)하며
• 내린 모든 결정에 대해 설명할 수 있는 능력

이것은 완전히 다른 기술입니다.

그리고 거의 아무도 이를 연습하지 않습니다.

내가 한 일

지난 1년 동안, 저는 AI 네이티브 (AI-native) 기업들에 지원하고 면접을 봐왔습니다.

저는 제가 받은 모든 과제 (Take-home assignment), 면접 브리프 (Interview brief), 그리고 제품 챌린지 (Product challenge)를 보관했습니다.

결국, 저는 그 브리프 중 5개를 누구나 수행해 볼 수 있는 오픈 소스 (Open-source) 포트폴리오 프로젝트로 탈바꿈시켰습니다.

각 프로젝트는 실제 기업의 실제 문제에 기반하고 있습니다.

여기에 있는 것들:

• 튜토리얼 없음
• 단계별 가이드 없음
• 예시 솔루션 없음

단지:

• 원본 브리프 (Original brief)
• 평가 기준 (Evaluation criteria)
• 빌드 로그 템플릿 (Build-log template)
• 의사결정을 위한 프레임워크 (Framework)

목표는 솔루션을 복사하는 것이 아닙니다.

목표는 AI 네이티브 빌더 (AI-native builder)처럼 생각하는 법을 연습하는 것입니다.

저장소 (Repository)

GitHub: github.com/ai-native-builder/ai-portfolio-projects

5가지 실제 사례 브리프

1. Ember Coach Hire — 셀프 서비스 예약 제품

Ember는 기술 중심의 전기 버스 회사입니다.

그들의 코치 고용 (Coach hire) 예약은 여전히 수동으로 처리됩니다.

당신의 과제는 다양한 여행 유형을 지원하는 셀프 서비스 예약 흐름을 설계하고 구축하는 것입니다.

어려운 점

대부분의 지원자는 예약 양식 (Booking form)에 집중합니다.

그들은 두 가지 중요한 제약 사항을 놓칩니다:

• 서로 다른 여행 유형은 서로 다른 비즈니스 로직 (Business logic)을 필요로 함
• 전기차는 디젤 차량 운영자가 갖지 못한 운영상의 제약 사항을 도입함

과제는 양식을 만드는 것이 아닙니다.

과제는 비즈니스를 이해하는 것입니다.

카테고리: 제품 (Product) / 예약 (Booking)

2. Creative Ops Platform — 워크플로우 자동화 (Workflow Automation)

소셜 미디어 팀은 스프레드시트와 이메일 체인을 통해 콘텐츠 승인 (Approvals) 과정을 관리합니다.

리더십, PR, 법무팀이 모두 동일한 콘텐츠를 검토합니다.

하지만 그들은 완전히 서로 다른 이유로 검토를 진행합니다.

어려운 점 (What makes it hard)

실제로는 하나의 워크플로우 (Workflow) 안에 두 개의 승인 시스템이 숨겨져 있습니다.

법무 검토 (Legal review)는 결정론적 (Deterministic)입니다.

마케팅 검토 (Marketing review)는 협업적 (Collaborative)입니다.

대부분의 지원자들은 이 둘을 하나로 합쳐버립니다.

실력 있는 빌더 (Builders)는 이들이 근본적으로 다른 시스템임을 인식합니다.

카테고리 (Category): 자동화 (Automation) / 워크플로우 (Workflow)

3. Legal Contract Review Agent — 법률 계약 검토 에이전트

소규모 사내 법무팀이 지속적으로 발생하는 저위험 상업 계약서들을 검토합니다.

대부분의 계약서는 80%가 표준 문구 (Boilerplate)로 구성되어 있습니다.

검토 대기열은 항상 하루의 업무량을 초과합니다.

어려운 점 (What makes it hard)

당신은 반드시 다음을 수행해야 합니다:

• 현실적인 계약서를 직접 확보할 것
• AI를 신뢰할 수 있는 영역과 그렇지 않은 영역을 결정할 것
• 인간이 반드시 개입해야 하는 지점을 결정할 것
• 실제적인 평가 프레임워크 (Evaluation framework)를 구축할 것

"맞아 보인다"는 것은 평가가 아닙니다.

카테고리 (Category): 에이전트 (Agent)

4. B2B Outreach Agent — Hospitality — B2B 아웃리치 에이전트 (환대 산업)

런던의 한 환대 산업 (Hospitality) 그룹이 더 많은 기업 예약 (Corporate bookings)을 원합니다.

그들의 아웃리치 (Outreach) 프로세스는 전적으로 수동입니다.

누군가가 다음 과정을 수행합니다:

1. 기업을 찾고
2. 담당자를 찾고
3. 데이터를 스프레드시트에 복사하고
4. 이메일을 작성합니다

어려운 점 (What makes it hard)

이것은 실제로는 다단계 시스템 (Multi-stage system)입니다:

• 찾기 (Find)
• 정보 보강 (Enrich)
• 검증 (Verify)
• 작성 (Write)

각 단계는 서로 다른 도구, 리스크, 그리고 실패 모드 (Failure modes)를 가집니다.

대부분의 지원자들은 템플릿에 회사 이름만 바꿔 넣고 그것을 개인화 (Personalization)라고 부릅니다.

그것은 개인화가 아닙니다.

카테고리 (Category): 에이전트 (Agent) / 자동화 (Automation)

5. Multi-Agent Orchestration — EdTech — 멀티 에이전트 오케스트레이션 (에듀테크)

한 교육 플랫폼이 두 개의 AI 시스템을 운영합니다:

• 입학 에이전트 (Admissions Agent)
• 커리어 어드바이저 (Career Advisor)

두 시스템 모두 독립적으로 구축되었습니다.

그들은 컨텍스트 (Context)를 공유하지 않습니다.

학습자가 다음과 같이 질문하면:

"저에게 맞는 프로그램은 무엇이고, 어떤 직업으로 이어지나요?"

연결되지 않은 두 시스템 사이에서 답변이 공전하게 됩니다.

어려운 점 (What makes it hard)

당신은 반드시:

• 오케스트레이션 레이어 (Orchestration layer) 설계
• 작동 가능한 프로토타입 (Prototype) 구축
• 자신의 아키텍처 (Architecture)를 방어하는 전략 메모 (Strategy memo) 작성

이 메모는 코드만큼이나 엄격하게 평가됩니다.

카테고리: 에이전트 (Agent) / 아키텍처 (Architecture)

당신이 실제로 연습하고 있는 것

이것들은 코딩 연습이 아닙니다.

의사결정 연습입니다.

모든 브리프 (Brief)는 동일한 기술을 서로 다른 각도에서 가르칩니다.

우선적인 탐색 (Discovery First)

코드 한 줄을 쓰기 전에 비즈니스를 이해하십시오.

명시적 범위 설정 (Explicit Scoping)

다음 사항을 기록하십시오:

• 무엇을 만드는가
• 무엇을 만들지 않는가
• 왜 그러한가

빌드 로그 (Build Logs)

결정을 내리는 동안 그 결정을 문서화하십시오.

나중에 하는 것이 아닙니다.

솔직한 평가 (Honest Evaluation)

피드백을 요청하기 전에 객관적인 기준에 따라 스스로를 채점하십시오.

채용 담당자가 실제로 원하는 것

AI 네이티브 (AI-native) 기업의 채용 담당자들은 다듬어진 데모 (Demo)를 찾는 것이 아닙니다.

그들은 판단력 (Judgment)의 증거를 찾고 있습니다.

그들은 다음을 보고 싶어 합니다:

• 당신이 모호함 (Ambiguity)에 어떻게 접근하는가
• 당신이 트레이드오프 (Trade-offs)를 어떻게 수행하는가
• 당신이 제약 조건 (Constraints)을 어떻게 다루는가
• 당신이 결정을 어떻게 전달하는가

완벽한 데모는 AI에 의해 생성될 수 있습니다.

하지만 훌륭한 결정의 흔적은 생성될 수 없습니다.

모든 프로젝트 뒤에 있는 프레임워크

모든 브리프는 Nassim Taleb에게 영감을 받은 의사결정 원칙 세트인 PRINCIPLES.md를 참조합니다.

비아 네가티바 (Via Negativa)

무언가를 추가하기 전에 제거하십시오.

바벨 전략 (Barbell Strategy)

핵심은 안정적으로 유지하십시오.

가장자리에서는 실험하십시오.

스킨 인 더 게임 (Skin in the Game)

되돌릴 수 없는 행동에는 명시적인 승인이 필요합니다.

최적화보다 강건성 (Robustness Over Optimisation)

우아하게 실패하는 단순한 시스템이, 붕괴해 버리는 영리한 시스템보다 낫습니다.

이 원칙들은 추상적이지 않습니다.

각 원칙은 프로젝트 내부의 실제 제품 또는 아키텍처 결정과 연결됩니다.

이 프로젝트들을 사용하는 방법

1. PRINCIPLES.md를 읽습니다.
2. 브리프를 하나 선택합니다.
3. 코드를 만지기 전에 탐색 (Discovery)을 수행합니다.
4. 빌드 로그 (Build log)를 작성합니다.
5. 기준에 따라 스스로 점수를 매깁니다.
6. 피드백을 받기 위해 결과물을 공유합니다.

과정은 최종 결과물보다 더 중요합니다.

한 가지 더

대부분의 사람들은 자신이 코딩할 수 있다는 것을 보여주기 위해 포트폴리오 프로젝트를 만듭니다.

AI 네이티브 (AI-native) 기업에 채용되는 빌더들은 자신이 사고할 수 있다는 것을 보여주기 위해 포트폴리오 프로젝트를 만듭니다.

그 차이는 면접 시작 후 첫 5분 이내에 명확하게 드러납니다.

리소스 (Resources)

GitHub: github.com/ai-native-builder/ai-portfolio-projects

커뮤니티 (Community): r/AINativeBuilder

채용 게시판 (Job Board): ai-native-builder.com