본문 바로가기
개발자/취업 커리어 입문

인턴에서 정규직 전환, 솔직하게 어떻게 했나

by 나무011 2026. 8. 2.
개발자 현직자 솔직 경험담

인턴에서 정규직 전환,
솔직하게 어떻게 했나

3개월 인턴 기간 동안 실제로 생각하고 행동한 것들

Frontend Developer 2026년 6월 약 13분 읽기

인턴 제안을 받던 날

취준 7개월 차였다. 계속 서류에서 탈락하다가 처음으로 최종 면접을 통과한 곳이 스타트업 인턴 자리였다. 정규직이 아니라는 사실에 잠깐 고민했지만, 당시 나한테는 "현직 개발자"라는 타이틀이 가장 필요했다. 3개월 후 전환 가능성이 있다는 말을 믿고 들어갔다.

그 믿음이 맞았다. 3개월 후 정규직 전환 제안을 받았다. 근데 그게 운이나 실력만은 아니었다. 인턴 기간 동안 의도적으로 한 것들이 있었다. 이 글은 그것들을 솔직하게 정리한 것이다.

인턴에서 정규직 전환
인턴에서 정규직 전환
3개월 인턴 기간
100% 전환 성공
+400만 연봉 협상 추가 확보
2번 전환 면담 횟수

3개월 인턴 기간 — 주차별 실제 기록

인턴 타임라인 — 실제로 있었던 일들
1~2주
 
 
🔍 탐색기
보기만 했다 — 의도적으로

코드를 열고 PR을 보고 슬랙을 읽었다. 먼저 말을 많이 하지 않았다. 팀의 언어, 코드 스타일, 의사결정 방식을 파악하는 게 우선이었다. 이 시기에 한 가장 중요한 일은 "온보딩 문서가 없다"는 걸 발견하고 직접 만들기 시작한 것이다.

3~4주
 
 
⚡ 첫 기여
작은 것부터, 그러나 완전하게

첫 PR을 올렸다. 작은 UI 버그 수정이었다. 중요한 건 작다는 것이 아니라 "왜 이 버그가 생겼는지, 어떻게 고쳤는지, 테스트 케이스가 어떤 게 있는지"를 PR description에 다 담았다는 것이다. 리드 개발자가 "PR description 잘 쓰네요"라고 했다.

5~6주
 
 
📈 성장
독립적으로 태스크를 완료하기 시작했다

누가 지시하기 전에 "이 부분 제가 맡을게요"를 먼저 말했다. 매일 퇴근 전 슬랙에 오늘 한 일을 짧게 공유했다. 팀원들이 인식하지 못해도 기록이 쌓이는 게 중요했다.

7~8주
 
 
⚠️ 위기
실수가 있었다 — 그 처리 방식이 중요했다

배포에서 작은 버그가 나왔다. 내 코드였다. 숨기고 싶었다. 그러지 않았다. 발견한 즉시 리드한테 메시지 보내고 원인과 수정 방향을 같이 올렸다. "빠르게 보고해줘서 고마워요"라는 답이 왔다. 실수보다 대응 방식이 평가됐다.

9~10주
 
 
🎯 핵심 기여
처음으로 기능 전체를 혼자 설계하고 구현했다

검색 필터 기능을 맡았다. 작은 것이 아니라 상태 설계, 컴포넌트 구조, 퍼포먼스 고려까지 처음부터 끝까지 내가 결정했다. 리드가 "이 정도 판단력이면 주니어 수준 충분히 넘어요"라고 했다. 그 말이 중요한 신호였다.

11주
 
 
💬 먼저 물었다
전환 가능성에 대해 직접 물어봤다

기다리지 않았다. 리드와 1:1 미팅에서 "인턴 기간이 2주 남았는데, 전환 가능성이 어느 정도인지 여쭤봐도 될까요?"라고 물었다. 이게 용기가 필요한 질문이었지만, 물어보지 않으면 아무도 먼저 말해주지 않을 수도 있었다.

12주
 
 
🎉 전환 제안
정규직 전환 면담 + 연봉 협상

CTO가 직접 면담을 잡았다. 전환 제안이 왔고, 연봉을 제시했다. 준비한 시장 데이터와 인턴 기간 기여 내용을 정리해서 더 달라고 했다. 400만 원이 올랐다. 인턴 때 기여한 것들을 숫자로 말할 수 있었던 게 협상력이 됐다.

실제로 평가받는 것들

인턴 기간 동안 "잘한다"는 평가를 받으려면 코딩 실력만이 전부가 아니었다. 리드와 대화하면서 파악한 것들, 그리고 내가 직접 경험한 것들을 정리하면 이렇다.

🔍
평가 요소 1
혼자 해결하는 능력보다 막혔을 때 어떻게 하는지

인턴한테 어려운 문제를 주는 건 실력을 테스트하는 게 아니다. 막혔을 때 어떻게 하는지를 보는 것이다. 혼자 2시간 보내다가 조용히 포기하는 사람과, 30분 혼자 시도해보고 "이렇게 해봤는데 여기서 막혀요, 혹시 방향이 맞는지 봐주실 수 있어요?"라고 묻는 사람은 다르게 평가된다.

