이력서 자동화 시스템 만들기 도전기 — 잘 되는 것, 안 되는 것 솔직 후기

다락방 · 에이전트 / 노코드 자동화 · · 좋아요 0 · 답글 0

연재 문서 자동화 시스템 설계 1/5편

시스템 설계 — AI가 나한테 인터뷰하다

처음부터 코드를 짜는 게 아니었습니다. 장피엠 님이 공유한 에이전틱 시스템 설계 프레임워크를 참고해서 "이런 시스템이면 좋겠다"는 생각을 먼저 구조화된 문서로 정리했습니다. 폴더 구조, 에이전트 역할 분리 원칙, 데이터 전달 패턴 같은 설계 원칙을 미리 잡아두고 시작한 게 나중에 큰 도움이 됐습니다.

📋 참고한 에이전틱 시스템 설계 프레임워크 (펼쳐보기)

사본

나는 [작업명]을 자동화하는 에이전트 시스템을 설계하려고 한다.

## 작업 개요

- **목적**: 
- **입력**: 
- **출력**: 
- **주요 제약조건**: 

---

## 내가 원하는 산출물

최종적으로 **하나의 통합 설계서 문서(md 파일)**를 만들고 싶다.
이 문서는 Claude Code에서 구체적인 구현을 할 때 참조할 **계획서** 역할을 한다.

### 설계서에 포함될 내용

1. **작업 컨텍스트 문서**
   - 배경, 목적, 범위, 입출력 정의, 제약조건, 용어 정의

2. **워크플로우 정의**
   - 단계별 흐름도, 분기조건, 상태 전이
   - LLM 판단 영역과 코드 처리 영역 구분
   - LLM이 직접 수행할 판단/의사결정 단계 명시
   - 각 단계의 성공 기준 및 검증 방법
   - 실패 시 처리 방식 (재시도 / 에스컬레이션 / 스킵)

3. **구현 스펙** (구조 개요만, 상세 내용 X)
   - 폴더 구조
   - CLAUDE.md 핵심 섹션 목록
   - 에이전트 구조 (단일 또는 서브에이전트)
   - 작업 단계별 처리 방식 (에이전트 판단 vs 스크립트)
   - 스킬/스크립트 파일 목록, 역할, 트리거 조건(언제 이 스킬이 호출되는가)
   - 서브에이전트 사용 시: 이름, 역할, 입출력, 데이터 전달 방식
   - 주요 산출물 파일 형식

---

## 설계 원칙

### [폴더 구조]

에이전트 설정은 `/.claude` 하위에 배치한다.



/project-root ├── CLAUDE.md # 메인 에이전트 지침 ├── /.claude │ ├── /skills/ │ │ ├── SKILL.md │ │ ├── /scripts # 결정론적 도구 │ │ └── /references # (선택) 도메인 지식, API 가이드 등 │ └── /agents/ │ └── AGENT.md ├── /output # 산출물 └── /docs # (선택) 참고 문서


### [판단과 코드의 역할 분리]

| 에이전트가 직접 수행 | 스크립트로 처리 |
|---------------------|----------------|
| 분류, 의사결정, 우선순위 판단 | 파일 I/O, 데이터 파싱 |
| 품질 평가, 정성적 분석 | 외부 API 호출 |
| 컨텍스트 기반 추론 | 반복 처리, 집계 |
| 자연어 생성/요약 | 정적 분석, 테스트 실행 |

### [검증 패턴]

각 워크플로우 단계에는 반드시 성공 기준을 정의한다. 검증 유형은 산출물 성격에 따라 선택한다.

| 검증 유형 | 적용 대상 | 예시 |
|-----------|----------|------|
| **스키마 검증** | 구조화된 산출물 | 필수 필드 존재, 타입 체크 |
| **규칙 기반** | 정량 기준이 있는 작업 | 항목 수, 글자 수, 필수 섹션 포함 |
| **LLM 자기 검증** | 정성적 판단 작업 | 요약 품질, 톤 적합성, 누락 여부 |
| **사람 검토** | 고위험 최종 산출물 | 외부 발송 문서, 의사결정 |

설계서 작성 시 각 단계마다 다음을 명시한다:
- **성공 기준**: 이 단계의 산출물이 충족해야 할 조건
- **검증 방법**: 위 유형 중 어떤 방식으로 확인하는가
- **실패 시 처리**: 아래 패턴 중 선택

### [실패 처리]

| 방식 | 사용 시점 |
|------|----------|
| **자동 재시도** | 검증 실패가 단순 누락/형식 오류인 경우 (최대 재시도 횟수 명시) |
| **에스컬레이션** | 판단 불확실성이 높거나 기준 자체가 모호한 경우 → 사람에게 확인 요청 |
| **스킵 + 로그** | 선택적 단계이며 전체 흐름에 영향 없는 경우 → 사유를 로그에 기록 |

