어느 날 팀에 새로 입사한 신입 개발자가 저한테 물어봤습니다.
"선배님, 처음에 어떻게 버티셨어요?"
그 말을 듣고 잠깐 멍하게 있었습니다. 버텼다는 표현이 맞는 건지, 아니면 그냥 흘러가다 보니 여기까지 온 건지 잘 모르겠지만, 분명한 건 1년차 때와 지금은 많이 다르다는 거였습니다. 코드를 대하는 방식도, 동료를 대하는 방식도, 나 자신을 대하는 방식까지도요.
이 글은 "3년 만에 이렇게 성장했습니다" 같은 성공 스토리가 아닙니다. 그냥 솔직하게, 달라진 것들을 짚어보는 글입니다. 지금 1년차를 보내고 있는 분들, 혹은 내가 제대로 가고 있는 건지 불안한 분들에게 조금이나마 도움이 됐으면 합니다.
① 코드보다 '맥락'을 먼저 보게 됐다
1년차 때는 일단 코드를 짜고 싶었습니다. 기획이 내려오면 "이거 어떻게 구현하지?" 가 먼저였어요. Jira 티켓을 열면 반사적으로 IDE를 켰고, 빠르게 구현해서 PR을 올리는 게 곧 잘하는 개발자라고 믿었습니다.
기능 완성 = 성공
빠른 PR이 곧 실력
기능 완성은 시작일 뿐
느린 PR이 결국 빠른 배포
3년차쯤 되니까, 기획서를 보면 코드보다 질문이 먼저 떠오릅니다. "이 기능이 정말 필요한 건가?", "엣지케이스는 어떻게 처리하기로 한 건가?", "백엔드 API는 이 형태로 내려오는 게 맞나?" 같은 것들이요. 처음에는 이런 질문을 하면 진행이 느려진다고 생각했는데, 오히려 반대였습니다. 질문 하나가 이틀치 재작업을 막아주는 경우가 꽤 있었거든요.
② 에러 메시지가 더 이상 무섭지 않다
솔직히 말하면, 1년차 때 빨간 에러 메시지를 보면 심장이 쿵 내려앉았습니다. 특히 운영 환경에서 뭔가 터졌다는 연락이 오면, 뭘 어디서부터 봐야 하는지도 모르고 그냥 멘탈이 흔들렸어요. 에러를 만나면 일단 구글링부터 했고, 스택오버플로우 첫 번째 답변을 그대로 붙여넣는 일도 종종 있었습니다.
"왜 되는지 모르겠지만, 일단 됩니다." — 1년차 나의 PR 코멘트
지금은 다릅니다. 에러 메시지를 보면 그 안에 꽤 많은 정보가 있다는 걸 알아서인지, 오히려 단서처럼 느껴집니다. Network 탭을 먼저 보는 습관, console에 어떤 시점에 어떤 로그를 찍을지 아는 감각, 그리고 무엇보다 "이게 내 코드 문제인지, 서버 문제인지, 아니면 환경 문제인지"를 빠르게 좁히는 능력이 생겼습니다.
이게 갑자기 생긴 게 아닙니다. 그냥 수백 번 에러를 만나다 보면 생기는 거더라고요. 결국 에러 디버깅 실력은 경험의 함수였습니다.
③ 코드 리뷰를 대하는 태도가 달라졌다
1년차 때는 코드 리뷰가 솔직히 좀 무서웠습니다. 내가 짠 코드에 코멘트가 달리면 "내가 틀렸다"는 느낌이 들었고, 특히 시니어 개발자한테 여러 개 코멘트를 받으면 은근 자존심이 상하기도 했습니다. 리뷰어가 코멘트를 많이 달수록 내가 못하는 거라고 생각했거든요.
최대한 빨리 resolved
"수정했습니다" 한 마디로 끝
왜 그런 피드백인지 먼저 이해
필요하면 내 의도를 설명하고 토론
지금은 오히려 코멘트가 많이 달리는 PR이 좋은 PR이라고 생각합니다. 팀원들이 코드를 꼼꼼히 봤다는 뜻이니까요. 그리고 리뷰를 하는 쪽도 경험해보니, 코멘트 하나하나에는 나름의 이유가 있습니다. "왜 이렇게 수정하라고 하는 건지"를 이해하려는 자세가 생기고 나서, 배우는 속도가 확실히 빨라졌습니다.
④ '모른다'고 말하는 게 편해졌다
이게 사실 가장 크게 달라진 부분입니다. 1년차 때는 "모른다"는 말을 정말 하기 싫었습니다. 모르면 무능해 보일까봐, 질문을 하면 민폐가 될까봐, 어떻게든 혼자 해결하려고 몇 시간을 붙잡고 있었습니다. 그러다 결국 못 풀면 더 늦게 물어보고, 그 사이에 일정이 밀리는 악순환이 반복됐어요.
지금은 30분 정도 혼자 고민해보고 안 풀리면 바로 물어봅니다. "이 부분 제가 이렇게 이해하고 있는데 맞나요?", "이 케이스에서는 어떤 방향이 나을 것 같으세요?" 이런 식으로요. 그리고 신기하게도, 모른다고 솔직하게 말하는 사람을 팀에서 답답하게 보지 않습니다. 오히려 소통이 잘 된다는 인상을 주더라고요.
⑤ 기술보다 '사람'이 더 중요하다는 걸 알았다
1년차 때는 기술 스택이 전부인 줄 알았습니다. 어떤 프레임워크를 쓰는지, 어떤 라이브러리가 요즘 핫한지, TypeScript 타입을 얼마나 잘 쓰는지 같은 게 개발자의 실력을 정의한다고 생각했습니다.
틀린 말은 아닙니다. 기술은 분명 중요합니다. 그런데 몇 년을 지내다 보니, 좋은 개발자와 훌륭한 개발자의 차이는 기술 실력이 아닌 경우가 많았습니다. 기획자가 전달하는 의도를 정확하게 파악하는 능력, 디자이너와 UI 스펙을 맞춰가는 과정에서 오해를 줄이는 능력, 팀원의 코드를 리뷰할 때 비판보다 제안의 언어를 쓰는 능력 — 이런 것들이 프로젝트의 완성도에 훨씬 더 큰 영향을 미쳤습니다.
- 기획자와 이야기할 때 — 기술 용어를 쓰지 않고 결과물로 설명하는 연습을 해보세요
- 디자이너와 이야기할 때 — "이건 구현이 어렵다"보다 "이렇게 하면 어떨까요?"를 먼저 꺼내보세요
- 팀원 코드 리뷰 시 — "이건 틀렸어요"보다 "이 방향은 어떻게 생각하세요?"가 훨씬 효과적입니다
- 윗선에 보고할 때 — 과정보다 결과와 영향도를 중심으로 이야기하세요
⑥ 완벽한 코드보다 '동작하는 코드'를 먼저 생각한다
이건 약간 역설적으로 들릴 수 있습니다. 3년차가 되면서 오히려 완벽주의가 줄었거든요. 1년차 때는 변수명 하나, 함수 분리 하나에 엄청 고민했습니다. "이게 클린 코드가 맞나?" 하면서 한 줄짜리 수정에 한 시간을 쓰기도 했어요.
지금은 순서가 다릅니다. 일단 동작하게 만들고, 그다음에 정리합니다. 완벽하게 짜려다가 아무것도 못 짜는 것보다, 동작하는 코드를 만들어놓고 리팩터링하는 게 훨씬 빠르고 안전하더라고요. 그리고 솔직히, 나중에 다시 보면 '완벽하다'고 생각했던 코드도 고칠 게 보입니다. 코드는 항상 현재진행형입니다.
"Make it work, make it right, make it fast." — Kent Beck
이 문장을 1년차 때도 알고 있었지만, 그때는 이해를 못 했던 것 같습니다.
1년차와 3년차 사이에는 사실 엄청난 기술적 진보가 있는 게 아닐 수도 있습니다. 물론 코드를 더 잘 짜게 되고, 더 넓은 시야로 설계를 하게 되기도 합니다. 하지만 그것보다 더 본질적인 변화는, 나 자신을 좀 더 편안하게 받아들이게 됐다는 겁니다.
모르는 게 있어도 괜찮고, 에러가 나도 당황하지 않고, 내 코드가 리뷰에서 깎여도 괜찮다는 것. 그리고 완벽하지 않아도 계속 나아가는 것. 그게 1년차에서 3년차로 가는 과정에서 제가 가장 크게 배운 것이었습니다.
지금 1년차를 보내고 있는 분들께 하고 싶은 말은 딱 하나입니다. 지금 힘든 게 정상입니다. 그리고 지금 느끼는 그 막막함은 2년 후에 분명히 달라져 있을 겁니다.
지금 몇 년차로 일하고 계신가요? 개발자로 일하면서 "이게 달라졌다"고 느낀 순간이 있다면 댓글로 공유해 주세요. 1년차 분들이라면 지금 가장 어렵게 느껴지는 부분이 무엇인지도 궁금합니다. 🙌
이 글이 도움이 됐다면 공유도 부탁드립니다. 비슷한 고민을 하고 있을 누군가에게 닿을 수 있도록요.