프론트엔드 개발 과정과 두 모자

들어가며

여기서 정리하는 것은 두 가지로 프론트엔드 개발 과정과 두 모자에 대해서 업무 스트레스를 최소화하기 위한 나만의 방법론을 정리한다.

프론트엔드 개발 과정에서는 개발자가 마크업 영역까지 담당하는 역할을 가졌다고 가정하고 정리한 내용이다.

두 모자는 마틴 파울러의 리팩토링 원칙 중 두 모자(Two hats)라는 메타포가 등장하는데, 해당 메타포와 비슷하게 일하는 방법에 대한 정리한 내용이다.

프론트엔드 개발 과정

게시판 목록을 조회하는 페이지를 만들었다고 가정했을 때, 프론트엔드 개발 과정은 다음과 같다.

(Task) 게시글 목록 조회 페이지 개발
(Sub Task) 마크업 개발
- (commit) REST API interface 작성
- (commit) 목업 데이터 작성
- (commit) 마크업 및 접근성 작업
- (commit) 스타일 작업
(Sub Task) REST API 연동
- (commit) API 유틸 추가
- (commit) API 유틸 적용
- (commit) 에러 케이스 처리

• Task: 지라 티켓이나 칸반 보드의 테스크 단위다.
• Sub Task: Task의 하위로 등록하는 테스크다.
• commit: Sub Task의 업무 완료 조건이며 Git commit message로 사용한다.

두 모자

두 모자는 일하는 방법에 대해 설명하기 위한 메타포이다. 일을 할 때 두 모자를 쓰곤 한다. 하나는 일을 시키는 모자, 다른 하나는 일을 하는 모자이다.

게시글 목록을 조회하는 페이지를 만들었다고 가정하겠다.

할 일

• 게시글 목록 조회 페이지 개발

---

이때는 일하는 모자를 쓰고 무엇을 해야 하는지 작성한다. 기획서를 보면서 되도록 업무를 잘게 쪼갠다고 생각하고 작업하는 게 좋다.

첫 번째 스탭으로는 이렇게 된다.

할 일

• (Task) 게시글 목록 조회 페이지 개발
  • (Sub Task) 마크업 개발
  • (Sub Task) REST API 연동

---

두 번째 스탭으로는 이렇게 된다.

할 일

• (Task) 게시글 목록 조회 페이지 개발
  • (Sub Task) 마크업 개발
    • (commit) REST API interface 작성
    • (commit) 목업 데이터 작성
    • (commit) 마크업 및 접근성 작업
    • (commit) 스타일 작업
  • (Sub Task) REST API 연동
    • (commit) API 유틸 추가
    • (commit) API 유틸 적용
    • (commit) 에러 케이스 처리

---

이렇게 일을 시키는 모자를 쓰고 작성이 완료되면 잠깐 스트레칭을 하고 일을 하는 모자를 착용한다.

그리고 일을 하나씩 해결해 간다.

할 일

• (Task) 게시글 목록 조회 페이지 개발
  • (Sub Task) 마크업 개발
    • (commit) REST API interface 작성
    • (commit) 목업 데이터 작성
    • (commit) 마크업 및 접근성 작업
    • (commit) 스타일 작업
  • (Sub Task) REST API 연동
    • (commit) API 유틸 추가
    • (commit) API 유틸 적용
    • (commit) 에러 케이스 처리

---

첫 번째 Sub Task의 3가지를 해결하고 마지막 하나가 남았다. 하지만 여기서 현실적인 문제가 있다. 디자인과 REST API는 UX나 기능 변경의 이유로 변경이 될 수 있다.

이때는 일하는 모자는 잠깐 내려두고 일을 시키는 모자를 착용한다.

이때 하나의 원칙이 더 나온다. 일은 전진만 하고 후진을 하지 않는다. 디자인이 변경되었다고 할 일을 다시 하는 게 아니고 새로운 일로 등록해야 한다.

디자인은 API 연동 작업 전에 마무리 해야 하므로 API 연동 업무 앞에 배치하고 API 변경 대응은 API 연동 작업 때 진행해도 충분하다. 업무를 다시 재배치한 상황은 이렇다.

할 일

• (Task) 게시글 목록 조회 페이지 개발
  • (Sub Task) 마크업 개발
    • (commit) REST API interface 작성
    • (commit) 목업 데이터 작성
    • (commit) 마크업 및 접근성 작업
    • (commit) 스타일 작업
  • (Sub Task) 디자인 변경 대응
    • (commit) 마크업 및 접근성 작업
    • (commit) 스타일 작업
  • (Sub Task) REST API 연동
    • (commit) API 변경 대응
    • (commit) API 유틸 추가
    • (commit) API 유틸 적용
    • (commit) 에러 케이스 처리

---

디자인 변경할 때는 마크업과 스타일 모두 수정이 필요하므로 테스크를 새로 등록하고, 했던 일은 Pull Request를 해서 마무리한다. API 변경은 interface 대응만 필요하므로 마이너한 작업이라 API 연동할 때 선작업한다.

전반적인 작업이 완료되었는데 마크업과 API가 변경된다면 어떻게 해야 할까? 이런 상황은 둘 다 한 테스크에 작업해도 작업에 무리가 없고 Pull Request의 파일 변경량이 리뷰어의 부담이 적기 때문에 하나의 테스크로 만들어서 작업한다.

할 일

• (Task) 게시글 목록 조회 페이지 개발
  • (Sub Task) 마크업 개발
  • (Sub Task) 디자인 변경 대응
  • (Sub Task) REST API 연동
  • (Sub Task) 기능 변경 대응
    • (commit) 마크업 및 접근성 작업
    • (commit) 스타일 작업
    • (commit) API 변경 대응

마치며

업무를 잘게 쪼개고 일하는 방법을 스스로 정해두니 컨텍스트 스위칭에 도움되서 개발 중간에 치고 들어오는 Pull Request나 협업에 도움이 된다.