3장. 업무 프로세스를 이해하면 길이 보인다
3-1. 코드는 알겠는데, 일은 모르겠다
한 신입 개발자가 있었다. 그는 학교에서 성적도 좋았고, 개인 프로젝트도 여러 개 해본 터라 자신감이 넘쳤다.
그런데 첫 프로젝트에 투입되자마자 당황했다. “이 버튼을 누르면 대출 신청이 되는 API를 만들어주세요.”
기능 구현 자체는 간단했다. 하지만 막상 코드를 짜다 보니 이런 질문들이 꼬리를 물었다.
대출 신청은 언제 가능해야 하지?
금액 제한은 누가 정하는 거지?
신청 후 바로 실행되는 건가, 아니면 심사 단계를 거치는 건가?
오류가 나면 어디까지 롤백해야 하지?
코드는 짤 수 있었다. 하지만 업무의 흐름을 모르니, 어디까지 구현해야 하는지조차 확신이 서지 않았다.
회사에서의 프로세스는 ‘귀찮은 관리 도구’가 아니다.
그건 곧 개발자가 움직이는 지도다.
예를 들어 대출 업무라면, ‘조회 → 신청 → 심사 → 실행 → 상환’이라는 전체 흐름이 있다.
개발자는 이 중 작은 API 하나를 담당하더라도,
그 API가 어느 시점에 호출되는지, 앞뒤 단계와 어떤 데이터를 주고받는지를 알아야 한다.
지도 없이 여행을 떠나는 것과 같다.
길은 열심히 걷는데, 목적지가 어디인지 모르니 계속 불안하다.
업무 프로세스를 이해하면 비로소 “아, 지금 내가 걷는 길이 여기구나” 하고 좌표가 찍힌다.
신입에게 가장 혼란스러운 건, 프로세스 자체보다 프로세스를 표현하는 단어들이다.
회의에서 이런 말이 오간다고 상상해보자.
“이번 스프린트에 백로그 태스크를 좀 줄입시다.”
“이건 에픽 단위에서 관리하는 게 맞아요.”
처음 들으면 마치 외계어 같다.
하지만 사실은 단순하다.
백로그(Backlog): 해야 할 일의 목록
스프린트(Sprint): 정해진 기간 동안 처리할 업무 묶음
에픽(Epic): 큰 목표, 예를 들면 ‘대출 서비스 개선’
태스크(Task): 구체적인 할 일, 예를 들면 ‘대출 신청 API 만들기’
즉, 거창해 보이는 용어들도 결국은 “큰 목표 → 작은 일 → 기간별 실행”으로 정리된 구조일 뿐이다.
이 틀을 이해하면, 더 이상 회의 시간이 두렵지 않다.
한 번은 신입 개발자가 기획이 아직 확정되지 않은 기능을 ‘미리 준비한다’며 구현해버렸다.
결과는? 기획이 바뀌면서 그 기능은 전부 폐기되었다.
며칠 동안 밤새 만든 코드가 단 하루 만에 쓰레기통으로 들어갔다.
또 다른 경우는 QA 일정을 몰라서 문제가 생겼다.
“내일까지 수정해드리겠습니다.” 하고 쉽게 약속했지만,
사실 QA가 이미 테스트를 끝내버린 상태였다.
결국 QA 일정이 깨지면서 배포 전체가 지연되었고, 팀장에게 한참 혼이 났다.
이런 경험을 해보면 알게 된다.
프로세스를 모르는 건 단순한 무지가 아니라, 팀 전체를 흔드는 리스크라는 것을.
프로세스를 완벽히 아는 건 시간이 걸린다.
하지만 신입이라면 당장 이런 습관부터 가질 수 있다.
질문 습관: “이 업무가 끝나면 어떤 단계로 넘어가나요?”
그림으로 정리: 백로그 보드나 프로세스를 직접 도식화해본다.
문서 탐독: Confluence, 사내 위키, 운영 매뉴얼을 틈틈이 읽는다.
연결 의식: 내 코드가 앞뒤 단계와 어떻게 이어지는지 항상 생각한다.
이 습관은 신입이 단순히 ‘코더’에 머무르지 않고,
조금씩 팀의 전체 흐름을 이해하는 ‘프로세스 플레이어’로 성장하게 만든다.
개발자로서 첫 해는 코드를 배우는 시기이자,
동시에 업무가 돌아가는 방식을 배우는 시기다.
프로세스를 이해하지 못하면 늘 불안하다.
하지만 흐름을 알게 되는 순간,
“내가 지금 어디에 있고, 무엇을 해야 하는지”가 명확해진다.
그리고 그때부터, 당신의 일은 단순한 기능 구현이 아니라
팀과 비즈니스를 함께 움직이는 일이 된다.