AI커리어문제해결도그푸딩

AI 시대 개발자의 자리 (1/5) — 내가 만든 이력서 서비스로 내 이력서를 써봤다

2026년 9월 28일7 분 읽기

AI 시대 개발자의 자리 (1/5) — 내가 만든 이력서 서비스로 내 이력서를 써봤다

두 달 넘게 글이 없었다. 코드를 안 쓴 건 아니다.

그동안 한 일은 하나다. 내가 만든 이력서 관리 서비스로, 내 이력서를 실제로 썼다. 그걸로 지원하고, 면접을 보고, 떨어지고, 붙었다.

만드는 것과 쓰는 것은 다른 일이다. 이 말은 너무 많이 들어서 이제 아무 의미가 없는 문장인데, 직접 겪으니 문장이 다시 살아났다. 그래서 이 시리즈는 기술 튜토리얼이 아니다. AI가 개발자를 대체한다는 이야기 속에서, 실제로 뭐가 팔리고 뭐가 안 팔렸는지에 대한 기록이다.


1. 도그푸딩은 "써보는 것"이 아니라 "걸어보는 것"이다

서비스를 만들 때는 계속 써봤다. 버튼을 누르고, 화면을 보고, 버그를 고쳤다. 그건 도그푸딩이 아니었다. 기능 테스트였다.

진짜 도그푸딩은 그 서비스의 결과물을 들고 밖으로 나가서, 남에게 평가받고 돌아오는 것이다. 이력서 서비스라면 면접에 붙거나 떨어지는 것까지가 하나의 사이클이다. 그 사이클을 돌려보니, 내가 공들여 만든 기능과 실제로 쓴 기능이 거의 겹치지 않았다.

만들 때 핵심이라 생각한 것실제로 쓴 정도
공고 자동 수집 크론거의 안 씀. 결국 직접 보고 고름
AI 이력서 자동 재작성초안만. 문장은 전부 손으로 고침
칸반 드래그 앤 드롭매일 씀. 상태가 바뀌는 게 실제로 일어나니까
공고별 서류 첨부매일 씀. 어디에 뭘 보냈는지 기억이 안 남
매칭 점수처음 며칠만. 점수가 낮아도 지원하게 됨

만들 때 가장 어려웠던 기능이 가장 덜 쓰였다. 가장 단순한 기능이 가장 많이 쓰였다. 이건 내 서비스가 잘못 설계됐다는 뜻이 아니라, 내가 "지원자가 뭘 힘들어하는지"를 몰랐다는 뜻이었다.

AI 재작성 기능을 내가 안 쓴 이유

이게 제일 뼈아팠다. 공고에 맞춰 이력서를 다시 써주는 기능을 꽤 정성껏 만들었는데, 정작 내가 안 썼다.

이유는 품질이 아니었다. 출력은 괜찮았다. 문제는 결과물이 "내 말"이 아니라는 것이었다. 면접에서 내 이력서에 적힌 문장을 그대로 읽어주며 "이건 무슨 뜻이죠?"를 물어본다. 그때 내가 쓴 문장이 아니면 설명이 흔들린다.

그래서 쓰는 방식이 바뀌었다.

  1. AI에게 공고를 넣고 **"이 공고가 요구하는 능력을 목록으로 뽑아줘"**만 시킨다
  2. 그 목록을 보고 내 경험 중 어느 걸 앞으로 올릴지 내가 정한다
  3. 문장은 직접 쓴다
  4. 마지막에 AI에게 **"어색한 문장만 지적해줘"**를 시킨다

AI가 결과물을 만드는 구조에서, AI가 판단 재료를 만들고 내가 결정하는 구조로 바꿨다. 이게 이 글 전체의 주제와 이어진다.


2. 이력서는 읽히지 않는다, 검색된다

한 달 남짓 지원하면서 통과한 이력서와 그렇지 않은 이력서를 나란히 놓고 봤다. 기술 스택이 문제가 아니었다.

