2년차 주니어 프론트 개발자가 시니어 프론트 개발자가 되기 위해 하게 된 일 : 기획 분석 / 기능 정의서 작성하기

 

나는 사실 시니어 개발자가 되고싶진 않다.

시니어 개발자가 된다는 것은 그만큼 더 많은 책임을 져야 한다는 사실..

그리고 실무 외의 일도 하게 될 가능성이 높아진다.

 

난 둘 다 원하진 않는다.

그렇다고 평생 주니어 개발자로 일하고 싶냐?

하면 그건 더더욱 아니기 때문에 결국은 한 발짝을 떼야 한다는 것!

그래서 요 몇 개월 간 내가 기존 업무 방식에서 어떤 변화를 주었는지에 대해 작성해보고자 한다.

 

---

내가 생각하는 주니어와 시니어 개발자의 차이는  🔎

 

1. 내가 만들어야 하는 것이 뭔지 손바닥 안에 전부 있다.

기획을 기획자의 의도대로 이해하는 것 또한 중요한 스킬!

 

 

2. 개발하는데 얼마나 걸리고, 어느 부분에서 시간이 걸릴 지 개발 전 단계에서 파악이 가능하다.

즉 업무 스케쥴을 정확하게 짤 수 있다.

 

 

3. 소프트 스킬이 더 좋다.

기획자, 디자이너와 소통할 때 '이건 시간이 오래걸려요', '이건 개발 공수가 너무 커요' 같은 

상대가 전혀 공감할 수 없는 방식으로 소통하는게 아니라

'이건 oo해서 oo하는 것이 oo이유로 더 합리적이기 때문에 oo방식으로 기획/디자인 수정을 요청드립니다'

 

와 같이 이유를 제대로 설명해서 상대를 납득시킬 수 있어야 한다.

 

(주관적인 의견입니다. 주니어 분들 중에도 이미 이 세 가지를 충족하시는 분들이 계시겠지요?)

 

---

업무 방식 레벨 UP 🌅

 

1. 기획 분석 문서를 작성한다. 

기획서를 읽고 바로 계획을 짜기 전에,

기획서를 분석한 문서를 먼저 작성하는 것이 좋다.

 

나중에 이 문서를 기반으로 기능 정의 문서를 작성할 수 있고,

기획이 말도 없이 변경되거나, 기획과 디자인이 상이하거나, 기획자와 싸울 때

이 문서가 큰 도움이 되기 때문이다.

 

무엇보다 한 번 작성하고 나면 기획서는 내 손바닥 안에 있 듯 훤해진다.

오히려 기획자보다 기획에 대해 더 꼼꼼하게 알게 된다.

 

1. 기획서를 읽고 유저 플로우를 작성한다. 

2. 플로우 순서대로 기능을 큰 덩어리로 쪼갠다.

3. 쪼갠 덩어리를 하나씩 살펴보며 기획서를 다시 한 번 읽는데, 이번엔 한 덩어리 당 자세한 기능 명세를 작성한다.

 

예시

1. 유저 플로우
    - 회원가입 페이지 접속
    - 개인정보 입력
    - 아이디 중복 검사
    - 가입 요청완료

2. 플로우 순서대로 기능 쪼개기
    - 개인정보 입력
    - 아이디 중복 검사
    - 가입 요청

3. 기능 명세
    1. 개인정보 입력
         a. 아이디 validation
         b. 비밀번호 정규식 validation
         c. 필수값 비 입력 시 버튼 비활성화

    2. 아이디 중복 검사
         a. 아이디 중복 검사하는 api 호출
         b. request param : {id : number}

    3. 가입 요청
         a. 가입 요청 api 호출
         b. request body : {id : number, password : string .....}

 

2. 기능 정의 문서를 작성한다.

기능 정의는

어떤 api가 필요하고,

각 api의 요청 데이터와 응답 데이터는 어떻게 와야 하는지,

에러가 발생할 경우 에러 리스폰스는 어떻게 와야 하는지 정의하는 것이다.

 

이걸 프론트 개발자가 해야 하는 이유는 아래와 같다.

1. 프론트와 백엔드 개발이 병행될 때 보통은 api가 아직 없음.
2. 프론트 개발자가 화면을 다 만들고 기능을 붙일 때 서버에서 불러온 데이터가 필요할 때가 겁나 많다.
3. 손 놓고 api가 만들어지길 기다릴 순 없다.
4. 그래서 데이터가 어떻게 올지 예상하며 mock데이터를 만들어서 개발을 한다.
5. api가 완성되고 보니 내가 만든 mock데이터랑 생김새가 완전 다르다!
6. 개발된 부분을 자잘하게 수정하느라 개발 공수가 늘어난다.

이렇기 때문에 완성될 api의 그림을

차라리 내가 먼저 그려놓고 백엔드 개발자에게 이렇게 만들어주세요~ 요청하면

나는 마음 놓고 내가 만든 데이터를 가지고 프론트 개발을 빨리 마칠 수 있다.

 

예시

< get list api >
- request : { id : number}
- response
    - success
       - data : { id:number, name:string}
    - error
       - { statusCode: 500, message : '에러 메시지' }
...

 

이런 식으로 api 목록을 세우고 request, success response, error response를 정의해주면 된다.

 

---

 

마치며

이 방식으로 한 차례 개발을 마쳐본 후기는,

처음에 시간이 많이 든다고 생각했지만 개발에 들어가니 

개발 속도가 무지 빨라짐.

기획자와 백엔드 개발자에게 당당해짐.

기획서는 꼼꼼히 읽었고, 오히려 기획서에서 누락된 부분으로 질문 발사 타타타탓~

기능정의서에 대해서 백엔드 개발자가 별 말이 없었다면

그대로 개발해주겠다는 것이기 때문에

api의 내용이 다를 경우 당당하게 '이거 고쳐주세요' 할 수 있었다.

아직 시니어로의 길은 멀었지만 이러한 업무 방식을 통해 훨씬 발전했다고 느낀다!