후자가 맞다. 막히는 것 자체가 문제가 아니다. 막혔을 때 자기 상태를 인식하고, 맥락을 정리해서 도움을 요청하는 능력이 실무에서 더 중요하다. 그게 팀에서 일하는 방식이니까.

📋
평가 요소 2
PR 하나가 전부를 말해준다

PR description이 빈칸인 사람과, "어떤 문제를 왜 이렇게 해결했고, 어떤 케이스를 테스트했고, 리뷰어가 주의깊게 볼 부분이 어디인지"를 쓰는 사람은 완전히 다르게 보인다.

내가 인턴 첫 PR을 올릴 때 description에 시간을 많이 썼다. 리드가 리뷰할 때 질문이 거의 없었다. 다 설명돼 있었으니까. "코드는 봤는데 description이 이미 다 설명해줘서 딱히 물어볼 게 없네요"라는 피드백이 왔다. 그게 가장 기분 좋은 코드 리뷰 경험이었다.

⚠️
평가 요소 3
실수보다 실수를 처리하는 방식

7~8주 차에 배포에서 버그가 났다. 내 코드였다. 그 순간 두 가지 선택지가 있었다. 조용히 고치고 넘어가거나, 바로 알리거나. 조용히 고칠 수도 있었다. 작은 버그였으니까.

그러지 않았다. 발견한 순간 리드한테 메시지를 보냈다. "이 부분에서 버그가 나왔습니다. 원인은 이것이고, 수정 방향은 이렇게 생각합니다. 지금 바로 PR 올려도 될까요?" 리드의 반응은 예상과 달랐다. "빠르게 보고해줘서 좋아요, 방향 맞으니 올려요." 실수를 숨기려는 사람과 문제를 빠르게 공유하는 사람은 신뢰도가 다르다.

인턴 평가는 3개월의 합산이 아니라 매일 쌓이는 인상이다. 하루 하루 어떻게 일하는지가 기억에 남는다.

전환 가능성을 높인 구체적 행동들

매일 퇴근 전 슬랙에 짧은 업무 공유

"오늘 검색 필터 컴포넌트 구현 완료, 내일 테스트 케이스 작성 예정"처럼 두 줄로. 팀이 인식하지 못하는 사이에도 내가 하고 있는 걸 보이게 만들었다. 한 달 뒤 리드가 "요즘 많이 하네요"라고 했다. 기억하고 있었다.

온보딩 문서를 직접 만들었다

없는 걸 만들면 팀에 기여하는 것이고, 내가 파악한 것을 정리하는 것이기도 하다. 세팅 방법, 자주 나오는 에러, 배포 절차를 문서화했다. 나중에 다른 인턴이 들어왔을 때 그 문서를 쓰는 걸 봤다. 그 순간이 뿌듯했다.

코드 리뷰에 먼저 참여했다

인턴이 시니어 PR에 리뷰 달기가 눈치 보였다. 그래도 했다. 작은 오타, 타입 안전성 개선, 링크 추가 — 크지 않아도 달았다. "인턴인데 리뷰 달면 이상한가?" 이런 생각은 접었다. 팀원으로 일하는 태도를 보여주는 것이 더 중요했다.

11주 차에 전환 가능성을 먼저 물었다

기다리면 아무 일도 안 일어난다. 2주가 남았을 때 1:1 미팅에서 직접 물어봤다. 처음엔 어떻게 말을 꺼낼지 몰라서 연습했다. "인턴 기간이 2주 남았는데, 전환 여부에 대해 어느 정도 생각해볼 수 있는지 궁금해서요." 이게 전환 프로세스를 시작하는 계기가 됐다.

회의에서 발언하는 데 시간이 걸렸다

처음 한 달은 회의에서 거의 말을 안 했다. 눈치가 보였고, 잘 모르는 것 같아서. 돌아보면 그게 아쉬운 부분이다. 작더라도 질문이나 의견을 내는 것이 "이 사람이 생각을 하고 있구나"를 보여주는 것이었는데.

인턴 기간 기여를 숫자로 정리해뒀다

전환 면담 전날 노션에 정리했다. "PR 27개 머지, 버그 수정 12건, 신규 기능 구현 3개, 온보딩 문서 작성, 코드 리뷰 참여 18건". 연봉 협상 자리에서 이게 근거가 됐다. 숫자가 없으면 "열심히 했습니다"밖에 못 한다.

전환 면담 — 실제로 오간 대화

