개발자 이직 후기와 연봉 협상 글 여덟 편 — 성공담이 아니라 절차를 적은 글만 골랐습니다

• 이직 후기가 많은데도 도움이 안 되는 이유
• 이 목록을 만든 방법
• 이직 과정 전체를 기록한 글
  • 6년차 개발자 이직기
  • 주니어 개발자 이직 회고
  • 2025 IT 개발자 경력 이직 후기
• 연봉 협상은 근거의 문제입니다
  • 개발자 이직으로 연봉올리기
• 이력서와 경력기술서 — 기술 나열에서 벗어나기
  • 개발자 이력서 본격적으로 쓰는 방법 - 실전편
  • 경력 기술서 작성법
  • 경력 개발자 이력서 쓰는법 예시
• 면접은 끝난 뒤가 더 중요합니다
  • 백엔드 개발자 면접 회고 - 1년차의 복기
• 이 블로그의 관련 글과 도구
• 이 목록의 한계

이직 후기가 많은데도 도움이 안 되는 이유

이직 후기는 검색하면 많이 나옵니다. 그런데 읽고 나면 남는 것이 별로 없는 경우가 많습니다. 대부분 결과를 말하기 때문입니다. 어디로 갔고 얼마가 올랐다는 정보는 읽는 순간에는 자극적이지만, 정작 내가 다음 주에 무엇을 해야 하는지는 알려 주지 않습니다.

이직은 사실 여러 단계가 순서대로 붙어 있는 절차입니다. 지원할 회사를 고르고, 이력서와 경력기술서를 쓰고, 면접을 보고, 처우를 협상하고, 인수인계를 하고 입사일을 맞춥니다. 각 단계마다 실수하기 쉬운 지점이 따로 있습니다. 그래서 이번에는 결과가 아니라 과정을 적은 글만 모았습니다.

이 목록을 만든 방법

순위가 아니라 편집자 개인의 선택입니다. 조회수나 인기를 잴 방법이 없고 재지도 않았습니다. 세 가지 기준을 썼습니다.

첫째, 과정을 순서대로 적은 글을 골랐습니다. 연봉이 얼마나 올랐는지만 적힌 글, 결론만 강조하는 글은 뺐습니다.

둘째, 잘 풀린 이야기만 모으지 않았습니다. 옮겼다가 금방 나온 경험, 떨어진 뒤 방향을 바꾼 경험이 오히려 더 유용합니다. 실패가 적힌 글을 일부러 남겼습니다.

셋째, 링크를 직접 열어 확인했습니다. 열리지 않거나 로그인을 요구하거나 실제 내용이 검색 결과의 설명과 다른 후보는 버렸습니다. 커뮤니티 질문 글처럼 경험담이 아니라 질문만 있는 페이지도 제외했습니다.

여기 실린 글들은 각자의 사례이지 일반 법칙이 아닙니다. 연차와 직군, 회사 규모에 따라 사정이 다르므로 방법이 아니라 관점을 참고하시는 편이 좋습니다.

링크는 2026-08-12에 직접 열어 확인했습니다. 개인 블로그 글은 사라지거나 주소가 바뀔 수 있습니다.

이직 과정 전체를 기록한 글

세 편 모두 시작부터 입사까지를 순서대로 적었습니다. 연차와 상황이 달라서 나란히 놓고 보면 공통된 구조가 보입니다.

6년차 개발자 이직기

벨로그 — Lim MyeongSeop · 2024년 11월 24일

지인 추천으로 옮긴 회사를 며칠 만에 그만두고, 이후 수십 곳에 지원한 끝에 다시 자리를 잡기까지를 적은 글입니다.

이런 사람에게 — 추천으로 들어오라는 제안을 받았는데 판단이 서지 않는 사람.

이 목록에서 가장 값진 글입니다. 옮긴 곳이 맞지 않아 곧바로 나온 경험을 숨기지 않고 적었기 때문입니다. 추천 이직은 절차가 짧아서 편해 보이지만, 그만큼 확인하지 못하고 들어가는 정보가 많다는 사실이 이 사례에서 드러납니다. 그리고 두 번째 구직에서는 지원 규모 자체를 크게 늘리는데, 이 대비가 첫 번째 실패의 원인을 스스로 진단한 결과처럼 읽힙니다. 마지막에 연봉이 아니라 근무 시간과 가족을 기준으로 결정하는 대목도 솔직합니다.

주니어 개발자 이직 회고

벨로그 — Mari · 2022년 11월 17일

