신입 개발자 입사 3개월, 실무를 하며 가장 많이 배운 6가지

| 서론

안녕하세요, 팡일입니다.

내일인 7월 12일이면 직장생활을 시작한 지도 어느덧 3개월이 됩니다. 시간이 정말 빠르다는 말이 이렇게 실감 날 줄은 몰랐습니다.

제가 다니는 회사는 별도의 수습 평가 기간을 운영하지는 않았지만, 근로계약서에는 형식적으로 3개월의 수습 기간이 명시되어 있었습니다. 그렇게 어느새 수습 기간도 끝나고, 이제는 정규직으로서 새로운 출발선에 서게 되었습니다.

지난 3개월은 정말 많은 것이 처음이었던 시간이었습니다. 학교에서 프로젝트를 진행하며 개발을 해왔지만, 실무는 생각했던 것과는 많이 달랐습니다. 기능을 구현하는 것만이 개발의 전부가 아니었고, 코드 리뷰를 받아들이는 태도, 팀의 개발 문화를 이해하는 과정, 함께 일하는 사람들과의 협업, 그리고 일정을 예측하고 책임지는 것까지 모두 개발자의 역할이라는 것을 조금씩 배워가고 있습니다.

돌아보면 정신없이 흘러간 시간이었지만, 그만큼 많은 것을 배우고 생각도 많이 바뀌었습니다. 입사 전에는 미처 알지 못했던 것들을 직접 경험했고, 개발을 바라보는 시선도 조금은 달라졌습니다.

그래서 수습 기간이 끝나는 지금, 잠시 걸음을 멈추고 지난 시간을 돌아보려 합니다. 무엇을 배우고, 어떤 시행착오를 겪었으며, 앞으로는 어떤 개발자가 되고 싶은지 정리해 두면 언젠가 다시 이 글을 읽었을 때 또 다른 배움을 얻을 수 있을 것 같습니다.

이번 글에서는 지난 3개월 동안 실무를 경험하며 느꼈던 점들과, 그 과정에서 배우고 고민했던 것들에 대해 이야기해 보려고 합니다.

| 1. 피드백은 내 역량을 평가하는 것이 아니라, 더 좋은 결과를 만들기 위한 과정이었다.

입사하기 전에도 여러 프로젝트를 진행하면서 코드 리뷰를 받아본 경험은 있었습니다. 하지만 회사에서 받는 피드백은 조금 다른 느낌이었습니다. 특히 처음에는 리뷰가 달릴 때마다 '내 코드가 많이 부족한가?', '내가 잘못 구현한 건가?'라는 생각을 자주 했던 것 같습니다. 아마 많은 신입 개발자들이 비슷한 감정을 느끼지 않을까 싶습니다. 누군가 내 코드를 하나하나 살펴보고 수정 사항을 남긴다는 것 자체가 마치 내 역량을 평가받는 것처럼 느껴질 수 있기 때문입니다.

그런데 시간이 지나면서 피드백을 바라보는 시각이 조금씩 달라졌습니다. 팀원들이 리뷰를 남기는 모습에는 누군가를 평가하거나 지적하는 의도는 없었습니다. 결국 모두가 같은 목표를 바라보고 있었고, 더 좋은 결과물을 만들기 위해 의견을 나누는 과정이었습니다.

예를 들어 기능을 하나 구현하면 "우리 팀에서는 이런 방식으로 작성하고 있습니다.", "이렇게 하면 이후 유지보수가 더 쉬울 것 같습니다.", "이 부분은 다른 기능에서도 재사용될 가능성이 있습니다."와 같은 피드백처럼 생각해볼 수 있죠. 처음에는 단순히 구현만 되면 되는 것 아닌가 하는 생각도 있었지만, 시간이 지나면서 그런 의견들이 모두 미래를 위한 이야기라는 것을 알게 되었습니다. 지금 당장의 기능만 바라보는 것이 아니라, 앞으로 계속 수정되고 확장될 코드를 함께 고민해 주고 있었던 것입니다.

