입사 후 첫 6개월에 실제로 해야 하는 것 — 코드보다 맥락
신입이 초기에 막히는 지점은 대부분 기술이 아니라 맥락 부족이다. 단계별 목표 설정.
막히는 지점은 대개 기술이 아니다
입사 초기에 어려움을 겪는 이유를 실력 부족으로 돌리기 쉽지만, 실제로는 맥락 부족인 경우가 많다.
- 이 코드가 왜 이렇게 됐는지 모른다 (히스토리)
- 누구에게 물어야 하는지 모른다 (사람)
- 무엇이 중요한지 모른다 (우선순위)
- 어디까지 결정해도 되는지 모른다 (권한)
이 넷은 코드를 더 잘 짠다고 해결되지 않는다. 초기 목표를 여기에 맞추는 편이 효율적이다.
1개월 — 환경과 지도
목표: 혼자 개발 환경을 세우고 작은 변경을 배포까지 보낼 수 있다.
- 로컬 실행, 테스트 실행, 배포 절차를 한 번씩 끝까지
- 저장소 구조를 큰 덩어리로 파악 (모든 파일이 아니라 경계)
- 팀의 작업 흐름 파악 (이슈 → 브랜치 → PR → 리뷰 → 배포)
첫 PR은 작을수록 좋다. 오타 수정이나 문서 보완도 충분하다. 목적이 기여가 아니라 파이프라인 통과이기 때문이다.
2~3개월 — 한 영역 깊이 보기
목표: 한 기능 영역에 대해 질문에 답할 수 있다.
전체를 얕게 아는 것보다 한 곳을 깊이 아는 편이 초기에는 유리하다. 그 영역이 팀 안에서의 첫 자리가 된다.
읽는 방법:
- 진입점(API 핸들러·화면 컴포넌트)에서 시작
- 호출을 따라 아래로 내려간다
- 이해 안 되는 부분에 물음표를 남기고 계속 간다
- 한 바퀴 돈 뒤 물음표를 모아서 한 번에 질문
처음부터 모든 걸 이해하려고 멈추면 진도가 안 나간다.
4~6개월 — 판단이 필요한 일
목표: 작업을 받았을 때 접근 방식을 스스로 제안할 수 있다.
이 단계에서 달라지는 것은 "어떻게 구현할까"가 아니라 "무엇을 만들지 확인하는 것"이다.
- 요구사항의 모호한 부분을 먼저 질문한다
- 두 가지 방식이 있으면 트레이드오프를 정리해 제안한다
- 예상 소요를 말하고, 어긋나면 일찍 알린다
세 번째가 특히 중요하다. 늦어지는 것보다 늦어질 것 같다고 늦게 말하는 것이 문제가 된다.
질문하는 방식
질문을 참는 것과 바로 묻는 것 사이의 기준이 필요하다. 흔히 쓰는 방식은 시간 상한이다.
```
30분 시도 → 그래도 막히면 질문
```
질문할 때는 시도한 것을 함께 정리한다.
```
X를 하려는데 Y에서 막혔습니다.
- A 방법 시도 → B 오류
- 문서 C 확인 → 해당 케이스 없음
- 관련 코드 D 확인 → 여기서 E로 보이는데 맞을까요?
```
이 형식이면 답하는 쪽의 비용이 크게 줄고, 답도 정확해진다.
초기에 남기면 좋은 것
온보딩하며 겪은 것을 기록해두면 두 가지로 쓰인다.
- 자신용: 같은 문제를 반복해서 겪지 않는다
- 팀용: 다음 입사자의 온보딩 문서가 된다
특히 "문서에 없어서 물어봐야 했던 것"을 모으면 그대로 문서 개선 항목이 된다. 신입만 볼 수 있는 것이라 초기에만 가능한 기여다.
하지 않아도 되는 것
- 전체 코드베이스 통독 — 대부분 다 못 읽고 지친다
- 모든 기술 스택 선행 학습 — 실제로 쓰는 부분부터 배우는 편이 빠르다
- 조용히 오래 붙들기 — 막힌 시간이 길수록 팀 전체 손해가 커진다
최종 수정 2026-08-28