[IT 회사 생활] 개발 업무는 어떤 순서로 해나가면 좋을까?

※ 일본의 한 포스팅을 번역한 글입니다. 오역 및 직역, 의역이 있을 수 있으며 틀린 내용은 지적해주시면 감사하겠습니다.

 

이번 포스팅에서 가정하고 있는 개발 업무

• 어플리케이션은 이미 수 년간 운용중인 Rails 어플리케이션
• 상품의 목록 화면에 "CSV 다운로드 버튼을 추가"하길 바라는 개발 업무
• 로컬의 개발 환경은 모드 셋업이 완료되어 있는 상태

 

 

[순서1] 현재 진행 중인 사양(시스템의 움직임)을 확인하기

---

 먼저 로컬 환경에서 Rails 어플리케이션을 동작시켜보면서 현재 어플리케이션은 어떤 흐름으로 움직이고 있는 사양을 확인한다. 예를 들어, 이번에 할 개발 업무인 "CSV 다운로드 버튼"을 추가할 화면에 어떻게 액세스하면 좋을지를 확인하는 등이다.

 "변경하는 것이 이 화면이니까"라고 전달받더라도, 정작 로컬 환경에서 개발하려면 어떤 링크를 따라가야 그 환면에 도달할 수 있는지 알 수 없거나 데이터 혹은 권한이 부족해서 화면이 표시되지 않는 경우도 꽤 있다.

 

 

[순서2] 기능 추가의 요건이나 구체적인 변경 내용을 확인하기

---

 다음은 기능 추가의 요건이나 구체적인 변경 내용을 확인한다. "CSV 다운로드 버튼을 추가해 CSV를 다운로드 할 수 있게 하면 되겠지?"라고만 생각하면 간단하게 느껴진다.

• 화면의 어떤 위치에 어떤 버튼을 추가할 것인가?
• 버튼을 링크했을 때 어떤 움직임이 되는가?
  • 확인 다이어 로그 표시는 필요할까?
  • 버튼을 링크한 후에 버튼을 disable하지 않아도 괜찮을까?
• CSV 파일에는 어떤 데이터를 출력하도록 할까?
  • 어떤 컬럼에 어떤 데이터를 출력할 것인가?
  • 데이터의 출력순서는 어떻게 할 것인가?
  • 날짜 표시 포맷은 어떻가 할 것인가? "yyyy/mm/dd"로 할 것인가? "yyyy-mm-dd" 혹은 또 다른 포맷으로 할 것인가?
• CSV 파일의 인코딩은 무엇으로 할 것인가? UTF-8으로 할 것인가? 아니면 또 다른 인코딩으로 할 것인가?

등등 단순한 CSV 다운로드 기능에도 꽤 많은 것들을 고려해야한다.

 또한, 기존의 다른 화면에 CSV 다운로드 버튼이 있다면 그 움직임도 확인해야한다. 

 

이상현상이나 보안 상의 사양도 검토하자.

 이상 현상이란 "경우에 따라 일어날 수 있는 그다지 반갑지 않은 동작 패턴"이다. CSV 다운로드의 경우로 말하자면, 다음과 같은 이상 현상이 발생할 가능성이 있다.

• 출력할 데이터가 0건인 경우 어떻게 할 것인가? 헤더 행만 다운로드하도록 할 것인가? 아니면 어떠한 특별한 방법으로 유저에게 알림을 줄 것인가?
• 다운로드하려고 한 데이터에 콤마 혹은 개행이 포함되어 있는 경우(즉 CSV 파일의 포맷을 망치는 데이터가 포함된 경우), 어떤 형식으로 출력할 것인가?

 그 외에도 로그인하지 않은 유저나 권한이 없는 유저가 잘못해서 (혹은 악의를 가지고) 직접 다운로드용 URL에 액세스해 온 경우등 보안상의 문제도 고려해야할 필요성이 있다.

 

업무의 배경이나 유스케이스도 확인하자.

 "무엇을 만드면 좋을까?" 뿐만 아니라 "왜 이 업무가 필요한 것일까?"이라는 배경도 확인해두자. 혹은 추가로, 이번에 만들 새로운 기능이 어떤 유스케이스서에서 사용되는지를 확인해두자.