무엇보다 감사했던 점은, 피드백을 준다는 것 자체가 생각보다 많은 시간을 필요로 한다는 것이었습니다. 누군가 제 코드를 처음부터 끝까지 읽고, 구조를 이해하고, 더 나은 방향을 고민해서 의견을 남겨준다는 것은 결코 당연한 일이 아닙니다. 실무를 경험하기 전에는 코드 리뷰를 하나의 절차 정도로만 생각했는데, 지금은 누군가 시간을 투자해서 성장할 수 있는 기회를 만들어 주는 과정이라는 생각이 더 크게 듭니다.

그래서 요즘은 리뷰가 많이 달려도 예전처럼 부담스럽기보다는, 오히려 배울 수 있는 내용이 많다는 생각을 하게 됩니다. 물론 여전히 리뷰를 받을 때마다 아쉬운 마음이 들기도 합니다. 하지만 그 아쉬움은 '내가 부족하다.'에서 끝나는 것이 아니라, '다음에는 더 좋은 코드를 작성해 보자.'라는 방향으로 이어지는 것 같습니다. 지난 3개월 동안 가장 크게 달라진 점이 있다면, 피드백을 바라보는 태도였던 것 같습니다.

| 2. 실무에서 좋은 코드는 '동작하는 코드'보다 '계속 읽힐 수 있는 코드'였다.

학교에서 프로젝트를 할 때는 기능이 정상적으로 동작하면 좋은 코드라고 생각했습니다. 요구사항을 만족하고 버그 없이 실행된다면 그것으로 충분하다고 여겼습니다. 물론 지금도 기능이 동작하는 것은 가장 중요합니다. 하지만 실무에서는 그보다 한 단계 더 나아가 '앞으로도 계속 읽히고 수정될 수 있는 코드인가?'를 훨씬 많이 고민한다는 것을 느꼈습니다.

그 과정에서 가장 먼저 생각이 바뀌었던 부분은 주석이었습니다. 저는 원래 주석을 꽤 좋아하는 편이었습니다. 설명을 자세히 적어두면 다른 사람이 이해하기 쉽고, 시간이 지나도 기억하기 좋다고 생각했습니다. 그래서 프로젝트를 할 때도 필요한 부분마다 주석을 남기는 습관이 있었습니다.

하지만 실무에서는 코드가 생각보다 훨씬 자주 변경되었습니다. 기능이 추가되고, 요구사항이 바뀌고, 리팩터링이 반복되면서 코드의 형태는 계속 달라졌습니다. 그런데 주석은 그렇지 않았습니다. 수정되지 않은 주석은 어느 순간 현재 코드와 다른 설명을 하고 있었고, 오히려 코드를 이해하는 데 방해가 되는 경우도 있었습니다. 흔히 말하는 stale comment를 직접 경험하게 된 것입니다.

그 이후부터는 '설명하는 코드'보다 '설명이 필요 없는 코드'를 작성하는 것이 더 중요하다는 생각을 많이 하게 되었습니다. 변수명 하나를 조금 더 고민하고, 메서드의 역할을 명확하게 나누고, 객체의 책임을 분리하는 것이 긴 주석을 남기는 것보다 훨씬 큰 도움이 된다는 것도 느꼈습니다.

객체를 설계하는 과정도 인상 깊었습니다. 어느 기능을 개발하면서 기존에 사용하던 Sensitivity라는 값 객체와 비슷하지만 조금 다른 PresenceSensitivity라는 객체가 필요했던 적이 있었습니다. 처음에는 새로운 클래스를 하나 만들면 된다고 생각했습니다. 하지만 리뷰를 통해 공통되는 부분은 추상화하고, 각 객체는 자신만의 책임만 가지도록 구조를 개선하는 방향을 고민하게 되었습니다.

