첫 직장 5개월 차 #1 — 회사에서 개발자는 뭐 하고 살까?

| 서론

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

어느덧 첫 직장에서 근무한 지도 5개월을 향해 가고 있습니다. 취업이 쉽지 않은 시장 속에서 감사하게도 직장을 갖게 되었고, 실제 현업에서 다양한 경험을 쌓아가고 있다는 사실에 여전히 감사함을 느끼곤 합니다.

9월이 되어 개강을 맞이하면서, 막학기를 앞둔 동생들과 이야기를 나눌 기회가 종종 있었습니다. 그러다 보니 자연스럽게 이런 질문들을 받게 되었습니다.

• 보통 출근하면 어떤 식으로 일해요?

• 실제로 일해보니 어때요?

• 직장생활을 하기 전과 후에 어떤 점이 달라졌어요?

생각해 보면 2025년 9월, 대학생활을 보내고 있던 저 역시 비슷한 것들이 참 궁금했습니다. 당시 현업에서 일하고 있던 형, 누나들에게 이런저런 질문을 던지며 제가 아직 경험해보지 못한 ‘실무’라는 곳을 상상하곤 했습니다.

그래서 이번 포스팅에서는 취준생 시절의 제가 궁금했던 질문들을, 입사 5개월 차가 된 지금의 제가 하나씩 답해보려고 합니다.

한 편에 모든 이야기를 담기에는 생각보다 하고 싶은 이야기가 많아 총 3편으로 나누어보았습니다. 그중 첫 번째 글에서는 가장 먼저 궁금했던 ‘회사에서 개발자는 실제로 어떻게 일하는가?’에 대한 이야기를 해보려고 합니다. 실제 회사에서 하루를 어떻게 보내는지부터, 학교에서 하던 개발과 실무에서의 개발은 무엇이 달랐는지까지 제가 직접 경험하며 느낀 것들을 솔직하게 공유해보겠습니다.

| 질문1. 보통 출근하면 하루를 어떤 식으로 보내나요?

하루의 시작은 인프라 점검부터

회사에 출근하면 가장 먼저 하는 일은 인프라를 점검하는 것입니다. 현재 운영 중인 여러 서비스가 정상적으로 동작하고 있는지, 전날 퇴근한 이후부터 오늘 출근하기 전까지 이슈나 버그가 발생하지는 않았는지를 확인합니다.

기존에 팀에서 작성해둔 스크립트를 실행하고, 출력되는 결과를 살펴보면서 여러 인프라 환경에 문제가 없는지 점검합니다. 구체적인 내용까지 이야기하기는 어렵지만, 상용 환경과 테스트 환경 등에서 운영되고 있는 것들이 정상적인지를 확인한다고 생각하면 될 것 같습니다.

만약 이 과정에서 이슈가 발견되면 팀의 소통 채널인 Slack에 상황을 공유하고, 해당 문제를 해결하는 것을 가장 우선순위가 높은 업무로 두고 진행합니다. 반대로 별다른 문제가 없다면 이상이 없다는 정도의 내용을 공유하고 각자의 업무를 시작합니다.

이후에는 데일리 미팅을 진행합니다. 저희 팀은 Jira를 활용해 각자의 업무를 관리하고 있는데, 데일리 미팅에서는 이를 바탕으로 어제 어떤 일을 했는지, 오늘은 무엇을 할 예정인지 간단하게 공유합니다. 팀원들에게 전달할 내용이 있다면 이 시간을 활용하기도 하고, 업무를 진행하면서 도움이 필요하거나 함께 고민해보고 싶은 부분이 있다면 자연스럽게 이야기를 나누기도 합니다.

데일리 미팅이 끝나면 본격적으로 각자 맡은 업무를 진행합니다. 사실 이때부터는 하루의 모습을 하나로 정의하기가 어렵습니다. 혼자 개발에 집중하는 날도 있고, 다른 팀원이나 다른 부서의 구성원과 함께 업무를 진행하기도 합니다. 미팅을 가져야 하는 날도 있고, 특정 문제를 두고 함께 해결책을 찾아야 하는 날도 있습니다. 결국 그날 내가 맡고 있는 업무가 무엇인지에 따라 하루의 모습도 꽤 많이 달라집니다.

개발자는 개발만 하지 않는다

생각보다 개발자가 회사에서 하는 일이 단순히 ‘코드를 작성하는 것’에만 머물러 있지는 않았습니다.

