꿀팁
On June 14, 2026경력기술서를 쓸 때마다 드는 생각 경력기술서를 쓸 때마다 같은 문제에 부딪혔다. 분명히 열심히 일했다. PR도 올렸고, 이슈도 닫았고, 기술적인 결정도 내렸다. 그런데 막상 경력기술서를 쓰려고 앉으면 백지가 된다. 뭘 어디서부터 쓰면 좋을지 모르겠고, 쓰다 보면 이걸 내가 한 건지, 팀이 한 건지 경계가 흐릿해진다. 그리고 결국 "주도적으로 개선했습니다" 같은 두루뭉술한 문장들로 채워진 문서가 완성된다. 이걸 반복하다가 이번에 다른 방법을 써봤다. GitHub 프로젝트 데이터를 AI에 넘기고, 경력기술서 초안부터 리뷰까지 한 번에 뽑는 워크플로우를 만든 것이다. 아이디어: 내가 한 일은 이미 기록되어 있다 경력기술서 작성이 어려운 이유 중 하나는 기억에 의존하기 때문이다. 몇 달 전에 내린 기술 결정의 이유, 그때 고려했던 대안들, 결과로 뭐가 달라졌는지를 머릿속에서 꺼내야 한다. 그런데 사실 그 정보는 이미 어딘가에 있다. PR 설명, 이슈 코멘트, 커밋 메시지. 내가 일하면서 남긴 흔적들이다. GitHub Projects에서 데이터를 export하면 이 흔적들을 JSON 형태로 가져올 수 있다. 이걸 AI에 넘기면 "내가 뭘 했는지"를 내 기억이 아니라 실제 작업 기록 기반으로 정리할 수 있다. 워크플로우 전체 흐름은 이렇다. 1단계: 프로젝트 데이터 export export-project.sh 스크립트를 실행하면 GitHub Projects의 PR, 이슈, 커밋 로그를 JSON으로 뽑아준다. 이게 모든 분석의 원재료가 된다. 2단계: 개발자/PM 관점 분석 현재 내가 개발자 겸 PM을 겸하고 있기 때문에 개발자/PM 관점으로 분석한다. 핵심은 네 가지다. 어떤 문제를 해결했는지 어떻게 해결했는지 (기술 의사결정 포함) 어떤 기술을 썼는지 성과가 뭔지 중요한 규칙이 하나 있다. 수치가 없으면 추정하지 않는다. 막연하게 "성능이 개선됐습니다"를 쓰는 것보다, "측정값 없음, 직접 확인 필요"로 남기도록 했다. 개발자 관점은 기술적 의사결정에 집중한다. 왜 이 방법을 선택했는지, 어떤 대안을 검토했는지, 어떤 트레이드오프를 고려했는지. PM 관점은 실행 기록이 아니라 판단 기록에 집중한다. 무엇을 했는지가 아니라, 왜 그 방향으로 결정했는지. 이 분리가 생각보다 중요했다. 많은 경력기술서가 "이걸 했고 저걸 했고"로 채워지는데, 그건 실행 기록이지 의사결정 기록이 아니다. 특히 PM이나 리드 역할을 강조하고 싶을 때 이 차이가 크게 드러난다. 3단계: 경력기술서 초안 생성 앞서 나온 분석을 바탕으로 경력기술서 초안을 작성한다. 포함 항목은 이렇다. 프로젝트 소개 (서비스 설명, 기간, 팀 규모, 담당 역할, 서비스 현황) 핵심 기여 — 개발 (문제 → 배경 → 결정 및 근거 → 결과 순서로) 핵심 기여 — PM (실행이 아닌 의사결정 중심) 성과 요약 기술 스택 JSON에서 확인할 수 없는 정보는 [직접 확인 필요]로 표기한다. 채워야 할 부분이 명시적으로 보이니까 보기 편했다. 4단계: 냉정한 리뷰 초안이 나오면 세 관점에서 리뷰를 받는다. 시니어 소프트웨어 엔지니어 시니어 PM IT기업 채용 담당자 좋은 점보다 아쉬운 점 위주로 나온다. 구체적으로 어떤 표현이 문제인지, 왜 문제인지, 어떻게 고쳐야 하는지, 수정 예시까지 달린다. "주도적으로 개선했습니다"처럼 책임 범위가 불명확한 표현, 수치 없이 쓴 성과, 타인과 본인 기여가 뒤섞인 부분 같은 것들이 걸러진다. 5단계: 수정본 생성 AI 리뷰 피드백을 반영해서 (참회하며) 수정본을 만든다. 해보고 나서 느낀 것들 좋았던 점: 작업 기록 기반이라 기억을 짜내지 않아도 됐다. 특히 몇 달 전 결정의 맥락을 PR 설명에서 다시 불러오는 부분이 유용했다. 혼자 쓸 때는 어느새 빠뜨렸던 내용들이 올라왔다. 리뷰 단계에서 순살이 됐다. 스스로 쓴 초안을 다시 읽으면 잘 안 보이는 것들, 예를 들면 과장된 표현이나 애매한 기여도 서술이 구체적으로 지적됐다. 가장 뼈아픈 지점은 '너 정도 연차에는 이정도는 기술되어야 하지 않니?' 하는 부분이었다. AI 네가 뭘 알아 흑흑. 한계도 있다: AI가 JSON에서 읽을 수 없는 맥락은 채울 수 없다. 팀 내 분위기, 비공식적으로 내린 결정, 코드 외부에서 일어난 일들은 직접 보완해야 한다. [직접 확인 필요] 태그가 붙은 부분이 많으면 결국 손을 많이 타야 한다. GitHub에 기록을 잘 남겼을수록 결과가 좋다. PR 설명을 대충 썼거나, 이슈를 잘 정리하지 않았다면 뽑히는 것도 그만큼 얕다. 역설적으로, 이 과정을 해보고 나서 평소 PR 설명을 더 신경 쓰게 됐다. 마치며 이 워크플로우가 완성된 경력기술서를 뽑아주지는 않는다. 하지만 백지에서 시작하는 것보다 훨씬 나은 출발점을 만들어준다. 그리고 혼자 쓸 때 보이지 않던 약점을 짚어준다는 것만으로도 충분히 쓸 만하다고 느꼈다. 무엇보다 경력기술서 작성하는 데에 드는 시간이 획기적으로 줄어들었다. 프로젝트 끝날 때마다 명령어 한 줄로 몇 분만에 지나 몇 달이 정리된다니 참 좋다.