서류가 잘 통과한 쪽잘 안 된 쪽
동작으로 시작 — "합쳤다", "줄였다", "만들었다"직책으로 시작 — "총괄", "담당", "리드"
앞 세 줄에 공고 단어가 들어 있음뒤쪽에 있거나 없음
한 항목이 한 문제를 다룸한 항목에 업무 다섯 개가 들어감
숫자가 있음 (개수, 기간, 줄어든 양)형용사가 있음 ("효율적으로", "성공적으로")

특히 직책으로 시작하면 잘 안 됐다. 직책은 회사마다 뜻이 다르다. 어떤 회사의 팀장은 실무를 하고, 어떤 회사의 팀장은 결재만 한다. 읽는 사람은 그걸 모르니까 판단을 미룬다.

반대로 동작은 회사가 달라도 뜻이 같다. **"세 부서가 따로 관리하던 데이터를 하나로 합쳤다"**는 어디서 읽어도 같은 그림이 그려진다.

한 가지 더. 해외 지원을 준비하면서 알게 된 건데, 어떤 나라의 취업 비자는 직책이 아니라 실제 수행 업무로 직종을 판정한다. 경력증명서에 "팀 총괄"만 적혀 있으면 심사에서 걸린다. "시스템을 설계하고 구축했다", "장애를 진단하고 해결했다" 같은 동작이 필요하다.

제도가 이미 그렇게 설계돼 있다는 건, 직책이 능력을 설명하지 못한다는 걸 제도도 알고 있다는 뜻이다.


3. 면접에서 아무도 프레임워크를 묻지 않았다

이게 가장 놀라웠다. 여러 곳에서 면접을 봤는데, "○○ 프레임워크 써보셨어요?"를 물은 곳이 거의 없었다.

대신 이런 걸 물었다.

  • 가장 어려웠던 문제가 뭐였고 어떻게 풀었나
  • 만든 걸 사람들이 안 쓰면 어떻게 하나
  • 팀 간에 의견이 갈렸을 때 어떻게 정리했나
  • 지금 회사에 AI를 붙인다면 어디서부터 시작하겠나

전부 문제를 어떻게 다루는지에 대한 질문이다. 기술은 그걸 설명하는 과정에서 자연스럽게 드러난다.

기억에 남는 순간이 있다. 내가 한 이야기 중에 반응이 가장 좋았던 건 화려한 아키텍처가 아니라 이거였다.

가장 어려웠던 건 사람이 아니라, 같은 단어를 서로 다르게 쓰고 있다는 걸 아무도 모르는 상황이었다. 두 팀이 같은 용어를 쓰는데 가리키는 대상이 달랐다. 회의에서 말은 통하는데 데이터가 안 맞았다.

기술 이야기가 하나도 없는데, 여기서 질문이 가장 많이 나왔다. 왜냐면 이 문제는 어느 회사에나 있고, 코드로는 안 풀리기 때문이다.

그리고 만든 걸 안 쓰면 어떻게 하냐는 질문에 대한 내 답도 비슷했다. 각 팀이 쓰던 양식을 그대로 두고, 공유 파일을 하나 만들어서 다른 팀이 실시간으로 뭘 적는지 보이게 했다. 그러니까 시키지 않아도 맞추기 시작했다. 시스템을 강제한 게 아니라 보이게 만든 것이 전부였다.


4. 못을 박는 사람이 필요하다

여기서 예전에 쓴 글로 돌아가야 한다. 토큰을 줄이는 방향으로 다시 돌아오는 이유에서 한 이야기의 연장이다.

AI 업계는 용어를 빠르게 만든다. 최근 몇 년만 봐도 이 순서로 왔다.

시기중심 용어관심사
초기프롬프트 엔지니어링어떻게 물어볼까
다음컨텍스트 엔지니어링무엇을 같이 넣을까
그다음하네스 엔지니어링도구와 실행 환경을 어떻게 붙일까
최근루프 엔지니어링스스로 돌게 만들고 언제 멈출까