PM과 기능에 대한 미팅을 진행하기도 하고, 하드웨어 팀과 협업이 필요한 부분에 대해 논의하기도 합니다. 새로운 기능을 만드는 것이 아니라 기존 기능이 정상적으로 동작하는지 점검하는 업무도 있습니다. 변경 사항이 배포되는 날에는 내부적으로 QA를 진행하면서 실제 운영 중인 서비스의 여러 기능이 제대로 동작하는지를 하나씩 검증하기도 합니다.

아직 신입인 저에게는 이 과정이 쉽지만은 않습니다. 운영하고 있는 서비스와 기능의 범위가 넓기도 하고, 단순한 개발 역량을 넘어 서비스에 대한 도메인 지식이 필요한 경우도 많기 때문입니다. 특히 실제 서비스에 변경 사항을 배포하고 이를 검증하는 과정에는 아직 부담감을 느끼기도 합니다. 하지만 실제 사용자가 있는 서비스를 운영하기 위해서는 피할 수 없는 과정이기도 합니다.

코드 리뷰도 일상적인 업무 중 하나입니다. 작업한 코드는 GitHub의 PR을 통해 팀원들에게 공유하고, 리뷰와 Approve를 거쳐야 Merge할 수 있습니다. 제가 작성한 코드를 팀원들에게 리뷰받기도 하지만, 반대로 다른 팀원이 작성한 코드를 제가 리뷰하기도 합니다. PR에 작성된 내용을 통해 어떤 작업인지 먼저 이해하고, 변경된 코드를 하나씩 살펴보면서 문제가 될 만한 부분이나 함께 검토하면 좋을 부분이 있는지를 확인합니다. 필요한 내용이 있다면 코멘트를 남겨 서로 의견을 주고받습니다. 개인적으로는 이렇게 서로의 코드를 확인하고 피드백을 주고받을 수 있는 문화가 좋다고 느끼고 있습니다.

이외에도 가이드 문서, API의 Request/Response를 정리한 문서, 기능 개발 문서 등 필요한 내용을 문서화하는 일도 있습니다. 결국 하루 동안 개발만 하는 것이 아니라 개발하고, 이야기하고, 확인하고, 리뷰하고, 기록하는 일을 함께 하고 있는 셈입니다.

생각보다 익숙하지만, 무게는 다른 하루

그렇다고 취준생 때 상상했던 개발자의 하루와 실제 하루가 완전히 다르다고 느끼지는 않았습니다. 오히려 이전에 여러 사이드 프로젝트를 진행하면서 경험했던 하루와 크게 다르지 않다고 느낄 때도 많습니다. 함께 논의하고, 문제를 해결하고, 코드를 작성하고, 결과물을 확인하는 큰 흐름 자체는 비슷했습니다.

다만 분명하게 다른 점도 있었습니다. 내가 작성한 코드와 내린 판단이 실제 운영 중인 서비스에 영향을 줄 수 있다는 것, 그리고 단순히 개발을 잘하는 것만으로는 부족하고 서비스에 대한 도메인 지식까지 필요하다는 점입니다.

어쩌면 취준생 때 생각했던 것처럼 ‘회사에서 개발하는 것’ 자체가 완전히 새로운 세계는 아니었습니다. 다만 비슷해 보이는 하루 속에서도, 내가 하는 일에 실제 사용자와 서비스가 연결되어 있다는 책임감의 차이가 학생 때의 개발과 실무를 구분하는 가장 큰 차이 중 하나라고 느끼고 있습니다.

| 질문2. 학교에서 하던 개발과 회사에서 하는 개발은 무엇이 다른가요?

기능을 만드는 것만큼 중요한 설계 원칙

입사 전과 후를 비교했을 때 가장 크게 달라진 점 중 하나는 정해진 설계 원칙과 아키텍처 안에서 코드를 작성해야 한다는 것입니다.

학생 때도 여러 사람과 프로젝트를 진행하면서 나름의 협업 규칙을 정해본 경험은 있었습니다. 하지만 대부분 커밋 컨벤션이나 폴더 구조, 네이밍 규칙 정도에 그쳤고, DDD와 같은 설계 패턴이나 명확한 아키텍처를 기반으로 개발해본 경험은 많지 않았습니다. 자연스럽게 코드의 구조보다는 주어진 기능을 완성하는 것에 더 집중했던 것 같습니다.

하지만 실무에서는 이미 오랜 시간 개발팀이 만들어온 설계 원칙과 아키텍처가 존재합니다. 새로운 기능을 개발한다고 해서 내가 원하는 방식으로 자유롭게 코드를 작성하는 것이 아니라, 기존 코드가 어떤 원칙으로 구성되어 있는지를 이해하고 그 안에서 일관성을 유지하며 개발하는 것이 중요했습니다. 입사 초기에는 이런 부분들이 새롭기도 했고, 한편으로는 신기하게 느껴졌습니다.

