주니어 개발자의 개발 일정 산출 노하우 세미나

 

 

 

'이거 만드는데 어느정도 걸리세요?'라는 질문 받을때마다 항상 난처했었다. 요구사항 분석을 하긴 했지만 실제로 개발 들어갔을때 내가 얼마나 걸릴지, 어떤 문제를 마주칠지 알 수 없으니 몇일 걸릴거라는 예상을 하기가 힘들었고, 개발속도가 느리고 능력없는 개발자로 비칠까봐 실제 내가 생각하는 예상공수보다 더 적게 얘기한 경우도 있었다. 이런 고민에 대한 해답을 찾는데 도움이 된 세미나에 참여하게 되었다. 주니어 개발자가 겪는 개발 일정 산출에 대한 고민을 이미 겪고, 다양한 환경에서 업무경험을 쌓으신 오윤지 개발자님이 발표해주셨다.

 

 

 

개발일정 산정 이전에 고려해야할것

먼저 자신이 속한 조직이 어떤 조직인지 파악할 필요 있다. 조직의 종류에 따라 일정 산출 방식이 달라질 수 있다. 

 

기능조직 vs 목적조직

기능조직

ex) 개발팀, 기획팀, 디자인팀

일정 수립 프로세스에 대한 의견을 조직장에게 구한다.

 

목적 조직

ex) 

결제팀 - PM, 디자이너, 개발자

주문팀 - PM, 디자이너, 개발자

광고팀 - PM, 디자이너, 개발자

유연하게 빠르게 서비스 개선 가능

주도적인 개발자가 좀더 적합

 

개발 일정 산출 역량

서비스 성숙도가 낮을 수록 일정 산출 역량 중요

수익 모델 찾기 위해 여러 MVP를 자주 만들 확률이 높음..

 

개발자의 일정 산출 역량이란

주어진 기획서 대로만 일정 수립 하는게 아니라 개발적으로 빠져있는 것들, 개발자가 아닌 사람이 봤을때 빠뜨린 부분까지 고려해서 일정 산출하는 역량

 

조직에서 역할별로 일정 산출 역량 중요

주니어는 상대적으로 위에서 주어지는 일정대로 맞춰서 개발하는 경우가 많음

시니어로 갈수록 프로젝트 리딩을 하게 되면 여러가지 검토하고 일정 산출 직접 해야함

 

연사님의 경험 공유

연사님이 서비스 성숙도가 낮은 회사에서 실제 겪은 사례를 공유해주셨다.

1. 물어볼 사람이 없으면 교과서라도 본다

입사한 직군(프론트엔드)의 업무와는 전혀 다른 개발 업무 요청이 들어옴

해당 개발 건에 대한 일정 산출 및 계획서 제출 요청이 들어옴

물어볼 사수가 없는 상황이었고, 관련 서적 참고

 

연사님이 참고한 책 ▼

소프트웨어공학(1학기, 워크북포함) : 네이버 도서

(진짜 방통대 교과서를 참고하셨다..)

 

 

1-1. 적극적인 커뮤니케이션 통한 요구사항 분석

사람마다 각자 똑같은 것을 봐도 다르게 생각할 수 있다.

[예시]
요청사항: ‘과일 담을 것을 만들어주세요’
요청고객이 생각한 것 → 과일 바구니
개발자A가 생각한 것 → 에코백
개발자B가 생각한 것 → 카트
기획자가 생각한 것  → 접시

 

 

최대한 많은 질문을 통해 요구사항을 명확하게 만든다.

[연사님 실제 사례]
요청사항: 미디어 파일 업로드할 수 있는 서버를 만들어주세요
질문:
업로드가능한 미디어 파일의 종류 
다운로드 권한?

 

미디어 파일의 종류에 대한 질문 시에 모든 종류의 파일을 다 지원하는 것은 무리이니 이번 배포버전에 지원되는 파일로 좁혀서 질문했다고 한다.

질문을 통해 고객사와 요구사항을 명확히 할때에 개발적으로 기획자가 생각하지 못한 부분이 있다면 개발자가 찾아서 확인해달라고 요청해야한다.

 

1-2. 개발프로세스 별 일정 산정

프로세스별 일정 산정에 고려했어야 했던 점들
설계	구현	배포준비
리서치	프로토타이핑 목표 수립 및 개발	로깅
아키텍처 설계	아키텍처 수정	배포 인프라 구성
모듈 설계	기능,성능,부하테스트	클라우드 사용시 예상 비용 측정
피드백 & 반영	피드백 & 반영	피드백 & 반영

 

설계

리서치 하고 내용 공유하고 상사에게 컨펌받고 하는 과정을 고려해서 설계 → 1주일

피드백&반영 하는 과정도 일정에 포함하도록 한다.

 

구현

프로토타이핑 - 핵심 기능 먼저 개발하고 이후 수정

프로토타이핑 하는 단계부터 테스트를 일정에 포함한다.

 

테스트

성능 중요. 성능 테스트 반드시 해본다. 기능 만들고 끝이 아니고 중간중간에 테스트 하는 과정을 거친다.

추후에 본 제품 개발할때 원래 생각했떤 것과 다르게 개발될 수있음..

 

배포 준비

얼마나 걸릴지 어떻게 할지 인프라 구성 어떻게 할지 PM에게 알려준다.

 

 

2. 기록하고, 일을 쪼개어 일정 산정의 정확도를 높인다

2-1. 개발일지 작성

안해봤던 작업, 병목이었던 작업, 얼마나 시간 걸렸는지 세세하게 기록

• troubleshooting
• todo, 회고(배운점, 개선할점), 백로그
• 회고 반드시 할것

2-2. 작업 잘게 분할한다

화면 기획서를 받은 후 작업 분할

