기존 이력은 편집 없이 그대로 가져와 아래 문제정의서의 기단이 됩니다. AI 이전의 경력도 함께 읽히도록.

문제 — 지원자가 씁니다

채용 시장에서 AI 인재에 대한 수요는 뚜렷해지고 있었다. 채용 공고에 'AI 활용 능력'이 요구 조건으로 명시되기 시작했으나, 이를 확인할 수단은 존재하지 않았다.

수요는 분명한 반면, 그 수요가 해소되는 시장은 형성되어 있지 않았다. 시장 어딘가에 공백이 존재한다는 의미였다. 관건은 공백의 위치였다.

가능성은 두 가지였다. 채용자 측 — 확인하고자 해도 열람할 창구가 없는 경우. 지원자 측 — 무엇을 준비해 제시해야 하는지 알 수 없는 경우. 어느 쪽이 비어 있는지에 따라 만들어야 할 제품이 달라진다.

현상은 확인되었으나 원인은 규명되지 않은 상태였다. 원인을 모른 채 제품을 고도화할 경우 방향 전체가 어긋날 수 있다고 판단했다. 이에 제품 고도화를 중단하고, 원인 조사를 우선하기로 결정했다.

판단 — 지원자가 씁니다

조사는 두 가설의 검증으로 설계했다. 채용자 측 가설은 '열람 가능한 창구가 존재하는가', 지원자 측 가설은 '준비하여 제시할 수단이 존재하는가'로 구체화했다. 이 기준으로 시장을 세 영역 — 업무 기록 도구, AI 채용 스크리닝 도구, 기존 잡보드 — 으로 나누어 조사했다.

채용자 측의 공백이 먼저 확인되었다. 스크리닝 도구는 기존 이력서의 심사 속도를 높일 뿐, AI 역량 자체를 보여주지 않는다. 잡보드의 'AI 역량' 항목은 지원자가 스스로 부여하는 태그에 불과하다. 근거 없이 누구나 붙일 수 있는 표기는 채용자에게 판별 근거가 되지 못한다. 열람할 창구가 부재했다.

지원자 측 역시 비어 있었다. 업무 기록 도구는 다수 존재했으나, 모두 개인의 기록 축적 단계에 멈춰 있었다. 그 기록을 채용에 제출 가능한 형태로 전환해 주는 서비스는 없었다. 준비할 수단이 부재했다.

두 가설 중 하나가 아니라 양측 모두 비어 있었으며, 원인은 하나로 수렴했다. 채용자와 지원자 사이에 '검증 가능한 기록'이라는 매개가 존재하지 않는다. 지원자는 제시할 방법이 없어 준비하지 못하고, 채용자는 열람할 대상이 없어 확인하지 못한다. 서로가 서로의 공백을 유지시키는 구조였다.

이 진단으로 제품의 요건이 도출되었다. 지원자의 기록을, 채용자가 검증할 수 있는 형태로 연결하는 것. 무엇을 구축할지는 다음 판단으로 넘겼다.

실행 기록 — 지원자가 쓰지 않습니다, 세션에서 그대로

✓세션 원문 대조 완료 ·기록은 편집되지 않았습니다

문제 — 지원자가 씁니다

시장 리서치를 통해, 채용자와 지원자 사이에 '검증 가능한 기록'이라는 매개가 없다는 것을 확인했다. 이 공백을 메우는 것이 제품의 방향이 되었다.

당시 채용자가 AI 역량을 확인할 수단은 역량 시험과 면접 실무 과제, 두 가지뿐이었다. 지원자는 일회성 시험 대비 외에 무엇을 준비해야 할지 알 수 없고, 채용자는 시험장의 수행만으로 일상에서 AI와 일하는 능력을 판별할 수 없다. 확인이 면접에 와서야 가능하니, 서류에서 후보를 가려내는 일은 애초에 불가능했다.

요건은 명확해졌다. 이력서에 AI 역량이 담기려면 실제 AI와 일한 대화 로그가 담겨야 하고, 로그가 증거가 되려면 그것을 읽어내는 지표가 있어야 한다.

판단 — 지원자가 씁니다

AI 활용 역량은 대화 로그 그 자체에 이미 드러나 있다고 판단했다.

일을 맡기는 문장, 어긋난 결과를 알아채는 개입, 검수를 거쳐 내보내는 마무리 — 역량을 구성하는 행동이 세션 안에 그대로 남는다. 그리고 수천 턴의 일상 로그는 시험과 달리 통째로 연출할 수 없다. 연출이 불가능하면서 일상 업무와 분리되지 않는 판정의 원천은 대화 로그뿐이었다.

