07. 이 기능은 며칠 작업 분량일까
그게 측정이... 대충... 되네요...
개발일을 시작하고 가장 어색한 질문 중 하나는
"그 작업은 며칠 정도 걸리실까요?"
이다.
지금까지는 보통 언제까지가 마감, 제출일이니까 그보다 일찍 마감해서 윗선에 보고 하고 수정사항을 고친 후, 최종 제출을 하는 형태였기에 이런 질문은 처음이었다. 내가 동공이 흔들리고 사고가 정지한 채로 있으면 사수가 슥 와서 보고선
"넉넉하게 일주일 정도면 될 것 같습니다."
하고 합의를 해 준다. 어떻게 아는 걸까.
그래도 사회생활 10년쯤 한 짬밥과 눈치덕분에 대충 어떻게 이 업무를 어떻게 굴려가고, 작업이 완료되는 예상시간을 측정하는지 알게 되었다.
개발자의 업무의 대부분은 갑자기 어디선가 툭 떨어진다. 출근을 해서 이전에 하고 있는 업무가 있지만 갑자기 어디선가 누군가에게 무슨 일이 터지는 것처럼 나에게도 그렇게 새로운 업무가 생긴다. 그리고 아직 입사한 지 얼마 되지 않았을 때는, 그저 당연하게도 모든 대답은 '네' 였다. 이렇게 갑자기 생긴 업무일수록 꼼꼼하게 확인하고 물어보는 과정이 꼭 필요했다. 그렇지 않으면 내가 지레짐작으로 만들어 둔 며칠의 작업이 전혀 쓸모없는 쓰레기가 되기 때문이다.
그 업무가 외부 업체에서 요청이 온 건지, 내부 요청인지에 따라서 어떤 과정으로 소통할지는 달라질 것이다. 그렇지만 분명한 것은 "버튼 색을 화사하게 해 주세요." 라는 추상적인 요구를 듣고 '화사한 노란색으로 하자.' 하고 수정했다가 "이런 색 말고 꽃분홍으로 해 주셔야죠." 라는 반응이 되돌아올 수 있다.
말 걸기 힘들다고 눈치 보고 있다가 이렇게 된 적이 몇 번 있었다. 다들 바쁘니까 하고 그냥 넘어가다간 다음에 더 큰 일이 되어버리니, 내 업무랑 관련된 것은 어떡해서든 내가 먼저 확실하게 확인하는 것이 서로에게 좋다! 모든 업무를 다 잘했다고 칭찬받는 것은 어렵지만 이 정도의 사소한 실수는 내가 사전에 방지할 수도 있고, 나 스스로에게도 힘 빠지는 일이 될 수 있으니까 작업하기 전에 꼼꼼히 확인하자.
이렇게 업무가 어떤 내용인지 확인하는 것, 그것이 내 업무 일정을 가늠할 수 있는 첫 번째 측정기준이다.
그리고 두 번째는 그 업무내용을 지금 상황에서 어떤 방법으로 구현시킬 수 있는지 코딩기술이 두 번째 측정기준이다.
A라는 똑같은 업무도 내가 하면 3일이 걸리지만, 사수가 하면 반나절이면 완성되는 것. 그런 것이다.
근데 이 똑같은 질문을 일을 하는 내내 자주 확인하고 확인 받을 것이다. 왜 자꾸 확인을 수시로 하나... 직원들이 일을 안 해서 계속 감시하는 건가ㅜㅜㅠ 하는 생각까지 들었다. 업무 효율이 안 나면 바로 바로 쪼는 그런 무서운 업계였던 것이가?! 하는 생각이 들 때쯤에 기획회의를 하는 중 이런 이야기가 귀에 꽂혔다.
"백엔드 업무는 일주일 정도 걸리고, 프론트 일은 백엔드 일이 마무리 된 다음에 그 이후에 진행될 수 있으니 그 보다 빨리 마무리되면 말씀드리겠습니다."
프로젝트는 곧 협업이기 때문에 내 업무 내용과 일정이 계속 업데이트되고 공유되는 것, 그것이 다른 사람 업무에 필요한 것이었다. 마찬가지로 다른 사람 업무가 밀린다면 내가 당장 할 수 있는 업무의 우선순위를 바꾸어 작업하는 것. 그런 것이 필요했다. 조금 더 자세하게 풀어보자.
프론트엔드로 들어간 신입들의 가장 첫번째 과제는 보통 회사 홈페이지 구조를 파악하고 그 중에 일부를 수정하는 것이다. 나 역시도 그렇게 홈페이지를 조금 만져보고 헉헉 거리고 있을 때 쯤, 사수 없이 혼자서 만들어야 할 조그만한 프로젝트가 주어졌다.
그리하여 만드는 것은 최소한의 기능만 있는 '미니 키오스크'였다. 와아.
사수는 다른 큰 프로젝트 기초를 구성하고 있었고, '미니 키오스크'에 들어가는 기능 정도는 이제 혼자서도 해 볼 만하다고 여러 개발자분들의 응원에 힘입어 시작했다.
이렇게 프로젝트를 진행하게 되면 처음에는 엄청 많은 기능으로 완벽하게 작동하는 프로그램을 만들고 싶지만 나는 방금 태어난 1년도 안 된 햇병아리다. 아직 솜털도 빠지지 않은 개발자는 그런 일을 할 수가 없다. 그렇기에 프로젝트에서 가장 중요한 기능 단위로 업무를 나누고 그 중에서도 중요한 것과 조금 덜 중요한 것, 타 업무와 연관되어서 나중에 진행해야 할 것 등을 나눈다.
내가 만들 미니 키오스크에서 필요한 주요 기능은 4가지이고, 이 중에서 당연히 키오스크로서의 기능 개발이 먼저였고 구글 애널리틱스 기능은 시간이 되는대로 천천히 적용하는 것으로 결정되었다. 구글 애널리틱스가 큰 업데이트가 있었는데 계속 업데이트가 되는 도중이고 국내에는 아직 제대로 정리된 자료가 없어서 시간이 더 걸릴 것으로 예상했다.
백엔드와 사수가 이미 기틀을 잡아둔 것이 있어서 해당 기능들을 우선적으로 가지고 사용하기로 했고, 기획과 디자인도 대략적으로 계획된 것이 있어서 첫번째 기획회의는 가볍게 끝났다. 디자인은 당장 다음주면 나올 수 있어서 이 프로젝트 완성에 가장 변수가 되는 것은 내 코딩실력이었다. 처음으로 내가 메인으로 코딩을 하는 프로젝트였다. 이 때, 깃허브와 소스트리를 사용하는 법도 힘들게 배웠다...
회사 서버에 내 프로젝트를 처음으로 업로드 할 때는 정말 무서워서 명령어 하나 엔터 누를 때마다 사수에게 확인받았다... 정말... 이걸 쳐도... 되나요... 서버... 죽으면 어떡하나요... 업데이트 한 첫날은 퇴근길에도 계속 사이트 보면서 얘 죽으면 어떡하지... 도로 회사 가야하나... 했었다. 근데 지금도 그러하다...
이 프로젝트와 함께 다른 프로젝트를 동시에 진행하면서 기획회의를 몇 번 참여해보니 하나의 프로젝트를 완성하기 위해서 사람들이 서로 업무를 쪼개고 나눠서 진행하고 그것들을 하나씩 모아서 완성하는 과정이 계속 반복된다. 사실 일을 진행하는 과정에는 지치고 힘들어서 맨날 회의가 끝나면 '집 가고 싶어요.'하고 널부러지지만 그래도 완성된 키오스크가 잘 작동하는 거 보면 나름 뿌듯하다. 마치 옛날에 상담하던 애기들 졸업시킬 때의 느낌과 살짝 비슷했다.
기획회의를 하면서 중간에 기능이나 디자인 변경이 있을 수도 있는데, 꼭 필요하지 않거나 구현하기 어려운 것이라면 적당히 원만한 협의를 보는 것도 필요하다는 것을 배웠다.
그런 과정없이 모든 수정사항을 다 해 드립니다는 현실적으로도 불가능하고, 정해진 일정이 계속 밀릴 수 있기 때문에 서로 타협하는 것도 중요하다. 처음에 정해진 기능에서 추가로 요청이 들어오는 것이 이번 작업이 완성된 후에 추가로 붙이기로 해서 내가 해야되는 일들을 하나하나 쪼개보았다.
사실 이 일을 진행할 때는 어버버 하느라 이렇게 쪼개진 않았지만, 그래도 깃허브에서 브랜치로 커밋을 하면서 일을 하다보니 기능 단위로 일을 진행하는 습관을 들이려고 노력했다. 그래야지 큰 오류가 났을 때 금방 이전 코드로 복귀해서 수습을 할 수가 있기 때문이다 (mm).
리액트를 쓰면 어쩔 수 없이 graphQL을 접하고 그러면 Apollo를 쓰게 되시겠다. 얘네로 데이터를 불러오고 수정하는 것을 먼저 학습하고, 틈틈히 GA4 관련된 내용도 찾아보면서 개발팀에 공유할 자료도 만들었다. 기존 유니버셜과 달라진 데이터도 많고 UI 자체도 바뀌어서 이전 버전을 사용하셨던 분들도 낯설어하셨기 때문이다.
1. 주문목록 보이기는 들어오는 DATA만 확인하면 금방 해결할 수 있었다.
2. 상태값을 여럿 써야하는 장바구니 구성이 어려웠다. 예상했던 시간이 지나 사수의 도움을 받게 되었다.
3. 2번이 막히는 동안 3번 후반부를 먼저 진행해두었고,
4. 구글 애널리틱스는 관련 라이브러리 2개를 다 사용해보고 그 중에서 더 사용하기 편리한 것으로 골랐다.
이 프로젝트는 중간 중간 정말 협업할 것이 많지 않아서 그나마 다행이었지만, 만약 내가 2번 기능 같은 일로 업무가 막혀서 일정이 밀리게 된다면 관련된 사람들에게 알려서 일정을 조율한다거나 아니면 다른 개발자에게 도움을 요청하는 등의 행동이 필요할 것이다. 내가 못함을 인정하는 것이 늘 어렵지만 하지만 이 부분은 다른 개발자들도 계속 반복해서 신입 개발자들에게 충고해주는 부분이었다. 아직 나도 잘 못하곤 있지만 다들 조금의 부끄러움을 이겨내고 잘 이야기 해 보자.
그래서 요즘엔 기획회의에 들어가서 자주 '아, 그 기능 지금 단계에서 필요없을 거 같은데' 하면서 슬쩍 누워보기도 한다. 그리고 처음과 같은 질문이 들어와도 그때처럼 마냥 당황하지만은 않는다. 속으로 천천히 생각을 해 보자.
그 기능을 하기 위해서는 어떤 어떤 구조로 코딩을 해야하고, 그러면 내가 추가로 더 알아야하는 것이 무엇인지. 내가 그거랑 비슷한 기능을 구현했을 며칠이 걸렸고, 그 과정에서 에러가 발생할 가능성을 생각해서 여유시간을 1일 정도 더해서. 그러면 내가 대충 작업을 완료할 수 있을 시간을 추정할 수 있다. 운이 좋아서 더 일찍 끝내면 기분도 좋더라. :)
