개발자 이직 실전 가이드 | 퇴사부터 합격까지 3개월 로드맵

작성 0xmote · 2026년 7월 16일 · 15분 읽기 · 수정 2026년 9월 25일 초급 가이드

이 글의 핵심

퇴사 후 준비는 시간 여유가 있는 대신 공백 기간에 대한 부담과 심리적 압박이 커서 계획 없이 시작하면 몇 주가 금방 지나갑니다. 이 글은 주차별로 무엇을 끝내야 하는지와 이력서 경력 기술 방식, 알고리즘 우선순위, 면접 답변 구조, 처우 협의에서 확인할 것, 자주 하는 실수를 정리합니다.

들어가며

퇴사를 결심하고 새로운 회사를 알아보는 과정은 설레면서도 막막합니다. 처음 이직을 준비하는 사람이 가장 많이 잃는 것은 시간인데, 무엇부터 해야 할지 정하지 못한 채 이력서를 계속 고치거나 알고리즘 문제만 풀다가, 면접에서 떨어진 뒤에야 “이렇게 준비했어야 했구나”를 깨닫는 경우가 흔합니다.

특히 퇴사 후 이직 준비는 재직 중 이직과 다릅니다. 시간적 여유는 있지만 심리적 압박이 크고, 공백 기간에 대한 부담도 있습니다. 재직 중에는 “안 되면 지금 회사에 남으면 된다”는 협상력이 있지만, 퇴사 후에는 그 선택지가 없어서 첫 오퍼를 서둘러 받아들이기 쉽습니다. 그래서 퇴사 후 준비일수록 기간과 단계를 미리 정해 두는 것이 중요합니다.

이 글은 12주를 단계별로 나눈 로드맵입니다. 각 단계에 쓰는 시간은 사람마다 다르므로, 주차는 기준으로만 보고 자신의 상황에 맞게 늘리거나 줄이면 됩니다.

퇴사 전후에 챙길 행정적인 일

준비를 시작하기 전에 확인해 둘 것이 있습니다. 퇴사하면 직장 건강보험이 지역가입자로 바뀌어 보험료가 달라질 수 있고, 조건이 맞으면 퇴사 후 일정 기간 안에 신청하는 임의계속가입으로 직장가입자 수준의 보험료를 유지할 수 있습니다. 또 자발적 퇴사는 원칙적으로 실업급여 대상이 아니라는 점(예외 사유가 있음)도 생활비 계획에 반영해야 합니다. 퇴직금 정산, 원천징수영수증과 경력증명서 발급은 나중에 처우 협의나 입사 서류로 요청받는 경우가 많으므로 퇴사 전에 받아 두는 것이 편합니다. 구체적인 기준은 바뀔 수 있으므로 건강보험공단과 고용센터에서 본인 상황으로 확인하십시오.

1주차: 휴식과 방향 설정

번아웃에서 벗어나기

퇴사 직후에는 1-2주 정도 충분히 쉬세요. 퇴사하자마자 준비를 몰아서 시작하면 오히려 비효율적인 경우가 많습니다. 번아웃 상태에서는 집중도 안 되고, 면접에서도 에너지가 느껴지지 않습니다. 다만 휴식 기간은 시작 전에 끝나는 날짜를 정해 두는 편이 좋습니다. “조금만 더 쉬고”가 반복되면서 한 달이 지나가는 것이 퇴사 후 준비에서 가장 흔한 패턴입니다.

추천 활동:

밀린 수면 보충
가벼운 운동 (산책, 러닝)
관심 있던 기술 블로그 읽기 (부담 없이)
친구들과 만나서 이야기 나누기

이직 방향 설정

휴식 후에는 내가 원하는 것을 명확히 정리하세요. 항목별로 1~5점의 중요도를 매겨 적어 두면 됩니다.