사실 이런 내용은 학교에서도 객체지향을 배우면서 많이 들었던 이야기였습니다. 하지만 직접 실무에서 경험해 보니 느낌이 많이 달랐습니다. 단순히 이론을 적용하는 것이 아니라, 앞으로도 계속 수정되고 확장될 가능성을 고려해서 구조를 만드는 과정이었기 때문입니다. 그래서 좋은 코드는 예쁘게 작성된 코드가 아니라, 시간이 지나도 쉽게 이해할 수 있고 변화에 잘 대응할 수 있는 코드라는 것을 조금씩 배우고 있는 것 같습니다.

| 3. 새로운 기술보다 먼저 배워야 했던 것은 팀의 개발 문화였다.

입사하기 전에는 새로운 기술을 빨리 배우는 것이 적응의 핵심이라고 생각했습니다. React를 더 잘해야 하고, TypeScript를 더 깊게 알아야 하고, 새로운 프레임워크도 공부해야 한다고 생각했습니다. 물론 그런 것들도 중요했습니다. 하지만 지난 3개월을 돌아보면 가장 많은 시간을 들여 배운 것은 기술이 아니라 '팀의 방식'이었습니다.

저는 여러 프로젝트를 협업으로 진행해 본 경험은 있었지만, 기존 서비스를 이어받아 유지보수하는 경험은 거의 없었습니다. 학교 프로젝트는 대부분 처음부터 직접 설계하고 구현했기 때문에 자연스럽게 제 방식대로 개발할 수 있었습니다. 하지만 회사는 이미 오랜 시간 동안 여러 개발자들이 함께 만들어 온 코드가 존재했고, 그 안에는 팀이 합의한 규칙과 철학이 담겨 있었습니다.

예를 들어 저희 팀은 DDD를 기반으로 4 Layer Architecture를 사용하고 있습니다. 개념 자체는 알고 있다고 생각했지만, 실제로 기능 하나를 개발하려고 하니 어디서부터 시작해야 하는지 막막했던 적이 많았습니다. Domain을 먼저 작성해야 하는지, Application 계층을 먼저 설계해야 하는지, Infrastructure는 어느 시점에 구현해야 하는지 쉽게 감이 오지 않았습니다. 결국 처음 작성했던 코드를 다시 되돌려 구조부터 수정했던 경험도 있었습니다.

그때 느꼈던 것은 '안다'와 '적용할 수 있다'는 전혀 다른 이야기라는 점이었습니다. 책을 읽으면서 이해했다고 생각했던 구조도 실제 서비스에서는 도메인과 요구사항이 함께 얽혀 있기 때문에 직접 구현해 보기 전까지는 체감하기 어려웠습니다. 그래서 처음에는 기능을 구현하면서도 "이 방향이 맞는 걸까?"라는 고민을 많이 했습니다. 구조를 이해했다고 생각했지만 막상 코드를 작성해 보면 예상과 다른 경우도 있었고, 결국 다시 구조를 수정하거나 처음부터 다시 구현했던 경험도 있었습니다. 그 과정에서 코드 리뷰와 기존 코드를 살펴보며 팀이 어떤 방식으로 설계하고 구현하는지를 조금씩 익혀갈 수 있었습니다. 아직도 배워가는 과정이지만, 실무에서는 새로운 기술을 익히는 것만큼이나 기존 팀의 사고방식과 개발 문화를 이해하는 것이 중요하다는 것을 많이 느꼈습니다.

개발 문화는 코드 구조에서만 끝나지 않았습니다. 커밋은 어느 정도 크기로 나누는 것이 좋은지, 하나의 PR에는 어느 정도의 작업을 담는 것이 적절한지, 왜 저희 팀은 Rebase Merge를 사용하는지, 충돌이 발생했을 때 reflog를 어떻게 활용하는지처럼 형상 관리 방식도 모두 팀의 문화였습니다. 이런 것들은 책으로 배우기보다 직접 경험하면서 익히는 부분이 훨씬 많았습니다.

결국 좋은 개발자는 자신의 방식만 고집하는 사람이 아니라, 기존 팀이 오랜 시간 만들어 온 흐름을 이해하고 그 안에서 일관성을 유지할 수 있는 사람이라는 생각을 많이 하게 되었습니다. 새로운 기능을 만드는 능력도 중요하지만, 기존 코드와 자연스럽게 어우러지는 코드를 작성하는 능력 역시 실무에서는 매우 중요한 역량이라는 것을 지난 3개월 동안 가장 많이 배운 것 같습니다.