• UI 컴포넌트 작업
• 상태관리 및 API 연동 작업
• 화면 작업

연사님은 노션 데이터베이스 테이블에 Estimate 항목을 만들어서 시간단위로 숫자값을 넣고 sum을 해서 총 얼마나 걸릴지 쉽게 확인할 수 있도록 함

 

2-3. 커뮤니케이션 비용을 최소화할 수 있도록 투명하게 공유하고, 리스크에 대해 사전에 함께 대비

백엔드 API 완성이 안 되었어도 API Mocking해서 먼저 작업하기. 이때 백엔드와 매우 적극적으로 커뮤니케이션, 피드백 받아야함(ex. 이렇게 mocking 해봤는데 실제 api 응답값도 이렇게 나올까요?)

 

3. 버퍼 두기

일정 산정 후 버퍼(추가)시간을 꼭 넣어라.

개발하다보면 예상대로 진행되는 경우가 드물고 반드시 병목이 반드시 생긴다.

과거 태스트와 일치도 버퍼
90% 이상	0
50% 이상	버퍼 2일
0~50%	2배

(ex. 과거 태스크와 90% 이상 비슷할 경우, 버퍼 0)

 

공휴일, 휴가, 작업할 수 없는 근무 시간(정기 회의시간, 회사 행사 등)을 고려하여 일정산정

프로젝트의 중요도와 개인 일정의 중요도를 잘 고려하여 타협점을 찾는다

비슷한 일 해본 동료나 상사, 커뮤니티에 우려되는 병목 지점 없는지 적극적으로 의견 구하기

4. 프로젝트 진행 중 일정 변경될때 대처방식

빠르고 효과적으로 공유하기

빠르게 공유

연사님의 경우, 이슈 생겨서 오래 걸린다면, 최대 하루 혼자서 해보고, 이틀째 걸린다면 바로 공유

 

효과적으로 공유

기획자에게 공유할때

• 이슈에 대해 어떤 방법 시도해봤는지
• 해결방법 리서치 결과
• 혼자서 해결할려면 얼마나 걸릴지
• 도움을 받을 수 있다면 얼마나 걸릴지

등 무조건 세세하게 문서화 해서 공유한다.

 

 

Q&A

Q. 문제 해결 못했을때 최악의 경우 예측, 우회법, 대안이 무엇인지

A. 회고 무조건 할것!!!

 

Q.동료 개발자의 일정 산정에 자의 반 타의반 따라서 비슷하게 산출하는 경우가 있는데, 실제로 개발자분들의 배경이 모두 다르다보니 그런 방법으로 산출하게되면 일정이 딜레이됩니다. 만약 동료 신입개발자분이 일정에 대해서 이런 압박을 받고 계신다면 어떻게 하면 좋을까요?A. (연사님이 속해있던 팀의 팀 문화) 다같이 있는 자리에서 3,2,1! 일정 동시에 얘기해서 나온 숫자 중에 가장 긴 숫자로 산정

 

Q.개발일지나 회고를 시간을 정해서 작성하는가?

A. 출근 직후 개발일지에 오늘 개발할거 적고, 퇴근전에 그 일지에 뭐했는지 등 회고 적기

 

Q. 주니어 때부터 비즈니스 적으로 생각해보는 훈련 어떻게?

A. 돈과 연관되어있으면 비즈니스이다. 다른 직군과도 기능 관련 얘기해보거나 개발자라면 좀 관대해질수있는데 유저 관점에서 이 돈 주고 쓸만한 기능인가? 등을 생각해보기

 

Q. 이력서나 면접에서 개발일지, 회고 등을 어떤 식으로 활용하는지

A. 경험을 얼마나 깊게 했는지에 대한 질문 면접에서 많이 받음. 면접 전에 회고, 개발일지 다 읽고 숙지하고 면접

 

Q. 회사가 문서화에 대해서 회의적인데 어떻게 하면 좋을지

A. 회사에서 문서화에 대해 회의적이라도 개인적으로라도 계속 문서화한다. 공유하고서 혼나는 것에 대해 두려워하지 말자

 

Q. 마감 직전에 고객사가 기능 추가 요구한다면?

A. 일단은 철야해서라도 만들되 성과평가자에게 어필을 많이 한다.

이러한 요구사항을 들었을때 이 기능이 진짜 중요한가 아닌가? 개발자로서 이 프로덕트가 엉망인가? 를 따져봤을때 그냥 나가도 될거같다고 판단되면 안하는 방향으로.. 

일정이 너무 빠듯하다고 말하는 게 어려운 회사라면 이직..

 

A. 경험을 깊게 해라

하나의 서비스를 만들더라도 3개의 서비스를 만든것처럼 깊게

문제 하나를 발견했을때 그 문제와 연관된 서브 문제에 대해 깊이 파보기. 가지 뻗어나가는 방식으로 공부

ex) 회원가입/로그인 → 인증, 인가 → 요즘의 인증,인가 방식 → OAuth, SSO?

 

 

 

느낀점

배민 개발자가 괜히 배민 개발자가 아니구나...

주니어 때 개발일정 산출, 기획서 작성 관련 물어볼 사수 없을때 방통대 교과서(소프트웨어공학) 참고 하신거 보고 정말 남다른 개발자 분이라고 생각했다.

또한 다시한번 회고의 중요성과 무엇이든 세세하게 기록하는 것이 중요하다는 걸 느끼게 되었다.

특히 일정 산정시 버퍼를 두는 방식에 대해서 새로 알게되었고, 버퍼 두기를 하려면은 내가 실제 개발할때 얼마나 걸리는지를 평소에 자세하게 체크해둬야 그 방식을 사용할 수 있겠다는 생각이 들었다. 평소에 기록하는 습관을 잘 들여놔야겠다.