첫 회사에서 몇 년을 보낸 뒤 개발 문화가 궁금해 옮기기까지의 과정과 감정을 함께 적은 글입니다.

이런 사람에게 — 지금 회사가 나쁘지 않은데도 이직을 고민하게 되는 사람.

이직 동기가 불만이 아니라 궁금증이었다는 점이 이 글을 특별하게 만듭니다. 코드 리뷰가 어떻게 돌아가는지, 다른 곳에서는 어떻게 일하는지를 알고 싶어서 움직였다는 서술은 많은 주니어의 상태를 정확히 설명합니다. 면접과 처우 협상, 퇴사 통보까지의 순서를 짚으면서 첫 회사를 떠나는 일이 감정적으로 쉽지 않았다는 점도 적습니다. 이직을 성장의 문제로 보되 그 대가를 함께 계산하려는 태도가 배울 만합니다.

2025 IT 개발자 경력 이직 후기

벨로그 — 코끼릭 · 2025년 9월 13일

3년차 개발자가 두 달에 걸친 지원 기간 동안 기술 면접과 인성 면접, 처우 협상을 거친 과정을 정리한 글입니다.

이런 사람에게 — 이직 준비에 실제로 시간이 얼마나 드는지 가늠하고 싶은 사람.

기간을 명시한다는 점이 이 글의 실용적인 가치입니다. 이직은 마음먹은 다음 주에 되는 일이 아니고, 지원부터 입사일 확정까지 몇 달이 걸린다는 사실을 알고 시작해야 중간에 조급해지지 않습니다. 초반에 떨어진 뒤 포트폴리오를 보완해 결과가 달라졌다는 대목도 구체적입니다. 옮긴 뒤 어떤 점이 달라졌는지를 함께 적어서, 이직의 목적이 무엇이었는지가 끝까지 유지됩니다.

연봉 협상은 근거의 문제입니다

협상 글은 많지만 대부분 태도만 이야기합니다. 이 글은 근거가 어디서 나오는지를 다룹니다.

개발자 이직으로 연봉올리기

벨로그 — 코딩몬스터TV · 2021년 1월 8일

한 회사 안에서 인정받기를 기다리는 것과 이직으로 조정하는 것을 비교하고, 협상의 근거를 어떻게 만드는지를 정리한 글입니다.

이런 사람에게 — 연봉을 올리고 싶은데 무슨 말을 근거로 삼아야 할지 모르겠는 사람.

이 글의 핵심 주장은 협상력이 말솜씨가 아니라 선택지의 수에서 나온다는 것입니다. 다른 곳에서 받은 제안이 있으면 요구에 근거가 생기고, 없으면 아무리 잘 말해도 요청에 머뭅니다. 그래서 협상을 잘하려면 협상 자리가 아니라 그 전 단계인 지원 단계에서 준비가 끝나 있어야 한다는 결론으로 이어집니다. 다만 경쟁 오퍼를 다루는 방식은 관계를 상하게 할 수도 있는 카드라서, 이 글의 관점을 참고하되 표현은 각자 상황에 맞게 조절하시기를 권합니다. 오래된 글이라 시장 상황에 대한 서술은 지금과 다를 수 있습니다.

이력서와 경력기술서 — 기술 나열에서 벗어나기

세 편이 같은 결론에 다른 경로로 도착합니다. 무엇을 썼느냐가 아니라 무엇을 해결했느냐를 적으라는 것입니다.

개발자 이력서 본격적으로 쓰는 방법 - 실전편

벨로그 — 딩코딩코 · 2021년 6월 4일

이력서를 만들 도구를 비교하고, 어떤 항목을 어떤 순서로 넣을지를 좋은 예와 나쁜 예로 대조한 글입니다.

이런 사람에게 — 빈 문서를 열어 놓고 첫 줄을 못 쓰고 있는 사람.

같은 내용을 좋은 예와 나쁜 예로 나란히 보여 주는 방식이 이 글의 강점입니다. 추상적으로 성과를 쓰라고 하면 막막하지만, 같은 경험이 두 가지로 적힌 것을 보면 차이가 바로 보입니다. 항목의 순서까지 다루기 때문에 구조를 처음 잡을 때 참고하기 좋습니다. 언급된 도구와 플랫폼은 지금 화면과 다를 수 있으니 형식보다 구성 원칙을 가져가시면 됩니다.

경력 기술서 작성법

벨로그 — JeongWu Park · 2025년 3월 23일

