프로젝트 흐름
전체를 봐야 한다.
프로젝트에 투입되면 가장 먼저 받는 게 화면설계서다. 두께는 프로젝트마다 다르지만, 보통 100페이지는 훌쩍 넘는다. 그중 내 담당은 고작 3페이지. 나머지 97페이지는 다른 사람 몫이다.
"내 것만 보면 되지 않나?"
신입 시절, 당연히 그렇게 생각했다. 할당받은 기능만 파악하고, 나머지는 훑어보지도 않았다. 프로젝트 관리자가 건네준 페이지만 펼쳐서 확인하고, 바로 코딩에 들어갔다.
문제는 며칠 뒤에 터졌다.
개발을 끝내 테스트에 넘겼는데, 데이터가 제대로 넘어오지 않았다. 앞 화면에서 처리한 정보를 받아야 하는데, 예상과 전혀 다른 형태로 들어왔다. 급하게 앞 화면 개발한 동료에게 물었다.
"이 데이터, 이렇게 보내주시기로 한 거 아니었나요?"
"화면설계서에 이렇게 나와 있는데요."
설계서를 다시 펼쳐보니, 그렇게 적혀 있었다. 내 담당 화면만 보느라, 바로 앞 화면의 데이터 처리 방식을 확인하지 않았던 거다. 개발한 코드를 처음부터 다시 짜야했다.
화면설계서 100페이지, 하나의 흐름이었다. 내 담당 3페이지, 그 흐름 속 한 조각에 불과했다.
쇼핑몰 프로젝트였다. 전체 화면은 500페이지를 훌쩍 넘기고, 고객의 상품 검색부터 결제까지 화면으로는 대략 100페이지 정도였다. 화면도 많은데, 뒤에서 돌아가는 시스템은 훨씬 복잡했다.
담당 업무는 상품 상세 화면 개발이었다. 고객이 상품 리스트에서 상품을 누르면 상세가 보이고, 장바구니, 결제 버튼을 누르면 해당 페이지로 넘기는 기능. 얼핏 단순해 보였다.
화면설계서를 처음부터 끝까지 읽는 데 이틀 걸렸다. 처음에는 불필요한 시간낭비 같았다. 전체를 보고 나니, 보이지 않던 것들이 보이기 시작했다.
상품 리스트에서 상세로 넘어올 때 단순히 상품 정보만 오는 게 아니었다. 할인 쿠폰 적용 여부, 적립금 적용 여부, 태그 정보, 재고 여부, 판매 여부까지 함께 넘어왔다. 장바구니 클릭 시 장바구니 시스템에 데이터를 넘기고, 받아와서 장바구니 카운트를 업데이트해야 한다.
상세 화면 하나였지만, 실제로는 앞뒤 다섯 개 화면과 연결되어 있었다. 그중 하나라도 놓치면 데이터가 끊기거나 잘못된 결과가 나왔다.
앞뒤 화면을 집중적으로 봤다. 리스트에서 어떤 데이터를 만들어 보내는지, 장바구니 담기 완료 후 어떤 정보를 가져오고, 어떤 정보를 보내야 하는지 확인했다. 화면설계서에 적힌 작은 메모 하나하나가 전부 의미를 갖고 있었다.
개발 중간에 기획자에게 질문할 일이 줄어들었다. 대부분의 답은 이미 화면설계서 어딘가에 적혀 있다. 전체를 봤기에, 어디에 뭐가 있는지 알 수 있다.
찰리 채플린의 <모던 타임스>. 공장 노동자가 컨베이어 벨트 앞에서 나사만 계속 조인다. 무엇을 만드는 지도 모른 채, 그저 눈앞의 나사만 돌린다.
화면설계서 전체를 보지 않는 개발자가 그 모습이다.
한 프로젝트에서 만난 개발자는 자기가 개발하는 기능이 전체에서 어떤 역할을 하는지 전혀 몰랐다. 그저 할당받은 코드만 짰다.
"이거 왜 이렇게 만들어야 해요?"
"화면설계서에 그렇게 나와 있으니까요."
"근데 이게 어디에 쓰이는 건데요?"
"그건... 잘 모르겠는데요."
전체를 보지 못하니, 자기가 만든 기능의 의미를 알 수 없었다. 의미를 모르니, 제대로 만들어졌는지도 판단할 수 없었다.
테스트 단계에서 문제가 터졌다. 기능은 작동하는데 데이터가 맞지 않았다. 앞 화면에서 넘어온 정보를 제대로 처리하지 못했다. 화면설계서를 다시 확인하니, 앞 화면에 대한 내용은 10페이지 전에 나와 있었다.
"전체를 보셨어야죠."
프로젝트 관리자가 한마디 했다. 그 개발자는 며칠간 밤을 새워 코드를 다시 짰다. 처음부터 전체를 봤다면, 한 번에 끝낼 수 있었던 일이었다.
중소규모 프로젝트에 투입됐을 때였다. 화면설계서는 80페이지 정도였고, 내가 담당한 부분은 그중 5페이지였다. 처음부터 전체를 읽었다.
내가 개발할 화면과 비슷한 기능을 다른 화면에서도 발견했다. 사용자가 버튼을 누르면 팝업이 뜨고, 정보를 입력하면 저장하는 단순한 구조. 거의 똑같았다.
다른 개발자에게 물었다.
"이 화면이랑 제 화면, 거의 비슷한데 같이 개발하면 안 될까요? 공통 코드로 만들면 둘 다 쓸 수 있을 것 같은데요."
"아, 맞네요. 그럼 제가 먼저 만들고 공유할게요."
개발 시간이 반으로 줄었다. 같은 코드를 두 번 만들 필요가 없었다. 나중에 수정할 일이 생겨도, 공통 코드 한 곳만 고치면 두 화면에 모두 적용됐다.
전체를 봤기에 가능한 일이다. 내 담당만 봤다면 똑같은 기능을 따로따로 만들고. 코드는 중복되고, 유지보수는 두 배로 힘들어졌을 것이다.
10년 차쯤 됐을 때, 프로젝트에 투입되면 가장 먼저 하는 일은 화면설계서 정독이었다. 100페이지든 200페이지든 처음부터 끝까지 읽었다. 메모도 많이 남겼다. 비슷한 기능끼리 표시하고, 데이터 흐름을 화살표로 그렸다.
프로젝트 전체, 하나의 그림처럼 보였다. 어디서 데이터가 시작되고, 어떻게 흘러가고, 어디서 끝나는지. 각 화면이 어떻게 연결되어 있는지. 한눈에 들어왔다.
개발 중에 막히는 일이 줄어들었다. 데이터를 어떻게 처리해야 할지 모르면 앞뒤 화면을 다시 확인했다. 대부분 거기에 답이 있다.
다른 개발자들과 협업할 때도 수월하다. 전체 흐름을 알고 있으니, 누가 어떤 부분을 개발하는지, 서로 어떻게 연결되는지 파악할 수 있다.
"이 데이터, 이렇게 보내주시면 될 것 같은데요."
"네, 알겠습니다. 그럼 형식, 이렇게 맞춰드릴게요."
간단한 대화만으로도 서로가 원하는 게 무엇인지 정확히 이해할 수 있다. 전체를 보기 때문이다.
화면설계서 100페이지 중 내 담당은 3페이지일 수 있다. 나머지 97페이지를 보지 않으면, 그 3페이지조차 제대로 만들 수 없다.
프로젝트는 흐름이다. 데이터는 한 화면에서 멈추지 않고 계속 흘러간다. 그 흐름을 이해하지 못하면, 결국 어디선가 막힌다.
내 담당 3페이지를 위해 전체 100페이지를 읽어야 하는 이유이다.