• 어떤 입장의 유저가
• 언제, 얼마나 빈번히 이 기능을 사용해
• 이 기능을 사용하여 어떤 업무를 하는가 (예: 다운로드한 CSV 파일을 어디에 사용할까?)

 이라는 점도 확인해두면 좋다는 의미이다.

 배경이나 유스케이스를 알아두면, "그러한 목적이라면, 이렇게 움직이도록 만드는게 좋을 것 같다" 혹은 "애초에 유저가 필요한 기능은 CSV 다운로드뿐만아니라, 화면에 표시되고 있는 데이터의 정렬 순도 필요하지 않을까?"이라는 시점에서 업무 내용을 파악할 수 있다.

 

 

[순서3] 현재의 로직이 어떻게 구현되어 있는지를 확인하기.

---

  다음은 소스코드와 함께 현재 로직이 어떻게 구현되어 있는지를 확인하자.

• 상품의 목록 화면은 어떻게 구현되어 있는가?
• 서버 사이드에서 Rails가 HTML를 랜더링하여 응답을 돌려주고 있는가?
• React나 Vue.js 등 어떤 프론트엔드 프레임워크를 사용하여 화면을 그리고 있는가?
• 이 때, API는 어디서 어떻게 어떤 데이터를 공급하고 있는가?
• CSV에 출력할 항목은 어떤 테이블의 어떤 컬럼에서 출력되고 있는가?
• 모델과 모델의 관계는 어떻게 되어 있는가?
• 기존의 CSV 다운로드 기능이이 있다면, 그것은 어떻게 구현되어 있는가?
• 공통 부품이나 공통 로직이 이미 있고, 차이만 구현하면 되는 것이 아닌가?

 담당하게 된 업무의 내용이나 화면의 동작만 보면 엄청 심플하지만, 로직과 함께 살펴보면 왜 이렇게 애매하지 싶은 경우들이 꽤 있다.  생각이상으로 현재 실행중인 로직이 복잡하여, 어떤 순서로 움직이고 있는지 잘 모를 때에는 선임 엔지니어에게 물어보자.

 

실제 환경의 데이터양이나 퍼포먼스 목표도 확인하자.

 이번에 예로 든 CSV 다운로드 기능이라면, 실제 환경의 데이터 베이스는 어느정도 데이터가 들어있고, 한번에 최대 며 건 데이터하도록 할 것인가를 확인해둘 필요가 있다.

 따라서, 개발 환경에서는 몇 초만에 다운로드됐지만, 실제 배포 환경에서는 10분 이상 기다리지 않으면 다운로드가 끝나지 않는 등의 문제가 발생한다. 시간이 너무 걸릴 것 같은 경우는 다음과 같은 대책을 생각해볼 수 있다.

• 스트리밍 형식으로 다운로드한다.
• 비동기로 CSV 파일을 생성한다.
• 배치 처리로 정해진 시간에 CSV 파일용 데이터를 생성한다.
• SQL를 튜링하거나 특정 칼람에 index를 붙여놓는다.
• 검색 조건을 엄격하게 설정하여 한 번에 취득하는 데이터의 건 수를 조정한다.

 

테스트 코드의 유무도 확인하자.

 구현 코드뿐만 아니라, 테스트 코드의 유무도 확인하자.

• 상품의 목록 화면에 이미 테스트가 준비되어 있는가? 준비되어있다면 이 CSV 다운로드의 테스트를 간단히 추가할 수 있는가?
• CSV 다운로드의 테스트가 다른 화면에도 적혀 있는가?

 기존의 테스트 코드가 있다면 그 테스트 코드를 활용하여 이번에 구현할 CSV 다운로드 기능의 테스트를 할 수 있지만, 그렇지 않은 경우에는 0부터 테스트 코드를 작성할 필요가 있다.

 

 

[순서4] 기능을 추가하기 위해서는 어디를 어떻게 변경하면 좋은지 리스트업하기 

