자소서 초안을 생성해 주는 퍼블리셔를 만들어 봤다. 원래는 블로그 포스터를 만들려 했었다. 티스토리에 글을 자동으로 발행하는 기능을 구현하려 했는데, 티스토리 Open API가 폐기되어 있었다. 우회 방법이 없는 것은 아니었지만, 투자 대비 얻는 것이 없다고 판단했고 일단 초안만 생성해주는 스킬로 사용하기로 했다.
그렇다면 무엇을 만들 것인가로 돌아와서, 다른 프로젝트 주제를 여러 가지로 추천받아 보기도 했으나 크게 와닿는 것은 없었다. 결국 피드백 서비스처럼 '내 문제를 해결하자'로 돌아왔고, 지원 병목을 일으키는 자소서 문제를 해결해 보기로 했다. 보통 이력서 하나로 지원하는 것을 선호하는 편인데, 잡코리아나 사람인에는 지원자 이력서를 패딩하는 플랫폼 자체 이력서가 있고, 여기서 자기소개서가 필수로 들어간다. 지금은 이력서에 들어간 자기소개와 비슷한 범용 문장으로 채워져 있지만, 이 공간을 지원 직무와 관련된 역량을 어필하기 위해 사용한다면 후킹 정도가 훨씬 클 것 같았다. 그래서 최근 면접 준비를 위해 만들어 뒀던 채용공고/직무분석 스킬도 재사용해서, 직무에 맞는 컨텍스트를 가지는 자소서를 작성해 보기로 했다.
구현 방향
목표는 사람인/잡코리아 기본 자소서(항목별이 아닌 한 덩어리의 플레인 텍스트)에 들어갈 내용을 채용 공고별로 작성하는 것이다. 공고의 자격요건과 우대사항을 분석해 이와 연결되는 역량 근거를 제시하여 자기소개 문장을 완성하고, 그것을 지원동기와 자연스럽게 연결하는 것까지가 범위이다.
1. 스토리뱅크 채우기
이를 위해 먼저 내 역량을 구조화하여 저장하는 스토리뱅크를 채우는 것으로 시작했다. 이것도 면접 준비용으로 이미 사용하고 있었지만, 자소서라는 비슷하지만 다른 프레임을 위해 경험들을 새로 수치화하고 역량별로 정리해두었다.
2. 스킬 구성
핵심 스킬 구성은 루트 스킬(하위 스킬들 오케스트레이션), 공고 분석 스킬, 초안 작성 스킬(writer), 초안 리뷰 스킬(reviewer) 로 잡았다. 그 사이 블로그 포스터에 사용했던 사용자 문장 스타일 학습을 위한 style-profiler 스킬도 재사용했다.
크롤링 문제
스킬 초안을 만들고 테스트를 하자마자 공고 분석 과정에서 문제가 발생했다. 원티드 채용공고에서는 발견되지 않던 문제인데, 사람인과 잡코리아는 JS 렌더링 방식이라 웹페칭으로 크롤링이 되지 않았다. 정적 HTML이 아닌 자바스크립트로 콘텐츠를 동적으로 그리는 구조이기 때문이다. 이 문제는 Firecrawl MCP를 붙여서 해결했다. 결과 산출물로 생성되는 임시 파일 및 다운로드된 이미지는 프롬프트에 Bash 명령어로 삭제 처리하도록 했다.
기술적 문제는 빠르게 해결됐지만, 핵심 문제인 품질 문제가 이후 계속 발견되엇다.
개선되지 않는 품질 문제
초안의 품질은 기대에 크게 미치지 못했다. 발견된 문제들은 다음과 같다.
- 임팩트 없는 소제목 남발
- 채용공고에서 비중 없는 역량을 가장 앞에 강조
- 기술 스택과 수치의 불필요한 나열
- 핵심 요건과 지원자 역량 간 약한 연결
- ai 냄새(이 자리에 지원하게 된 이유 등 과장된 서술)
이 많은 문제들을 해결하기 위해서는 글의 뿌리가 되는 재료를 손봐야 한다고 생각했다. 따라서 기존의 스토리뱅크를 재구성해 '역량 카탈로그'라는 데이터베이스로 구조화했다. 역량별로 관련 경험들을 인덱싱하고 각 경험에 어떤 역량이 매핑되는지를 명시하는 문서로, ai 가 각 역량 재료들을 어떻게 사용할지 매우 구체적으로 가이드를 제시하는 방법이다. 이전보다 '무엇을 어떻게 해라'가 훨씬 명료해졌다.
그렇지만 다음 초안에서는 또다른 문제가 드러났다. 부자연스러운 도입부, 경험 하나에 300자가 넘어가는 지나치게 자세한 서술, 연결 포인트를 찾기 어려운 기술과 경험의 나열, 어색한 주제 전환 등 반복해서 나타나는 문제도 있었고 새 지침으로 인해 보이는 새로운 문제도 있었다. 여전히 ai 냄새가 나는 문장도 보였다.
가장 심각한 문제라고 생각한 것은, 구조적 오류가 있음을 발견하지 못한 것이었다. '역량 인덱스가 여러 역량을 동시에 매핑하고 있을 경우 writer 는 어떤 기준으로 강조할 역량을 선택할 것인지?' 라는 질문 하나에 깨져버리는 fragile 한 구조를 어느새 만들고 있었다. 각 지침과 설계는 ai 가 제안해 주는 가이드를 따라, 내가 동의할 수 있는 합리적인 선택 + 별도 평가 기준을 가진 리뷰어 확인까지 받아가면서 작업한 것이었지만 그 길을 따라가 보니 구조적 결함이 있는 프레임워크가 완성돼 있었다.
이 문제들을 해결하기 위해 ai 와 논의를 거쳤고, 아래와 같이 여러 지침을 추가했다.
- 단일 에피소드 150자 블로커
- 서술 방식 변경(STAR → 자연 서술+수치 제시)
- 본문 작성 후 도입 문장 작성
- 리뷰어에 문장 연결성+지원동기 하드 블로커 추가
- 지나치게 구체적인 기술 이름 언급 자제
- 카탈로그 인덱스 매핑 규칙 설정
- AI 냄새 예시 추가
또한 디버그 용도로, 모델이 어떤 사고 구조로 해당 문단을 작성했는지 추적하기 위해 메타 draft 파일이란 별도 산출물에 문단별 작성 계획도 함께 출력하도록 했다.
이후의 결과물도 마찬가지로 핵심적인 문제를 잡지 못하였다. 여전히 '드러내고 싶은 건 많은데 드러나지 않는' 글이었고, 너무 많은 지침의 혼재와 충돌로 writer 는 지침대로 쓰는데 특정 기준은 계속해서 통과하지 못하는 문제도 발생했다.
지침 다이어트
너무 많고 구체적인 지침의 혼재와 그들간의 충돌이 이 문제의 근본 원인이라고 생각했다. 프롬프트 작성자인 나부터가 좋은 자소서가 뭔지 모르는데, 눈에 보이는 문제들을 덮는 방향의 지침을 계속 추가하다 보니 나도 뭘 만드는지 모르는 물건을 만들고 있었다. 방향을 바꾸어, 필수적인 것(수치 제시, 사용자 voice 반영, AI 냄새 제거, 핵심 역량 전달 및 자연스러운 흐름)만 남겨놓고 AI의 자율성에 맡기는 것으로 변경했다. Writer의 지침을 대폭 제거하고, 역량 카탈로그의 매핑 규칙도 제거 및 단순화했다. 이전에는 "무엇을 어떻게 써라"를 구체적으로 지시했다면, 이번에는 "이것만은 지켜라"를 최소한으로만 남긴 것이다.
그 결과로, 분량 설정이나 일부 문장 스타일 수정 등 사소한 조정을 거치고, 85% 정도 만족도의 결과물을 얻었다. 이 이상의 품질을 위해서는 문장 스타일 표본이나 역량 경험 등 재료 데이터가 더 쌓여야 할 것 같다. 또 글쓰기라는 창작에 가까운 영역에서 아무래도 '남이 써준 글이 내가 쓴 글보다 더 나같은가?' 에 yes 를 내놓기란 쉽지 않은 것 같아서, 스스로의 통과 기준도 약간 타협하여 이 정도로 만족하기로 했다.
핵심 인사이트
- 지침은 구체적일수록 좋은것만은 아니다.
문제가 발생하면 그 문제를 덮기 위한 지침을 추가한다. 각각의 지침을 추가할 때는 ai 와 치밀하게 논의하고, 납득되는 결론을 내린 후에야 실제 지침으로 추가했다. 그러나 이런 지침이 많아질수록 이전 지침과 충돌을 일으키고, ai 는 모든 지침을 만족하기 위해 목표했던 것과 거리가 먼 결과물을 만들거나 지침의 일부를 빼먹기도 한다.
- ai 가 제시하는 가이드를 따라가다 보니 어느새 모순된 구조를 만들고 있었다.
위의 이야기와 이어지는 내용인데, 문제가 발생할 때마다 ai 와 합리적인 논의>결정>반영의 루프를 따라가다 보니 어느새 질문 하나에 깨져버리는 구조를 만들고 있었다. 이것을 깨달았을 때 느낀 것은, 각각의 논의가 합리적이었더라도 ai 와의 대화는 그 당시의 컨텍스트에 국한되고 편향되어 있을 확률이 높다는 것이다. 즉 나눈 대화의 한마디 한마디에 모든 컨텍스트에 대한 이해가 뒷받쳐주진 않는다는 이야기다. 중요한 것은 메이커인 자신이 프레임워크의 흐름을 이해하고, 통제할 수 있어야 한다. 사용자가 중심을 잡지 못하면 ai 는 그저 구조화된 실패작을 만들 뿐이다. 결국 ai로 뭔가를 제대로 만들려면, 도메인 지식과 설계 역량이 중요한 것 같다.
이번 경험으로 얻게 된 것은 명확하다.
지침은 구체적일수록 좋지만은 않다. 많은 지침은 혼란과 충돌을 야기할 수 있기 때문에, 본인이 통제하기 어렵다면 차라리 핵심적인 소수의 규칙을 통해 가드레일을 만드는 것이 좋다. 과도한 규제나 조건이 있는 작업은 코드가 하는게 나을 수도 있다 ai 가 잘하는 영역을 추려야 한다.
이번 작업은 코드는 하나도 들어가지 않은 글쓰기라는 창작 영역이었기에 다른 경험과 조금 다른 관찰일 수도 있겠다. 그렇지만 앞서 말한 것처럼, 중요한 것은 자신이 이 도메인의 본질을 이해하고 통제하는 것이다. 도메인 지식이 부족하면 그 부분까지도 ai 에게 의존할 수밖에 없겠지만, 그럴수록 원하는 품질의 결과물을 얻기까지 많은 길을 돌아가야 하는 것 같다. 이 경험을 반면교사 삼아서 이전 작업인 블로그 포스터의 완성도를 더 높여보고자 한다.
'Study' 카테고리의 다른 글
| DDD 는 silverbullet일까? (0) | 2026.08.03 |
|---|---|
| 코드리뷰를 왜 할까? (0) | 2026.07.29 |
| 피드백서비스 개선기 (0) | 2026.01.22 |
| Ollama+Spring 피드백 프로젝트 개발 2 (0) | 2026.01.17 |
| 커리어 나침반 문서 (1) | 2026.01.05 |