첫 직장 5개월 차 #2 — 신입 개발자는 어떻게 적응할까?

| 서론

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

지난 글에서는 첫 직장 5개월 차의 시선으로 회사에서 개발자가 하루를 어떻게 보내는지, 그리고 학교에서 하던 개발과 실무에서의 개발은 무엇이 다른지에 대해 이야기해보았습니다.

실제 서비스를 운영하고, 팀의 설계 원칙에 맞춰 코드를 작성하고, 코드 리뷰와 QA를 거치면서 느낀 것은 결국 실무 개발 역시 혼자 하는 일이 아니라는 점이었습니다.

그렇다면 이제 막 그 환경에 들어온 신입 개발자는 실제로 어떤 일을 하게 될까요?

저 역시 입사 전에는 신입으로서 빠르게 기능을 개발하고 성과를 보여주고 싶은 마음이 컸습니다. 하지만 실제로 일을 시작해보니 새로운 회사에 적응한다는 것은 단순히 코드를 잘 작성하는 것만으로 이루어지는 과정이 아니었습니다.

이번 글에서는 입사 초기 어떤 업무부터 시작했는지, 업무의 범위가 어떻게 조금씩 넓어졌는지, 그리고 모르는 것을 마주했을 때 어떻게 해결하고 질문하며 적응해가고 있는지에 대해 이야기해보려고 합니다.

| 질문3. 신입 개발자는 입사하면 실제로 어떤 일을 하나요?

작은 업무부터 시작하는 데에는 이유가 있었다

물론 지금도 회사에서 큰 비중을 차지하는 업무를 맡고 있다고 하기는 어렵습니다. 그래도 어느덧 반년을 향해 달려가면서, 입사 초와 비교하면 조금씩 비중 있는 업무를 맡게 되는 것 같습니다.

입사 초에는 정말 작은 단위의 업무부터 시작했습니다. 기억에 남는 업무 중 하나는 백엔드에서 새롭게 제공하는 데이터를 화면에 노출하는 일이었습니다. 하나의 객체에 새로운 필드가 추가되었고, 해당 데이터를 기존 표에 새로운 열로 추가해 보여주는 작업이었습니다.

코드 변경 자체만 놓고 보면 정말 사소한 업무였습니다. 하지만 이 업무의 목적은 단순히 새로운 열 하나를 추가하는 데에만 있지 않았습니다. 코드를 변경한 뒤 팀의 규칙에 맞춰 커밋하고, PR을 작성하고, 팀원들에게 코드 리뷰를 요청하고, 피드백을 반영한 뒤 메인 브랜치에 병합하는 등 팀에서 하나의 코드가 반영되기까지의 전체적인 프로세스를 경험하고 적응하는 것도 중요한 목적이었습니다.

이러한 과정에 조금씩 익숙해진 이후에는 회사가 가지고 있는 도메인 지식을 이해하기 위한 업무도 진행했습니다. 실제 하드웨어 기기를 사용하면서 가이드 문서를 작성하기도 했는데, 이를 통해 이 기기가 어떤 동작을 하는지, 어떤 기능을 제공하는지, 왜 필요한지, 데이터는 어떤 방식으로 적재되는지 등을 자연스럽게 배울 수 있었습니다.

그 과정에서 개발팀이 사용하는 플랫폼과 업무 도구를 익히고, 여러 서비스가 어떤 구조로 운영되고 관리되는지도 조금씩 이해하게 되었습니다. 특히 제가 다니고 있는 회사는 여러 서비스가 MSA 형태로 운영되고 있기 때문에 전체적인 구조를 이해하는 것만으로도 많은 지식이 필요했습니다. 사실 이러한 부분은 지금도 계속 알아가고 있는 중입니다.

돌이켜보면 입사 초기에는 무언가 대단한 기능을 빠르게 만들어내는 것보다 ‘우리 회사는 어떤 서비스를 만들고 있는가’, ‘우리 팀은 어떤 환경에서 어떻게 개발하는가’, ‘어떤 개발 문화와 방식을 가지고 있는가’를 이해하는 것이 중요한 업무 중 하나였던 것 같습니다.

그리고 일을 하면서 한 가지 더 느낀 점은 서비스의 모든 코드를 이해한 뒤에 업무를 시작할 수는 없다는 것이었습니다. 내가 직접 작성한 코드라면 어느 정도의 윤곽을 알고 있겠지만, 다른 사람이 오랫동안 작업해온 영역까지 모두 이해하는 것은 쉽지 않습니다.

