이력서 한 줄을 포트폴리오 섹션으로 풀어내는 4-Phase 하네스 설계하기

목차

도입: 포트폴리오 작성에 하네스가 필요했던 이유

최근 한 회사 전형에 지원하면서 포트폴리오를 만들어야 하는 상황이 됐다. 그런데 막상 시작하니 나 혼자서는 막막했다. 이력서 항목 중 어떤 게 면접관 시점에서 매력적인지 판단하기 어려웠고, 골랐다 한들 그걸 어떻게 풀어쓸지, 리뷰는 또 어떤 기준으로 해야 할지도 감이 안 잡혔다.

내가 매력적이라고 생각하는 게 면접관에게도 매력적일까? 그리고 그걸 누가 어떤 기준으로 판단하지?

단일 프롬프트로 한 번에 시도해보지는 않았다. (어차피 안 될 게 뻔했기 때문이다) 평소 경험상 단일 세션에서 큰 작업을 한 번에 시키면 컨텍스트 오염 때문에 리뷰 품질부터 무너진다. 어차피 하네스로 갈 거라면 처음부터 단계를 잘 분해해서 설계하는 편이 낫다. 마침 나는 평소에도 하네스 파이프라인을 즐겨 만드는 편이다. 블로그에 만들어둔 스킬들이 거의 다 그런 식이다. 이번에도 같은 방식으로 가기로 했다.

여기서 한 가지 짚고 가자. 왜 굳이 “포트폴리오”를 만드는가? 이력서로 보여주기 어려운 문제 해결 과정을 가장 잘 풀어쓸 수 있는 형식은 사실 블로그 글이다. 그런데 블로그 글에는 두 가지 한계가 있다. (1) 면접관이 정말 그 글을 찾아 읽을지 장담할 수 없고, (2) 글의 결이 너무 취업용으로 보이면 정보 전달 의도가 흐려진다. 그래서 나는 포트폴리오라는 형식으로 한 번 압축하기로 했다.

면접까지 간다면 이거 한 번 물어봐 주세요, 잘 대답할 수 있어요~

이런 뉘앙스로 면접관에게 질문을 유도하는 트리거. 그게 내가 생각하는 포트폴리오의 본질적 역할이라고 본다.

의사결정 주체를 어디서 분리할까

먼저 정리해야 할 건 “어디까지 AI에 맡기고, 어디서부터 인간이 직접 해야 하는가”였다. 답은 분명했다. 나의 진짜 경험 부분은 AI에게 맡기면 안 된다. 이력서에 적힌 한 줄은 압축된 요약이지 그 자체가 경험은 아니기 때문이다. AI는 그 한 줄을 보고 그럴싸한 이야기를 지어낼 수는 있지만, 그건 내 경험이 아니라 평균적인 누군가의 경험이 된다.

이력서 한 줄은 진짜 경험을 압축한 결과물이지, 그 자체가 경험은 아니다.

그렇다면 AI는 무엇을 잘하는가. 내가 발견한 답은 말투와 표현의 일관성이다. 내가 에피소드를 정리되지 않은 형태로 던져도, AI는 그걸 듣고 적절한 단어와 표현으로 구성해준다. 물론 가끔 너무 과한 표현이 들어가서 직접 수정해야 하는 부분도 있었지만, 어쨌든 일관된 톤으로 마감하는 일은 AI가 더 빠르고 정확했다.

이 두 가지가 정해지자 단계 분해의 그림이 잡혔다. 평소 내가 개발용 하네스를 설계할 때 자주 쓰는 패턴이 있다. 플래너 → 실행자 → 리뷰어의 루프다. 플래너가 무엇을 해야 할지 정하고, 실행자가 작업을 진행하고, 리뷰어가 결과를 검증하는 식이다. 포트폴리오 작성도 결국 이 패턴 위에 올릴 수 있다고 봤다. 다만 그대로는 부족했다. 한 단계가 빠져 있었다.

