Skip to content
←

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

✨ Learn with Quiz
|

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

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

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

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

이 목록을 만든 방법

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

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

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

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

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

링크는 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년차 사이에 몰려 있어서, 시니어 이상의 이직이나 직군 전환 사례는 이번 목록에 없습니다.

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

Eight Korean Posts on Changing Jobs and Negotiating Salary — Chosen for Process, Not Success Stories

A note on language. Every linked piece below is written in Korean. The descriptions here are mine, in English, but the destinations are Korean-language pages.

Why so many job-change write-ups still do not help

Search for job-change write-ups and you will find plenty. Yet after reading, little tends to remain, because most of them report an outcome. Where someone went and how much their pay rose is stimulating in the moment but does not tell you what to do next week.

Changing jobs is really a procedure made of stages joined in sequence. You choose where to apply, write a resume and a career description, interview, negotiate terms, hand over your work, and settle a start date. Each stage has its own characteristic mistake. So this list gathers only writing that records the process rather than the result.

How this list was assembled

An editorial pick by one person, not a ranking. I have no way to measure view counts or popularity, and I did not try. I used three criteria.

First, I chose pieces that record the process in order. Posts that state only how much pay increased, or that emphasize the conclusion alone, are out.

Second, I did not collect only stories that worked out. Leaving a new job soon after joining, or changing direction after rejections, is often more useful. I deliberately kept writing that records failure.

Third, I opened every link and checked it. Candidates that would not load, demanded a login, or whose actual content did not match the search snippet were dropped. Community threads that only ask a question rather than recount an experience were also excluded.

These are individual cases, not general laws. Circumstances differ by years of experience, role, and company size, so take the perspective rather than the recipe.

Every link was opened and verified on 2026-08-12. Personal blog posts can disappear or change addresses.

Full accounts of the whole process

All three record the sequence from start to first day. The years of experience and circumstances differ, so placing them side by side reveals a shared structure.

A sixth-year developer changes jobs

Velog — Lim MyeongSeop · November 24, 2024

The author leaves a company joined through a referral after only a few days, then applies to dozens of places before landing somewhere that fits.

Read this if — someone has offered to refer you in and you cannot tell whether to take it.

The most valuable piece on this list, because it does not hide the experience of joining somewhere and immediately leaving. Referral moves look easy because the process is short, and this case exposes exactly how much you fail to verify when it is. In the second search the author greatly enlarges the number of applications, and that contrast reads like a self-diagnosis of what went wrong the first time. The closing decision, made on working hours and family rather than pay, is candid.

A junior developer's job-change retrospective

Velog — Mari · November 17, 2022

Several years at a first company, then a move driven by curiosity about engineering culture, with the emotions recorded alongside the steps.

Read this if — your current job is not bad and you find yourself considering a move anyway.

What makes this distinctive is that the motive was curiosity rather than dissatisfaction. Wanting to know how code review actually runs, and how people work elsewhere, describes many juniors precisely. It walks through interviews, terms negotiation, and giving notice, while acknowledging that leaving a first company was emotionally hard. The stance of treating a move as a growth question while still counting its cost is worth learning.

A 2025 mid-career developer job-change write-up

Velog — 코끼릭 · September 13, 2025

A third-year developer covers a two-month application period through technical interviews, personality interviews, and terms negotiation.

Read this if — you want a realistic sense of how much time preparation actually takes.

Stating the duration is this piece's practical value. Changing jobs does not happen the week after you decide to; knowing it takes months from first application to a confirmed start date is what keeps you from panicking midway. The passage about improving the portfolio after early rejections, and the results changing, is concrete. It also records what became different after the move, so the purpose of the change stays visible to the end.

Salary negotiation is a question of evidence

Plenty of negotiation posts discuss attitude. This one addresses where the evidence comes from.

Raising your salary by changing jobs

Velog — 코딩몬스터TV · January 8, 2021

Compares waiting for recognition inside one company against adjusting through a move, and sets out how negotiating evidence is built.

Read this if — you want a raise but do not know what to base the request on.

The central claim is that leverage comes not from eloquence but from the number of options you hold. With an offer elsewhere, your request has a basis; without one, however well you speak, it stays a request. That leads to the conclusion that negotiating well means the preparation is already finished at the application stage, not at the negotiating table. Note that using a competing offer is a card that can damage a relationship, so take the perspective and adjust the wording to your own situation. It is an older post, so its description of market conditions may not match today.

Resumes and career descriptions: escaping the stack list

Three pieces arrive at the same conclusion by different routes. Write what you solved, not what you used.

How to write a developer resume, in practice

Velog — 딩코딩코 · June 4, 2021

Compares tools for building a resume and contrasts weak versus strong versions of the same sections.

Read this if — you have the blank document open and cannot write the first line.

Its strength is showing the same content as a poor example and a strong one, side by side. Being told abstractly to write about impact is paralyzing; seeing one experience written two ways makes the difference immediately legible. It also covers the ordering of sections, which helps when you are laying out the structure for the first time. The tools and platforms mentioned may look different now, so take the composition principles rather than the specific formats.

How to write a career description

Velog — JeongWu Park · March 23, 2025

Notes from a career-description writing workshop, focused on turning accomplishments into measurable form.

Read this if — you have done a lot but everything looks ordinary once you try to write it.

This is useful because it inverts the problem. The key observation is that having nothing to write is not because the work was ordinary but because there is no record of it. Writing impact with metrics requires having kept those metrics, which means recording now rather than when you start preparing to leave. Organizing by categories such as problem-solving, productivity improvement, and collaboration is also directly applicable. Its virtue is that the conclusion moves from document formatting to how you work.

Examples of resume writing for experienced developers

Brunch — 자기소개서 예시 작성법 · August 18, 2025

Sets out, with structure and examples, how an experienced hire's resume should differ from an entry-level one.

Read this if — you are still editing the resume you wrote as a new graduate.

Its usefulness is naming the mistakes specific to experienced-hire resumes, item by item. Listing only the stack, and failing to separate team results from your own contribution, are the two big ones, and both leave the reader with nothing to verify. It recommends describing situation, task, action, and result separately, and shows that shape as an example. Where the previous two are developer accounts, this one is a document-craft treatment, so all three together do not overlap.

Interviews matter most after they end

Interview write-ups tend to get written only after an offer. This one shows the other side.

A backend developer's interview retrospective: reviewing year one

Velog — 코헤 · October 28, 2025

A first-year backend developer reconstructs the questions and their own answers, then diagnoses what was missing.

Read this if — you cannot even remember what you said once an interview ends.

What makes this good is how specific the self-assessment is. It names the weak areas precisely, such as database design and deployment tooling, and analyzes what the company's structure demands of the role. The post ends with an offer in hand but the decision unresolved because of the terms, and an unresolved ending is closer to reality than a tidy one. Reconstructing an interview to this level immediately produces preparation material for the next one.

Related writing and tools on this blog

Limits of this list

Six of the eight are Velog posts. That is where verifiable writing on this topic was easiest to find, not evidence that good writing lives nowhere else. The experience range also clusters between one and six years, so senior-level moves and role changes are absent from this list.

One closing note. Everything here is an individual case. There is no guarantee the same method produces the same result, and negotiation in particular depends heavily on a company's circumstances and timing. Read these for the order of the stages and the items to prepare.