이 명제를 가설로 두지 않기 위해, 로그에서 역량을 실제로 읽어내는 측정 체계를 직접 구축했다. 그 결과가 역량 4축 판정 체계다.

• 위임 — 어떤 크기의 일을, 어디까지 AI에게 맡기는가. 맡기는 순간의 발화로 판정한다
• 지시 — 맡긴 일을 명확한 기준과 제약으로 시키는가. 지시문의 구조로 판정한다
• 분별 — AI의 결과가 어긋났을 때 알아채고 바로잡는가. 개입의 순간으로 판정한다
• 책임 — 결과물을 검수를 거쳐 밖으로 내보내는가. 내보내는 순간으로 판정한다

판정에는 두 원칙을 두었다. 사람이 주도한 행동만 계수한다 — AI가 알아서 한 일은 그 사람의 역량이 아니다. 모든 판정은 당시 발화를 인용해야 한다 — 인용하지 못하는 판정은 폐기한다.

이로써 '로그에서 읽힌다'는 것은 가설이 아니라 작동하는 체계가 되었다. 구현 대상은 대화 로그에서 AI Fluency를 읽어내는 시스템으로 확정했다.

실행 기록 — 지원자가 쓰지 않습니다, 세션에서 그대로

✓세션 원문 대조 완료 ·기록은 편집되지 않았습니다

문제 — 지원자가 씁니다

측정 체계를 만들고 나니 질문이 하나 남았다. 우리의 지표는 'AI를 얼마나 능숙하게 다루는가'를 보여준다. 그런데 기업이 채용에서 확인하고 싶은 것이 정말 그것인가.

채용자의 관점에서 보면 간극이 있었다. AI가 실행을 대체할수록 '시키면 잘 만든다'는 것은 누구에게나 가능한 값이 되어 간다. 기업이 뽑고 싶은 사람은 AI를 잘 다루는 사람이 아니라, AI로 일을 해내는 사람이다. 실행 능숙도를 중심에 둔 인재상으로는 이 둘이 구분되지 않았다.

'AI 인재'가 무엇인지부터 다시 정의해야 했다. 정의가 바뀌면 측정도, 이력서의 구조도 함께 바뀌는 문제였다.

판단 — 지원자가 씁니다

기업이 'AI 역량'이라는 말로 실제로 보고 싶어 하는 것을 두 층으로 재정의했다.

첫째 층은 암묵지다. 무엇이 진짜 문제인지 정의하는 능력, 그리고 결과를 검증하고 개선하는 능력 — 경험 속에서 그 사람 안에 쌓여야만 나오는, 시켜서 되지 않는 것들이다. 둘째 층은 그 암묵지를 AI에게 위임하여 실행으로 옮기는 역량이다. 실행 그 자체는 기본값으로 내려가고, 이 두 층이 인재를 가른다.

재정의에 맞춰 서비스를 개편했다. 이력서의 단위를 '판단 카드'로 바꿨다. 채용자가 카드 한 장에서 읽는 것은 세 가지다 — 지원자가 무엇을 문제로 정의했는지, 어떤 대안을 왜 기각하고 무엇을 택했는지, 그리고 그 판단을 AI에게 위임해 실행한 세션 기록까지. 암묵지가 앞에, 실행 증거가 뒤에 — 채용자가 확인하고 싶은 순서 그대로다.

인재상은 이렇게 바뀌었다. 'AI를 능숙하게 다루는 사람'이 아니라 — 문제를 스스로 정의하고, 해결을 판단하며, 그 실행을 AI에게 위임해 끝까지 해내는 사람.

이 인재상이 보이도록 세 가지 변화를 구현했다.

• 이력서와 로그의 분리 — 자동으로 쌓인 작업 이력 화면은 '로그'로 내리고, 사람이 판단을 직접 쓴 카드만 '이력서'로 부르기로 했다
• 판단의 자동 추론 금지 — 판단을 AI가 대신 추론해 채우는 방식을 실측으로 비교한 뒤 금지했다. 그럴듯하게 쓰지만 사실과 어긋난다 — 암묵지는 본인만 쓸 수 있다
• 실행 기록의 선별 연결 — 카드마다 그 판단을 실행한 세션 기록만 골라 붙이고, 열람하면 당시 대화 원문까지 열리게 했다

실행 기록 — 지원자가 쓰지 않습니다, 세션에서 그대로