그게 Interview 단계다. 이력서 큐레이션 결과에는 자세한 에피소드가 담겨 있지 않기 때문이다. 면접관이 이력서를 읽고 “이게 무슨 의미죠? 어떤 상황이었나요?”라고 묻는 것처럼, 큐레이션 다음에 인간이 디테일을 직접 채워 넣는 단계가 있어야 했다. 이력서 한 줄을 두고 미래의 면접관이 던질 법한 질문을 미리 던지고 스스로 답하는 셈이다.

면접관이 이력서를 보고 물어볼 법한 질문을 미리 풀어두자.

여기까지 정해지니 자연스럽게 4단계가 도출됐다. Curation → Interview → Drafting → Review. 단계마다 의사결정의 주체가 다른 구조다. 매번 이렇게 단계를 가르는 게 습관이 됐는데, 이번 경우에는 평소 개발용 하네스 설계에서 누적된 직관이 그대로 박혔다.

Phase별 하네스 구조

전체 흐름을 먼저 그림으로 정리하면 다음과 같다.

┌─────────────┐    ┌─────────────┐    ┌─────────────┐    ┌─────────────┐
│  Curation   │ →  │  Interview  │ →  │  Drafting   │ →  │   Review    │
│   AI 주도   │    │  인간 주도  │    │   AI 주도   │    │  AI + 인간  │
└─────────────┘    └─────────────┘    └─────────────┘    └─────────────┘
   후보 선별        디테일 채우기      마크다운 작성       다차원 평가
   ✋ GATE 1         ✋ GATE 2                          ✋ GATE 3·4

Phase 1, 2, 4 끝에 사용자 게이트가 있고, Phase 3과 4는 한 묶음으로 자동 루프된다. 하나씩 풀어보자.

Phase 1: Curation (후보 선별)

입력은 두 가지다. 첫째, 내가 손으로 관리하는 이력서 마크다운과 프로젝트 메타데이터. 둘째, 지원하는 회사의 JD(직무 설명서)다 (선택).

이 단계의 핵심은 모든 후보 항목을 동등하게 보지 않는다는 점이다. JD가 있으면 다섯 가지 슬롯으로 파싱한다.

1. 회사·도메인
2. 핵심 책임
3. 우대 기술 키워드
4. 시니어리티
5. 인재상·평가 기준

이 다섯 슬롯과 각 후보 항목의 매칭도를 항목별 가중치로 채점한다 (기술 매칭 40 / 책임 매칭 30 / 인재상 매칭 20 / featured 10). 단일 점수 대신 분해해서 출력하면 사용자가 우선순위 근거를 직접 검증할 수 있다.

같은 단계에서 한 가지 더 한다. 이력서 한 줄을 문제·해결·결과 셋으로 점검하는 작업이다. 이력서 한 줄에서 셋 중 하나라도 빠져 있으면, 그 줄 자체가 갱신 후보다. 빠진 게 있으면 그게 곧 다음 인터뷰 단계의 입력이 된다.

이력서 한 줄과 포트폴리오 한 섹션은 같은 압축본과 풀이본 관계다.

이 첫 단계는 AI 주도다. 사용자는 마지막에 “어떤 항목 N개를 작성할 것인가”만 결정한다.

Phase 2: Interview (디테일 채우기)

선택된 항목을 한 번에 하나씩 순회한다. 각 항목마다 네 가지 카테고리의 질문 풀에서 3~5개를 골라 던진다.

1. 앵커링: 이력서에서 추론한 정보로 “이게 맞나요?” 형태로 시작
2. 정량: 결과를 채울 수치 답변 (필수, 한 개 이상)
3. 의사결정·트레이드오프: 다른 선택지 대신 이것을 고른 이유
4. 실패: 시도했다가 실패한 경험, 거기서 배운 것

앵커링 질문이 먼저 나오는 이유는 인간의 부담을 줄이기 위해서다. 빈 페이지를 두고 “본인 경험을 자유롭게 말씀해 주세요”라고 하면 막막하지만, “이 프로젝트는 약 8개월 진행된 것으로 정리되어 있는데 맞나요?”라고 물으면 답이 술술 나온다.