AI의 등장으로 이러한 변화는 더욱 크게 느껴집니다. 요즘은 실제로 제가 처음부터 끝까지 직접 타이핑하며 코드를 작성하는 경우가 많지 않습니다. AI Agent를 활용하면 코드를 생성하는 것 자체는 이전보다 훨씬 쉬워졌습니다. 대신 저는 생성된 코드의 Diff를 확인하면서 기존 설계 원칙과 어긋나지는 않는지, 의도한 대로 동작하는지, 잠재적인 문제는 없는지를 검토하는 데 더 많은 시간을 사용합니다.

결국 코드를 만들어내는 것보다 만들어진 코드를 이해하고 검증하는 능력이 더욱 중요해지고 있다고 느끼고 있습니다. AI가 코드를 대신 작성해줄 수는 있지만, 그 코드가 우리 팀의 코드베이스에 들어가도 되는지를 판단하는 것은 결국 개발자의 몫이기 때문입니다.

동작하는 코드에서, 문제가 없는 코드로

학교나 개인 프로젝트에서는 기능이 정상적으로 동작하는 것 자체가 하나의 중요한 목표였다면, 실무에서는 그보다 훨씬 많은 것을 고려해야 했습니다.

실제 사용자가 이용하고 있는 서비스에 코드가 반영되기 때문에 새로운 기능이 잘 동작하는 것뿐만 아니라 기존 기능을 깨뜨리지 않는지도 중요합니다. 빌드 과정을 통해 일차적으로 문제를 확인하기도 하지만, 실제 배포가 이루어지면 기능 체크리스트를 활용해 배포된 환경에서 여러 기능이 정상적으로 동작하는지 직접 검증합니다. 운영하고 있는 서비스와 기능이 많다 보니 배포와 검증에만 반나절 정도를 사용하기도 합니다.

개발할 때 예외 처리를 바라보는 시선도 많이 달라졌습니다. 예를 들어 데이터를 Fetch하는 기능 하나를 구현하더라도 요청에 실패했을 때 어떻게 처리할 것인지, 사용자에게 어떤 안내를 보여줄 것인지, 사용자가 그다음에는 어떤 행동을 취할 수 있도록 해야 하는지까지 고민하게 됩니다.

개인 프로젝트를 할 때는 기능이 동작하지 않으면 콘솔에 찍힌 에러를 확인하면서 고치거나, 때로는 어떤 상황에서 에러가 발생하는지조차 제대로 파악하지 못하고 넘어간 적도 있었습니다. 하지만 실제 서비스에서 오류가 발생해 사용자의 행동을 막거나 서비스 이용 자체에 영향을 준다면 이야기가 달라집니다. 그래서 지금은 정상적인 상황만큼이나 정상적이지 않은 상황에서 서비스가 어떻게 동작해야 하는지를 더 많이 고민하게 되었습니다.

트래픽과 부하에 대해서도 새롭게 생각하게 되었습니다. 겉으로 보기에는 문제가 없어 보이는 코드도 많은 요청이 한꺼번에 들어오는 상황에서는 전혀 다른 결과를 만들 수 있다는 것을 경험했습니다. 실제로 많은 요청으로 인해 서버에 문제가 발생했던 경험을 통해, 평소에는 정상적으로 동작하는 코드라고 해서 모든 환경에서 안전한 것은 아니라는 것을 알게 되었습니다.

프론트엔드 개발자인 제가 부하 테스트를 직접 많이 진행한 것은 아니지만, 이 경험을 통해 단위 테스트나 통합 테스트뿐만 아니라 부하 테스트를 비롯한 다양한 테스트를 경험해보는 것도 개발자에게 필요한 역량이라는 생각을 하게 되었습니다.

학생 때의 경험은 결국 실무로 이어진다

그렇다고 학생 때 했던 개발과 실무가 완전히 단절되어 있다고 생각하지는 않습니다. 오히려 일을 시작하고 보니 학생 때 해봤던 크고 작은 경험들이 생각보다 많이 연결되고 있었습니다.

먼저 CLI 환경을 다뤄본 경험이 많은 도움이 되었습니다. 요즘은 GitHub Desktop이나 GUI 기반의 개발 도구가 잘 만들어져 있어 명령어를 직접 입력하지 않고도 많은 작업을 할 수 있습니다. 그럼에도 실무에서는 여전히 CLI를 사용할 일이 많습니다. 특히 Git은 거의 매일 사용하기 때문에 stash, rebase, worktree 등을 활용해 작업물을 관리했던 경험이 실제 업무에서도 도움이 되었습니다. 기본적인 Linux 명령어에 익숙해지는 것 역시 개발자라면 한 번쯤 충분히 경험해볼 필요가 있다고 느꼈습니다.