### [에이전트 구조 선택]

**단일 에이전트** (기본):
- 워크플로우가 단순하고 지침이 짧을 때

**서브에이전트 분리** (필요 시):
- **컨텍스트 윈도우 최적화가 필요할 때** -- 지침이 길어서 항상 로드하면 비효율적인 경우, 서브에이전트로 분리하여 필요한 시점에만 해당 지침 로드
- 독립적인 작업 블록이 명확히 구분되고, 각각 다른 도메인 지식이 필요할 때

### [서브에이전트 설계]

- 메인 에이전트(CLAUDE.md)가 오케스트레이터 역할
- 서브에이전트 간 직접 호출 금지 → 메인을 통해 조율
- AGENT.md에 역할, 트리거 조건, 입출력, 참조 스킬 명시

### [데이터 전달 패턴]

| 방식 | 사용 시점 |
|------|----------|
| **파일 기반** | 데이터가 크거나 구조화된 경우 → `/output/step1_result.json` |
| **프롬프트 인라인** | 데이터가 작고 단순한 경우 |

권장: 중간 산출물은 `/output/`에 저장하고 파일 경로만 전달

### [스킬 vs 서브에이전트]

| 스킬 | 서브에이전트 |
|------|-------------|
| 도구/기능 단위 (작음) | 역할/책임 단위 (큼) |
| 여러 에이전트가 공유 가능 | 특정 워크플로우 전용 |
| 예: `file-parser`, `api-caller` | 예: `code-reviewer`, `report-generator` |

---

## 주의사항

- CLAUDE.md, AGENT.md, 스킬 파일의 **상세 내용은 작성하지 않는다** (구현 시 작성)
- 구현 스펙은 **구조와 역할 정의 수준**까지만

---

## 진행 방식

### 1단계: 작업 파악 (필수 확인 항목)

사용자 입력을 받으면 아래 세 영역의 정보가 충분한지 판단한다.
**부족한 영역이 있으면 해당 영역의 질문만 한다. 모두 충분하면 바로 설계에 착수한다.**

| 영역 | 확인할 것 | 부족할 때 질문 예시 |
|------|----------|-------------------|
| **목표와 성공 기준** | 이 에이전트가 궁극적으로 달성해야 할 목표가 명확한가? 성공/실패를 판단할 수 있는 기준이 있는가? | "이 에이전트가 잘 작동했다는 걸 어떻게 알 수 있나요? 어떤 결과가 나와야 성공인가요?" |
| **작업 절차** | 입력→출력까지의 구체적 단계가 있는가? 분기 조건이 명확한가? | "A 이후에 B로 갈지 C로 갈지는 어떤 기준으로 판단하나요?" |
| **에이전트 조직** | 단일/멀티 에이전트 선호가 있는가? 역할 분리 기준이 있는가? | "이 작업을 하나의 에이전트가 순차 처리하면 되나요, 아니면 분리하고 싶은 역할이 있나요?" |
| **기술/도구 대안** | 현재 쓰는 도구가 있는가? 없다면 목적에 맞는 도구·API·라이브러리를 역제시하여 선택을 도울 수 있는가? | "지금 쓰고 있는 도구가 있나요? 없다면 이런 방식들이 가능한데, 어떤 게 상황에 맞을 것 같나요?" |

### 질문 원칙


- 질문은 뻔하거나 상투적이지 않아야 하며, 매우 심층적으로 접근하여 내용이 완성될 때까지 인터뷰를 계속 이어가야 합니다 (최대 3턴)
- 사용자가 모르겠다고 하면 설계 원칙에 따라 LLM이 판단하고 그 근거를 명시한다
- 사용자가 "알아서 해줘"라고 하면, 합리적 기본값을 적용하되 핵심 선택지만 확인한다

### 2단계: 설계서 작성

확인이 끝나면 "설계서에 포함될 내용"에 따라 통합 설계서(md 파일)를 작성한다.

### 3단계: 리뷰

설계서 초안을 제시하고, 수정할 부분이 있는지 확인한다.

그 문서를 Claude Code에게 읽혀서 인터뷰를 시켰습니다.

사본

@[파일명]을 읽고 AskUserQuestionTool을 사용하여 기술적 구현, UI & UX, 우려 사항, 트레이드오프 등 모든 측면에 대해 저를 상세히 인터뷰해줘. 질문은 뻔하거나 상투적이지 않아야 하며, 매우 심층적으로 접근하여 내용이 완성될 때까지 인터뷰를 계속 이어가야 한다. 인터뷰가 끝나면 [파일명]에 내용을 업데이트 해줘.

이 순간이 꽤 인상적이었습니다. AI가 제가 생각하지 못했던 부분을 정확하게 짚어가며 질문했거든요.