✓세션 원문 대조 완료 ·기록은 편집되지 않았습니다

문제 — 지원자가 씁니다

제품의 다음 작업을 정해야 하는 시점이었다. 선택지는 둘이었다. 채용 기업 쪽 기능(B2B)을 먼저 올릴 것인가, 지원자 쪽 수집 생태(B2C)를 먼저 넓힐 것인가. 당시 업무 기록 수집은 Claude Code 한 도구만 지원하고 있었다.

감으로 정하지 않기 위해 시장부터 조사했다. 터미널에서 쓰는 AI 에이전트들의 사용률을 확인했고, Claude Code 외에 다른 범용 AI Agent 툴들의 시장 점유율이 빠르게 높아지는 것을 확인했다. 사용 생태가 다양해지는 속도가 예상보다 빨랐다. 이 속도라면 한 도구만 지원하는 수집은 곧 지원자 업무의 일부만 담는 이력서를 만들게 된다.

판단 — 지원자가 씁니다

B2C 확장을 먼저 작업하기로 판정했다. 에이전트 생태가 다양해지는 속도가 B2B 기능의 긴급도보다 빨랐고, 수집이 불완전해지면 그 위에 올릴 채용 기능도 함께 부실해지기 때문이다. 첫 확장 대상은 조사에서 사용 규모의 성장이 확인된 범용 에이전트 Hermes로 정했다.

시작 전에 원칙 두 가지를 세웠다. 이 서비스에서 수집된 기록은 곧 이력서의 증거다. 확장 작업이 기존 기록을 조금이라도 건드리면 이미 만들어진 모든 이력서의 신뢰가 함께 무너진다. 그래서 첫째 — 기존 데이터는 단 한 건도 변하지 않을 것. 둘째, 이번 확장이 Hermes 전용 땜질이 되면 세 번째, 네 번째 에이전트마다 같은 고생을 반복하게 된다. 그래서 — 다음 에이전트는 쉽게 붙는 구조로 만들 것.

가장 위험한 지점은 기록의 이중 계상이었다. 두 에이전트를 오가며 일하면, 수집기가 기록을 나눠 올리는 경계에서 같은 대화 조각이 양쪽에 두 번 올라갈 수 있다. 그러면 그 사람의 작업량과 위임량이 실제보다 부풀려진다 — 이력서로 치면 경력 한 줄이 두 번 계산되는 것이라, 검증 가능한 이력서라는 전제 자체가 깨진다.

해법은 규칙 하나로 정리했다. '지난번 이후 새로 생긴 부분만 올린다.' 다만 새 부분만 잘라 올리면 대화의 앞뒤가 끊겨 판정 품질이 떨어지므로, 직전 대화 여덟 턴을 참고용으로만 동봉하고 소유는 새 기록에만 남게 했다. 누적 방식으로 보고되는 위임 토큰 수치도 같은 원리로 — 직전 보고값을 저장해 두고 그 이후의 증가분만 계상되게 했다.

확장 구조는 번역의 문제로 접근했다. 도구마다 기록을 남기는 방식이 다르다 — Claude Code는 파일 로그로, Hermes는 내장 데이터베이스로. 도구별 처리를 본체에 심으면 도구가 늘 때마다 본체가 복잡해진다. 그래서 모든 도구의 기록이 하나의 표준 형식으로 번역되어 들어오는 단일 계약을 설계했다 — 본체는 표준만 알면 되고, 새 도구는 번역기(어댑터) 하나만 추가하면 된다. 특정 도구의 버릇을 표준으로 승격하지 않는 것을 설계 원칙으로 삼았고, 설계 후 코드를 역-감사해 누락된 필드를 두 차례 적발해 메웠다.

Hermes 자체는 추측 없이 실측했다. 내부 저장 구조를 직접 열어 세션·메시지·위임 테이블을 확인하고, 문서로 알 수 없는 정보는 20개 정밀 질문지로 만들어 하나씩 직접 실행해 답을 얻었다. 위임 기능은 실제로 한 번 실행해 기록의 실물까지 확인한 뒤에야 어댑터를 붙였다.

마지막으로 세 가지를 실측으로 검증했다. 같은 데이터를 다시 수집해도 어떤 기록도 중복으로 쌓이지 않는다. 새로운 대화가 추가되면 그 대화만 정확히 하나 반영된다. 그리고 기존 Claude Code 수집 경로는 전 구간 테스트에서 어떤 영향도 받지 않았다. 세 가지가 모두 확인된 뒤에 확장 작업을 완료했다.