Git과 GitHub를 활용한 협업 경험도 마찬가지입니다. 실무에서는 코드에 변경 사항이 생기면 PR을 통해 무엇을 변경했는지 설명하고, 팀원들에게 코드 리뷰를 받은 뒤 문제가 없다고 판단되면 Merge하는 과정을 거칩니다. 학생 때는 협업을 하더라도 하나의 브랜치에 바로 Merge하거나 PR을 적극적으로 활용하지 않는 경우가 있었는데, 실무에서는 작은 변경 사항도 PR 단위로 관리하는 것이 자연스러운 개발 과정 중 하나였습니다.

PR뿐만 아니라 Release Note를 작성하거나 여러 브랜치의 작업을 관리하는 등, 혼자 개발할 때는 쉽게 접하지 못했던 과정들도 경험하고 있습니다. 그래서 학생 때부터 단순히 Git 명령어를 아는 것을 넘어 Git을 활용해 여러 사람과 실제로 협업해보는 경험을 가져보는 것이 큰 도움이 된다고 생각합니다.

무엇보다 중요한 것은 결국 사람과 함께 일해본 경험이었습니다. 다른 사람이 작성한 코드를 읽고 이해하는 것, 내 코드에 대한 피드백을 받아들이는 것, 반대로 다른 사람에게 어떤 방식으로 피드백을 전달할 것인지 모두 협업의 일부입니다. 사소해 보이지만 질문을 어떻게 하고 답변을 어떻게 하는지, 의견이 다를 때 어떻게 이야기하는지 같은 태도 역시 함께 일하는 데 중요한 부분이라고 느끼고 있습니다.

태스크를 관리하는 능력도 빼놓을 수 없습니다. 내게 주어진 일이 무엇인지, 이 업무의 목표가 무엇인지, 어느 정도의 시간이 필요한지를 스스로 파악하고 관리하면서 일해야 합니다. 저희 팀에서는 Jira를 활용해 업무를 관리하고 Slack을 통해 소통하고 있는데, 학생 때도 기회가 된다면 이러한 협업 도구를 단순히 사용해보는 것을 넘어 실제 팀처럼 활용해보는 경험을 만들어보는 것도 좋다고 생각합니다.

결국 학생 때 무엇을 경험했느냐는 생각보다 자연스럽게 실무로 이어집니다. 중요한 것은 단순히 “Git을 써봤다”, “팀 프로젝트를 해봤다”처럼 경험의 개수를 늘리는 것이 아니라, 그 안에서 어떤 방식으로 협업했고 어떤 문제를 만났으며 무엇을 배웠는지에 있다고 생각합니다.

그리고 취업을 준비하는 입장이라면 자신이 했던 경험을 단순한 프로젝트 경험으로 남겨두기보다, 그 경험이 실무에서 필요한 역량과 어떻게 연결되는지를 고민하고 설명할 수 있다면 취업을 준비하는 과정에서도 분명 도움이 되지 않을까 생각합니다.

| 마무리

첫 번째 글에서는 제가 회사에서 보내고 있는 하루와, 학생 때 하던 개발과 실무에서의 개발이 어떻게 달랐는지를 이야기해보았습니다.

취업 전에는 회사에서의 개발이 학생 때 경험했던 것과 완전히 다른 세계일 것이라고 생각하기도 했습니다. 하지만 막상 일을 시작해보니 학생 때 프로젝트를 진행하며 경험했던 개발과 협업의 과정이 자연스럽게 실무로 이어지는 부분도 많았습니다. 다만 실제 사용자가 있는 서비스를 다루고, 기존의 설계 원칙과 팀의 개발 방식 안에서 여러 사람과 함께 일한다는 점에서 그 책임과 무게는 분명히 달랐습니다.

그리고 이러한 환경에 처음 들어온 신입 개발자가 처음부터 모든 것을 잘할 수는 없었습니다. 그렇다면 실제로 신입 개발자는 입사해서 어떤 일을 맡게 되고, 수많은 모르는 것들을 마주하면서 어떻게 팀에 적응해나가게 될까요?

다음 글에서는 제가 입사 초 어떤 업무부터 시작했는지, 그리고 모르는 것을 어떻게 해결하며 조금씩 팀의 구성원이 되어가고 있는지에 대해 이야기해보겠습니다.