주니어 때 알았으면 좋았을 개발 습관 5가지

개발자 현직자 솔직 경험담

주니어 때 알았으면 좋았을
개발 습관 5가지

3년 뒤에 후회한 것들 — 1년 차 나에게 가장 해주고 싶은 말

Frontend Developer 3~4년차 2026년 6월 약 14분 읽기

3년 전 나한테 편지를 쓴다면

주니어 1년 차 때 가장 많이 들었던 말은 "코드가 동작하면 된 거 아니야?"였다. 나도 그렇게 생각했다. 기능이 돌아가면 일을 한 거라고. 그 생각이 3년 동안 나를 얼마나 느리게 성장시켰는지 지금은 안다.

코드 리뷰를 받으면서, 내가 1년 전에 짠 코드를 다시 읽으면서, 동료의 PR을 보면서 — 천천히 알게 됐다. 좋은 개발자가 되는 것은 기술을 많이 아는 것이 아니라 좋은 습관이 몸에 배어 있는 것이라는 걸. 지금 소개하는 5가지는 "진작 알았으면"이 가장 많이 나온 것들이다.

주니어 때 알았으면 좋았을 개발 습관 5가지

3년 회고 기간

5가지 핵심 습관

1년차 이 글이 필요한 시점

지금도 연습 중인 것들

01

Habit 1 — 가장 먼저 바꿔야 할 것

커밋 메시지를 제대로 쓴다

중요도

⭐⭐⭐⭐⭐

주니어 때 커밋 메시지를 "fix", "update", "수정", "작업"으로 썼다. 그날 뭘 바꿨는지 기억하면 되지라고 생각했다. 3개월 뒤에 그 코드를 다시 봤을 때 이 커밋이 왜 생겼는지 전혀 알 수 없었다. 더 나쁜 건 팀원도 그 이유를 물어봐야 알 수 있었다는 것이다.

❌ 주니어 때

fix
update
수정
작업중
asdf

✅ 지금

fix: 결제 버튼 더블클릭 방지 처리
feat: 이력서 PDF 다운로드 기능 추가
refactor: 인증 로직 커스텀 훅으로 분리
perf: 이미지 lazy loading 적용

좋은 커밋 메시지는 "무엇을 바꿨는가"보다 "왜 바꿨는가"를 담는다. Conventional Commits 형식을 쓰면 타입(feat/fix/refactor/perf/docs)으로 변경의 성격을 바로 알 수 있다. 팀에서 형식을 강제하지 않아도 혼자서라도 지키면 6개월 뒤 내가 고맙다고 할 것이다.

✅ Conventional Commits 형식 — 실제 사용 예시

# 형식: <type>(<scope>): <subject>
feat(auth): 소셜 로그인 구글 OAuth 연동 fix(payment): 결제 금액 소수점 반올림 오류 수정 refactor(user): useUserProfile 커스텀 훅으로 추출 perf(image): Next.js Image 컴포넌트로 교체, LCP 개선 docs(readme): 로컬 개발 환경 세팅 가이드 추가 test(cart): 장바구니 수량 변경 단위 테스트 추가
# 본문에 WHY를 적는 습관 fix(checkout): 쿠폰 중복 적용 방지 처리
쿠폰 코드를 빠르게 클릭하면 동일 쿠폰이 두 번 적용되는 레이스 컨디션 발생. isApplying 플래그로 중복 호출 방어.

💡 지금 바로 시작하는 방법

커밋할 때 "이 커밋 메시지를 3개월 뒤 나 또는 팀원이 보면 이해할 수 있나?"를 한 번 생각해본다. 이 질문 하나가 커밋 메시지 품질을 바꾼다.

02

Habit 2 — 가장 체감이 컸던 것

PR 올리기 전에 내가 먼저 리뷰한다

중요도

⭐⭐⭐⭐⭐

주니어 때 PR을 올리는 순서가 이랬다. 기능을 만든다 → 대충 동작 확인한다 → 바로 PR 올린다 → 팀원이 리뷰한다. 팀원의 리뷰 코멘트 중 50%가 "이건 혼자 봤으면 알 수 있었을 것들"이었다. 오타, console.log 제거 안 함, 불필요한 주석, 개발 환경에서만 되는 로직.

📍 실제로 있었던 리뷰 코멘트

"console.log가 17개 있어요" / "이 변수명 오타인 것 같아요" / "개발 URL이 하드코딩돼 있어요" / "이 코드 push 전에 빼신 거 맞죠?" — 이 코멘트들은 전부 내가 한 번만 읽어봤으면 발견할 수 있었다. 팀원의 리뷰 시간을 낭비한 것이었다.

지금은 PR을 올리기 전에 내가 먼저 Diff를 끝까지 읽는다. 파일 하나씩, 라인 하나씩. 부끄러운 것들이 보인다. 그것들을 고치고 올린다. 팀원 리뷰에서 나오는 코멘트가 절반으로 줄었다. 팀원의 시간을 아끼는 것이 곧 팀 전체의 생산성이다.

