신입 개발자가
입사 첫 날 받은 충격
부트캠프에서 배운 것과 실제 회사 코드 사이의 그 간극에 대해
입사 전날 밤
출근 전날 밤을 기억한다. 설레서 잠을 제대로 못 잤다. 준비한 것들을 머릿속으로 정리했다. React는 꽤 됐고, TypeScript도 기본은 알고, Next.js 프로젝트도 포트폴리오에 두 개가 있었다. 부트캠프에서 6개월을 갈았고, 취준 8개월을 버텼다. 드디어 내일이었다.
어떤 걸 만들게 될까 상상했다. 깔끔한 컴포넌트 구조, 모던한 스택, 코드 리뷰 문화. 면접 때 CTO가 "우리는 최신 기술 스택을 쓴다"고 했고, GitHub 잔디가 파릇파릇한 팀원들이 보였다. 좋아 보였다.
노트북을 받고 세팅 시작했다. 선배가 "레포 클론하고 README 따라 세팅하면 돼요"라고 했다. README를 열었다. 마지막 업데이트가 2년 전이었다. 거기 적힌 Node.js 버전이 지금 내 컴퓨터에 없는 버전이었다. 세팅 첫 걸음부터 막혔다.
에러 메시지를 보면서 처음으로 든 생각은 "내가 뭔가 잘못한 건가"였다. 아니었다. 그냥 README가 낡은 것이었다. 그걸 아는 데 한 시간이 걸렸다.
기대와 현실 — 하루 만에 무너진 것들
최신 기술 스택 (Vite, Turborepo, pnpm)
깔끔하게 정리된 컴포넌트 구조
상세한 온보딩 문서와 가이드
PR 코드 리뷰 문화, 페어 프로그래밍
테스트 코드가 잘 갖춰진 환경
변수명이 직관적인 읽기 좋은 코드
CRA + npm + 오래된 webpack 설정
2,000줄짜리 컴포넌트 파일 하나
낡은 README 한 장. 온보딩은 구두로
"급하니까 일단 바로 main에 푸시해요"
테스트 코드 0개. "나중에 써야 하는데…"
temp, temp2, finalFinal 같은 변수명
충격 1 — 코드베이스가 부트캠프와 달랐다
메인 화면 컴포넌트를 처음 열었을 때의 그 느낌이 아직도 생생하다. VS Code 미니맵이 엄청나게 길었다. 스크롤을 내려도 내려도 코드가 끝나지 않았다. useState가 30개가 넘었고, useEffect 안에 useEffect가 있었고, 컴포넌트 안에 인라인으로 정의된 컴포넌트가 있었다.
부트캠프에서 "컴포넌트는 하나의 역할만"이라고 배웠다. 실제 레포는 달랐다. 이 파일 하나가 회원가입, 로그인, 소셜 로그인, 약관 동의, 비밀번호 찾기까지 다 담고 있었다. "왜 이렇게 됐냐"는 질문은 나중에 알았다. 개발자 세 명이 출산휴가, 퇴사, 이직이 겹친 6개월 동안 급하게 기능을 붙인 흔적이었다.
const AuthPage = () => { // TODO: 나중에 분리하기 (2년 전 커밋) const [data, setData] = useState(null) const [data2, setData2] = useState(null) // 뭔지 모름 const [temp, setTemp] = useState('') // 임시 const [finalData, setFinalData] = useState() const [finalData2, setFinalData2] = useState() // ... (useState 27개 더)
useEffect(() => { useEffect(() => { // ← 이게 가능한지도 몰랐다 // 왜 여기 있는지 아무도 모름 }, []) }, [data, data2, temp])
// 1,800줄 후... // ============================== // 아래 코드는 건드리지 마세요!! // 이유는 모르지만 지우면 안 됩니다 // ============================== }
실제 회사 코드는 수년 동안 여러 사람이 급하게 붙인 것들이 쌓여 있다. 이상적인 구조로 되어 있지 않은 게 정상이다. "왜 이렇게 됐지"가 아니라 "이게 어떻게 동작하는지"를 먼저 파악하는 게 신입의 역할이다.
충격 2 — 아무도 날 기다리지 않았다
온보딩이라는 게 존재했다. 그런데 그 온보딩이란 게 선배가 하루 중 틈날 때 30분씩 설명해주는 것이었다. 문서는 없었다. 질문하면 "그냥 코드 보면 알 거예요"라는 말이 돌아왔다.
선배가 나쁜 사람이 아니었다. 그냥 바빴다. 나를 위한 시간이 따로 없었다. 스타트업 특성상 모두가 자기 일에 치여 있었다. 내가 스스로 찾고, 스스로 해결해야 한다는 걸 그때 처음 알았다.
충격 3 — 첫 번째 배포가 이렇게 됐다
입사 사흘째에 간단한 버튼 색상 변경 태스크를 받았다. CSS 두 줄짜리 수정이었다. PR을 만들어야지 싶었는데 PM이 말했다.
"급해서요, 그냥 main에 바로 올려주실 수 있어요? 오늘 오후에 데모가 있어서."
부트캠프에서 배운 Git 플로우가 있었다. feature 브랜치 → PR → 리뷰 → 머지. 그런데 지금 main에 직접 푸시하라고 한다. 어색했지만 했다. 버튼 색이 바뀌었다. 데모는 됐다. 리뷰는 없었다. 테스트도 없었다. 그냥 됐다.
나중에 선배한테 조용히 물어봤다. "원래 PR 써야 하는 거 맞아요. 근데 지금 팀이 바빠서 형식보다 속도를 우선하고 있어요. 나중에 팀이 안정되면 잡아가야 하는 부분이에요." 그 '나중에'가 몇 년이 됐다는 걸 나중에 알았다.
충격 4 — 아무도 "왜"를 설명하지 않았다
코드를 보면서 이해가 안 가는 부분이 수십 개였다. 왜 이 API는 GET인데 body가 있지? 왜 이 컴포넌트는 렌더링할 때마다 API를 두 번 호출하지? 왜 이 값은 localStorage에 있고 저 값은 sessionStorage에 있지?
물어보고 싶었다. 그런데 무언의 분위기가 있었다. "이런 것도 모르나"라는 시선이 두려웠다. 그래서 혼자 파악하려다 반나절을 날렸다.
코드를 탐색하다가 이런 주석을 발견했다.
// 이거 건드리면 결제가 안 됩니다. 이유는 모르지만 절대 수정 금지
처음엔 웃겼다. 그리고 무서워졌다. 왜 건드리면 안 되는지 아무도 몰랐고, 그냥 신화처럼 전해져온 거였다. 팀에서 가장 오래된 선배한테 물어봤더니 "전 개발자가 퇴사하면서 말해줬는데 이제 기억이 잘..." 이라고 했다.
부트캠프에서는 "왜 이렇게 짜야 하는지"를 배웠다. 현실에서는 "왜 이렇게 짜여 있는지" 아무도 모르는 경우가 많았다. 그리고 그게 정상이었다.
충격 5 — 회의가 예상과 달랐다
입사 첫 주 금요일에 스프린트 계획 회의가 있었다. 처음 참석하는 팀 회의라 설레었다. 기술적인 토론이 있을 것 같았다. 어떤 아키텍처 결정이 있었고, 왜 이 방향을 택했는지 들을 수 있을 것 같았다.
실제 회의는 달랐다. 30분 내내 일정 조율이었다. "이거 이번 주에 가능해요?" "그럼 이거는 다음 주로?" PM과 팀장이 주도했고, 개발자들은 대부분 예상 공수를 숫자로 말하는 게 전부였다. 기술 이야기는 5분도 안 됐다.
기술 토론은 따로 없었다. 각자 맡은 걸 알아서 하는 구조였다. 팀에서 가장 나이 어린 신입인 내 의견을 구하는 시간은 없었다. 있어도 없는 존재 같은 느낌이었다.
그래서 어떻게 적응했나
충격을 받고 무너지면 안 됐다. 이게 현실이라면 현실에 맞게 적응해야 했다. 첫 달을 돌아보면 이 다섯 가지가 전환점이 됐다.
뭔가 만들려 하지 않았다. 레포의 폴더 구조, 자주 쓰이는 유틸 함수, API 호출 패턴을 파악하는 것에만 집중했다. 이해 안 되는 건 메모해뒀다가 선배한테 한꺼번에 질문했다. 뭉쳐서 물어보면 방해를 덜 끼쳤다.
없으면 만들었다. 내가 세팅하면서 막혔던 것들, 해결 방법, 주의사항을 노션에 정리해서 팀에 공유했다. 선배가 "이거 좋다, 앞으로 이걸 온보딩 문서로 쓰자"고 했다. 작은 기여였는데 팀에서 존재가 보이는 첫 번째 순간이었다.
"이 부분 어떻게 해야 하나요?"보다 "이 부분 이렇게 해봤는데 맞는 방향인지 봐주실 수 있어요?"가 더 잘 먹혔다. 선배의 시간을 덜 뺏는 질문 방식이었고, 내가 먼저 생각해봤다는 게 보였다.
처음엔 코드를 보면서 속으로 "왜 이렇게 짰지"라고 생각했다. 한 달이 지나니 그게 바뀌었다. 이 코드를 짠 사람은 그 당시의 상황에서 최선을 다했을 거라는 걸 알게 됐다. 레거시는 나쁜 개발자가 아니라 빠르게 변하는 비즈니스가 만든다.
입사 전 알았으면 좋았을 것들
이제 취준하거나 곧 입사하는 분들에게 말해주고 싶은 것들이다. 내가 첫 날 이걸 알았다면 덜 충격받았을 것이다.
회사 대부분이 그렇다. 특히 스타트업. 뭔가 세팅하다 막히면 내 잘못이 아닐 확률이 높다. 직접 문서를 만들어두면 동료들이 고마워한다.
"이거 어떻게 해요?"보다 "이렇게 해봤는데 이 부분이 막히는데 혹시 방향이 맞는지 확인해주실 수 있나요?"가 훨씬 잘 받아들여진다. 내가 먼저 시도한 흔적이 있으면 선배도 더 잘 도와준다.
빨리 기여하고 싶은 마음이 앞서면 기존 코드를 잘 모른 채 새 코드를 붙이는 실수가 생긴다. 코드 읽기에 첫 달을 써도 된다. 그게 오히려 빠른 길이다.
"이 코드 왜 이렇게 됐어요?"를 선배한테 물어볼 때 톤이 중요하다. 비판이 아니라 이해를 구하는 질문이어야 한다. 그 코드를 짠 사람이 아직 팀에 있을 수도 있다.
현실은 트레이드오프다. 항상 최선의 구조를 가질 수 없다. 마감이 있고, 리소스가 제한됐고, 기술 부채가 쌓인다. 그걸 이해하고 그 안에서 조금씩 나아지게 하는 게 진짜 실무다.
온보딩 문서 업데이트, 낡은 주석 수정, 타입 에러 하나 고치기 — 작아도 팀에 기여하는 게 보이면 달라진다. 큰 기능을 만들기 전에 작은 것부터 신뢰를 쌓아야 한다.
3개월이 지났을 때
어디에 뭐가 있는지 대략 알게 됐다. "이 기능은 저 쪽에 있을 것 같다"는 감이 생기기 시작했다.
어느 선배한테 어떤 걸 물어봐야 하는지 알게 됐다. 팀의 언어를 조금씩 이해하기 시작했다.
2,000줄 컴포넌트가 이제 "이런 거구나"로 바뀌었다. 여전히 이상적이지 않지만 무섭지는 않았다.
작은 리팩토링이었다. useState 이름을 더 명확하게 바꾼 것이 전부였다. 그게 그렇게 뿌듯했다.
입사 첫 날의 충격은 진짜였다. 기대와 현실의 간극이 컸고, 내가 준비됐다고 생각했던 것들이 생각보다 좁은 범위였다는 게 드러났다. 그런데 그 충격이 나쁜 것만은 아니었다. 그 간극을 채우는 과정에서 진짜 실무 감각이 생겼다.
부트캠프는 수영장에서 수영하는 법을 가르쳐준다. 회사는 바다다. 파도가 있고, 바닥이 보이지 않고, 조류가 있다. 그게 나쁜 게 아니라 그냥 다른 환경이다. 적응하면 바다에서 수영하는 게 수영장보다 재밌는 순간이 온다. 적어도 나는 그랬다.
괜찮다. 모르는 게 정상이고, 이해 안 가는 게 당연하고, 겁나는 게 맞다. 그 코드를 짠 선배들도 처음엔 똑같았다. 그냥 오늘 이해한 것 하나를 메모해두고, 내일 하나 더 이해하면 된다. 한 달이면 다르고, 세 달이면 또 다르다.
💬 신입 개발자 시절 가장 충격받았던 순간이 있나요?
입사 첫 날, 혹은 첫 달에 기대와 달라서 당황했던 경험 — 어떤 이야기든 댓글로 나눠주세요. 지금 취준 중이거나 곧 입사를 앞둔 분들에게 가장 현실적인 정보가 될 것 같습니다. 현직자 분들의 "그때 그랬지" 경험도 환영합니다.
'개발자 > 취업 커리어 입문' 카테고리의 다른 글
| 개발자 취업 준비 6개월, 실제로 공부한 것과 쓸모없었던 것 (0) | 2026.07.19 |
|---|---|
| 스타트업 vs 대기업, 첫 직장을 선택하며 고민한 것들 (0) | 2026.07.12 |
| 개발자 연봉 협상, 처음엔 이렇게 실패했다 (0) | 2026.07.05 |
| 포트폴리오 없이 신입 개발자로 합격한 방법 (1) | 2026.06.28 |
| 불합격 메일을 받던 날, 나는 무엇을 몰랐던 걸까 (0) | 2026.06.21 |