"Fit Score를 LLM이 산정한다고 하셨는데, 세부 채점 기준을 직접 설계하실 건가요, 아니면 LLM의 판단에 온전히 위임하실 건가요?"

"LinkedIn과 리멤버를 자동화로 크롤링하면 이용약관 위반 리스크가 있습니다. 어떻게 처리할 계획이신가요?"

저는 코딩 경험이 없는데, 이런 트레이드오프까지 하나하나 짚어가며 설명해주니까 설계 단계에서 훨씬 명확하게 결정을 내릴 수 있었습니다. 비개발자 입장에서는 이 과정 자체가 큰 도움이었습니다.

서브에이전트 구성 — "팀처럼 일하게 하는" 설계 원리

이 시스템에서 제가 가장 신경 쓴 부분입니다. 에이전트 하나가 모든 걸 다 하게 하면 금방 엉망이 됩니다. 그래서 사람처럼 역할을 분리해서 팀처럼 구성했습니다.

총 5개의 에이전트:

에이전트

역할

하는 일

Research Agent

리서치 담당

사람인 등에서 채용 공고 자동 수집

Job Evaluator

평가 담당

공고마다 Fit Score + 경력 적합성 평가

Company Research Agent

조사 담당

지원 전 회사 HRD 맥락 파악

Resume Writer

작성 담당

JD + 내 경력을 매칭해서 이력서 초안 작성

Resume Reviewer

검토 담당

작성 원칙 기준으로 이력서 검토 후 피드백

핵심 설계 원칙 3가지:

1. 역할 분리 철저히 리뷰어는 검토와 피드백만 합니다. 직접 수정하지 않습니다. 수정은 반드시 라이터가 합니다. 처음에는 "그냥 리뷰어가 고치면 안 되나?" 싶었는데, 그렇게 하면 검토 기준이 흐려지고 책임 소재가 불명확해집니다. 회사에서도 QA 팀이 직접 개발하지 않는 것과 같은 이유입니다.

2. 에이전트끼리 직접 대화 금지 모든 중간 결과물은 파일로 저장 후 경로만 공유합니다. 에이전트가 서로 직접 소통하면 나중에 무슨 일이 있었는지 추적이 안 됩니다.

3. Hallucination 방지 이력서에는 resume_base.md와 Notion DB에 실제로 있는 경험만 씁니다. AI가 그럴듯하게 지어내는 일이 없도록 명시적으로 막았습니다.

사본

이력서에는 Notion DB 및 resume_base.md에 실제 존재하는 경험만 기술한다.

이 원칙을 넣기 전에는 AI가 그럴듯한 내용을 만들어내는 경우가 있었습니다. 이력서에서 사실이 아닌 게 들어가면 나중에 큰일 나니까요.

첫 /search-all 실행 — "오, 이게 되네"

시스템을 완성하고 처음으로 채용 공고 자동 탐색을 돌렸을 때가 기억납니다. 명령어 하나 입력했더니 사람인에서 공고를 자동으로 수집하고, 제 경력 기준으로 Fit Score를 계산해서 순위까지 매겨 리포트로 뽑아줬습니다.

플랫폼 3~4개를 번갈아 뒤지면서 적합한 공고를 골라내던 걸 이제 한 번의 명령으로 할 수 있게 됐습니다. 시간으로 따지면 공고 탐색에 쓰던 시간이 절반 이하로 줄었습니다.

STAR 구조화 — 잘 됐던 것과 안 됐던 것

이력서를 쓸 때 단순히 경험을 나열하는 게 아니라 STAR 기법(상황-과제-행동-결과)으로 임팩트 있게 써야 합니다. 여기서도 AI가 역질문하는 방식이 도움이 됐습니다.

사본

문제해결형 과정(@@@ 기업명) 에서 가장 어려웠던 순간이 언제였나요?

이런 식으로 AI가 질문하면서 제가 미처 정리하지 못했던 경험들을 끌어냈습니다. "이해관계자 기대치 충돌이 제일 어려웠던 것 같다"고 답하면, AI가 그걸 STAR 구조로 만들어줬습니다.

다만 솔직히 말하면, 여기서 한계를 느꼈습니다. 경력기술서에 기록된 내용만 가지고 하려다 보니 깊은 이야기가 잘 안 나왔습니다. AI가 물어물어 확인할 수는 있지만, 진짜 나만 아는 이야기는 결국 내가 먼저 찬찬히 고민해서 정리해야 합니다. 쓰레기를 넣으면 쓰레기가 나옵니다.

resume_base.md 날아간 사건

Day 4에 황당한 일이 있었습니다. 다른 AI 도구(Hermes)가 핵심 이력서 데이터 파일(resume_base.md)을 덮어써버려서 내용이 다 날아갔습니다.

