1장. 첫 출근, 코드보다 더 중요한 것들
처음 출근하는 날, 우리는 설렘과 긴장을 동시에 안고 현관문을 나선다.
출근길의 사람들은 다들 바빠 보이고, 지하철의 창밖 풍경은 유난히 낯설게 느껴진다. 신입 개발자라는 이름은 마치 어색한 옷처럼 아직 내게 잘 맞지 않는다.
어쩌면 당신은 지금도 코드에는 자신이 있다. 학교에서, 독학으로, 부트캠프에서 수많은 프로젝트를 해냈고, 밤새 디버깅하며 문제를 풀던 시간도 있다. 그런데 막상 첫 회사에 들어오니, 이상하게도 코드보다 더 당황스러운 것들이 많다.
누구에게 물어봐야 할지 모르겠고, 동료들의 대화는 마치 다른 언어처럼 들린다. 코드를 짜기도 전에, 회의에 들어가고, Jira를 보고, 릴리즈 일정을 확인하고… 분명 개발자로 입사했는데, 개발 이외의 것들이 머릿속을 어지럽힌다.
그리고 그 순간, 우리는 깨닫게 된다.
직장이라는 곳은 단순히 ‘개발’만 하는 곳이 아니라는 것을.
‘개발’은 학교에서 배운 지식이지만, ‘일’은 현장에서 배워야 한다.
많은 신입 개발자들이 착각하는 것이 있다.
“코드만 잘 짜면 된다.”
물론 맞는 말이다. 하지만 불완전하다. 현실에서 코드는 ‘혼자’가 아니라 ‘팀’으로 완성된다.
개발자가 하는 일은 단순히 기능을 구현하는 것이 아니다.
기획자의 요구사항을 해석하고, 디자이너와 조율하고, 다른 개발자와 코드를 나눠 짜고, QA의 피드백을 반영하며, 운영 중인 시스템에 최소한의 리스크로 반영한다.
이 일련의 과정은 협업 없이는 불가능하다.
그리고 이 모든 과정에서 중요한 건, 코드 그 자체보다, 맥락을 이해하는 능력이다.
기능의 목적은 무엇인지, 왜 이 시점에 이 기능을 만드는지, 사용자에게 어떤 영향을 줄 수 있는지를 이해해야 한다. 개발자는 결국 비즈니스의 언어를 코드로 번역하는 사람이기 때문이다.
‘노트북은 뭘 가져가야 하지?’
‘코딩 테스트는 끝났는데 또 뭘 시험하진 않겠지?’
‘다들 어떤 옷 입고 있지?’
첫 출근을 앞두고 수많은 걱정이 머릿속을 스친다. 사실 대부분은 기우다. 하지만 미리 알고 준비하면 훨씬 편안해지는 것들이 있다. 다음은 첫 출근 전에 꼭 확인해 두면 좋은 사항들이다.
노트북이 지급되는지 vs 개인 장비를 사용하는지 확인하기
IDE, Git, VPN, 사내 메신저 등 기초적인 툴 설치 여부
계정 세팅이 필요한 툴들 목록 받아보기 (Jira, Confluence, Notion 등)
리눅스 계정/서버 접근 권한 등 설정 관련 사전 안내 요청하기
첫날 Onboarding 일정이 있는지 확인
멘토나 배정된 매니저가 있는지
사내 메신저(슬랙, 잔디 등)에서 누구에게 먼저 인사하면 좋을지 알아두기
복장은 정장이 기본인지, 캐주얼 OK인지 확인 (슬랙 예의상 물어봐도 됨)
출근 시간 및 점심 식사/회의 여부 체크
사무실 출입 방식, 게이트, 보안카드 관련 안내
그리고 하나 더.
자기소개 한 줄 정도는 준비해 두자.
“어떤 개발자이고 싶은지”, “무엇을 잘하고 싶은지”를 짧게 말할 수 있다면, 동료들이 당신을 기억해주는 속도가 훨씬 빨라진다.
요즘 채용공고를 보면, '최신 맥북', '자율 출근제', '간식 무제한', '사내 스터디 지원' 같은 문구들이 눈에 띈다.
물론 이런 복지는 중요하다. 하지만 그것만 보고 입사하면 진짜 중요한 걸 놓치기 쉽다.
개발자에게 가장 중요한 복지는 다음과 같은 것들이다.
명확한 업무 범위와 책임선
→ 내 일과 팀의 일이 구분되지 않으면, 신입은 책임을 떠안기 쉽다.
성장에 대한 피드백
→ 코드 리뷰, 1on1 미팅, 성과 평가가 투명하게 이뤄지는가?
문제가 생겼을 때 탓보다는 해결을 우선하는 문화
→ 실수를 했을 때 어떻게 반응하는지 보면 조직의 민낯이 보인다.
팀워크 기반의 개발 프로세스
→ 협업과 문서화, 리뷰 문화가 정착되어 있는지 확인해보자.
복지는 단순히 ‘지급되는 것’이 아니라, 일하는 방식을 얼마나 건강하게 만들 수 있느냐의 문제다.
좋은 회사는 단지 돈을 많이 주는 곳이 아니라, 좋은 개발자로 오래 살아남을 수 있게 해주는 곳이다.
많은 신입 개발자들이 말한다.
“코드만 잘 짜면 되지, 도메인까지 알아야 하나요?”
이 질문에 대한 답은 명확하다.
“좋은 코드와 쓸모 있는 코드는 다릅니다.”
업무에서 다루는 도메인을 이해하지 못하면, 맥락 없는 구현만 반복하게 된다.
예를 들어 보험 도메인을 모르면, '납입주기'와 '보험종목' 사이의 관계가 얼마나 민감한지를 이해하기 어렵다.
결과적으로 ‘돌아가는 코드’를 만들 수는 있어도, 실제로 문제를 해결하는 코드는 만들기 어렵다.
도메인 지식을 빠르게 익히는 법:
사내 위키/문서에서 비즈니스 흐름을 먼저 읽자.
사용자가 누구인지, 어떤 목적을 가지고 쓰는지 목표를 파악하자.
기획자나 팀 리더에게 왜 이 기능을 개발하는지 물어보자.
도메인을 이해한 개발자는 회사에 필수적인 존재가 된다.
그리고 그런 개발자에게는 기획이나 전략에 더 깊이 참여할 기회가 주어진다.
개발자로 사회에 첫발을 디딘다는 건, 코드를 짜는 사람이 된다는 의미만은 아닙니다.
팀의 일원이 되고, 조직의 문화를 배우고, 사용자와 문제를 연결짓는 다리가 되는 일입니다.
코드를 넘어 ‘일’을 이해하는 사람, ‘맥락’을 짚어내는 사람, 그리고 ‘협업’하는 사람.
그런 개발자가 되기 위한 첫걸음, 지금부터 함께 시작해 봅시다.