그래서 모든 코드를 완벽하게 이해하려 하기보다는 먼저 서비스가 어떤 구조와 시스템으로 이루어져 있는지를 파악하고, 그 안에서 하나씩 기능을 맡아보면서 필요한 영역을 점차 깊게 알아가는 방식으로 적응하고 있습니다.

프론트엔드로 입사했지만, 기능을 중심으로 일하기

저는 프론트엔드 개발자로 입사했지만, 실제 업무가 항상 프론트엔드 영역에서만 끝나는 것은 아니었습니다.

팀에서는 프론트엔드와 백엔드를 명확하게 나누기보다 하나의 기능을 완성하는 것에 초점을 맞추는 경우가 있습니다. 그렇다 보니 기능에 따라서는 프론트엔드뿐만 아니라 백엔드 코드를 함께 수정해야 하는 상황도 종종 마주했습니다.

특히 AI Agent를 활용하면서 익숙하지 않은 영역의 코드를 작성하는 것 자체에 대한 진입장벽은 이전보다 많이 낮아졌습니다. 물론 AI가 코드를 만들어준다고 해서 그대로 사용할 수 있는 것은 아닙니다. 앞서 이야기했듯 기존 아키텍처와 설계 원칙에 어긋나지는 않는지, 작성된 코드가 어떤 방식으로 동작하는지를 이해하고 검증하는 과정은 여전히 필요합니다.

최근에는 이러한 방식으로 프론트엔드뿐만 아니라 백엔드 작업, 이벤트 핸들링, 크론 작업 등 이전보다 다양한 범위를 경험하고 있습니다. 작은 업무부터 시작해 조금씩 하나의 기능을 맡는 범위가 넓어지고 있다는 점에서 입사 초와 지금의 차이를 느끼고 있습니다.

신입에게 가장 먼저 필요한 것은 잘하는 것보다 배우는 것

사실 입사 전에는 조금 다른 모습을 기대하기도 했습니다.

나름대로 개인 서비스를 운영하고 여러 프로젝트를 경험해봤기 때문에, 입사하면 빠르게 실제 서비스의 기능 개발을 맡아 기여할 수 있을 것이라고 생각했습니다. 열정도 많았고, 업무를 받으면 더 많은 것을 해보고 싶다는 욕심도 있었습니다. 같은 직군의 동료가 새로운 기능을 구현하는 모습을 보면서 저 역시 “이런 기능을 구현했다”라고 보여줄 수 있는 결과를 만들고 싶다는 마음도 있었습니다.

하지만 일을 시작하고 보니 역시 신입은 신입이었습니다.

바로 큰 기능을 맡는 것보다 작은 업무부터 시작해 기존의 업무 방식과 개발 환경을 이해하고, 팀이 가지고 있는 체계 안에 빠르게 적응하는 것이 먼저 필요했습니다. 물론 이는 회사마다 다를 것이라고 생각합니다. 인원이 적고 빠르게 움직이는 스타트업이라면 신입에게도 곧바로 업무에 뛰어들 수 있는 역량을 요구할 수 있고, 이미 어느 정도의 체계를 가지고 있는 조직이라면 기존의 것을 충분히 이해하고 흡수하는 과정이 더 중요할 수도 있습니다.

신입이 가져야 하는 마음가짐에 대해서도 생각이 조금 달라졌습니다.

신입이기 때문에 ‘내가 과연 잘할 수 있을까?’라는 걱정에 지나치게 위축될 수도 있고, 반대로 ‘신입이지만 무엇이든 다 해내겠다’라는 열정이 앞설 수도 있습니다. 저 역시 후자에 가까운 마음으로 시작했던 것 같습니다.

지금은 그 사이에서 적절한 온도를 찾는 것이 중요하다고 생각합니다. 신입인 만큼 부족하고 모르는 것이 있다는 사실을 인정하되, 그것을 핑계로 물러서기보다는 내게 주어진 일을 성실하게 해내면서 하나씩 배우는 자세가 먼저 필요하다고 느끼고 있습니다.

조금씩 팀의 한 자리를 채워가는 과정

그래도 일을 하면서 ‘나도 이제 실무에서 일하고 있구나’라고 느끼는 순간들이 있습니다.