| 4. 결국 가장 중요한 것은 기술보다 함께 일하는 사람들이었다.

입사하기 전에는 '좋은 회사'라고 하면 가장 먼저 기술적인 성장 환경을 떠올렸습니다. 어떤 기술 스택을 사용하는지, 얼마나 규모 있는 서비스를 운영하는지, 내가 새로운 기술을 많이 경험할 수 있는지 같은 것들이 가장 중요하다고 생각했습니다. 물론 지금도 그런 부분은 개발자에게 중요한 요소라고 생각합니다. 새로운 문제를 해결하고, 더 좋은 품질의 코드를 고민하며, 다양한 경험을 쌓는 것은 분명 개발자로서 성장하는 데 큰 도움이 됩니다.

하지만 지난 3개월을 돌아보면서 가장 크게 느낀 것은, 결국 그런 성장도 사람을 통해 이루어진다는 사실이었습니다.

신입 개발자가 회사의 프로덕트를 이해하는 것은 생각보다 훨씬 어려운 일입니다. 이미 몇 년 동안 개발되어 온 서비스에는 수많은 배경과 맥락이 숨어 있습니다. 왜 이런 구조를 사용했는지, 왜 이런 방식으로 개발하는지, 어떤 문제를 해결하기 위해 현재의 형태가 되었는지는 문서만 읽는다고 이해할 수 있는 내용이 아니었습니다.

결국 계속 질문할 수밖에 없습니다.

• "왜 이렇게 구현하셨나요?"

• "이 부분은 왜 Domain에 있는 건가요?"

• "여기서는 어떤 방향으로 개발하는 것이 좋을까요?"

신입이라면 이런 질문을 수도 없이 하게 됩니다.

그런데 팀마다 분위기는 분명 다를 것이라고 생각합니다. 어떤 곳에서는 질문하는 것 자체를 부담스러워하기도 하고, 너무 자주 질문하면 눈치를 주는 경우도 있다고 들었습니다. 하지만 감사하게도 제가 속한 팀은 그렇지 않았습니다.

질문을 하면 귀찮아하기보다 같이 고민해 주셨고, 단순히 답만 알려주기보다 왜 그렇게 생각하는지까지 설명해 주셨습니다. 제가 놓친 부분이 있으면 방향을 잡아주셨고, 스스로 고민해 볼 수 있도록 힌트도 많이 주셨습니다. 그러다 보니 질문하는 것에 대한 부담도 점점 줄어들었습니다.

개발 외적인 분위기도 참 좋았습니다. 같이 점심을 먹으며 사소한 이야기를 나누고, 서로의 관심사를 이야기하기도 하고, 스프린트 회의를 하면서도 '어떻게 하면 서로 더 잘할 수 있을까?'를 함께 고민하는 모습이 인상 깊었습니다. 코드 리뷰 역시 누군가를 지적하기 위한 시간이 아니라 함께 더 좋은 방향을 찾기 위한 시간이었습니다.

좋은 기술 환경도 중요하지만, 그 기술을 함께 고민하는 사람들이 어떤 태도를 가지고 있는지는 그보다 더 중요할 수도 있겠다는 생각을 많이 했습니다. 지난 3개월 동안 가장 감사했던 것은 좋은 코드를 배우게 된 것보다도, 좋은 사람들과 함께 일할 수 있었다는 점이었습니다.

| 5. 일을 하는 것보다, 일을 예측하는 것이 더 어려웠다.

입사 초반에는 주어진 업무를 따라가는 시간이 많았습니다. 기능을 구현하고, 리뷰를 받고, 수정하면서 하나씩 배우는 과정이 이어졌습니다. 하지만 6월부터는 조금씩 혼자 담당하는 업무들이 생기기 시작했습니다.

