앞선 작업에서는 데이터 분석 업무를 반복 가능한 Skill로 만들고, 실제로 테스트와 검증까지 진행했습니다.
이번에는 그 방식을 다른 업무에도 적용해보고 싶었습니다.
그래서 다음과 같이 요청했습니다.
경력기술서 작성 Skill을 만들어보자.처음 목표는 비교적 단순했습니다.
기존 이력서와 경력자료를 정리하고
지원 직무에 맞는 경험을 골라내고
성과 중심으로 경력기술서를 작성하고
과장된 표현이나 근거 없는 숫자를 막는 것
하지만 작업을 진행하면서 목표가 조금 달라졌습니다.
단순히 “경력기술서를 잘 써주는 Skill”이 아니라,
AI가 만들어낸 경력 문장을 실제 근거와 연결하고, 과장이나 오류가 있으면 최종 문서로 넘어가지 못하게 하는 Skill
을 만드는 방향으로 발전했습니다.
진행 방법
1. 경력기술서 작성 절차부터 Skill로 만들기
먼저 경력기술서 작성 과정을 하나의 절차로 정리했습니다.
원본 경력자료 확인
→ 경력 연대기 정리
→ 경력과 성과를 개별 주장으로 분리
→ 근거와 개인 기여도 확인
→ 수치 검증
→ 지원 직무와 연결
→ 경력 문장 작성
→ 최종 문장과 근거 연결
→ 검증
→ 사용자 확인
지원하는 문서 유형도 몇 가지로 나눴습니다.
여러 지원에 활용할 전체 경력 원장
특정 채용공고 맞춤 경력기술서
이력서용 짧은 성과 문장
프로젝트 중심 경력기술
리더·관리자용 경력 요약
채용공고가 없는 경우에는 억지로 특정 직무에 맞추지 않고, 먼저 전체 경력을 정리한 Career Bank를 만드는 방식으로 설계했습니다.
2. AI가 경력을 마음대로 꾸미지 못하도록 기준 만들기
경력기술서에서 가장 걱정됐던 부분은 AI가 문장을 보기 좋게 만들면서 실제 경험보다 과장할 가능성이었습니다.
그래서 각각의 경력 내용을 다음 상태로 구분하도록 했습니다.
문서로 확인됨
사용자가 직접 확인함
원본 수치에서 계산됨
추가 확인 필요
근거 없음
예를 들어 사용자가 확인하지 않은 역할이나 성과는 최종 문서에 바로 넣지 않고 보류합니다.
근거가 없는 내용은 실패 처리하도록 했습니다.
확인 필요
→ HOLD
근거 없음
→ FAIL
입력 자료를 읽을 수 없음
→ BLOCKED
검증 완료
→ PASS
3. 팀 성과와 개인 성과를 구분하기
경력기술서에서 특히 주의한 부분은 “팀이 한 일을 내가 혼자 한 것처럼 쓰는 문제”였습니다.
그래서 개인 기여도를 별도로 관리했습니다.
led
→ 방향과 주요 의사결정을 주도
owned
→ 정해진 범위를 직접 책 임
co-led
→ 공동으로 주도
contributed
→ 주요 작업 일부에 참여
supported
→ 자료·검토·운영 등을 지원
직급이나 연차만 보고 자동으로 주도, 총괄 같은 표현을 사용하지 않도록 했습니다.
예를 들어 다음 문장이 있다고 했습니다.
전사 HR 혁신 프로젝트를 단독으로 총괄했습니다.
그런데 실제 근거가 프로젝트 일부에 참여한 수준이라면 다음처럼 낮추도록 했습니다.
HR 데이터 표준화 프로젝트에서
검증 기준 정리에 참여했습니다.
문장을 화려하게 만드는 것보다 면접에서 실제로 설명할 수 있는 수준으로 유지하는 것을 우선했습니다.
4. 숫자가 들어간 성과는 더 엄격하게 검증하기
경력기술서에서는 다음과 같은 표현이 자주 등장합니다.
업무 효율을 50% 개선했습니다.
오류율을 크게 감소시켰습니다.
처리시간을 절반으로 단축했습니다.
하지만 근거가 없는 숫자는 오히려 위험합니다.
그래서 숫자가 포함된 성과에는 다음 정보가 모두 있어야 통과하도록 만들었습니다.
실제 값
기간
비교 기준
적용 범위
출처
예를 들어 실제 기록이 있다면 다음처럼 사용할 수 있습니다.
월간 보고 작성시간을
10시간에서 8시간으로 줄였습니다.
반대로 수치는 있지만 근거가 없으면 질문하거나, 숫자를 제거하거나, 문장을 삭제하도록 했습니다.
5. Skill이 제대로 작동하는지 TDD로 시험하기
Skill 문서만 작성하고 끝내지 않았습니다.
검증 기능을 별도의 프로그램으로 만들고, 테스트를 먼저 작성한 뒤 실패를 확인하고 기능을 구현하는 방식으로 검증했습니다.
초기 테스트에는 다음과 같은 상황을 넣었습니다.
정상적인 경력
→ PASS
사용자 확인이 필요한 경력
→ HOLD
근거 없는 경력
→ FAIL
수치 출처가 없는 성과
→ FAIL
개인 기여도가 없는 경력
→ FAIL
경력 문장과 승인된 Claim이 다른 경우
→ FAIL
또한 주민등록번호처럼 경력기술서에 포함되면 안 되는 민감정보도 차단하도록 했습니다.
첫 단계에서는 약 15개의 테스트를 통과했습니다.
이때만 해도 꽤 완성도가 높다고 생각했습니다.
6. “잘 쓴 경력기술서란 무엇인가?”부터 다시 정의하기
Skill을 만든 뒤 다음 질문을 던졌습니다.
잘 써진 경력기술서가 무엇인지 정의해봐.
그리고 지금 만든 Skill이
그 수준을 어느 정도 구현할 수 있는지도 평가해봐.
AI는 잘 쓴 경력기술서를 다음과 같이 정의했습니다.
지원 직무와 관련된 경력을 선별하고,
본인이 어떤 범위에서 무엇을 했으며
어떤 변화와 결과를 만들었는지를 쉽게 판단할 수 있고,
모든 핵심 문장을 면접에서 근거로 설명할 수 있는 문서.
이를 다시 세 가지 기준으로 압축했습니다.
사실인가?
지원 직무와 관련 있는가?
채용 담당자가 빠르게 판단할 수 있는가?
처음 자기평가 결과는 약 82점이었습니다.
특히 사실성 검증, 기여도 통제, 숫자 검증은 꽤 잘 구현됐다고 평가했습니다.
그런데 이후 독립 리뷰에서 문제가 발견됐습니다.
7. 독립 리뷰를 돌려보니 82점 평가가 무너졌다
독립 리뷰에서는 일부러 Skill을 속이려고 했습니다.
예를 들어 실제 Source는 단순한 출근 기록인데 다음과 같은 문장을 연결하는 식입니다.
전사 혁신 프로젝트를 단독으로 총괄했습니다.
기존 검증기는 Source가 존재하는지는 확인했지만,
그 Source가 정말 해당 문장을 뒷받침하는지
까지는 확인하지 못했습니다.
즉,
Source가 존재한다
≠
Source가 그 주장을 증명한다
는 문제가 있었습니다.
또 다른 우회도 발견됐습니다.
기존 검증기는 -로 시작하는 bullet을 중심으로 확인하고 있었는데,
일반 문단
* 별표 bullet
1. 번호 목록
| 표 안의 성과 |
처럼 다른 형식으로 근거 없는 주장을 넣으면 검증을 피할 수 있었습니다.
숫자도 비슷했습니다.
최종 문장:
매출을 99% 늘렸습니다.
등록된 Metric:
보고서 작성시간 5% 단축
처럼 전혀 다른 수치를 연결해도 통과할 가능성이 있었습니다.
이 결과를 반영해 기존 82점 평가는 철회하고 약 61점 수준으로 낮췄습니다.
이 과정이 오히려 중요한 전환점이었습니다.
8. Machine Gate와 Human Gate를 분리하기
이 문제를 단순히 정규식을 몇 개 추가하는 방식으로 해결하지 않기로 했습니다.
대신 검증 책임을 두 영역으로 나눴습니다.
Machine Gate
AI와 코드가 확실하게 확인할 수 있는 부분을 담당합니다.
JSON 구조
Source와 Claim 연결
수치 필드 누락
개인 기여도 누락
문서에 승인되지 않은 문장 삽입
입력 파일 변경 여부
검증 결과와 파일 해시
채용공고와 경력 연결
개인정보 패턴
검증 영수증의 버전과 상태
Human Gate
사람만 제대로 판단할 수 있는 부분을 담당합니다.
실제 문서가 해당 경력을 정말 증명하는가
문장의 의미가 원본보다 과장되지 않았는가
개인 기여 수준이 실제와 맞는가
회사 기밀이 노출되지 않았는가
이 문장을 면접에서 설명할 수 있는가
최종 경력기술서의 품질이 충분한가
즉 Machine Gate를 통과하더라도 사람이 검토하지 않았다면 최종 PASS를 받을 수 없도록 바꿨습니다.
Machine PASS
+ Human Review 없음
→ REVIEW_REQUIRED
9. 최종 문장과 근거를 더 강하게 연결하기
이후에는 경력을 단순 문장으로 관리하지 않고, 하나의 구조화된 Claim으로 만들었습니다.
개념적으로는 다음과 같습니다.
경력 Claim
누가
→ 지원자
무엇을 했는가
→ 인건비 보고 프로세스 표준화
어떤 범위에서
→ 여러 조직
어떤 역할로
→ 직접 담당
어떤 결과를 만들었는가
→ 보고시간 감소
근거는 무엇인가
→ 업무 자료 + 사용자 확인
그리고 최종 문장이 이 Claim보다 의미를 확대하지 않았는지 사용자가 직접 확인하도록 했습니다.
Human Review 자체도 특정 문장뿐 아니라 다음 자료 전체의 해시값과 연결했습니다.
Evidence Ledger
Claim Map
Audit Document
최종 경력 문장
따라서 검증 이후 문장이나 근거가 바뀌면 기존 승인이 자동으로 무효가 됩니다.
10. 문서 형식을 이용한 검증 우회도 막기
이전에는 Markdown의 특정 bullet 형식만 강하게 검사했습니다.
그래서 검증용 경력기술서인 Audit Copy에서는 허용되는 형식을 아예 제한했습니다.
허용:
지정된 제목
지정된 섹션
경력 헤더
Claim ID가 연결된 경력 bullet
허용하지 않음:
일반 자유 문단
별표 목록
번호 목록
표
인용문
HTML
코드 블록
Claim ID가 없는 성과 문장
즉 검증 대상 문서 자체를 닫힌 형식으로 만든 것입니다.
검증이 끝난 이후에는 내부 Claim ID를 제거해 실제 제출용 Clean Copy를 만들도록 했습니다.
11. 숫자 표현 검증에서 또다시 문제가 발생했다
숫자 검증을 강화했지만 한국어에서는 새로운 문제가 생겼습니다.
예를 들어 다음과 같은 표현입니다.
두 배
수백 건
열댓 건
두어 건
약20%
두 시간 남짓
열 건 안팎
절반가량
처음에는 일부 표현만 인식하거나,
약20%
→ 20%
열한 건
→ 한 건
처럼 전체 표현이 아니라 일부만 추출하는 문제가 있었습니다.
그래서 단순 숫자가 아니라 문장에 실제 표시된 전체 수량 표현을 하나의 단위로 검증하도록 수정했습니다.
최종 문장: 약20%
등록된 수량: 20%
→ FAIL
최종 문장: 약20%
등록된 수량: 약20%
→ PASS 가능
이후 한국어 수량 표현을 계속 추가했습니다.
두어 건
열댓 건
수십여 건
두 시간 반
한 달 반
약 이틀
세 차례
두 명씩
최대 10건
2025년도
3분의 1
12. 그런데 정규식만 늘리는 방식에도 한계가 있었다
수량 검증을 계속 강화하다 보니 더 본질적인 문제가 보였습니다.
예를 들어 다음 단어입니다.
사건
구분
오일
한국어 일반 단어로 볼 수도 있지만, 기계적으로 보면 숫자와 단위의 조합처럼 해석될 가능성도 있습니다.
즉 모든 한국어 수량을 정규식만으로 완벽하게 판정하려고 하면
일반 단어를 숫자로 잘못 판단
또는
실제 수량 표현을 놓침
중 하나가 계속 생길 수 있었습니다.
그래서 다시 책임을 나눴습니다.
Machine Gate
→ 확실하게 판단 가능한 수량 표현 검사
Human Gate
→ 문장 전체의 수량 표현이 빠짐없이 등록됐는지 확인
Human Review에는 다음 확인값도 추가했습니다.
quantitative_completeness_checked: true
즉,
“이 문장 안에 있는 명시적·암묵적 수량을 사람이 직접 확인했다”
는 기록을 남기도록 했습니다.
13. 독립 리뷰 → 실패 → 수정 → 재리뷰를 반복하기
이번 작업에서는 독립 리뷰를 한 번만 하지 않았습니다.
리뷰에서 결함이 발견될 때마다 다음 과정을 반복했습니다.
독립 리뷰
→ 새로운 우회 발견
→ 실제로 실패하는 테스트 작성
→ RED 확인
→ 해당 부분 만 최소 수정
→ 전체 테스트 재실행
→ 후보 버전 고정
→ 새로운 독립 리뷰
그 과정에서 발견된 문제는 매우 다양했습니다.
Source와 Claim의 의미 불일치
수치와 Metric 불일치
다양한 Markdown 형식 우회
중복 JSON Key
오래된 Human Review 재사용
오래된 PASS 영수증 재사용
입력과 출력 경로 충돌
검증 중 파일이 변경될 가능성
가짜 PASS Receipt
수량 표현 우회
경력 헤더 안에 숨긴 주장
JD와 실제 경력 연결 누락
한 번 테스트를 많이 통과했다고 해서 Skill이 완성됐다고 판단하지 않은 것이 중요했습니다.
14. 테스트는 15개에서 40개까지 늘어났다
초기에는 약 15개의 테스트로 시작했습니다.
독립 리뷰가 반복되면서 공격 테스트가 계속 추가됐고, 최종 후보에서는 40개의 테스트가 모두 통과했습니다.
초기
→ 15개 테스트
독립 리뷰 후
→ 20개
추가 공격 검증
→ 23개
한국어 수량·문서 구조·영수증 검증 강화
→ 30개 이상
최종 후보
→ 40/40 PASS
테스트용 경력자료도 네 가지 상태로 유지했습니다.
정상 경력
→ PASS
사용자 확인 필요
→ HOLD
의도적으로 과장된 경력
→ FAIL
문제 부분만 최소 수정
→ 다시 PASS
15. 최종 독립 리뷰 통과
수차례 실패한 뒤 마지막 독립 리뷰에서는 더 이상 차단 수준의 결함이 발견되지 않았습니다.
최종 후보 상태는 다음과 같았습니다.
Independent Review: PASS
Blocking defects: 0
Tests: 40/40 PASS
Candidate readback: 전체 일치
다만 여기서도 바로 설치 완료라고 선언하지 않았습니다.
남아 있는 단계가 있었기 때문입니다.
기술 검증
→ 완료
실제 사용자 경력자료 적용
→ 아직
실제 경력기술서 Human Review
→ 아직
최종 설치
→ 아직
즉 기술적인 후보 검증은 완료했지만, 실제 사람의 경력자료에 적용해보는 마지막 검증은 별도로 남겨뒀습니다.
결과와 배운 점
처음에는 단순히 경력기술서를 작성하는 Skill을 만들려고 시작했습니다.
하지만 결과적으로는 다음과 같은 구조를 가진 검증형 경력 작성 시스템으로 발전했습니다.
경력 원자료
→ Evidence 정리
→ Claim 구조화
→ 개인 기여도 확인
→ 수치 검증
→ 채용공고 매핑
→ Audit 경력기술서 작성
→ Machine Gate
→ Human Gate
→ Clean Copy 생성
AI가 잘 써주는 것보다 사실을 지키는 것이 먼저였다
처음에는 좋은 표현을 만들어주는 것이 중요하다고 생각했습니다.
하지만 경력기술서에서는 오히려 다음 문제가 더 위험했습니다.
없는 숫자를 만듦
팀 성과를 개인 성과처럼 작성
참여한 일을 총괄했다고 표현
지원 직무에 맞추기 위해 경험을 확대
AI가 만든 문장을 검증 없이 사용
그래서 문체보다 먼저 경력 사실과 문장의 연결 구조를 만드는 것이 중요했습니다.
테스트 통과가 곧 완성은 아니었다
처음 15개 테스트를 모두 통과했을 때는 상당히 완성된 Skill처럼 보였습니다.
하지만 독립 리뷰에서는 테스트에 포함되지 않은 새로운 우회 방법을 계속 찾아냈습니다.
15/15 PASS
≠
Skill이 안전하다
오히려 중요한 것은 새로운 공격 사례가 나왔을 때,
문제를 숨기지 않고
→ 실제 실패를 재현하고
→ 테스트에 추가하고
→ 최소 수정하고
→ 전체를 다시 검증하는 것
이었습니다.
AI의 자기평가도 검증해야 했다
초기에는 Skill의 구현 수준을 약 82점으로 평가했습니다.
하지만 독립 리뷰 결과를 반영하자 61점 수준으로 낮춰야 했습니다.
이 과정에서 배운 것은 AI가 만든 결과뿐 아니라 AI가 내린 자기평가 역시 증거에 따라 수정될 수 있어야 한다는 점입니다.
Machine과 Human의 역할을 구분하는 것이 중요했다
특히 한국어 자연어의 의미나 실제 경력 근거의 진위처럼 코드만으로 완전히 판정하기 어려운 영역이 있었습니다.
이를 억지로 자동화하기보다 다음처럼 나누는 것이 더 현실적이었습니다.
기계가 확실히 확인할 수 있는 것
→ Machine Gate
사람의 의미 판단이 필요한 것
→ Human Gate
이 구조를 통해 자동화가 할 수 있는 범위를 과장하지 않으면서도, 반복 검증 업무는 상당 부분 줄일 수 있었습니다.
최종적으로 만든 것은 “글쓰기 Skill”만은 아니었다
이번 작업의 결과는 단순한 경력기술서 템플릿이 아니었습니다.
글쓰기
+ 사실 관리
+ 수치 검증
+ 역할 검증
+ 채용공고 매핑
+ 품질 평가
+ 독립 리뷰
+ 실패 차단
+ 사용자 승인
이 연결된 하나의 업무 흐름을 만든 것이 더 큰 결과였습니다.
현재 기술 검증과 독립 리뷰까지는 통과했지만, 실제 사용자 경력자료를 적용한 최종 검증은 남아 있습니다.
다음 단계에서는 실제 경력자료와 채용공고를 이용해 Career Bank와 경력기술서를 작성하고, “기술적으로 검증된 Skill이 실제로도 좋은 경력기술서를 만들어내는가?”를 확인해볼 계획입니다. 📝🤖