흐름 자체는 자연스럽다. 문제는 이 목록을 따라가는 것이 실력인 것처럼 되어버린 분위기다.

나도 다 해봤다. 그리고 어느 순간 이런 생각이 들었다.

못을 박아야 하는데, 망치를 만드는 데 시간을 다 쓰고 있다.

도구를 위한 도구를 만든다. 그 도구를 관리하는 도구를 또 만든다. 에이전트를 만들고, 에이전트를 관리하는 에이전트를 만든다. 그 과정에서 원래 박으려던 못이 뭐였는지 잊는다.

면접을 다 보고 나서 확실해진 게 이거다. 회사는 망치를 잘 만드는 사람을 찾는 게 아니다. 어디에 못이 필요한지 찾아내고, 있는 망치로 박아서, 그게 실제로 붙어 있게 만드는 사람을 찾는다.

기술 용어를 모르면 안 된다는 말이 아니다. 용어는 알아야 한다. 대화가 되니까. 다만 용어의 최신성이 곧 실력이라는 착각은 위험하다. 새 용어는 6개월마다 온다. 문제를 찾아내는 능력은 그 주기와 무관하다.


5. 정리 — 결국 문제해결로 귀결된다

한 달 남짓 지원하고 면접을 보며 알게 된 걸 줄이면 이렇다.

  1. 도그푸딩은 결과물을 들고 밖에 나가 평가받는 것까지다. 기능 테스트는 도그푸딩이 아니다
  2. 가장 어렵게 만든 기능이 가장 덜 쓰였다. 어려움과 가치는 비례하지 않는다
  3. 이력서는 직책이 아니라 동작으로 읽힌다. 제도도 그렇게 설계돼 있다
  4. 면접은 프레임워크를 묻지 않는다. 문제를 어떻게 다루는지 묻는다
  5. AI가 결과를 만드는 구조보다, AI가 재료를 만들고 내가 결정하는 구조가 잘 작동했다
  6. 용어를 따라가는 것과 문제를 푸는 것은 다른 일이다

AI가 개발자를 대체한다는 이야기가 계속 나온다. 내가 한 달 동안 본 시장은 조금 다른 말을 하고 있었다. 대체되는 건 "지시받은 것을 구현하는 일"이고, 남는 건 "무엇을 구현해야 하는지 정하는 일"이다.

그 남는 일을 회사는 요즘 여러 이름으로 부른다. FDE, AI Native Engineer, 그리고 Go To Market Owner. 이름이 계속 바뀌는 게 그 자체로 신호다.

이 시리즈의 구성

다섯 편으로 쓴다. 앞의 두 편은 내 경험과 시장 관찰이고, 가운데 두 편은 구조 이야기이고, 마지막 한 편은 결론이다.

편다루는 것한 줄
1편 (이 글)도그푸딩 · 이력서 · 면접회사는 망치를 잘 만드는 사람이 아니라 못을 박는 사람을 찾는다
2편FDE · AI Native Engineer · GTM Owner세 이름은 같은 층에 없다. FDE만 직무로 굳었다
3편커리어 두 갈래기술로 깊어지는 길과 사업으로 넓어지는 길, FDE는 그 사이에 있다
4편토큰 · 원가 · 가격토큰이 원가가 되면서 기술 결정이 그대로 손익 결정이 됐다
5편결론그걸 할 수 있는지는 호기심의 범위가 정한다

한 문장으로 줄이면 : AI가 대체하는 건 시키면 하는 일이고, 남는 건 무엇을 시킬지 정하는 일이다. 그리고 무엇을 시킬지는 무엇을 궁금해했는지가 정한다.

다음 편에서는 그 이름들을 하나씩 보면서, 어느 것이 실제로 직무로 굳었고 어느 것이 아직 이름뿐인지 쓴다.

PM

backtodev

40대 PM, 다시 개발자로 돌아갑니다. 실패하고 배우며 성장하는 기록.