경력기술서 작성 워크숍에서 배운 내용을 정리하면서, 성과를 측정 가능한 형태로 바꾸는 방법을 다룬 글입니다.

이런 사람에게 — 한 일은 많은데 막상 쓰려니 다 평범해 보이는 사람.

이 글이 유용한 이유는 문제를 거꾸로 뒤집기 때문입니다. 쓸 것이 없어 보이는 이유는 일이 평범해서가 아니라 기록이 없어서라는 지적이 핵심입니다. 성과를 지표와 함께 적으려면 그 지표를 평소에 남겨 둬야 하고, 그러려면 이직을 준비할 때가 아니라 지금부터 기록해야 합니다. 문제 해결, 생산성 개선, 협업 같은 범주로 나눠서 정리하는 방식도 실제로 적용하기 좋습니다. 결론이 문서 작성법이 아니라 일하는 방식으로 넘어간다는 점이 이 글의 미덕입니다.

경력 개발자 이력서 쓰는법 예시

브런치 — 자기소개서 예시 작성법 · 2025년 8월 18일

신입과 경력의 이력서가 어떻게 달라야 하는지를 구조와 예시로 정리한 글입니다.

이런 사람에게 — 신입 때 쓰던 이력서를 그대로 고쳐 쓰고 있는 사람.

경력 이력서에서 자주 나오는 실수를 항목별로 짚는다는 점이 이 글의 쓸모입니다. 기술 스택만 나열하는 문제, 팀 성과와 자기 기여를 구분하지 않는 문제가 대표적인데, 둘 다 읽는 쪽에서는 검증할 수 없는 서술입니다. 상황과 과제, 행동과 결과로 나눠 서술하는 방식을 권하면서 그 형태를 예시로 보여 줍니다. 앞의 두 글이 개발자의 경험담이라면 이 글은 문서 작성 관점의 정리라서, 셋을 함께 보면 관점이 겹치지 않습니다.

면접은 끝난 뒤가 더 중요합니다

면접 후기는 붙었을 때만 쓰이는 경향이 있습니다. 이 글은 그 반대편을 보여 줍니다.

백엔드 개발자 면접 회고 - 1년차의 복기

벨로그 — 코헤 · 2025년 10월 28일

1년차 백엔드 개발자가 면접에서 오간 질문과 자기 답변을 다시 정리하면서, 무엇이 부족했는지를 스스로 진단한 글입니다.

이런 사람에게 — 면접이 끝나고 나면 무슨 말을 했는지도 기억나지 않는 사람.

이 글이 좋은 이유는 자기 평가가 구체적이기 때문입니다. 데이터베이스 설계나 배포 도구처럼 부족했던 영역을 특정해서 적고, 그 회사의 구조상 어떤 역할을 요구하는지도 함께 분석합니다. 그리고 제안을 받았지만 조건 때문에 계속 고민하는 상태로 글이 끝나는데, 이렇게 결말이 정리되지 않은 후기가 오히려 현실에 가깝습니다. 면접 직후에 이 정도로 복기해 두면 다음 면접의 준비 자료가 그대로 만들어집니다.

이 블로그의 관련 글과 도구

• 언제 이직해야 하는가 — 옮길지 말지를 판단하는 단계의 글입니다.
• 연봉 협상 — 근거를 만든 다음 실제 대화를 어떻게 끌고 갈지를 다룹니다.
• 읽히는 이력서 — 위 세 편과 함께 보면 좋습니다.
• 시스템 설계 면접 준비 — 경력 면접에서 비중이 큰 영역입니다.
• 연봉 계산기 — 제안받은 금액을 실수령액으로 환산해 비교할 때 씁니다.

이 목록의 한계

여덟 편 중 여섯 편이 벨로그 글입니다. 개발자 이직 후기라는 주제에서 검증 가능한 형태로 찾기 쉬운 곳이 그쪽이었기 때문이고, 다른 곳에 좋은 글이 없다는 뜻은 아닙니다. 그리고 연차 분포가 1년차에서 6년차 사이에 몰려 있어서, 시니어 이상의 이직이나 직군 전환 사례는 이번 목록에 없습니다.

마지막으로 한 가지만 덧붙입니다. 여기 실린 글들은 모두 개인의 사례입니다. 같은 방법이 같은 결과를 낸다는 보장은 없고, 특히 협상은 회사의 사정과 시점에 크게 좌우됩니다. 절차의 순서와 준비할 항목을 참고하는 용도로 읽으시기를 권합니다.