가장 먼저 떠오르는 것은 제가 만든 기능이 실제 서비스에 반영되어 동작하는 모습을 볼 때입니다. 다른 사람에게는 작은 기능일 수 있지만, 만든 사람인 저는 어떤 부분을 제가 작업했는지 알고 있습니다. 제가 작성한 코드가 실제 데이터를 바탕으로 동작하고 사용자에게 제공되는 모습을 보면 내심 뿌듯함을 느끼곤 합니다.

하나씩 업무를 경험하면서 이전에는 보이지 않았던 것들이 보이기 시작한 것도 변화 중 하나입니다. 이슈가 발생했을 때 이전에 경험했던 내용을 바탕으로 원인이 될 만한 부분이 떠오르거나, 비록 작은 문제라도 스스로 해결할 수 있을 때면 조금씩 이 환경에 적응하고 있다는 느낌을 받습니다.

팀원들과의 관계에서도 비슷한 변화를 느낍니다. 처음보다 제 생각과 의견을 적극적으로 이야기할 수 있게 되었고, 제가 한 일에 대해 팀원들이 인정해주거나 함께 기뻐해줄 때면 팀의 구성원이 되어가고 있다는 생각이 듭니다. 처음에는 이해하기 어려웠던 피드백도 함께 일하는 시간이 쌓이면서 팀원들의 스타일과 그 피드백의 이유를 조금씩 이해하고 받아들일 수 있게 되었습니다.

최근에는 개발팀 안에서의 업무뿐만 아니라 영업팀이나 기획팀 등 다른 부서와 협업할 기회도 생겼고, 지방에 있는 현장으로 직접 외근을 나가 개발팀에서 확인해야 하는 업무를 수행하기도 했습니다. 아직 부족하고 익숙하지 않은 부분이 많지만, 저를 믿고 그러한 업무를 맡겨준 팀장님과 팀원들에게 감사한 마음도 들었습니다.

입사 첫날과 지금을 비교한다고 해서 갑자기 엄청난 개발자가 된 것은 아닙니다. 여전히 모르는 것이 많고 배워야 할 것도 많습니다. 다만 처음에는 ‘내가 무엇을 보여줄 수 있을까’를 많이 생각했다면, 지금은 ‘이 팀 안에서 내가 맡은 역할을 어떻게 잘 해낼 수 있을까’를 조금 더 생각하게 된 것 같습니다.

어쩌면 신입으로 성장한다는 것은 처음부터 큰일을 맡아내는 것이 아니라, 작은 일부터 하나씩 경험하면서 조금씩 믿고 맡길 수 있는 범위를 넓혀가는 과정인지도 모르겠습니다.

| 질문4. 모르는 것이 생기면 어떻게 하나요?

일단 스스로 해결해보기

업무를 하다 보면 모르는 것을 정말 자주 마주하게 됩니다. 처음 보는 코드일 수도 있고, 사용해보지 않은 언어나 기술일 수도 있고, 회사의 도메인이나 기존 기능에 대한 이해가 부족한 경우도 있습니다.

저는 이런 상황에서 가장 먼저 AI Agent의 도움을 받아 실제 코드와 변경 이력을 기반으로 문제를 파악하려고 합니다. 결국 개발자에게는 스스로 문제를 파악하고 해결할 수 있는 능력이 기본적으로 필요하고, 이러한 경험들이 하나씩 쌓이면서 문제 해결 능력도 향상된다고 생각하기 때문입니다.

특히 요즘의 AI Agent는 코드베이스의 컨텍스트를 함께 살펴보면서 여러 영역에 걸쳐 있는 내용을 빠르게 탐색하고 설명해준다는 점에서 많은 도움을 받고 있습니다.

한번은 Go로 작성된 기능과 로직을 확인해야 했던 적이 있습니다. 당시에는 Go 문법 자체가 익숙하지 않았기 때문에 코드를 바로 이해하기가 쉽지 않았습니다. 하지만 문법을 하나씩 공부하는 것부터 시작하기보다는, 해당 코드가 전체적으로 어떤 흐름을 가지고 동작하는지를 AI Agent에게 설명해달라고 요청했습니다. 이해하기 어려운 부분은 제가 이미 알고 있는 개념에 비유해서 다시 설명해달라고 요청하면서 하나씩 흐름을 파악할 수 있었습니다.

물론 방대한 코드를 직접 하나씩 찾아보는 과정도 전체적인 구조와 환경을 이해하는 데 도움이 될 수 있습니다. 하지만 지금은 AI Agent라는 좋은 도구가 있는 만큼, 찾는 과정 자체에 지나치게 많은 시간을 사용하는 것보다 빠르게 탐색하고 이해하는 데 적극적으로 활용하는 편입니다. 심지어 제가 이미 알고 있다고 생각하는 내용도 제가 이해한 내용을 풀어서 설명한 뒤, 잘못 이해한 부분은 없는지 더블 체크를 요청하기도 합니다.

