12 KiB
설계 문서
1. 문제 정의
자기소개서는 문장 생성 문제가 아니라 개인 기억을 직무 맥락에 맞게 선택하고 검증하는 문제입니다. 일반적인 한 번짜리 프롬프트는 다음 실패를 만들기 쉽습니다.
- 입력이 빈 곳을 그럴듯한 수치나 감정으로 채움
- 팀 경험을 지원자 개인 성과로 압축함
성장,협업,도전,기여같은 추상어를 반복함- 회사명만 바꾸면 재사용할 수 있는 지원동기를 만듦
- 사용자 말투보다 지나치게 매끈하고 균일한 문장을 만듦
- 서로 다른 문항에서 같은 경험과 교훈을 반복함
따라서 이 하네스는 생성 모델 앞에 개인 사실 저장소, 단계별 승인, 근거 연결, 결정적 검증기를 둡니다.
2. 설계 목표와 비목표
목표:
- 신입 IT 지원자도 학교, 개인 프로젝트, 동아리, 아르바이트, 오픈소스에서 직무 근거를 찾게 하기
- 개인 사실과 모델 해석을 분리하고 사용자가 수정·확정하게 하기
- 회사·직무·문항별로 경험을 다시 선택하되 개인의 중심 서사는 유지하기
- 초안의 모든 핵심 사실을 경험 ID로 역추적하기
- 사람다운 글을 실제 구체성, 판단, 시행착오, 사용자 문체에서 만들기
- 개인정보와 기밀을 기본적으로 로컬·비추적 상태에 두기
비목표:
- AI 탐지기 우회나 탐지 점수 최적화
- 오탈자, 동의어 치환, 난삽화로 사람처럼 위장하기
- 사실이 없는 역량과 성과를 생성하기
- 채용 합격을 보장하거나 모든 회사에 통하는 범용 답안을 만들기
3. 전체 구조
사용자 대화
│
▼
AGENTS.md ──▶ SKILL.md ──▶ 조건별 reference 문서
│ │
│ ├─ 인터뷰·확인·개요·작성 규칙
│ └─ chat command router
▼
.cover-letter/ 개인 작업 데이터
│
├─ profile.json
├─ stories.json
├─ applications.json
├─ session.json
├─ drafts/
└─ exports/
│
▼
harness.py
├─ init / status / next / validate
├─ context
├─ check-draft
├─ approve
└─ export
에이전트는 인터뷰와 의미 판단을 담당하고, CLI는 파일 생성, 참조 무결성, 준비 상태, 글자 수, 근거 주석, 지원되지 않은 수치, 승인 잠금, 내보내기를 결정적으로 처리합니다. 이 경계 덕분에 모델이 검증 결과까지 임의로 낙관하는 문제를 줄입니다. 이력서·공고·회고는 신뢰할 수 없는 데이터로 취급하며, 그 안의 지시문이나 명령은 실행하지 않습니다.
.cover-letter/는 0700, 핵심 JSON과 내부 .gitignore는 0600으로 유지합니다. 내부 .gitignore의 * 규칙과 저장소 루트 제외 규칙을 함께 사용합니다. 원문 전체보다 확인 가능한 최소 요약을 저장하고 자격증명·식별번호·NDA 원문은 저장하지 않습니다.
4. 상태 모델
NEW
↓ 시작 정보 확인
SCOPED
↓ 경험·가치관·문체 수집
COLLECTING
↓ 프로필과 사용할 경험 확인
PERSONAL_MODEL_CONFIRMED
↓ 공고·직무 확인
TARGET_READY
↓ 문항·분량 확인
QUESTION_READY
↓ 문항별 개요 승인
OUTLINE_APPROVED
↓ 근거 연결 초안
DRAFTED
↓ 하드 게이트와 품질 검증
VERIFIED
↓ 사용자 낭독·면접 설명 확인
USER_APPROVED
↓ 초안·사실·개요 변경 감지
NEEDS_RECHECK
빠른 모드는 경험 수와 인터뷰 깊이를 줄일 뿐 OUTLINE_APPROVED, 사실 근거, 개인정보, 분량 게이트를 생략하지 않습니다. 사용자가 확정 사실이나 공개 권한을 수정하면 에이전트는 이를 참조한 VERIFIED 문항을 needs_recheck로 되돌립니다. VERIFIED에는 승인 해시가 없으므로 이 전환은 작업 규칙이 담당합니다. approve --confirm-all 이후의 USER_APPROVED 상태부터는 CLI가 초안·컨텍스트 해시 차이를 자동 감지해 NEEDS_RECHECK와 내보내기 차단을 강제합니다.
session.stage는 진행 포인터이고 진실의 원천이 아닙니다. status는 프로필·경험·지원처·문항의 실제 필드와 승인 해시를 다시 계산합니다. check-draft는 읽기 전용이고, 에이전트가 대화 검증을 포함해 DRAFTED/VERIFIED를 기록합니다. approve --confirm-all만 최종 USER_APPROVED와 해시를 기록합니다.
5. 데이터 분리
프로필
목표 직무, 경력 단계, IT를 선택한 이유, 반복되는 가치관, 문체 표본, 금지 표현, 개인정보 규칙을 보관합니다. 문체는 “AI가 흉내 낼 버릇”이 아니라 사용자가 평소 허용하는 어휘·설명 깊이·문장 호흡의 경계입니다.
경험 카드
경험은 E### 단위로 저장합니다. 상황보다 다음 항목이 중요합니다.
- 문제를 알아차린 신호
- 당시의 제약
- 팀 범위와 본인 범위
- 첫 가설과 실패한 시도
- 고려한 대안과 선택 이유
- 행동 순서
- 측정 결과와 관찰 결과
- 성과에 대한 기여 범위
- 이후 실제로 바뀐 습관
- 공개 허용 상태
- 결과의 소유 범위
user/team/shared
지원처와 문항
회사 사실, 공고 원문, 출처·확인 시점, 요구 행동, 경험 매핑, 문항 원문, 글자 수, 승인 개요를 함께 둡니다. 모델이 해석한 회사 문화는 공고 원문과 같은 사실 등급을 가질 수 없습니다.
초안
초안은 원천 사실을 바꾸지 못하는 파생 데이터입니다. 문항에 연결된 모든 본문 문단에 <!-- evidence: E001,V002 --> 같은 내부 주석을 붙입니다. 한 문장에는 하나의 경험 계열만 쓰고 승인 개요에 든 정확한 근거만 허용합니다. 제출용 내보내기에서만 주석을 제거합니다.
구체적인 필드는 data-model.md에 정의합니다.
6. 대화 설계
처음에는 8개 항목의 양식을 한 번에 채우게 강요하지 않습니다. 최소 범위를 받고 경험 하나씩 다음 루프를 반복합니다.
자유 회상
→ 사실 후보 요약
→ 사용자 역할·수치·제약 빈칸 질문
→ 사실과 모델 해석 분리
→ 사용자 수정·확인
→ 사용 허용 상태 설정
원문 전체는 기본 저장하지 않습니다. 사용자가 확인한 요약과 모델 해석 후보를 분리하고, 고위험 민감정보는 blocked 상태로 보존하는 대신 삭제·일반화합니다.
중립 질문을 한 번에 1~3개만 묻습니다. “성능을 크게 개선했겠네요?”처럼 답을 유도하지 않고 “무엇을 어떤 조건에서 측정했나요? 정확하지 않으면 수치를 빼도 됩니다”라고 묻습니다.
가치관도 선언을 곧바로 저장하지 않습니다. 예를 들어 사용자가 “저는 책임감이 있습니다”라고 하면, 마감 전에 어떤 위험을 발견했고 무엇을 포기하거나 우선했는지 묻습니다. 서로 다른 경험에서 같은 행동이 반복됐을 때만 지속적인 가치관 후보로 제시합니다.
7. 문항 작성 알고리즘
- 문항이 요구하는 답을 동기, 역량, 성장, 문제 해결, 협업, 입사 후 계획으로 분해합니다.
- 공고의 기술명을 관찰 가능한 행동으로 변환합니다.
- 확인된 경험을 요구 행동과 매핑합니다.
- 가장 강한 경험 하나와 보조 근거를 선택합니다.
- 한 문장 핵심 답변과 문단별 역할을 제안합니다.
- 사용자가 선택한 개요만 승인 상태로 저장합니다.
- 승인 개요가 참조한 근거만 컨텍스트에 넣습니다.
- 초안 문단에 근거 ID를 연결합니다.
- 사실 → 문항 → 구성 → 문체 → 압축 순서로 검증합니다.
- 사용자가 여섯 확인 항목을 검토한 뒤 초안·컨텍스트 해시를 잠급니다.
- export에서 해시와 게이트를 다시 확인한 뒤 주석을 제거합니다.
글자 수가 짧을수록 경험을 여러 개 나열하지 않습니다. 보통 한 문항에는 하나의 핵심 경험을 쓰고, 가치관이나 반복 행동을 짧은 보조 근거로 사용합니다.
8. 품질 게이트
하드 게이트
하나라도 걸리면 제출 후보가 될 수 없습니다.
- 출처 없는 수치, 기간, 기술, 역할, 성과, 회사 사실
- 미확인 또는 사용 금지 근거
- 팀 성과를 사용자 개인 성과로 바꾼 인과
- 개인정보, 고객 정보, API 키, 내부 URL, NDA 대상 정보
- 문항 요구 누락 또는 글자 수 초과
- 승인되지 않은 개요
- 사용자가 구두로 설명할 수 없는 문장
- 승인 개요 밖 근거 또는 한 문장에 합성된 여러 경험
- 팀·공동 결과를 개인 성과로 바꾼 문장
[확인 필요], TODO, 비정규화 한글, 보이지 않는 문자- 승인 후 바뀐 초안이나 사실 컨텍스트
소프트 품질
100점 루브릭을 사용하되 점수보다 하드 게이트를 우선합니다.
| 항목 | 배점 | 핵심 질문 |
|---|---|---|
| 사실성·추적성 | 25 | 모든 사실이 확인된 근거에 연결됐는가 |
| 개인 고유성·소유권 | 20 | 관찰, 선택, 시행착오, 책임 범위가 보이는가 |
| IT 기술 판단 | 15 | 기술명이 아니라 이유·대안·검증이 있는가 |
| 가치관·성찰 | 15 | 선언이 아니라 행동과 이후 변화로 드러나는가 |
| 직무·공고 정합성 | 10 | 공고 요구와 실제 경험이 연결되는가 |
| 사용자 목소리 | 10 | 본인 어휘와 설명 깊이를 보존하는가 |
| 문항·구성 준수 | 5 | 질문에 바로 답하고 분량을 지키는가 |
85점 이상은 사용자 확인 후 제출 후보, 70~84점은 부분 재인터뷰, 70점 미만은 문장 수정 대신 경험 수집으로 돌아갑니다.
9. 고유성 검사
핵심 문단마다 다음 개인 지문 중 두 가지 이상을 요구합니다.
- 처음 알아차린 구체적 신호
- 당시 제약
- 직접 내린 결정
- 선택하지 않은 대안과 이유
- 담당한 기능·프로세스 범위
- 실패한 시도나 판단 변경
- 확인 가능한 결과
- 이후 바뀐 행동
- 속도·품질·복잡성 사이의 트레이드오프
추가로 이름 교체 테스트, 회사명 교체 테스트, 2분 설명 테스트, 팀/개인 소유권 테스트, 반대 선택 테스트를 사용합니다. 이 검사는 글을 일부러 불규칙하게 만들기 위한 것이 아니라 내용이 실제 사용자에게만 속하는지 확인하기 위한 것입니다.
CLI 의미 검사는 영문 기술명, 한국어 구체 명사, 행동·소유권 표지의 보수적인 휴리스틱입니다. 자연스러운 동의어를 거짓 양성으로 막을 수 있으므로, 이때는 검사를 우회하지 않고 근거와 공유하는 구체 명사를 남기거나 경험 카드의 확인 표현을 고칩니다. 반대로 검사 통과는 사실의 진실성을 증명하지 않으므로 사람의 사실·면접 확인이 필수입니다.
10. 구현 범위
현재 구현은 다음 P0/P1 기능을 제공합니다.
- 저장소 단위 스킬과 대화 명령 라우팅
- 개인 작업 공간 템플릿
- 상태와 다음 작업 계산
- 데이터·참조 무결성 검사
- 승인된 근거만 모으는 컨텍스트 생성
- 근거 주석, 수치, 분량, 상투 표현의 결정적 검사
- 문항 근거 범위, 경험 합성, 팀/개인 소유권, Unicode·내부 URL 검사
- 허용 필드 기반 컨텍스트 투영, 서명 URL·사설 엔드포인트 제거
- 결과 전용 근거 대조와 숫자·단위·한글 수량 검사
- 여섯 사용자 확인과 초안·컨텍스트 해시 잠금
- 제출용 주석 제거 내보내기
- 표준 라이브러리 기반 자동 테스트
향후 확장 후보는 문체 표본의 통계 비교, 문항 간 경험 중복 경고, 포털별 글자 수 어댑터, 구조화 익명화 사전, 면접 질문 자동 생성입니다. 확장하더라도 모델이 원천 사실을 수정하지 못한다는 원칙은 유지합니다.