실행 기록 — 지원자가 쓰지 않습니다, 세션에서 그대로

✓세션 원문 대조 완료 ·기록은 편집되지 않았습니다

문제 — 지원자가 씁니다

MVP의 경계를 정의하고 구현하는 동안, 범위가 계속 커지는 것을 확인했다. 하나를 만들면 그것을 받치는 다음 것이 필요해졌고, '여기까지가 MVP'라는 선이 구현 속도보다 빠르게 밀려났다.

시장 쪽도 비슷한 상태였다. AI 인재 채용의 문제는 현상으로는 분명했지만 — 수요도, 공백도 확인되어 있었다 — 고객이 가장 아파하는 뾰족한 지점이 어디인지는 여전히 특정되지 않았다.

안의 제품은 커지고, 밖의 시장은 흐릿했다. 이대로 구현을 계속하면 큰 제품을 들고, 뾰족하지 않은 시장에 나가게 된다.

판단 — 지원자가 씁니다

구현 확장을 멈추고 GTM을 확정했다. 우리의 문제 해결 능력을 대표적으로 보여줄 수 있는 랜딩 페이지를 먼저 만든다. 제품 전체가 아니라, 우리가 무엇을 문제로 정의했고 무엇으로 풀었는지가 한 화면에서 읽히는 페이지다. 이 페이지에 대한 시장의 반응이, 특정하지 못하고 있던 뾰족한 지점을 알려주는 측정이 된다.

이 판단과 함께 MVP의 범위도 다시 조였다. 그간 붙은 요소를 전수 검토해 불필요한 계층을 삭제했고, 접근 자체를 뒤집었다 — '지금 것에서 빼기'가 아니라, 검증된 기준 버전 위에 '더할 것을 정의하기'. 범위가 다시 커지는 것을 구조적으로 차단하는 방식이다.

랜딩은 만들고 끝내지 않고 정련했다. 번역체 문장을 구조 차원에서 진단해 고치고, 국내 서비스들의 어체 관례를 조사해 전환했으며, 실제 구현에 없는 기능을 서술한 문구를 적발해 실체에 맞게 교정했다. 보여주기 위한 과장 없이, 실제로 하는 일만 적히게 하는 것 — 검증 가능한 이력서를 파는 서비스의 랜딩이라면 그 자체가 증명이어야 하기 때문이다.

실행 기록 — 지원자가 쓰지 않습니다, 세션에서 그대로

✓세션 원문 대조 완료 ·기록은 편집되지 않았습니다

문제 — 지원자가 씁니다

'광부 키우기'는 토스 미니앱 플랫폼(앱인토스)에서 운영한 리워드 앱이다. 사용자는 광고를 보며 게임 속 재화를 캐고, 그 재화를 실제 토스 포인트로 바꿔 간다. 광고 수익의 일부를 사용자에게 돌려주는 구조라, 사용자가 자주 오고 오래 머물수록 서비스도 사용자도 이득을 보는 모델이다.

그런데 리워드 앱에는 구조적인 이탈 문제가 있다. 사용자가 오는 목적이 보상이기 때문에, 보상을 받는 순간 목적이 소진된다. 실제 지표도 그랬다. 첫 보상만 받고 다시 오지 않는 사용자가 많았고, 남아 있는 사용자도 광고를 보고 기다리는 것 외에 할 일이 없어 체류 시간이 짧았다.

가장 쉬운 처방은 보상을 더 주는 것이다. 그러나 이 길은 두 번 실패한다. 지급이 늘어나는 만큼 수익 구조가 무너지고, 보상이 목적인 사용자는 보상이 커져도 받는 순간 똑같이 떠난다. 그래서 문제를 보상의 크기가 아니라 구조로 다시 정의했다 — 이 서비스에는 보상 말고는 돌아올 이유도, 머물 이유도, 다른 사람을 데려올 이유도 없다.

판단 — 지원자가 씁니다

이탈을 하나의 문제로 묶지 않고 네 개의 실패 지점으로 분해했다. 언제, 왜 떠나는지가 서로 다르면 처방도 달라야 하기 때문이다. 그리고 각 지점에 기능을 하나씩 대응시켰다.

첫째, 한 번 받고 떠나는 사용자 — 랭킹. 보상을 받고 나면 더 할 일이 없다는 것이 이탈의 첫 번째 결이었다. 여기에 실제 수령한 토스 포인트 기준의 순위를 공개했다. 게임 속 가상 점수가 아니라 진짜로 받아 간 돈의 순위라서, 방금 첫 보상을 받은 사용자에게 '나보다 많이 받은 사람들'이 곧바로 보인다. 막 소진된 목적이 비교라는 새 동기로 갱신된다.