---

 이제 본격적으로 해야 할 일을 리스트업하자. "CSV 다운로드 버튼을 추가하여 CSV 파일을 다운로드 할 수 있도록 한다"를 조금 더 잘게 쪼개서 리스트업해야한다는 뜻이다. 하나의 목록은 30분에서 1시간정도 끝나는 내용으로 하는 것을 추천한다.

 예를 들어 CSV 다운로드 기능이이라면 다음과 같이 상세하게 업무를 분리할 수 있다.

• CSV 다운로드용 루팅을 routes.rb에 추가
• 화면 상에 CSV 다운로드 버튼을 배치하여 CSV 다운로드용 패스(URL)에 리퀘스트를 보내도록 하기
• 컨트롤러에 CSV 다운로드용 액션을 추가하기
• CSV의 생성 로직을 구현하기. CSV 다운로드 기능은 모두 공통 로직이 있으므로, 이번에는 데이터 취득과 파일 명 작성의 로직만을 구현하고, 그 외의 처리는 공통 로직에 맡기기
• CSS를 사용해서 버튼을 보기 좋기 바꾸기
• CSV 다운로드 기능 테스트 쓰기

 

각 작업의 소요 시간도 대중해보기

 우선 작업 내용을 리스트업했다면 각각의 소요시간에 대해 대략 작성해두자. 지금까지 사용해 본 적이 있는 라이브러리를 이용하는 경우나 이미 익숙한 방법이 있다면 간단히 끝날 수도 있지만, 반대로 지금까지 해 본적 없는 라이브러리를 사용한 코드나 0에서 시작해야한다면 생각 이상으로 시간이 걸리는 리스크가 있다.

 작업 내용을 크게 크게 작성하면 불분명한 부분이 많아 소요 시간 오차가 커지지만, 세세하기 분리하여 작업을 정의하면 각 작업의 소요 시간의 정밀도가 올라간다.

 

 

[순서5] 작업 분할이 끝나면 선배에게 리뷰받기

---

 작업의 세분화가 끝나면 그 결과를 선배 프로그래머나 개발 리더에게 리뷰받자. "이번에는 이런 순서로 이렇게 구현하려고 합니다"이라는 내용을 선배에게 전달해 의식차이가 있는지, 더욱 생각해봐야할 문제가 있는지 등등 확인 받자. 

 또한 이때 대체적으로 걸리는 작업 시간도 함께 전달하자. 명확하게 시간이 걸리는 작업이나 리스크가 큰 작업는 미리 전달해두는 것이 중요하다. 중요한 것은 여기까지 아직 한 줄의 코드도 작성하지 않았다는 것이다. 

 

 

[순서6] 구현하기

---

 구현을 시작했다면 WIP(work in progress)의 풀리퀘스트를 만들어, 작업중의 코드 차이를 다른 사람이 확인할 수 있도록 해두자.

 

고민하는 제한 시간을 정해서, 그 시간을 넘었을 경우 도움 요청하기.

 구현중 생각한 대로 되지 않아 고민하고 있을 수 있다. 이럴 때 반드시 언제까지 해결 안되면 도움을 구해야겠다는 제한 시간을 정해두고 그 시간을 넘으면 도움을 요청하자. 적절한 시간은 30분정도라고 생각된다. 선배에게 도움을 구할 때 너무 미안해하지 말자. 혼자 고민해서 3일만에 완료하는 것보다는 선배에게 상담해서 2시간안에 끝내는 것이 팀 전체로 봤을 때 효율이 좋다.

 

 

[순서7] 구현이 끝나면 풀 리퀘스트의 WIP을 제거한 후 완료

---

 구현을 끝냈으면 풀 리퀘스트의 WIP를 제거한 후 코드 리뷰 의뢰하자. 경우에 따라 일부의 코드를 수정하거나 화면 동작 수정을 요구받을 수 있을 것이다. 풀 리퀘스트의 승인이 되면 main 브랜치에 머지되어 작업이 끝난다.

---

참고자료

https://qiita.com/jnchito/items/017487cd882091494298