각 답변은 인터뷰 노트로 즉시 저장된다. 한 번 만든 인터뷰 노트는 다른 회사 JD에도 재사용할 수 있는 영구 자산이 된다.

같은 프로젝트로 다른 JD에 맞춰 작성할 때 인터뷰 노트가 있으면 이 단계를 스킵하거나 부분 재실행할 수 있다.

이 단계가 의사결정 분리의 핵심이다. AI는 내 경험의 디테일을 알 수 없기 때문이다.

Phase 3: Drafting (마크다운 작성)

인터뷰 노트가 모이면 portfolio-strategist 에이전트가 호출된다. 입력은 다음과 같다.

• 인터뷰 노트 (Phase 2 결과)
• JD 컨텍스트 (Phase 1 파싱 결과)
• 이력서 원문 한 줄 (단어수 비율 검증을 위해)
• 작성 템플릿
• 전략 원칙

에이전트는 인터뷰 노트의 진짜 내용을 바탕으로 마크다운 섹션을 생성한다. JD 키워드가 인위적으로 박히지 않고 인터뷰 내용 안에서 자연스럽게 등장하도록 가이드를 줬다.

이 단계에는 사용자 게이트를 두지 않는다. 작성 직후 곧바로 다음 단계 평가가 시작되기 때문이다. 결과가 부족하면 자동 재작성 루프로 넘어간다.

Phase 4: Review (채용 담당자 시점 평가)

작성된 마크다운에 대해 portfolio-reviewer 에이전트가 호출된다. 평가는 다차원 임계로 한다.

• 구조 (Binary): 문제·해결·결과 구조 + 정량 지표 포함 여부
• 적합도 (70+): JD 매칭, 이력서 한 줄과의 일관성
• 가독성 (75+): 단어수 비율 (1:8~1:15가 정상)
• 종합 (80+)

세 카테고리 모두 임계를 통과하고 종합 점수가 80을 넘어야 PASS다. 미통과면 어떤 카테고리가 부족한지 피드백과 함께 Phase 3을 재호출한다. 최대 3회까지 자동 루프가 돈다.

단어수 비율이 1:3 미만이면 복사 의심, 1:30 초과면 장황 의심으로 본다.

마지막 게이트에서 사용자가 결과를 검토한 뒤 저장한다. 이 시점이 인간이 다시 끼어드는 자리다. AI 평가를 받아들일지 말지의 최종 결정은 사람의 몫이다.

설계의 핵심 결정 두 가지

스킬을 만들면서 내린 결정 중 두 가지를 짚어두고 싶다. 둘 다 이유가 명확하고, 그 이유가 곧 내가 평소에 하네스를 만드는 사고 방식의 일부다.

결정 1: 작성 에이전트와 평가 에이전트를 분리한다

Phase 3과 Phase 4를 같은 에이전트가 처리하면 어떨까? 한 에이전트가 마크다운을 작성하고, 그 결과를 평가하고, 부족하면 다시 쓰는 방식이다. 동작은 할 것 같다. 하지만 두 가지 문제가 있다.

첫째, 컨텍스트 오염이다. 작성에 쓴 컨텍스트가 평가 단계에까지 영향을 준다. 어떤 표현을 왜 골랐는지, 어떤 부분이 약점인지를 이미 “알고 있는” 상태로 평가하면 시야가 좁아진다.

둘째, 자기 결과물에 관대해지는 경향이다. AI도 사람처럼 본인이 쓴 글에는 관대하게 점수를 매긴다. 본인이 만든 출력을 본인이 평가하면 평가 임계 자체가 흔들린다.

그래서 portfolio-strategist(작성 전담)와 portfolio-reviewer(평가 전담)를 분리했다. 두 에이전트는 서로 다른 입력을 받고, 다른 컨텍스트에서 동작한다. 평가가 객관적으로 작동하려면 작성과 완전히 분리되어 있어야 한다.

본인이 만든 출력을 본인이 평가하지 않게 한다.

결정 2: 인터뷰 답변을 파일로 남긴다