저희 팀은 스프린트 방식으로 업무를 진행합니다. 2주 동안 진행할 업무를 미리 계획하고, 각 업무에 필요한 포인트를 산정합니다. 하루를 1포인트 정도로 계산하면, 회의 시간을 제외하고 약 9.5포인트 정도의 업무를 계획하게 됩니다. 처음에는 이 방식이 꽤 합리적이라고 생각했습니다. 해야 할 일을 미리 계획하고, 그 계획대로 진행하면 된다고 생각했기 때문입니다.

하지만 막상 직접 포인트를 산정해 보니 생각보다 훨씬 어려웠습니다.

처음 맡는 기능은 익숙하지 않은 도메인을 이해하는 시간도 필요했고, 구현하는 과정에서 예상하지 못한 요구사항이 생기기도 했습니다. 리뷰를 받으면서 구조를 수정하는 경우도 있었고, 테스트를 진행하면서 새롭게 발견되는 문제들도 있었습니다. 결국 처음 예상했던 시간보다 더 오래 걸리는 일이 자주 발생했습니다.

두 번 정도의 스프린트를 지나면서 계획했던 업무를 모두 끝내지 못했던 경험도 있었습니다. 처음에는 조금 아쉬웠습니다. 스스로 부족한 것은 아닐까 하는 생각도 했습니다.

그런데 팀원분들이 해주셨던 말이 기억에 남습니다.

• "포인트를 너무 꽉 채우려고 하지 않아도 됩니다."

• "실무는 생각보다 변수가 정말 많아요."

그 말을 듣고 조금은 마음이 편해졌습니다.

저는 열심히 하면 더 많은 일을 할 수 있다고 생각했습니다. 하지만 실무에서는 단순히 많은 일을 하는 것보다 예측 가능한 일정 안에서 안정적으로 결과를 만드는 것이 더 중요했습니다. 여유를 두고 계획하는 것도 하나의 능력이었고, 경험이 많은 팀원들에게 예상 공수를 먼저 물어보는 것도 중요한 습관이라는 것을 배우게 되었습니다.

아직도 업무를 얼마나 예상해야 하는지는 어렵습니다. 하지만 예전처럼 혼자 고민하기보다 먼저 의견을 구하고, 조금 더 현실적인 계획을 세우려고 노력해보려고합니다. 이것 역시 신입 개발자가 배워야 하는 중요한 역량 중 하나라는 생각이 듭니다.

| 6. 퇴근 후에도 성장하고 싶었지만, 현실은 생각보다 쉽지 않았다.

입사하기 전에는 퇴근 후에도 개발 공부를 계속할 수 있을 것이라고 생각했습니다. 사이드 프로젝트도 하고, 기술 블로그도 꾸준히 작성하고, 운동도 하고, 책도 읽으면서 균형 잡힌 생활을 할 수 있을 것이라고 막연하게 생각했습니다.

하지만 현실은 생각보다 달랐습니다.

하루 종일 업무에 집중하고 퇴근하면 생각보다 에너지가 많이 남아 있지 않았습니다. 저녁을 먹고 잠깐 쉬다 보면 어느새 하루가 끝나 있었고, 야구를 보거나 일상을 보내다 보면 '오늘도 아무것도 못 했네.'라는 생각이 들기도 했습니다.

그래도 꾸준히 이어가고 있는 것이 하나 있습니다. 바로 업무 일지입니다.

매일 어떤 업무를 했는지 기록하고, 해야 할 일을 정리하면서 하루를 마무리하고 있습니다. 다만 시간이 지나면서 지금 작성하고 있는 업무 일지는 조금 성격이 다르다는 생각도 들었습니다. 업무를 회고하기 위한 기록이라기보다, 해야 할 일을 관리하기 위한 메모에 가까웠기 때문입니다.

앞으로는 조금 더 기록의 방향을 바꿔보고 싶습니다.