둘째, 다시 올 이유가 없는 사용자 — 파견. 보상이 그 자리에서 끝나면 재방문은 사용자의 호의에 기대게 된다. 그래서 보상 수령 시점을 미래로 옮기는 기능을 만들었다. 캐릭터를 파견 보내면 정해진 시간이 지난 뒤에 돌아와야 보상을 받을 수 있다. 재방문이 호의가 아니라 일정이 된다.

셋째, 머물 이유가 없는 사용자 — 리듬 채굴. 기존 루프는 광고를 보고 기다리는 수동적인 것뿐이라, 앱을 켜 둘 이유가 없었다. 사용자의 조작에 보상이 실시간으로 반응하는 능동 루프를 새로 설계했다 — 박자에 맞춰 조작할수록 더 캐는 방식이라, 머무는 시간 자체가 플레이가 된다.

넷째, 데려올 이유가 없는 사용자 — 길드. 혼자 해도 아무 차이가 없으면 아무도 친구를 부르지 않는다. 함께할수록 이득인 구조(길드 가입과 보상 공유)를 만들어, 기존 사용자가 새 사용자를 데려오는 레퍼럴 경로를 열었다. 광고비 없이 사용자가 사용자를 늘리는 유일한 길이었다.

네 기능은 맡은 실패가 다르지만 하나의 원칙을 공유한다. 보상의 크기를 키우지 않고, 보상에 도달하는 구조를 바꾼다. 지급 총량은 그대로 둔 채, 돌아오고 · 머물고 · 데려오는 행동이 늘어나게 하는 설계다.

실행 기록 — 지원자가 쓰지 않습니다, 세션에서 그대로

✓세션 원문 대조 완료 ·기록은 편집되지 않았습니다

문제 — 지원자가 씁니다

리텐션 기능들이 자리를 잡으면서 남는 사용자는 늘었지만, 새로 들어오는 사용자가 늘지 않았다.

원인은 플랫폼의 마케팅 구조에 있었다. 앱인토스에서 운영자가 쓸 수 있는 공식 마케팅 도구는 '스마트 발송' — 콘솔에서 푸시·알림 메시지를 만들고 세그먼트를 골라 보내는 기능이다. 문제는 도달량의 통제권이 운영자에게 없다는 점이었다. 실제 운영에서 초기 약 3,000건이 발송된 뒤로는 발송량이 크게 늘지 않았고, 원하는 시점에 원하는 규모로 임의 발송할 수 있는 구조도 아니었다.

정리하면 이런 상황이었다. 제품은 준비됐는데, 노출량은 플랫폼이 쥐고 있다. 문제를 '메시지를 어떻게 더 보내느냐'가 아니라 '발송 기회 자체를 어떻게 더 얻느냐'로 다시 정의했다.

판단 — 지원자가 씁니다

발상을 뒤집었다. 발송 기회는 앱 단위로 주어진다. 그렇다면 앱을 하나 더 만들면, 발송 기회도 하나 더 생긴다.

'농부 키우기'라는 형제 앱을 만들었다. 핵심은 개발 비용이었다 — 새 게임을 만드는 것이 아니라, 광부 키우기의 서버 구조·게임 설계·기능 전부를 재사용하고 테마만 광산에서 농장으로 교체했다. 채굴은 수확이 되고, 광부는 농부가 됐다. 이 재사용 덕분에 개발은 하루 만에 끝났다.

두 앱은 서로의 채널이 되도록 연결했다. 인앱 화면에 상대 앱으로 가는 크로스 프로모션을 넣어 — 농부 키우기의 발송으로 유입된 신규 사용자가 광부 키우기까지 흘러오고, 광부 키우기의 기존 사용자는 농부 키우기의 초기 사용자가 된다. 한 앱 몫의 발송 기회가, 두 앱의 노출로 바뀌는 구조다.

결과적으로 마케팅 예산 없이, 플랫폼의 규칙 안에서, 막혀 있던 유입에 새 경로가 열렸다. 이후 신규 콘텐츠와 미션도 두 앱에 나눠 실으며 상호 유입을 운영의 기본 동선으로 만들었다.

실행 기록 — 지원자가 쓰지 않습니다, 세션에서 그대로

✓세션 원문 대조 완료 ·기록은 편집되지 않았습니다