Phase 2 인터뷰 답변을 처리하는 방법은 두 가지다. 메모리에 두고 Phase 3에서 곧바로 소비하는 방식, 또는 파일로 저장한 뒤 다음 단계에서 다시 읽는 방식이다. 첫 번째가 더 빠르다. 그런데 이 스킬은 두 번째를 택했다.

이유는 사용자 승인이다. 인터뷰 답변을 사용자가 한 번 검토하고, 필요하면 직접 편집한 뒤 다음 단계로 넘어가야 한다. 메모리에만 있으면 검토할 시점이 없다. 파일로 떨어뜨려놓아야 사용자가 펼쳐 보고 고칠 수 있다.

부수 효과도 있다. 인터뷰 노트는 그 자체가 영구 자산이 된다. 같은 프로젝트로 다른 회사 JD에 맞춰 포트폴리오를 다시 쓰는 상황이 오면, 이미 채워진 노트를 재사용할 수 있다. 인터뷰는 한 번 하면 그 결과가 누적된다.

한 번 답한 것은 다시 답할 필요가 없어야 한다.

이 두 결정이 합쳐지면 한 가지 흐름이 보인다. AI가 만든 결과물은 사용자가 볼 수 있는 자리에 남긴다는 패턴이다. 인터뷰 노트도, 평가 결과도, 마크다운 섹션도 모두 파일이거나 사용자 게이트 화면 안에 노출된다. 평소 내가 하네스를 만들 때 가장 자주 신경 쓰는 부분이다.

실제 적용 후기

이 스킬을 만들게 된 직접적 계기인 한 회사 전형에 그대로 적용해 포트폴리오 페이지를 완성했다. 의도한 흐름이 그대로 작동했고, 4-Phase 모두 실제로 부담스럽지 않게 굴러갔다.

다만 한 가지 부족한 점이 보였다. AI가 생성한 결과물이 너무 전문 용어 위주로 흐르는 경향이 있었다. 정확한 표현을 고르려고 하다 보니 평소 내가 쓰는 말투보다 무거워졌고, 그 결과 누가 봐도 “AI가 쓴 것 같다”는 느낌을 주는 문장이 섞여 있었다. 마지막 단계에서 사람이 다시 손을 봐야 자연스러워졌다.

정확한 단어를 고르는 것과 자연스러운 톤을 고르는 것은 같은 일이 아니다.

이 점은 다음 회차의 개선 포인트로 남겨뒀다. portfolio-strategist 에이전트에 톤 가이드를 더 명시적으로 줘야 할 것 같다. 본인이 평소 쓰는 표현 사례를 함께 입력으로 넣는 식이다.

재사용성은 아직 직접 검증해보지는 않았다. 다른 회사 JD에 적용해본 적이 없기 때문이다. 다만 인터뷰 노트가 모두 파일로 저장되어 있고 JD 컨텍스트는 입력 단에서만 영향을 주는 구조라, 같은 프로젝트로 다른 JD를 받으면 Phase 2를 거의 스킵할 수 있을 거라고 본다. 이건 다음 전형에서 자연스럽게 검증될 것이다.

전체적으로는 “이 정도면 충분하다”는 감각이다. 이력서 한 줄에서 출발해 검증된 케이스 스터디까지 도달하는 흐름이 한 호흡으로 이어졌고, 가장 막막했던 부분, 즉 어떤 항목을 고르고 어떻게 풀어낼지의 판단을 도와주는 부분이 자동화됐다는 점이 이 스킬의 본질적 가치였다.

마무리

포트폴리오 작성에서 막혔던 지점은 결국 두 가지였다. 어떤 사례를 고를 것인가, 그걸 어떻게 풀어낼 것인가. 4-Phase 하네스는 이 두 질문을 단계로 나눠서 처리한다. 큐레이션이 첫 번째 질문을 풀고, 인터뷰가 디테일을 채우고, 작성과 평가가 풀이의 품질을 보장한다.