AI만 활용하는 것은 아닙니다. 사내 Drive에 남아 있는 문서나 Slack에서 이전에 오갔던 대화를 찾아보면서 필요한 컨텍스트를 채우기도 합니다. 누군가 문서로 남겼거나 여러 사람이 대화를 나눴던 내용이라면 그만큼 업무에서 중요하게 다뤄졌던 내용일 가능성이 있기 때문입니다. 물론 오래된 정보일 수도 있기 때문에 정답으로 받아들이기보다는 현재 상황을 이해하기 위한 참고 자료로 활용하는 편입니다.

한 번 알게 된 것은 다음을 위해 기록하기

그리고 개인적으로 중요하게 생각하는 것이 하나 더 있는데, 바로 기록하는 습관입니다.

시드 데이터를 넣는 방법, 앱을 빌드하는 방법, Release Note를 작성하는 방법, 앱 SDK를 업그레이드하는 방법 등 업무를 하면서 처음 경험한 내용은 가능한 한 문서로 남겨두려고 합니다.

처음에는 한 번만 필요한 정보처럼 보여도 몇 달 뒤 비슷한 업무를 다시 해야 하는 경우가 있습니다. 그때 처음부터 다시 찾아보기 시작하면 똑같은 곳에 또 시간을 사용하게 됩니다. 반대로 이전에 경험했던 과정을 잘 기록해두면 과거의 기록 자체가 하나의 해결책이 되어줍니다.

실제로 이렇게 남겨둔 기록이 이후 업무에서 도움이 된 경우가 많았습니다. 그래서 저는 모르는 것을 해결하는 것만큼, 해결한 것을 다시 모르는 상태로 돌아가지 않도록 기록하는 것도 중요하다고 생각합니다.

질문하는 것도 방법이 필요했다

이렇게 AI와 기존 코드, 문서 등을 활용해 충분히 찾아봤음에도 해결되지 않는다면 그때는 팀원들에게 질문을 드리는 편입니다.

지금 생각해보면 입사 초에는 꽤 열정적으로 질문을 관리했습니다. 당시에는 아직 팀원들의 스타일도 잘 몰랐고, 어느 정도의 질문을 얼마나 자주 드려도 되는지에 대한 감도 없었습니다.

그래서 Notion에 Database Table을 만들어 주제, 답변자, 질문, 참고 사항 등을 정리한 뒤 질문을 드리곤 했습니다. 질문을 받는 팀원 입장에서도 어떤 내용을 궁금해하는지 한눈에 파악할 수 있었고, 당장 답변하기 어려운 상황이라면 본인의 업무를 마친 뒤 확인해서 답변해줄 수 있다는 장점이 있었습니다.

일을 하면서 질문을 어떻게 전달하느냐도 꽤 중요하다는 것을 배웠습니다.

너무 많은 배경부터 장황하게 설명하면 오히려 상대방이 핵심을 찾기 어려울 수 있습니다. 그래서 가능하면 먼저 궁금한 것을 두괄식으로 이야기하고, 그다음 현재 어떤 상황인지, 왜 이 질문을 하게 되었는지, 제가 확인한 내용은 무엇인지 정도를 간결하게 덧붙이는 것이 좋았습니다.

질문의 긴급도에 따라 방법도 달라집니다. 급하지 않은 내용이라면 텍스트로 정리해서 전달하는 것이 서로의 업무 흐름을 방해하지 않는 좋은 방법이라고 생각합니다. 반대로 빠르게 해결해야 하는 문제라면 잠시 시간이 괜찮은지 여쭤본 뒤 직접 이야기를 나누는 것이 훨씬 빠를 때도 있습니다.

다만 구두로 질문하는 것은 상대방이 집중하고 있던 업무의 흐름을 끊을 수 있습니다. 그래서 가능하면 상대방이 편하게 이야기할 수 있는 시간을 먼저 확인하고, 질문할 내용을 미리 정리한 뒤 그 시간에 한꺼번에 이야기하려고 하는 편입니다.

결국 질문을 잘한다는 것은 내가 원하는 답을 빠르게 얻는 것뿐만 아니라, 답변해주는 사람의 시간과 업무 흐름까지 함께 고려하는 것이라고 생각하게 되었습니다.