사본

헤르메스가 나의 resume_base.md 파일을 날려버렸어. 
나름 복구하려고 하긴 했는데 파일이 완전 깨진 상황이야.

여러 이력서 파일(PDF, DOCX)을 다시 파싱해서 복구하는 데 반나절이 걸렸습니다. 중요한 데이터는 백업이 필수라는 걸 몸으로 배운 날이었습니다.

Before vs After

항목

Before

After

채용 공고 탐색

플랫폼 3~4개 수동으로 뒤지기

/search-all 명령어 하나로 수집 + 평가

이력서 작성

공고 볼 때마다 처음부터 다시 작성

JD 넣으면 경력 매칭 + 초안 자동 생성

이력서 검토

스스로 또는 지인에게 부탁

작성 원칙 기준으로 AI가 7개 카테고리 검토

에이전틱 시스템 이해

개념만 알던 수준

직접 설계하고 구동해본 수준

결과물

  • 5개 서브에이전트로 구성된 HRD 채용 자동화 시스템

  • 회사별 맞춤 이력서 3개 완성 (유명 외국계기업 교육담당자, 심텍, 플립온코리아)

  • 아직 허접한 부분 있음 — 원티드/잡코리아 자동화 미완성, 이력서 베이스 데이터 고도화 필요

효과적이었던 것

  1. 에이전틱 시스템을 이해하고 시작하기 — 일잘러 장피엠 님의 영상처럼 개념을 먼저 잡고 시작하는 게 중요합니다. AI한테 무작정 시키는 것과, 에이전트가 어떻게 루프를 돌며 작동하는지 이해하고 시키는 건 결과가 다릅니다.

  2. AI가 나한테 질문하게 만들기 — "이렇게 해줘"보다 "내 상황을 인터뷰해서 시스템을 설계해줘"가 훨씬 잘 됩니다. 트레이드오프까지 같이 검토해주니까 비개발자도 좋은 결정을 내릴 수 있습니다.

  3. 에이전트 역할 분리 — 검토하는 에이전트와 작성하는 에이전트를 분리하는 것만으로도 품질이 크게 달라집니다.

이렇게 하면 안 돼요

  1. 베이스 데이터 없이 시작하기 — AI가 아무리 잘 물어봐도, 내 경험이 제대로 정리되어 있지 않으면 깊은 이야기가 안 나옵니다. AI 쓰기 전에 내 경력을 먼저 정리하세요.

  2. 에이전트 하나에 다 맡기기 — 역할을 분리하지 않으면 나중에 어디서 뭐가 잘못됐는지 파악이 안 됩니다.

  3. 중요한 파일 백업 안 하기 — AI 도구가 파일을 덮어쓸 수 있습니다. 경험담입니다.

  4. 생각보다 더 구체적인 디렉션 — 자기소개서 양식에 대해서 AI가 어느정도 기본 지식을 갖고있다고 생각하면 안됩니다. 글자수, 문장의 형태(개괄식으로 끝낼지 문장으로 끝낼지) 등 생각보다 기초적인 수준에서의 디렉션이 필요합니다.

프롬프트 1: AI에게 내 업무 시스템 설계 인터뷰 시키기

[내 업무 개요를 담은 문서]를 읽고, 기술적 구현 방법, 트레이드오프, 우려 사항 등 모든 측면에 대해 나를 상세히 인터뷰해줘. 질문은 한 번에 하나씩, 내 답변을 듣고 다음 질문으로 넘어가는 방식으로 진행해. 인터뷰가 끝나면 최종 설계안을 정리해줘.

[내 업무 개요를 담은 문서]는 본인이 하고 싶은 자동화 내용으로 바꾸세요.

프롬프트 2: 에이전트 역할 분리 원칙 설정하기

이 시스템에서 [검토 에이전트]와 [작성 에이전트]의 역할을 철저히 분리해줘.

  • [검토 에이전트]는 검토와 피드백 작성만 담당. 직접 수정 금지.

  • [작성 에이전트]는 [검토 에이전트]의 피드백을 받아서만 수정 작업 수행.

  • 모든 중간 결과물은 파일로 저장 후 경로만 공유.

[검토 에이전트], [작성 에이전트]는 본인 업무에 맞는 역할명으로 바꾸세요.

프롬프트 3: AI가 나한테 역질문하게 만들기

내 [경험/업무 내용]을 바탕으로, 강점을 가장 잘 드러낼 수 있도록 나한테 질문해줘. 질문은 한 번에 하나씩, 구체적인 선택지를 포함해서 물어봐. 내 답변을 들으면서 [목표 결과물]을 함께 만들어가자.

[경험/업무 내용], [목표 결과물]은 본인 상황에 맞게 바꾸세요.

태그: #문서자동화