❌ 셀프 리뷰 없이 PR

평균 리뷰 코멘트 12개
console.log 방치
오타, 하드코딩
팀원 시간 낭비
리뷰가 느려짐

✅ 셀프 리뷰 후 PR

평균 리뷰 코멘트 5개
명백한 실수 사전 제거
PR 설명이 더 명확해짐
리뷰 사이클이 짧아짐
팀원 신뢰도 올라감

✅ PR 올리기 전 체크리스트

console.log 전부 제거 / 하드코딩된 값 환경변수로 / 오타 확인 / 불필요한 주석 삭제 / 빠진 파일 없는지 / Diff 전체 한 번 읽기. 이 6가지만 해도 PR 품질이 달라진다.

03

Habit 3 — 가장 늦게 깨달은 것

막히면 30분 룰 — 시간을 정해두고 찾고, 넘으면 묻는다

중요도

⭐⭐⭐⭐

주니어 때는 두 가지 극단 중 하나였다. 막히면 바로 물어보거나, 물어보기 창피해서 3시간을 혼자 씨름하거나. 둘 다 좋지 않았다. 바로 물어보면 스스로 생각하는 능력이 안 생기고, 너무 오래 혼자 하면 시간을 낭비한다.

📍 3시간 혼자 씨름한 적이 있었다

API 응답이 이상하게 왔다. 혼자 3시간 디버깅했다. 결국 선배한테 물어봤다. 5분 만에 해결됐다. 선배가 "이런 건 빨리 물어보는 게 낫다"고 했다. 그때 '30분 룰'을 알게 됐다. 30분 동안 혼자 고민하고, 해결 안 되면 질문한다. 이게 생각보다 많은 것을 바꿨다.

30분 룰의 핵심은 질문하는 방식에 있다. 30분 동안 고민하면서 "무엇을 시도했는지", "어디까지 파악했는지"가 쌓인다. 그걸 갖고 물어보면 훨씬 구체적인 질문이 된다. "이거 왜 안 돼요?"가 아니라 "A를 시도했는데 B 에러가 나고, 원인이 C인 것 같은데 맞는지 확인해주실 수 있나요?"가 된다. 이 질문의 질 차이가 성장 속도를 만든다.

💡 좋은 질문의 구조 — 30분 고민 후에 이렇게 묻는다

# ❌ 나쁜 질문 "이 코드 왜 에러 나요?" "API 호출이 안 돼요"
# ✅ 좋은 질문 구조 상황: "결제 완료 후 주문 내역 API가 403을 반환해요" 시도한 것: "Authorization 헤더 확인, 토큰 만료 여부 확인, 네트워크 탭에서 요청 확인했어요" 파악한 것: "토큰은 유효한데 권한 문제인 것 같아요" 질문: "이 엔드포인트에 별도 역할 권한이 필요한지 백엔드 설정 확인 부탁드릴 수 있을까요?"
# 이 구조로 물어보면 답을 받는 속도가 달라진다

⚠️ 30분 룰이 안 되는 상황

운영 장애나 배포 블로킹 상황에서는 30분을 기다리지 않는다. 영향 범위가 크거나 팀 전체가 멈추는 상황이면 바로 알린다. 30분 룰은 개인 개발 중 막혔을 때의 기준이다.

04

Habit 4 — 팀에서 가장 드러나는 것

작업 중 막히거나 달라지면 먼저 말한다

중요도

⭐⭐⭐⭐

주니어 때 가장 자주 들었던 피드백 중 하나가 "미리 알려줬으면 좋았을 텐데"였다. 일정이 밀릴 것 같은데 말을 못 했다. API 스펙이 바뀌었는데 혼자 해결하려다 늦어졌다. 예상보다 복잡한 작업인데 혼자 씨름했다. 결국 데드라인 당일에 "사실 안 됐어요"를 말하게 됐다.

팀에서 "말 안 하는 것"이 가장 나쁜 신호다. 막혀 있는 걸 말하는 게 부끄러운 게 아니다. 막혀 있는데 말 안 하는 게 문제다. 팀원이나 리드는 미리 알면 도울 수 있고, 일정을 조정할 수 있다. 당일에 알면 선택지가 없다.

❌ 말 안 했을 때

혼자 해결하려다 더 늦어짐
팀이 모르니 대응 못 함
마감 당일 "안 됩니다"
신뢰가 떨어짐
팀 전체 일정이 흔들림

✅ 미리 말했을 때

팀이 미리 대응 가능
리드가 해결책 제시
일정 조정 여유 생김
책임감 있다는 인상
팀 신뢰가 쌓임

📍 미리 말하는 것이 어떻게 달라지는지