단순히 무엇을 했는지를 적는 것이 아니라, 왜 그렇게 구현했는지, 어떤 고민을 했는지, 어떤 피드백을 받았는지까지 함께 남기고 싶습니다. 지금은 당연하게 느껴지는 고민들도 시간이 지나면 분명 잊어버릴 것이고, 그때 다시 돌아볼 수 있는 기록이 있다면 그것도 하나의 자산이 될 것이라고 생각합니다.

기술 블로그도 같은 이유에서 다시 성실하게 시작해 보려고 합니다. 누군가에게 정보를 전달하기 위한 글도 좋지만, 결국 가장 많이 배우는 사람은 글을 쓰는 사람이라는 말을 점점 실감하고 있습니다. 머릿속으로 이해했다고 생각했던 내용도 글로 정리하는 순간 부족한 부분이 보이고, 다시 공부하게 되는 경험을 여러 번 했기 때문입니다.

지난 3개월은 정말 정신없이 지나갔습니다. 돌아보면 부족했던 점도 많았고, 아쉬웠던 순간도 많았습니다. 그럼에도 불구하고 하나 분명한 것은 입사 첫날의 저와 지금의 저는 분명 많이 달라졌다는 것입니다. 앞으로도 새로운 기술을 배우고, 더 좋은 코드를 고민하는 것도 중요하겠지만, 좋은 피드백을 받아들이는 태도, 팀과 함께 일하는 방법, 꾸준히 기록하고 돌아보는 습관까지 함께 성장시켜 나가고 싶습니다.

아직 3개월밖에 되지 않았지만, 오히려 그렇기 때문에 더 많이 배우고 더 많이 성장할 수 있는 시간들이 남아 있다고 생각합니다. 3개월 뒤, 그리고 1년 뒤에는 또 어떤 생각을 하게 될지 벌써부터 조금은 기대가 됩니다.

| 결론

지난 3개월을 돌아보며 가장 크게 느낀 것은, 개발은 결국 코드를 잘 작성하는 것만으로는 완성되지 않는다는 점이었습니다.

좋은 피드백을 받아들이는 태도, 시간이 지나도 읽기 쉬운 코드를 작성하려는 고민, 팀의 개발 문화를 이해하고 맞춰가는 과정, 함께 일하는 사람들과의 관계, 현실적인 일정 산정, 그리고 꾸준히 기록하고 돌아보는 습관까지. 이 모든 것들이 모여 조금씩 저를 개발자로 만들어 가고 있다는 생각이 들었습니다.

입사 전에는 '잘하는 개발자'가 되는 것이 목표였다면, 지금은 '함께 일하기 좋은 개발자'가 되고 싶다는 생각이 더 커졌습니다. 혼자 뛰어난 코드를 작성하는 것보다 팀과 함께 일관성 있는 결과를 만들어 내고, 피드백을 통해 계속 성장하며, 동료들이 함께 일하고 싶은 개발자가 되는 것이 훨씬 중요한 가치라는 것을 지난 3개월 동안 배울 수 있었습니다.

아직 모르는 것도 많고, 부족한 점도 많습니다. 앞으로도 더 어려운 문제를 만나게 될 것이고, 시행착오도 계속 겪게 될 것이라고 생각합니다. 하지만 지금처럼 배움을 즐기고, 질문하는 것을 두려워하지 않으며, 꾸준히 기록하고 돌아보는 습관만 잃지 않는다면 조금씩이라도 성장해 나갈 수 있을 것이라 믿습니다.

3개월이라는 시간은 개발자 인생에서 정말 짧은 시간입니다. 하지만 저에게는 학교에서 배웠던 것들이 실무와 연결되기 시작한, 그리고 개발을 바라보는 관점이 바뀌기 시작한 의미 있는 시간이었습니다.

이번 회고도 시간이 지난 뒤 다시 읽어보면 부족한 부분이 많이 보일지도 모르겠습니다. 하지만 그때는 지금보다 더 성장했다는 뜻일 테니, 그 또한 기분 좋은 일일 것 같습니다. 이제는 다음 3개월을 기대해 보려고 합니다. 그때는 또 어떤 고민을 하고, 어떤 배움을 얻게 될지 기대하며 오늘의 회고를 마무리하겠습니다.