설계의 핵심은 두 가지였다. 단계마다 의사결정의 주체가 다르다는 점, 그리고 AI가 만든 결과물은 사용자가 볼 수 있는 자리에 남긴다는 점이다. 이 두 가지 패턴은 이 스킬에서 처음 발견한 게 아니다. 평소 내가 하네스를 만들 때마다 자연스럽게 따라가는 결이고, 이번에도 그대로 박혔다.

부족한 부분은 다음 회차에서 다듬어가면 된다. 톤 가이드를 더 명시적으로 주는 시도, 다른 회사 JD로 재사용성을 검증하는 시도는 다음 전형이 오면 자연스럽게 진행될 것이다. 하네스는 한 번 만들고 끝나는 게 아니라 사용 후기에 따라 진화한다.

직접 만들어보고 싶은 분을 위한 프롬프트

이 글의 4-Phase 구조를 그대로 복제하고 싶다면, 본인이 사용하는 AI 코딩 도구(Claude Code, Cursor 등)에 다음 프롬프트를 주면 된다.

포트폴리오 작성을 위한 4-Phase 하네스 스킬을 만들어줘.

## 입력
- 이력서 마크다운 파일 (한 줄씩 PSR 형태로 정리된 항목들)
- 프로젝트 메타데이터 파일 (선택)
- JD(직무 설명서): 파일·URL·인라인 텍스트 어느 형태든 받음 (선택)

## Phase 1: Curation (AI 주도)
- 이력서·프로젝트 데이터에서 모든 후보 항목 추출
- JD가 있으면 회사·도메인 / 핵심 책임 / 우대 키워드 / 시니어리티 /
  인재상 같은 슬롯으로 파싱한 뒤 각 후보 항목의 매칭 점수를 매김
- 이력서 한 줄을 P(문제)·S(해결)·R(결과) 셋으로 분해하여
  빠진 요소 표시
- 사용자 게이트: 어떤 항목 N개를 작성할지 최종 선택

## Phase 2: Interview (인간 주도)
- 선택된 항목마다 카테고리별 질문 풀에서 3~5개 선별:
  앵커링·정량·의사결정·실패 같은 카테고리
- 앵커링 질문 우선 (이력서에서 추론한 정보로 "이게 맞나요?" 형태로 시작)
- 정량 질문 필수 (수치 답변 한 개 이상 확보)
- 답변은 즉시 파일로 저장 (메모리에만 두지 않음)
- 사용자 게이트: 인터뷰 노트 검토·편집 후 진행 승인

## Phase 3: Drafting (AI 주도)
- 작성 전담 에이전트 호출 (예: portfolio-strategist)
- 입력: 인터뷰 노트 + JD 컨텍스트 + 이력서 원문 한 줄 + 작성 템플릿
- 출력: 마크다운 섹션
- 사용자 게이트 없음 (Phase 4로 자동 진행)

## Phase 4: Review (AI 평가 + 인간 승인)
- 평가 전담 에이전트 호출 (예: portfolio-reviewer)
  ★ 작성 에이전트와 반드시 분리할 것
- 다차원 평가 임계 적용 (구조·적합도·가독성·종합)
- 단어수 비율 검증: 이력서 한 줄 ↔ 포트폴리오 섹션이 1:8~1:15면 정상
- 미통과 시 Phase 3 자동 재호출 (최대 N회)
- 사용자 게이트: 평가 결과 확인 + 최종 저장

## 핵심 원칙
1. 작성 에이전트와 평가 에이전트를 반드시 분리.
   컨텍스트 오염과 자기 결과물에 관대해지는 경향을 막기 위함
2. AI가 만든 결과물은 파일이나 사용자 게이트 화면 안에 노출.
   사용자가 검토·편집할 시점을 만들기 위함
3. 인터뷰 노트는 영구 자산.
   같은 프로젝트로 다른 JD에 재사용 가능해야 함

본인 환경에 맞게 입력 데이터 위치, 에이전트 호출 방식, 평가 점수 임계를 조정하면 된다. 핵심은 4-Phase 구조와 의사결정 주체의 분리다. 나머지는 본인 워크플로우에 맞게 변형해서 쓰면 된다.