1년차 프론트엔드 개발자가 설계하는 방법

연차가 쌓일수록 개발하는 시간보다 설계하는 시간이 길다고 한다.

 

이번에는 설계가 얼마나 중요한지 모르고 있었던 필자가,

설계에 대해 여러 시행착오를 겪고 어째서 설계가 중요하다고 느꼈는지 적어보고자 한다.

 

본문에 들어가기 전 미리 스포를 하자면(?)
필자가 직접 느낀 설계의 장점은 '편하다' 라는 점이였다.

---

 

필자는 설계할 때, 크게 5가지를 중점적으로 정리한다.

• 동작 플로우는 어떻게 되는가?
• UI를 어떻게 그릴 것인가?
• 로직적으로 중요한 부분은 어떤 것인가?
• 구현은 어떻게 할 것인가?
• api는 프론트에서 필요한 필드들을 모두 갖추고 있는가?

동작 플로우는 어떻게 되는가?

아무리 열심히 개발을 했다고 정작 동작하는 방식과 플로우가 기획과 다르다면,
QA기간에 급하게 수정을 하거나 심하면 다시 설계를 하고 개발을 해야 하는 경우가 생긴다.

이를 방지하기 위해 필자는 우선 동작 플로우가 어떻게 이루어지는지 확실하게 파악하고 넘어가는 편이다.

간단하게 블로그 글에 댓글을 작성하는 기능을 만든다고 예를 들어보면 동작 플로우는 아래와 같을 것이다.

1. '댓글을 작성하세요' placeholder가 있는 Textarea를 클릭
2. Textarea가 포커싱됨
3. Textarea에 글을 작성하고 '댓글 작성' 버튼 클릭
4. 댓글 생성 api를 서버에 요청
5. 서버에서 응답을 내려줌
  - 실패 응답. ex) 500: 오류 -> '500 오류가 발생했습니다' 얼럿 모달이 화면에 띄워짐.
6. 성공 응답. 200: 성공 -> '댓글 작성에 성공했습니다' 토스트 메세지가 화면에 띄워짐.
7. 댓글 작성 영역 하단에 작성이 완료된 댓글이 보여짐.

 

이런 식으로 사전에 동작 플로우를 작성해두면,

기획에 대한 이해도를 높일 수 있고, 간단하게 이후에 어떻게 개발을 해야할 지 고민을 할 수 있다.

UI를 어떻게 그릴 것인가?

UI는 생각보다 개발자들이 쉽게 놓치는 부분이다.

필자는 UI가 잘못되면, 기획자와 디자이너의 의도를 망가뜨리는 행동이라 생각해

항상 디자인과 동일하게 화면을 개발하려고 노력한다.

 

디자인은 피그마를 통해 전달받는데 보통 꼼꼼하게 살펴보아야 할 부분들은 아래와 같다.

• 반응형 고려
  • 화면이 늘어났을 때, 어떻게 보여지는게 디자인 의도와 일치하는지 디자이너와 적극적인 소통이 필요하다.
• 화면에 따른 적절한 display 속성 찾기
  • 화면 구성에 따라 block, flex, grid 등등.. 일관성을 유지하면서도 깔끔하게 개발할 수 있는 display 속성이 어떤건지 고민이 필요하다.
• 컴포넌트로 만들 구성 요소 파악
  • 반복되는 부분들을 찾아 최대한 잘게 쪼개 컴포넌트로 만들어야 한다.
• 그 외의 사소한 부분들
  • 애니메이션이 있다면 가속도와 진행 시간은 어떻게 되는지?
  • 개발한 각 요소의 css가 디자인과 일치하는가?

로직적으로 중요한 부분은 어떤 것인가? 

동작은 간단해 보여도 개발하기에 까다로운 부분을 찾아야 한다.
이런 부분을 초기 단계에 찾지 못하면, 개발이 마무리 될 즈음에 열심히 변명하고 있는 나 자신을 보게 될지도 모른다.

 

이 케이스 외에도 개발하기는 쉬워도,

이미 만들어 놓은 공통 컴포넌트에서 벗어나는 요구사항이 있으면. 기획자와의 적절한 소통이 필요하다.
(물론 확장성 있는 공통 컴포넌트를 만들어 두는게 가장 중요하다)

api는 프론트에서 필요한 필드들을 모두 갖추고 있는가?

필자가 다니는 회사는, 프론트엔드가 설계/개발에 들어가기 전 어느정도 백엔드 api 문서가 나온다.
이를 기반으로 기획서와 화면설계서, api 문서를 대조해보며 빠진 api가 어떤 부분인지 먼저 확인하는 과정을 거친다.

 

백엔드 개발자가 바라보는 시각와 프론트엔드 개발자가 바라보는 시각이 어느정도 다르다보니, 이 단계에서 누락된 필드를 은근 자주 발견하게 된다.
그렇기에 필자는 설계할 때, api를 꼼꼼히 확인해 이후 있을 소통 비용을 줄인다.

구현은 어떻게 할 것인가?

설계의 마지막 단계이자 설계의 핵심인 구현 부분이다.
구현에 들어가기에 앞서 현재 상황을 고려해 어떤 아키텍처/디자인 패턴을 사용할지,

테스트 코드를 어느정도 작성할 것인지 등등을 주어진 상황과 시간에 맞춰 결정을 해야한다.

 

블로그 글에 댓글을 작성하는 기능 설계를 이어가보자.

필자가 라이브러리를 react로 선택했고, 아키텍처로 클린 아키텍처를 선택했다.

이에 맞춰 구현 부분 설계에 들어가서 아래와 같은 문서를 작성했다.

 

클린 아키텍처를 선택했기 때문에 Entity, Repository, Usecase로 나누어서 각 레이어에서 어떻게 구현될지 간단하게 interface, class, mothod를 고민했다.

• entity
  • comment class
    • method: get commentIdentifier
    • method: get commentData
    • method: get commentAuther
  • comment model
    • interface: CommentResponseInterface
    • interface: CommentRequestInterface
    • interface: CommentPostResponseInterface
    • interface: CommentPostRequestInterface
• repository
  • method: fetchPostComment
  • method: fetchGetComment
• usecase
  • method: saveComment
  • method: get commentDisplayable
  • method: get authorName

위 설계에 대해 부연 설명을 하자면,
respository에서 fetchPostComment, fetchGetComment를 통해 서버와 api를 통해 통신하고,
받아온 데이터를 usecase에서 가공해 presentation 레이어에 데이터를 전달해 주도록 구현하였다.

 

이런 방식의 설계를 통해 필자는 개발할 때, 흐름을 끊기지 않고 설계한 그대로 개발을 이어나갈 수 있었다.
이를 통해 버그를 줄이고, 구현 시간을 많이 단축할 수 있었다.

---

말은 되게 거창하고 복잡하게 했지만, 필자는 보통 설계에 하루 정도의 시간을 쓴다.

이런 식으로 설계하고 나서 시간을 따져 봤을 때,소통에 사용되는 시간, QA후 수정하는 시간이 감소해

결과적으로 설계에 쓴 하루의 시간보다 더욱 많은 시간을 절약할 수 있었다.

 

누가 알려주지 않는, 필자가 개척한 설계 방법이기 때문에 아직은 미숙한 단계일지도 모르지만,
벌써부터 장점을 충분히 누리고 있기 때문에 필자는 앞으로도 설계를 점점 고도화 시켜나갈 것이다.