개인 프로젝트와 클론 코딩으로 포트폴리오를 채우고, 마침내 받아낸 합격 목걸이. 첫 출근 날 자리에 앉아 지급받은 맥북을 열 때까지만 해도 자신감이 넘쳤습니다.
하지만 실무의 벽은 높았습니다. 깔끔하게 정돈된 강의 속 코드와 달리 수만 줄의 레거시 코드가 얽혀 있었고, 에러 로그는 제 예상 범위를 번번이 벗어났습니다. 입사 첫 달, 저는 제가 ‘코더’는 될 수 있어도 아직 ‘개발자’는 아니라는 사실을 뼈저리게 깨달았습니다.
오늘은 부트캠프나 책에서는 알려주지 않는, 제가 첫 회사에서 직접 부딪히고 깨지며 배운 5가지 실수와 10가지 생존 팁을 솔직하게 공유해 보려 합니다.
1. “혼자 해결해야 인정받겠지?” (질문의 타이밍)
신입 시절 가장 많이 했던 착각입니다. 모르는 것을 물어보면 실력이 없다고 생각할까 봐 혼자서 구글링과 스택오버플로우를 전전하며 하루를 통째로 날린 적이 있습니다. 결국 마감일이 되어서야 사수에게 SOS를 쳤고, 사수는 단 5분 만에 해결책을 찾아주었습니다. 그때 들었던 피드백을 잊지 못합니다. “개발은 혼자 하는 게 아니라 팀으로 하는 겁니다.”
💡 생존 팁 1 & 2
- Tip 1. 타임박싱(Timeboxing) 도입하기: 혼자 고민하는 시간의 마지노선을 ‘2시간’으로 정하세요. 그 시간이 넘어가면 무조건 팀원이나 사수에게 질문해야 합니다.
- Tip 2. 질문 템플릿 만들기: 그냥 “이거 안 돼요”가 아니라,
[현재 상황] - [시도해 본 방법] - [의심되는 원인]순서로 정리해서 질문하세요. 질문을 정리하는 과정에서 스스로 답을 찾는 경우도 많습니다.
2. Happy Path만 고려한 코딩 (예외 처리 누락)
데이터가 완벽하게 들어오고, 사용자가 기획 의도대로만 클릭할 것이라는 순진한 생각으로 코드를 짰습니다. 하지만 실무(Production) 환경에서 사용자는 예상치 못한 행동을 하고, 서버는 가끔 응답하지 않습니다. 데이터가 빈 배열로 오자마자 화면이 하얗게 변하는 ‘화이트 아웃’ 현상을 겪고 나서야 방어적 프로그래밍의 중요성을 알았습니다.
💡 생존 팁 3 & 4
- Tip 3. 에러/로딩 UI를 먼저 고민하기: 데이터가 정상적으로 렌더링 되는 화면보다, 로딩 중일 때(Skeleton UI)와 에러가 났을 때(Fallback UI)의 화면을 먼저 세팅하는 습관을 들이세요.
- Tip 4. 옵셔널 체이닝(?.)과 기본값 생활화: API 응답 값은 언제든 바뀔 수 있습니다.
user?.profile?.image || 'default.png'처럼 방어적으로 접근하세요.
3. “내 스타일이 더 세련됐는데?” (컨벤션 무시)
입사 초기, 저는 최신 문법과 제가 익숙한 폴더 구조를 고집했습니다. 기존 코드 베이스가 낡아 보였기 때문입니다. 하지만 제 코드가 섞이자 프로젝트의 통일성이 깨졌고, 다른 팀원들이 제 코드를 유지보수하기 힘들어졌습니다. 좋은 코드란 화려한 코드가 아니라 ‘예측 가능한 코드’라는 것을 배웠습니다.
💡 생존 팁 5 & 6
- Tip 5. 팀의 컨벤션이 곧 법이다: ESLint, Prettier 설정은 물론, 변수명 짓는 규칙(Naming Convention)이나 폴더 구조는 무조건 기존 팀의 룰을 따르세요.
- Tip 6. 커밋 메시지도 커뮤니케이션:
fix: 버그 수정처럼 대충 적지 마세요. 왜 수정했는지, 어떤 이슈와 연결되는지(Issue #123) 명확히 남겨야 나중에 롤백할 때 단서가 됩니다.
4. 개발 용어로만 소통하려 했던 태도
기획자나 디자이너가 무리한 요구를 할 때, “그건 비동기 통신 라이프사이클 때문에 렌더링 단에서 블로킹이 걸려서 안 됩니다”라고 말했습니다. 상대방은 당연히 이해하지 못했고 감정만 상했습니다. 타 직군과의 원활한 소통 능력이 프론트엔드 개발자의 핵심 역량임을 깨닫는 순간이었습니다.
💡 생존 팁 7 & 8
- Tip 7. 일상 언어로 번역해서 말하기: “서버에서 데이터를 가져오는 동안 화면이 멈춰 보일 수 있어서, 부드럽게 넘어가는 다른 방식을 제안해 드려도 될까요?”처럼 사용자 경험(UX) 관점에서 설명하세요.
- Tip 8. ‘안 된다’고 하기 전에 대안 제시: 무작정 안 된다고 하기보다, “그 기능은 일정상 A 방식으로 구현하면 이번 주 내로 가능한데 어떠신가요?”라고 선택지를 드리세요.
5. 일정보다 완벽함을 추구한 오버 엔지니어링
재사용성을 높이겠다고 컴포넌트를 너무 잘게 쪼개고 추상화하느라 정작 배포 기한을 맞추지 못할 뻔했습니다. 스타트업이나 실무 환경에서는 ‘완벽한 코드’보다 ‘일정에 맞춰 동작하는 프로덕트’가 훨씬 중요합니다.
💡 생존 팁 9 & 10
- Tip 9. 일단 돌아가게 만들 것 (MVP 마인드): 처음부터 예쁘게 짜려고 하지 마세요. 일단 요구사항을 충족하는 동작하는 코드를 먼저 만들고, 남는 시간에 다듬는 것이 안전합니다.
- Tip 10. 리팩토링은 PR(Pull Request) 직전에: 기능 구현이 끝났다면, 내가 짠 코드를 제3자의 시선으로 다시 읽어보며 불필요한 콘솔 로그(console.log)를 지우고 변수명을 다듬은 뒤 리뷰를 요청하세요.
주니어의 가장 큰 무기는 ‘성장하는 태도’입니다
돌이켜보면 실수는 부끄러운 것이 아니었습니다. 실무 경험이 없는 신입이 에러를 내고 헤매는 것은 당연합니다. 진짜 문제는 같은 실수를 반복하거나, 모르는 것을 아는 척하고 넘어가는 태도입니다.
오늘 하루 작성한 코드가 마음에 들지 않더라도 너무 자책하지 마세요. 매일 발생한 에러와 해결 과정을 개인 블로그나 노션(Notion)에 ‘성장일지’로 꼼꼼히 기록해 두시길 바랍니다. 그 기록들이 1년 뒤, 여러분을 한 명의 든든한 프론트엔드 개발자로 만들어줄 가장 훌륭한 포트폴리오가 될 것입니다.
새로운 시작을 앞둔 모든 주니어 개발자분들의 첫걸음을 응원합니다!