항목	질문	중요도 예시 (1~5)
연봉	최소 수용 금액은 얼마인가?	4
기술 스택	다음 이직 때도 통할 경험인가?	5
워라밸	야근·온콜 빈도를 감당할 수 있는가?	3
문화	코드 리뷰, 의사결정 방식이 맞는가?	4
성장	배울 수 있는 선배·문제가 있는가?	5
안정성	회사의 재무 상태, 투자 단계는?	2

이 우선순위를 정해두면 회사를 선택할 때 흔들리지 않습니다. 여러 곳에서 동시에 연락이 오면 그 순간의 분위기나 연봉 숫자 하나에 끌려가기 쉬운데, 미리 적어 둔 기준이 있으면 “나는 기술 스택을 5점으로 매겼는데 이 회사는 여기에 맞지 않는다”처럼 판단 근거가 생깁니다. 연봉만 보고 옮겼다가 기술 스택이 맞지 않아 1년도 안 되어 다시 이직하는 경우가 개발자 커뮤니티에서 자주 이야기되는 실패 사례입니다.

목표 회사 리스트 작성

20-30개 회사 리스트를 만드세요. 너무 적으면 선택지가 없으며, 너무 많으면 준비가 산만해집니다. 회사 찾는 방법:

원티드, 로켓펀치, 프로그래머스 채용 공고
링크드인 “Jobs” 탭
관심 있는 서비스의 채용 페이지 직접 방문
개발자 커뮤니티 (Blind, 디스콰이엇) 추천

회사를 고를 때는 채용 공고보다 그 회사의 기술 블로그와 공개 발표 자료가 더 많은 것을 알려 줍니다. 어떤 문제를 풀고 있는지, 기술 스택이 공고의 나열과 실제로 같은지, 글을 쓰는 사람이 여러 명인지(개발 문화가 한두 명에게 의존하는지)를 확인할 수 있고, 면접에서 “왜 우리 회사인가요?”라는 질문에 구체적으로 답할 재료도 됩니다.

2-3주차: 포트폴리오 정비

GitHub 프로필 정리

경력직 면접에서 GitHub을 반드시 보는 것은 아니지만, 이력서에 링크를 적었다면 면접관이 열어 볼 가능성이 높다고 생각하고 정리해 두는 것이 좋습니다. 면접 중에 최근 저장소를 보고 “요즘 Go를 공부하셨네요?”처럼 질문이 이어지는 경우도 흔합니다. 반대로 방치된 저장소가 가득하면 링크를 적지 않는 편이 나을 수도 있습니다.

체크리스트:

프로필 사진 추가 (전문적인 느낌)
Bio 작성 (한 줄로 내 정체성)
README.md 작성 (자기소개 + 기술 스택)
Pinned repositories 설정 (대표 프로젝트 3-4개)
최근 활동 (의미 있는 커밋이 있으면 좋지만, 잔디를 채우기 위한 커밋은 오히려 역효과)

Pinned 프로젝트 선택 기준:

완성도 높은 프로젝트 (README, 테스트, 문서화)
최신 기술 스택 (지원하는 회사의 기술과 유사)
실용적인 프로젝트 (토이 프로젝트보다는 실제 문제 해결)

대표 프로젝트 만들기

시간이 있다면 1-2개 프로젝트를 새로 만드세요. 경력직이라면 회사 코드를 공개할 수 없어서 GitHub이 비어 있는 경우가 많은데, 실무에서 다뤘던 문제(동시성, 캐시, 장애 대응)를 작은 규모로 재현한 프로젝트는 “회사에서 무엇을 했는지”를 설명하는 좋은 보조 자료가 됩니다. 면접관이 관심을 갖는 부분은 기능 목록보다 왜 그렇게 설계했고 무엇을 포기했는지이므로, README에 설계 결정과 한계를 적어 두면 면접 질문이 자연스럽게 그쪽으로 흘러갑니다. 프로젝트 아이디어:

