이력서 피드백을 받았던 내용에 대해 해당 내용으로 반복해서 쓸수 있는 헤르메스 첫 도전

긴 이력서 피드백, AI와 함께 '업무 나열’에서 '문제 해결 사례’로 바꿔봤다

📝 한줄 요약

긴 경력 이력서와 외부 피드백을 AI에게 함께 전달해, 추상적인 조언을 실제 문장 규칙으로 바꾸고 수정 범위에 맞는 초안을 만들었다. AI가 대신 경력을 꾸며준 것이 아니라, 흩어진 문제·행동·성과를 연결하고 빠진 근거를 찾아주는 편집자로 일하게 했다.

바쁘시면 이것만 읽어도 돼요:

• 이력서 원문과 피드백을 따로 보지 않고 AI가 함께 대조하게 했다.

• 수정 범위를 자기소개와 최근 경력으로 제한해 불필요한 전면 수정을 막았다.

• 모든 경험을 문제 → 선택 이유 → 실행 → 결과 순서로 다시 구성했다.

• 원문에 없는 수치나 기술적 설명은 만들지 않고 확인 항목으로 남겼다.

• 한 번 쓰고 끝내지 않도록 작성 규칙을 재사용 가능한 스킬로 저장했다.

🎯 이런 분들께 도움돼요

• 경력은 많은데 이력서가 업무 목록처럼 보이는 개발자

• "무엇을 했는지는 알겠지만 왜 했는지 모르겠다"는 피드백을 받은 분

• AI에게 이력서를 맡기면 과장된 문장이 나올까 걱정되는 분

• 회사나 서비스 정보를 공개하지 않고 이력서 개선 과정을 공유하고 싶은 분

😫 피드백은 구체적이었지만, 수정은 여전히 어려웠다

받은 피드백의 요지는 분명했다. 진행 배경, 역할, 성과를 따로 나열하지 말고 한 흐름으로 연결하라는 것이었다. "아키텍처를 설계했다"고만 쓰지 말고 왜 그 구조가 필요했는지 설명해야 했고, AI 도구를 사용했다는 사실보다 실제로 어떤 작업이 얼마나 줄었는지를 보여줘야 했다.

문제는 이 조언을 긴 이력서 전체에 직접 적용하는 일이었다. 어떤 배경이 어떤 성과와 연결되는지 다시 찾아야 했고, 역할과 성과가 섞인 문장도 구분해야 했다. 표현을 강하게 바꾸다 보면 원문에 없는 원인이나 수치를 덧붙일 위험도 있었다.

그래서 AI에게 단순히 "이력서를 멋있게 고쳐줘"라고 하지 않았다. 원문, 피드백, 수정 범위, 금지 조건을 한 번에 전달했다.

이력서 원문과 받은 피드백을 대조해 주세요.
수정 범위는 자기소개와 최근 회사 경력으로 제한합니다.
피드백에서 반복되는 작성 규칙을 먼저 정리한 뒤,
그 규칙에 따라 바로 사용할 수 있는 문장을 제안해 주세요.
원문에 없는 수치나 기술적 사실은 만들지 말고 확인이 필요한 항목으로 표시해 주세요.

🛠️ 사용한 도구

• Hermes Agent: PDF 확인, 피드백 분석, 수정안 작성, 규칙의 스킬화

• PDF 텍스트 추출 도구: 긴 이력서에서 필요한 범위의 원문을 정확하게 확인

• 문서 작성 스킬: 결과를 공개 가능한 사례글 형태로 정리

개인정보 보호를 위해 이름, 연락처, 회사명, 서비스명, 재직 기간, 내부 시스템 이름은 게시글에서 제외했다. 경력 수치도 여러 개를 조합하면 개인을 추정할 수 있다고 판단해 구체적인 값 대신 작성 방식만 남겼다.

🔧 첫 번째 작업: 피드백을 문장 규칙으로 바꾸기

피드백은 길었지만 반복되는 요구는 몇 가지로 모였다.

가장 중요한 규칙은 하나였다.

문제나 불편 → 선택한 해결 방법과 이유 → 내가 직접 한 일 → 확인 가능한 결과

기존 이력서는 진행 배경, 역할 및 기여, 성과가 각각 떨어져 있었다. 작성자에게는 같은 프로젝트라 자연스럽게 연결되지만, 처음 읽는 사람은 배경을 읽고 몇 줄 아래에서 관련 행동을 찾은 뒤 다시 성과를 확인해야 한다.