AI가 있어도 결국 사람에게 물어봐야 하는 것

AI Agent를 적극적으로 활용하고 있지만, 그렇다고 모든 것을 AI만으로 해결할 수 있다고 생각하지는 않습니다.

일반적인 프로그래밍 지식이나 코드의 동작 방식, 특정 라이브러리나 언어에 대한 내용은 AI의 도움을 받아 상당 부분 해결할 수 있습니다. 기존 코드와 충분한 컨텍스트가 주어진다면 “이 코드는 어떻게 동작하는가?”에 대해서도 꽤 좋은 설명을 얻을 수 있습니다.

하지만 “우리 팀은 왜 이렇게 만들었는가?”, “이 기능이 회사의 비즈니스에서 어떤 역할을 하는가?”와 같은 질문은 조금 다릅니다.

제가 다니고 있는 회사 역시 웹사이트와 애플리케이션을 개발하지만, 회사의 핵심 기술을 이해하기 위해서는 하드웨어를 통해 인프라를 구축하고 에너지를 절감하는 전체적인 구조에 대한 이해가 필요합니다. 회사가 어떤 하드웨어 제품을 가지고 있는지, 각 장비는 어떤 역할을 하는지, 소프트웨어와는 어떤 방식으로 통신하는지, 그렇게 만들어진 데이터가 웹과 앱에서는 어떤 형태로 제공되는지를 함께 이해해야 합니다.

물론 코드만 계속 따라가다 보면 어느 정도의 동작 방식은 파악할 수 있습니다. 하지만 코드에는 ‘어떻게’ 동작하는지는 담겨 있어도, 항상 ‘왜’ 그렇게 만들어졌는지까지 적혀 있는 것은 아닙니다.

특히 오랜 시간 서비스를 만들어온 과정에서 생긴 설계의 이유나 과거의 의사결정, 하드웨어와 소프트웨어 사이의 관계, 회사가 가지고 있는 도메인 지식은 실제로 그 과정을 경험한 사람에게 설명을 듣는 것이 훨씬 빠르고 정확할 때가 많았습니다.

그래서 요즘은 모르는 것이 생겼을 때 무조건 혼자 해결하거나, 반대로 바로 누군가에게 답을 구하는 것 모두 정답은 아니라고 생각합니다.

AI와 기존 자료를 활용해 내가 확인할 수 있는 것은 최대한 스스로 확인하되, 코드만으로 알 수 없는 맥락과 경험이 필요한 순간에는 사람에게 제대로 질문하는 것.

결국 실무에서의 문제 해결 능력에는 답을 찾아내는 능력뿐만 아니라, 어떤 도구를 활용할지, 언제 질문할지, 그리고 누구에게 물어봐야 할지를 판단하는 능력까지 포함되는 것 같습니다.

| 마무리

입사 첫날과 지금을 비교해보면 여전히 모르는 것도 많고, 배워야 할 것도 많습니다. 그렇지만 작은 업무부터 하나씩 맡아보고, 모르는 것을 직접 찾아보고, 필요할 때는 팀원들에게 질문하면서 조금씩 이 환경에서 일하는 방법을 배워가고 있습니다.

특히 신입으로 일하면서 느낀 것은 모르는 것이 있다는 사실 자체보다 그것을 어떻게 해결해나가는지가 더 중요하다는 점입니다. 스스로 찾아볼 수 있는 것은 AI와 코드, 기존 문서 등을 활용해 충분히 확인하고, 혼자서는 알 수 없는 팀의 맥락과 도메인 지식은 경험한 사람에게 질문하는 과정 역시 실무에서 필요한 능력이라고 생각하게 되었습니다.

결국 신입으로 적응한다는 것은 처음부터 모든 것을 알고 잘하는 사람이 되는 과정이라기보다, 모르는 것을 하나씩 알아가면서 조금씩 믿고 맡길 수 있는 범위를 넓혀가는 과정에 더 가까운 것 같습니다.

그렇다면 실제로 일을 경험해본 지금, 다시 취업을 준비하던 시절로 돌아간다면 저는 무엇을 다르게 준비할까요?

마지막 글에서는 지난 5개월을 돌아보며 다시 취준생이 된다면 어떤 경험을 더 해보고 싶은지, 그리고 2025년 9월의 저에게 어떤 이야기를 해주고 싶은지에 대해 이야기해보겠습니다.