REST API 서버 (Express, Go Gin, FastAPI)
실시간 채팅 (WebSocket, Redis)
데이터 파이프라인 (Kafka, Airflow)
크롤러 + 대시보드 (Puppeteer, React)
CLI 도구 (Go, Rust) 중요한 것:
코드 품질 (린트, 포맷터, 테스트)
README 작성 (설치, 실행, 아키텍처 설명)
커밋 메시지 (Conventional Commits)
브랜치 전략 (feature, develop, main)

# 실시간 채팅 서버
## 기술 스택

- Backend: Go (Gin, WebSocket)
- Database: PostgreSQL, Redis
- Infrastructure: Docker, Kubernetes
## 주요 기능

- 실시간 메시지 전송 (WebSocket)
- 메시지 영속화 (PostgreSQL)
- 온라인 사용자 관리 (Redis)
- 부하 테스트 (10,000 동시 접속)
## 아키텍처

[아키텍처 다이어그램 이미지]
## 실행 방법

\`\`\`bash
docker-compose up -d
go run main.go
\`\`\`
## 성능 최적화

- Redis Pub/Sub로 서버 간 메시지 브로드캐스트
- Connection Pool 최적화
- 메시지 배치 처리

이 README 예시의 “부하 테스트 (10,000 동시 접속)” 같은 항목은 실제로 측정했을 때만 쓰십시오. 면접에서는 거의 반드시 “어떤 도구로, 어떤 환경에서, 어떤 조건으로 측정했나요?”, “병목은 어디였나요?”라는 질문이 따라옵니다. 그 질문에 답할 수 있는 작은 숫자가, 설명할 수 없는 큰 숫자보다 훨씬 좋은 인상을 남깁니다.

4-5주차: 이력서 작성과 지원

이력서 작성 핵심

1페이지에 핵심만 담으세요. 면접관은 30초 안에 이력서를 훑어봅니다. 구조 (추천):

1. 이름, 연락처, GitHub, 블로그
2. 간단한 소개 (2-3줄)
3. 기술 스택 (능숙한 것만)
4. 경력 (최근 순, 프로젝트 중심)
5. 학력 (간단히)

경력 작성 팁

Before (나쁜 예):

- 백엔드 개발 담당
- API 개발 및 유지보수
- 버그 수정

After (좋은 예):

- 결제 API 성능 개선: 응답 시간 500ms → 50ms (10배 개선)
  * Redis 캐싱 도입, DB 쿼리 최적화 (N+1 문제 해결)
  * 일 거래액 10억원 처리 안정화
  
- 실시간 알림 시스템 구축 (WebSocket, Redis Pub/Sub)
  * 동시 접속자 10,000명 처리
  * 메시지 전송 지연 100ms 이하 달성
  
- 레거시 코드 리팩토링: 테스트 커버리지 0% → 80%
  * 배포 시간 30분 → 5분 단축
  * 프로덕션 버그 월 10건 → 2건 감소

핵심:

숫자로 증명 (성능, 규모, 결과)
기술 스택 명시 (Redis, WebSocket)
비즈니스 임팩트 (거래액, 사용자 수)

숫자를 쓸 때 흔히 하는 실수는 팀 전체의 성과를 내 성과처럼 적는 것입니다. “응답 시간 10배 개선”이라고 쓰면 면접관은 “그중 본인이 한 부분은 무엇인가요?”를 묻습니다. 캐싱 설계를 했는지, 쿼리를 고쳤는지, 측정 환경을 만들었는지 자신의 기여를 한 줄 더 적어 두면 이 질문에 막히지 않습니다. 정확한 숫자를 모르거나 공개할 수 없다면 “p95 응답 시간을 절반 이하로” 같은 대략적인 표현도 충분합니다.

지원 전략

동시에 5-10곳 지원하세요. 한 곳씩 지원하면 시간이 너무 오래 걸립니다. 지원 우선순위:

1순위 (3-5곳): 꼭 가고 싶은 회사
2순위 (5-7곳): 괜찮은 회사
3순위 (5-10곳): 면접 연습용 팁: 3순위 회사로 먼저 면접을 보세요. 면접 감각을 익힌 후 1순위 회사 면접을 보는 게 유리합니다. 다만 채용 과정의 길이는 회사마다 크게 달라서(서류부터 최종 합격까지 2주에서 두 달 이상), 순서를 완벽히 맞추기는 어렵습니다. 1순위 회사의 과정이 긴 편이라면 조금 일찍 지원하고, 다른 회사의 오퍼 수락 기한이 먼저 다가오면 1순위 회사에 일정을 앞당길 수 있는지 솔직하게 물어보는 것도 흔히 쓰는 방법입니다.

6-8주차: 코딩 테스트 준비

효율적인 준비 방법

하루 2-3시간, 3주를 기준으로 잡되, 알고리즘을 오래 쉬었다면 더 길게 잡으십시오. 이미 한 번 준비해 본 사람은 기억을 되살리는 데 몇 주면 되지만, 처음이라면 몇 달이 걸리는 것도 이상하지 않습니다. 핵심은 자주 나오는 유형만 집중하는 것입니다. 경력직 코딩 테스트는 난이도보다 제한 시간 안에 정확하게 푸는 것을 보는 경우가 많아서, 새 유형을 넓게 공부하는 것보다 기본 유형을 실수 없이 빠르게 푸는 연습이 효과적입니다.

필수 알고리즘 (우선순위 순)

# 1. 해시맵 (가장 많이 나옴)
# 문제: 두 수의 합
def twoSum(nums, target):
    seen = {}
    for i, num in enumerate(nums):
        complement = target - num
        if complement in seen:
            return [seen[complement], i]
        seen[num] = i
    return []
# 2. 투 포인터
# 문제: 정렬된 배열에서 두 수의 합
def twoSumSorted(nums, target):
    left, right = 0, len(nums) - 1
    while left < right:
        current = nums[left] + nums[right]
        if current == target:
            return [left, right]
        elif current < target:
            left += 1
        else:
            right -= 1
    return []
# 3. 슬라이딩 윈도우
# 문제: 최대 길이 부분 배열
def maxSubArray(nums, k):
    max_sum = sum(nums[:k])
    current_sum = max_sum
    
    for i in range(k, len(nums)):
        current_sum += nums[i] - nums[i-k]
        max_sum = max(max_sum, current_sum)
    
    return max_sum

실전 팁

시간 배분:

1주차: 배열, 해시맵, 문자열 (기초)
2주차: 투 포인터, 슬라이딩 윈도우, 스택/큐
3주차: DFS/BFS, DP (기본), 이진 탐색 플랫폼 추천:
백준: 한국 기업 (네이버, 카카오)
LeetCode: 외국계 기업 (구글, 아마존)
프로그래머스: 중소기업, 스타트업 하루 루틴:

09:00-10:00  쉬운 문제 2개 (워밍업)
10:00-11:30  중간 난이도 1-2개
14:00-15:00  어려운 문제 1개 (시도만)
저녁         틀린 문제 복습

9-10주차: 기술 면접 준비

자주 나오는 질문 유형

경력직 기술 면접에서 반복해서 나오는 유형을 정리했습니다. 대부분의 질문은 이력서에 적은 내용에서 출발하므로, 이력서의 모든 줄에 대해 “왜 그렇게 했나요?”라는 질문에 답할 수 있는지 먼저 점검하십시오.

1. 프로젝트 경험

질문: “가장 어려웠던 기술적 문제와 해결 과정을 설명해주세요.” 답변 구조 (STAR):

Situation: 상황 설명
Task: 내가 맡은 역할
Action: 구체적인 해결 방법
Result: 결과 (숫자로) 예시 답변:

[Situation]
결제 API가 트래픽 증가로 응답 시간이 500ms를 넘어가면서 
고객 불만이 증가했습니다.
[Task]
저는 백엔드 개발자로서 성능 개선을 담당했습니다.
[Action]
1. 프로파일링으로 병목 지점 파악 (DB 쿼리가 80% 차지)
2. N+1 쿼리 문제 발견 → JOIN으로 해결
3. 자주 조회되는 데이터는 Redis 캐싱 (TTL 5분)
4. 부하 테스트로 검증 (Apache JMeter)
[Result]
- 응답 시간: 500ms → 50ms (10배 개선)
- DB 부하: 70% 감소
- 일 거래액 10억원 안정 처리

2. 기술 깊이 질문

질문: “HTTP와 HTTPS의 차이를 설명해주세요.” 나쁜 답변: “HTTPS가 보안이 더 좋아요.” 좋은 답변:

HTTP는 평문 통신이라 중간자 공격에 취약합니다.
HTTPS는 TLS/SSL로 암호화하여 3가지를 보장합니다:
1. 기밀성: 데이터 암호화 (AES-GCM, ChaCha20 등)
2. 무결성: 데이터 변조 방지 (TLS 1.3은 AEAD 암호로 암호화와 무결성을 함께 보장)
3. 인증: 서버 신원 확인 (CA가 서명한 인증서)
실무에서는 Let's Encrypt로 무료 인증서를 발급받으며,
Nginx에서 SSL 설정을 합니다. HSTS 헤더로 강제 HTTPS 전환도 설정합니다.

팁: 개념 → 동작 원리 → 실무 경험 순으로 설명하세요. 면접관은 좋은 답변에서 멈추지 않고 한 단계씩 더 깊이 들어갑니다(“TLS 핸드셰이크에서 키는 어떻게 교환되나요?”, “인증서가 만료되면 무슨 일이 생기나요?”). 모르는 단계에 도달했을 때 “거기까지는 확실히 모르지만, 제가 이해하기로는 ~일 것 같습니다”처럼 아는 것과 추측을 구분해 말하면, 틀리더라도 좋은 평가를 받는 경우가 많습니다.

3. 트러블슈팅 질문

질문: “프로덕션에서 장애가 발생했을 때 어떻게 대응하나요?”

# 장애 대응 프로세스
def handle_production_incident():
    # 1. 즉시 대응 (5분 이내)
    check_monitoring_dashboard()  # Grafana, Datadog
    check_error_logs()            # Sentry, CloudWatch
    check_recent_deployments()    # 최근 배포 확인
    
    # 2. 임시 조치 (10분 이내)
    if is_critical():
        rollback_deployment()     # 이전 버전으로 롤백
        notify_team()             # 팀에 알림
    
    # 3. 근본 원인 분석 (1시간 이내)
    analyze_logs()
    reproduce_locally()
    identify_root_cause()
    
    # 4. 영구 수정 (당일)
    fix_bug()
    add_tests()
    deploy_fix()
    
    # 5. 사후 분석 (3일 이내)
    write_postmortem()
    improve_monitoring()
    prevent_recurrence()

위의 단계는 암기할 절차가 아니라 답변의 뼈대입니다. 면접관이 특히 보는 것은 “원인을 찾기 전에 먼저 서비스를 복구했는가”(롤백 우선), 그리고 “같은 문제가 다시 생기지 않게 무엇을 바꿨는가”(모니터링, 테스트, 프로세스)입니다. 답변 예시는 다음과 같은 형태가 됩니다.

답변 예시:

"새벽 2시에 결제 API가 다운되어 호출을 받았습니다.
모니터링을 보니 DB 커넥션 풀이 고갈된 상태였으며,
최근 배포한 코드에서 커넥션을 제대로 반환하지 않는 버그를 발견했습니다.
즉시 이전 버전으로 롤백하여 5분 만에 서비스를 복구했으며,
다음 날 버그를 수정하고 커넥션 모니터링 알람을 추가했습니다.
이후 같은 문제는 발생하지 않았습니다."

11-12주차: 면접 및 협상

면접 당일 팁

면접 30분 전:

회사 홈페이지, 기술 블로그 다시 읽기
내 이력서 다시 읽기 (질문 예상)
물 한 잔 마시기 (긴장 완화) 면접 중:
모르는 질문은 실제로 “잘 모르겠습니다” (거짓말하지 말 것)
질문의 의도를 파악 (막히면 “이런 의미인가요?” 확인)
화이트보드 코딩은 큰 소리로 생각 과정 설명 면접 후:
당일 저녁에 감사 메일 (선택사항이지만 좋은 인상)
면접 질문 기록 (다음 면접 대비)

연봉 협상

협상 타이밍: 최종 면접 후 처우 제안을 받았을 때 협상 전 준비:

시장 연봉 조사 (원티드, 로켓펀치, Blind)
내 현재 연봉 + 희망 인상률
최소 수용 가능 금액 (이것보다 낮으면 거절) 협상 멘트 예시:

[제안받은 금액이 낮을 때]
"제안해주신 조건 감사합니다. 
제 경력과 기술 스택을 고려했을 때, 
시장 평균이 X만원 정도인 것으로 알고 있습니다.
Y만원 정도로 조정 가능할까요?"
[다른 오퍼가 있을 때]
"다른 회사에서 X만원 제안을 받았는데,
귀사를 더 선호하고 있습니다.
비슷한 수준으로 맞춰주실 수 있을까요?"
[스톡옵션 대신 연봉]
"스톡옵션보다는 기본 연봉을 높이는 것을 선호합니다.
스톡옵션 대신 연봉으로 조정 가능할까요?"

협상 시 주의사항:

근거 없이 높게 부르지 말 것 (시장 자료, 다른 오퍼, 맡을 역할의 범위 등 근거와 함께)
공격적이지 않게 (협력적 태도)
대안 제시 (연봉 안 되면 입사 보너스, 재택, 교육비 등)
다른 오퍼를 언급할 때는 실제 있는 오퍼만. 확인을 요청받는 경우도 있습니다.

한국 회사에서는 처우 협의 단계에서 직전 연봉 증빙(원천징수영수증 등)을 요청하는 경우가 많고, 제안 연봉이 직전 연봉에 인상률을 곱하는 방식으로 정해지는 경우도 흔합니다. 이때 성과급이나 수당이 연봉에 포함되는지, 제안 금액이 기본급인지 총액인지를 반드시 확인하십시오. 같은 숫자라도 구성에 따라 실수령액이 크게 다릅니다. 스톡옵션은 행사가, 베스팅 일정, 퇴사 시 행사 가능 기간을 확인하지 않으면 가치를 판단할 수 없습니다.

실전 팁

면접 준비 체크리스트

## 기술 면접 전날

- [ ] 내 프로젝트 코드 다시 읽기
- [ ] 자주 쓴 기술 스택 공식 문서 훑기
- [ ] 회사 기술 블로그 읽기
- [ ] 예상 질문 리스트 점검
- [ ] 옷 준비 (비즈니스 캐주얼)
- [ ] 일찍 자기 (최소 7시간)
## 면접 당일

- [ ] 30분 일찍 도착
- [ ] 노트북, 충전기 챙기기 (과제 면접 대비)
- [ ] 이력서 출력본 2부
- [ ] 명함 (있다면)
- [ ] 질문 리스트 (역질문용)
## 면접 후

- [ ] 감사 메일 (선택)
- [ ] 면접 질문 기록
- [ ] 부족했던 부분 복습

자주 하는 실수

1. 이력서에 거짓 쓰기

❌ "React 능숙" (실제로는 튜토리얼만 봄)
✅ "React 기본 (TodoList 프로젝트 경험)"

2. 연봉만 보고 결정

❌ 연봉 1000만원 더 받고 레거시 회사 입사
   → 6개월 후 다시 이직 (시간 낭비)
   
✅ 연봉은 조금 낮아도 성장 가능한 회사 선택
   → 1년 후 실력 향상으로 더 좋은 곳 이직

3. 면접에서 아는 척

❌ "Kubernetes? 네, 잘 알죠!" (실제로는 모름)
   → 깊이 질문에 답 못함 → 신뢰 상실
   
✅ "Docker는 써봤는데 Kubernetes는 아직입니다.
    하지만 관심이 많아서 공부하고 있습니다."

공백 기간 대처법

3개월 이하: 문제없음. “이직 준비 기간”이라고 하면 됩니다. 3-6개월: 이 기간 동안 뭘 했는지 설명 필요

“새로운 기술 스택 학습 (프로젝트 링크)”
“오픈소스 기여 (PR 링크)”
“개인 프로젝트 개발 (GitHub 링크)” 6개월 이상: 솔직하게 설명
“번아웃으로 휴식 필요했습니다”
“가족 사정으로 시간이 필요했습니다”
“창업을 시도했으나 접었습니다” 중요: 공백 기간 동안 완전히 놀지는 않았다는 것을 보여주세요. GitHub 커밋, 블로그 글, 온라인 강의 수료증 등.

공백 기간 질문에서 면접관이 실제로 확인하려는 것은 대개 두 가지입니다. “다시 일할 준비가 되었는가”와 “퇴사 이유가 우리 회사에서도 반복되지 않을까”입니다. 그래서 번아웃이나 가족 사정 같은 이유를 말할 때는 이유 자체보다 지금은 해결되었고 왜 이 시점에 돌아오려 하는지를 한 문장 덧붙이는 것이 좋습니다. 이전 회사를 비난하는 말은 사실이더라도 면접관에게는 “여기서도 같은 불만이 생길 수 있다”는 신호로 읽히기 쉬우니 피하십시오.

여러 오퍼 받았을 때

비교 기준표 만들기:

| 항목 | A사 | B사 | C사 | 가중치 |
|------|-----|-----|-----|--------|
| 연봉 | 7000 | 8000 | 7500 | x2 |
| 기술스택 | Go, K8s | Java, Spring | Python, Django | x3 |
| 워라밸 | 9-6 | 10-7 | 9-6 | x2 |
| 성장기회 | 높음 | 중간 | 높음 | x3 |
| 출퇴근 | 30분 | 1시간 | 재택 | x1 |
| 팀 분위기 | 좋음 | 보통 | 좋음 | x2 |
총점은 각 항목을 1~5점으로 매긴 뒤 가중치를 곱해 더해서 계산

결정 전 체크:

3일 정도 시간을 두고 생각하기
믿을 수 있는 선배/멘토와 상담
장단점 리스트 작성
직감도 중요 (면접 때 느낌)

실무에서 느낀 이직의 진실

좋은 이직 vs 나쁜 이직

개발자들이 이직을 돌아보며 자주 이야기하는 두 가지 전형을 비교하면 다음과 같습니다.

좋은 이직의 전형:

기술 스택: 원하던 방향으로 이동 (예: 모놀리식 Spring → Go + Kubernetes)
연봉: 적정 수준 인상
워라밸: 면접 때 확인한 대로 유지
성장: 맡는 문제의 범위가 넓어짐 나쁜 이직의 전형:
연봉: 큰 폭 인상 (당장은 좋음)
기술 스택: 공고와 달리 오래된 레거시 유지보수 위주
워라밸: 면접 때 들은 것과 다름
결과: 1년도 안 되어 재이직, 이력서에 짧은 경력이 남음 교훈: 연봉을 무시하라는 뜻은 아닙니다. 다만 짧은 재직 기간은 다음 이직에서 설명이 필요한 부담이 되므로, 연봉 차이가 크지 않다면 맡을 업무와 성장 기회에 더 높은 가중치를 두는 편이 장기적으로 유리한 경우가 많습니다. 나쁜 이직을 피하는 가장 현실적인 방법은 면접 마지막의 역질문 시간에 “입사하면 첫 3개월 동안 맡게 될 일”, “팀의 배포 주기와 온콜 방식”, “최근에 나간 사람이 있다면 그 이유”처럼 구체적인 질문을 하는 것입니다.

이직 후 적응 팁

첫 3개월:

질문 많이 하기 (모르는 척 해도 됨)
코드 리뷰 적극 참여
팀 문화 파악 (점심, 회의 스타일)
작은 성과 만들기 (버그 수정, 문서화) 6개월 후:
주도적으로 프로젝트 제안
기술 공유 (사내 세미나)
멘토링 (신입 도와주기)

타임라인 요약

| 주차 | 활동 | 시간 투자 |
|------|------|----------|
| 1주 | 휴식, 방향 설정 | 하루 1-2시간 |
| 2-3주 | 포트폴리오 정비 | 하루 4-6시간 |
| 4-5주 | 이력서 작성, 지원 | 하루 3-4시간 |
| 6-8주 | 코딩 테스트 준비 | 하루 2-3시간 |
| 9-10주 | 기술 면접 준비 | 하루 3-4시간 |
| 11-12주 | 면접, 협상 | 주 2-3회 면접 |

마무리

퇴사 후 이직은 기간을 정해 집중하는 편이 좋습니다. 3개월은 많은 사람에게 현실적인 기준이지만, 시장 상황과 직군에 따라 더 걸릴 수 있으므로 생활비 계획은 여유 있게 세워 두십시오.

가장 중요한 3가지:

포트폴리오: 코드로 실력 증명
면접 준비: 경험을 구조적으로 설명하는 연습
마인드셋: 떨어져도 괜찮다 (경험 쌓기) 여러 곳에서 떨어지는 것은 이직 과정에서 흔한 일입니다. 떨어질 때마다 받은 질문과 막힌 지점을 기록해 두고 다음 면접 전에 그 부분만 보완하면, 면접을 거듭할수록 답변이 눈에 띄게 단단해집니다. 결과와 상관없이 이렇게 자신의 경험을 정리하고 설명하는 연습 자체가 다음 커리어에서도 계속 쓰이는 자산이 됩니다.

같이 보면 좋은 글

자주 묻는 질문 (FAQ)

Q. 연봉이 더 높은 쪽을 고르면 안 되는 경우는 언제인가요?

A. 연봉 차이만 보고 레거시 기술 위주의 회사로 옮기면, 몇 년 뒤 다음 이직을 할 때 쌓은 경험이 시장에서 잘 통하지 않을 수 있습니다. 제안을 비교할 때는 연봉과 함께 맡게 될 업무와 기술 스택, 팀의 개발 문화, 성장 가능성을 같이 보는 것이 좋습니다. 면접 과정에서 팀이 실제로 어떤 문제를 풀고 있는지 질문해 두면 판단 근거를 얻을 수 있습니다.

이 글의 핵심

들어가며

퇴사 전후에 챙길 행정적인 일

1주차: 휴식과 방향 설정

번아웃에서 벗어나기

이직 방향 설정

목표 회사 리스트 작성

2-3주차: 포트폴리오 정비

GitHub 프로필 정리

대표 프로젝트 만들기

4-5주차: 이력서 작성과 지원

이력서 작성 핵심

경력 작성 팁

지원 전략

6-8주차: 코딩 테스트 준비

효율적인 준비 방법

필수 알고리즘 (우선순위 순)

실전 팁

9-10주차: 기술 면접 준비

자주 나오는 질문 유형

1. 프로젝트 경험

2. 기술 깊이 질문

3. 트러블슈팅 질문

11-12주차: 면접 및 협상

면접 당일 팁

연봉 협상

실전 팁

면접 준비 체크리스트

자주 하는 실수

공백 기간 대처법

여러 오퍼 받았을 때

실무에서 느낀 이직의 진실

좋은 이직 vs 나쁜 이직

이직 후 적응 팁

타임라인 요약

추천 자료

코딩 테스트

기술 면접

연봉 정보

마무리

같이 보면 좋은 글

자주 묻는 질문 (FAQ)

Q. 연봉이 더 높은 쪽을 고르면 안 되는 경우는 언제인가요?