AI는 각 항목을 하나의 인과관계로 묶도록 제안했다. 예를 들면 이런 방식이다.

수정 전

• 조회 속도가 느렸음

• 병목 쿼리를 식별함

• 인덱스를 적용함

• 성능을 개선함

수정 후 구조

특정 화면의 응답 지연으로 운영팀의 업무가 늦어졌습니다. 느린 API와 쿼리 실행 계획을 조사해 실제 병목을 확인하고, 조회 및 정렬 조건에 맞는 인덱스를 적용했습니다. 그 결과 응답 시간이 [개선 전]에서 [개선 후]로 줄었습니다.

문장이 조금 길어졌지만 읽는 사람은 한 번에 이해할 수 있다. 무엇보다 "병목 쿼리를 식별했다"에서 끝나지 않고, 어떻게 확인했고 무엇을 바꿨는지 설명하게 됐다.

🔧 두 번째 작업: 역할과 성과를 분리하기

이 과정에서 가장 유용했던 지적은 "많이 맡았다"와 "좋은 결과를 만들었다"가 다르다는 것이었다.

여러 서비스를 혼자 운영했다는 내용은 책임 범위와 난이도를 보여준다. 하지만 그 자체가 성과는 아니다. 성과로 쓰려면 반복 업무를 자동화해 문의가 줄었거나, 장애 탐지 시간이 짧아졌거나, 확보한 시간을 신규 개발에 투입했다는 변화가 뒤따라야 한다.

AI는 문장을 다음 기준으로 나눴다.

• 역할: 무엇을 책임졌는가

• 행동: 문제를 해결하기 위해 무엇을 바꿨는가

• 성과: 그 결과 어떤 수치나 상태가 달라졌는가

이 구분만 해도 "혼자 많은 일을 했다"는 설명이 "어떤 운영 문제를 어떻게 줄였다"는 사례로 바뀌었다.

🔧 세 번째 작업: 그럴듯하지만 위험한 표현 걸러내기

이력서에는 면접 질문을 부르는 단어가 있다. 주도, 무중단, 수평 확장, 재발 방지, 팀 생산성 향상 같은 표현이다. 근거가 있으면 좋은 표현이지만, 이유와 측정 방법을 설명하지 못하면 오히려 약점이 된다.

AI는 이런 표현을 바로 강화하지 않고 먼저 확인 질문으로 돌렸다.

• 왜 단일 구조가 문제가 되었는가?

• API와 배치를 분리해야 했던 실제 이유는 무엇인가?

• 실행 계획에서 어떤 연산이 병목이었는가?

• 개인의 작업 시간이 줄어든 것인가, 팀 전체 처리량이 늘어난 것인가?

• "재발하지 않았다"고 판단한 관찰 기간은 얼마인가?

이 부분이 예상보다 중요했다. AI에게 문장을 멋있게 만드는 역할만 주면 빈칸을 그럴듯하게 채울 수 있다. 반대로 "근거가 없으면 쓰지 말라"는 규칙을 주면 면접 전에 준비할 질문 목록까지 얻을 수 있다.

🔧 네 번째 작업: AI 활용을 도구 소개가 아닌 변화로 쓰기

"AI를 주 개발 도구로 사용했다"는 문장은 눈에 띄지만, 실제로 무엇이 좋아졌는지는 알려주지 못한다. 그래서 AI 활용 경험도 다른 경력과 같은 규칙으로 바꿨다.

• 어떤 반복 작업이 있었는가

• AI가 어떤 문서와 시스템을 참고했는가

• 어느 단계에서 사람이 확인했는가

• 시간, 오류, 처리량이 어떻게 달라졌는가

• 개인 효율인지 팀 효율인지

예를 들어 "AI 코딩 도구와 문서 시스템을 연동했다"에서 끝내지 않고, 이슈 확인부터 문서 작성, 코드 수정, 테스트, 리뷰 요청까지 어떤 흐름을 연결했는지 적는 방식이다. 측정값이 개인 기준이라면 "팀 생산성"이라고 부풀리지 않고 "개발 작업 시간 단축"이라고 표현한다.

이 기준은 이력서뿐 아니라 사내 AI 도입 사례를 정리할 때도 그대로 쓸 수 있다.

✅ 결과

이번 작업의 결과는 문장 몇 개가 아니었다. 앞으로 다른 경력 항목을 고칠 때도 사용할 수 있는 검토 기준이 생겼다.

Before vs After