"이 작업이 예상보다 복잡해서 목요일까지는 어려울 것 같아요. 금요일까지는 될 것 같은데 일정 조정 가능한지 확인해주실 수 있을까요?" — 이 한 마디가 마감 당일 "안 됩니다"보다 100배 낫다. 그리고 이걸 잘 하는 사람이 팀에서 신뢰받는다.

💡 말하는 타이밍

일정의 20%를 쓰고도 예상 대비 진행이 절반 이하면 말할 타이밍이다. 3일짜리 작업이면 첫날 오후쯤 "생각보다 시간이 더 걸릴 것 같다"를 알리는 것이 맞다.

05

Habit 5 — 3년 후 가장 체감하는 것

배운 것을 기록한다 — 형식에 상관없이

중요도

⭐⭐⭐⭐⭐

주니어 때 배운 것을 기록하지 않았다. 머릿속에 있으면 된다고 생각했다. 3개월 지나니 기억이 안 났다. 6개월 전에 해결했던 문제를 또 검색하고 있었다. 1년이 지나니 "분명히 한 번 풀었는데"가 반복됐다.

기록의 형식은 중요하지 않다. 노션, 마크다운 파일, 블로그, 심지어 GitHub Issues도 된다. 중요한 건 "나중에 내가 찾을 수 있는 곳에 적는다"는 것이다. 완벽하게 정리하려다 아무것도 안 적는 것보다, 핵심만 3줄 적는 게 낫다.

❌ 기록 안 했을 때

3개월 뒤 같은 검색 반복
해결했던 문제 또 삽질
성장이 눈에 안 보임
이직 시 경험 정리 어려움
기술 면접에서 막힘

✅ 기록했을 때

내 검색 엔진이 생김
같은 실수 반복 안 함
성장이 로그로 쌓임
이력서·포트폴리오 재료
블로그로 브랜딩 가능

📝 내가 쓰는 TIL 기록 템플릿 — 3분이면 작성 가능

## 2026-06-15
### 문제 Next.js App Router에서 서버 컴포넌트가 쿠키를 읽지 못하는 문제
### 원인 cookies()는 동적 함수라 정적 렌더링 불가. force-dynamic 또는 noStore() 필요
### 해결 export const dynamic = 'force-dynamic' 또는 headers()나 cookies()를 쓰면 자동 dynamic
### 참고 https://nextjs.org/docs/app/building.../cookies
### 교훈 서버 컴포넌트에서 요청 기반 데이터를 읽을 때는 렌더링 방식 확인이 먼저
# 이것만 적어도 3개월 뒤 나한테 큰 도움이 된다

✅ 기록 습관을 만드는 가장 쉬운 방법

일하다 막혔다 해결되는 순간이 기록 타이밍이다. 해결하고 난 직후 3분 동안 "문제 / 원인 / 해결"만 적는다. 3분이 나중에 3시간을 아낀다.

5가지 한눈에 보기 — 난이도와 임팩트

습관

시작 난이도

장기 임팩트

① 커밋 메시지 제대로 쓰기

쉬움

매우 높음

② PR 올리기 전 셀프 리뷰

쉬움

매우 높음

③ 30분 룰 — 막히면 시간 정해두고

보통

높음

④ 막히면 먼저 말하기

어려움

매우 높음

⑤ 배운 것 기록하기

보통

매우 높음

이 5가지 중 하나도 기술이 아니다. 전부 태도와 습관이다. 기술은 배우면 되지만, 나쁜 습관은 고치는 데 훨씬 오래 걸린다. 주니어 때 좋은 습관을 만드는 게 3년 뒤 내 성장 속도를 결정한다.

한 번에 다 바꾸려 하지 않아도 된다

이 5가지를 동시에 시작하면 부담스럽다. 하나씩 하면 된다. 오늘 당장 할 수 있는 가장 쉬운 것부터. 커밋 메시지 형식을 바꾸는 건 지금 당장 시작할 수 있다. 셀프 리뷰는 다음 PR부터 적용하면 된다.

습관이 된다는 건 "의식하지 않아도 자연스럽게 하게 되는" 상태다. 그 상태까지 가려면 의식적인 반복이 필요하다. 처음엔 어색하고 번거롭다. 2~3주가 지나면 안 하는 게 이상해진다. 그게 습관이 된 것이다.

3년 전 나한테 이 글을 보여줄 수 있다면 좋겠다. 그럴 수 없으니 지금 읽고 있는 분들에게 대신 전한다. 지금 시작하면 3년 뒤의 당신이 고마워할 것이다.

💬 주니어 때 알았으면 좋았을 습관이 있으신가요?

내가 꼽은 5가지 외에도 "진작 이걸 알았으면"이라고 생각한 개발 습관이 있다면 댓글로 나눠주세요. 지금 주니어인 분들에게 가장 현실적인 조언이 될 것 같습니다.