전환 면담 — 12주 차, CTO와 미팅
C
CTO
인턴 기간 어땠어요? 본인 스스로 평가하면 어떻게 될 것 같아요?
처음 2주는 파악하는 데 시간이 걸렸고, 3주 차부터 PR을 올리기 시작했어요. 가장 의미 있었던 건 9주 차에 검색 필터를 처음부터 설계하고 구현한 경험이었고요. 7주 차에 배포 버그가 있었을 때 빠르게 보고하고 수정한 게 팀에 피해를 최소화했다고 생각해요.
C
CTO
리드 평가도 좋았어요. 코드 품질보다 일하는 방식이 인상적이었다고. 전환 제안 드리고 싶은데, 연봉 희망이 어떻게 돼요?
감사합니다. 시장 데이터 기준으로 저와 비슷한 경력의 프론트엔드 개발자 평균이 이 정도고, 이번 인턴 기간에 기여한 것들을 감안하면 OO원 정도를 희망합니다.
C
CTO
말씀하신 근거가 합리적이에요. 내부 검토 후 연락드릴게요. 이틀 안에요.
✅ 전환 면담에서 효과적이었던 것

스스로 평가를 먼저 말한 것. CTO가 어떻게 평가하는지 물어볼 때 "좋았던 것 같습니다"보다 구체적으로 "9주 차에 검색 필터를 처음부터 구현했고, 버그 발생 시 빠르게 보고했다"처럼 사례로 말한 것. 평가자가 아니라 내가 먼저 증거를 제시하는 방식이었다.

해야 할 것과 하지 말아야 할 것

✅ 하면 좋은 것들
 

온보딩 과정에서 불편했던 것을 문서로 만든다. 당장 기여이고 나중에 팀 자산이 된다.

 

PR description을 리뷰어 입장에서 쓴다. 왜, 어떻게, 어디를 주목해야 하는지.

 

실수를 빠르게 공유한다. 숨기는 것보다 빠른 보고가 신뢰를 만든다.

 

매일 한 일을 짧게 기록한다. 팀이 기억하지 못해도 기록은 남는다.

 

전환 가능성을 먼저 물어본다. 기다리면 아무 일도 안 일어날 수 있다.

❌ 피해야 할 것들
 

2시간 이상 혼자 막혀 있지 않는다. 30~60분이면 물어볼 타이밍이다.

 

"어차피 인턴이니까"로 자기 검열하지 않는다. 팀원처럼 일하는 태도가 평가된다.

 

쉬운 태스크만 고르지 않는다. 어려운 것에 도전하는 모습이 기억된다.

 

회의에서 아무 말도 안 하지 않는다. 작은 질문이라도 존재감을 만든다.

 

기여를 숫자로 정리하지 않은 채 전환 면담에 들어가지 않는다.

전환이 안 됐다면 어떻게 했을까

💭
솔직한 생각
전환 거절이라는 가능성에 대해

인턴 기간 동안 "전환이 안 되면 어떻게 하지"를 한 번도 생각하지 않은 건 아니었다. 특히 7~8주 차에 버그가 있었을 때, '이거 때문에 안 될 수도 있다'는 생각이 순간 들었다.

그런데 동시에 이런 생각도 했다. 전환이 안 되더라도 이 3개월이 의미가 없는 건 아니다. 27개의 PR, 온보딩 문서, 검색 필터 구현 — 전부 내 포트폴리오가 된다. "현직자로서 실무 코드를 작성했다"는 경험은 어딜 가도 쓸 수 있다.

그 생각이 오히려 인턴 기간을 편안하게 만들었다. 전환을 위해 연기하는 게 아니라, 이 기회에서 최대한 배우고 기여하는 것. 그 태도가 결국 전환으로 이어졌다고 생각한다.

⚠️ 인턴 전환을 생각하는 분들에게 현실적인 말

전환율은 회사마다 다르다. 처음부터 헤드카운트가 없어서 전환이 어려운 경우도 있고, 기여와 무관하게 예산 문제로 안 되는 경우도 있다. 내가 아무리 잘 해도 안 되는 경우가 있다. 그게 내 실패가 아니다. 그 경우엔 인턴 경험을 들고 이직을 준비하면 된다. 현직 경험 있는 구직자와 없는 구직자는 다른 레벨이니까.


정규직 전환 통보를 받던 날 퇴근길이 기억난다. 이상하게 아무 감정이 없었다. 3개월 동안 충분히 했다는 느낌이 있었기 때문이었다. 결과보다 과정에서 이미 뭔가를 얻었다는 감각이 먼저였다.

인턴 기간은 짧다. 그래서 매일이 중요하다. 하루하루 쌓이는 인상이 3개월 후의 결정을 만든다. "어차피 인턴이니까"라는 생각이 아니라 "이 팀의 일원으로 기여한다"는 태도로 임한다면 — 결과가 전환이든 아니든, 그 시간은 낭비되지 않는다.

💬 인턴 경험이나 전환 과정에서 어떤 경험을 하셨나요?

전환에 성공한 분, 아쉽게 안 됐던 분, 지금 인턴 중인 분 모두 — 어떤 이야기든 댓글로 나눠주세요. 비슷한 상황에 있는 분들에게 가장 현실적인 참고가 될 것 같습니다.


소개 및 문의 · 개인정보처리방침 · 면책조항

© 2026 나무핀