최종적으로 자기소개 수정안, 최근 경력의 우선순위, 프로젝트별 재작성 초안, 면접에서 확인할 꼬리 질문을 함께 정리했다. 같은 규칙을 problem-solution-impact-resume라는 스킬로 저장해 다음 이력서 검토에서도 다시 사용할 수 있게 했다.

💬 이 과정에서 배운 AI 활용 팁

효과적이었던 것

1. 원문과 피드백을 같이 준다. 피드백만 주면 AI는 일반론을 반복한다. 원문이 있어야 어떤 문장이 왜 문제인지 연결할 수 있다.

2. 수정 범위를 먼저 고정한다. "최근 경력과 자기소개만"처럼 범위를 정하면 전체 문체가 불필요하게 바뀌지 않는다.

3. 사실을 만들지 못하게 명시한다. 수치, 기술 선택 이유, 팀 사용 여부가 없으면 질문으로 남기게 한다.

4. 면접 질문까지 만들게 한다. 강한 표현마다 예상 질문을 붙이면 과장된 문장을 미리 발견할 수 있다.

5. 좋았던 규칙은 스킬로 저장한다. 다음 작업에서 같은 설명을 처음부터 반복할 필요가 없다.

이렇게 하면 안 돼요

1. "전문적으로 고쳐줘"처럼 기준 없이 요청하지 않는다. 결과가 매끄럽더라도 본인의 실제 경험과 멀어질 수 있다.

2. 개인 작업 시간 단축을 근거 없이 팀 생산성으로 확대하지 않는다.

3. 기술 이름을 추가하는 것으로 기술적 깊이를 대신하지 않는다.

4. 공개 글에 원문 이력서를 그대로 붙이지 않는다. 회사명뿐 아니라 서비스명, 정확한 날짜, 내부 구조, 여러 성과 수치의 조합도 개인을 식별하는 단서가 될 수 있다.

🌍 다른 업무에 적용한다면?

이 작성법은 이력서 외에도 활용할 수 있다.

• 프로젝트 회고를 문제 해결 사례로 정리할 때

• 성과 평가나 승진 자료를 작성할 때

• 포트폴리오의 프로젝트 설명을 다듬을 때

• 장애 보고서에서 원인과 대응 결과를 연결할 때

• AI 도입 사례를 도구 자랑이 아닌 업무 변화로 설명할 때

공통점은 같다. "무엇을 했다"보다 "왜 했고 무엇이 달라졌는가"가 읽는 사람에게 더 많은 정보를 준다.

🚀 다음에는 이렇게 발전시킬 수 있다

다음 단계에서는 지원하려는 직무에 맞춰 같은 경력을 다르게 정렬할 수 있다. 제품 중심 회사에는 전환율과 고객 경험 개선을 먼저 보여주고, 플랫폼 조직에는 시스템 현대화와 운영 안정성 사례를 앞세우는 방식이다.

또한 면접 답변까지 연결해 각 경력 문장마다 다음 내용을 준비할 수 있다.

• 당시 선택할 수 있었던 다른 방법

• 실제로 선택한 방법과 이유

• 본인이 직접 구현한 범위

• 측정 방법과 관찰 기간

• 해결 과정에서 생긴 부작용이나 트레이드오프

📋 재사용 가능한 프롬프트

이력서와 피드백을 함께 분석할 때

첨부한 이력서와 피드백을 대조해 주세요. 먼저 피드백에서 반복되는 작성 규칙을 추출하고, 제가 지정한 경력 범위에만 적용해 주세요. 각 경험은 문제·배경 → 선택 이유 → 직접 수행한 해결 방법 → 정량적 또는 관찰 가능한 결과 순서로 작성해 주세요. 역할과 성과를 구분하고, 원문에 없는 수치·기술·인과관계는 만들지 말고 [확인 필요]로 표시해 주세요. 마지막에는 면접에서 나올 수 있는 꼬리 질문도 정리해 주세요.

기술 프로젝트 문장을 검증할 때

아래 프로젝트 설명에서 주도, 설계, 개선, 무중단, 확장 가능, 재발 방지, 팀 생산성처럼 근거가 필요한 표현을 찾아 주세요. 각 표현에 대해 ① 현재 문장만으로 확인 가능한 사실, ② 빠진 선택 이유나 구현 방법, ③ 필요한 측정값, ④ 예상 면접 질문을 정리해 주세요. 확인되지 않은 내용은 더 강하게 표현하지 마세요.