2024.03.28 프로젝트 회고

프로젝트가 완료되고 난 후, 전체적으로 코드를 검토를 해보다 문득 들었던 생각이 있다.

'아, 기록이 필요하구나.'

어떤 상황에 부딪치고, 대응하고 해결하는 과정을 기록하지 않는다면 나의 경험을 허공으로 버리는 꼴이 되어버릴 것 같았다.

이제부터 꾸준하지는 않더라도 프로젝트가 종료되면 회고를 해보려고 한다.

---

- 프로그레스바 만들기

• 관리자 서비스에서 유저에게 보여줄 목적으로 프로그레스바를 만들었다.
• 프로그레스바는 네가지의 신청 단계를 보여준다. 예. ○ -- ○ -- ○ -- ○
• 각 신청 단계마다 세부 단계가 있다.
• 세부 단계는 각 단계에서 색깔로 표현한다. 기본 회색. 완료 녹색. 취소 적색. 미진행 회색. 예. ○녹색 -- ○녹색 -- ○적색 -- ○회색
• 예외 상황. 첫번째 단계를 건너뛰고 두번째 단계부터 시작하는 경우가 있다. 예. ○회색 -- ○녹색 -- ○적색 -- ○회색
• 상기 내용으로 인해 프로그레스바 라이브러리나 보통의 프로그레스바로 제작이 어려움.
• 해당 프로그레스바는 관리자 서비스의 특정 페이지에서 전용으로 사용하게 됨으로 전용 컴포넌트로 제작.
• 각 신청 단계에 해당하는 상태 문자열을 지정.
• 특정 상태가 확인된 경우 회색, 녹색, 황색, 적색, 검은색 중 하나를 지정해 표시한다.

---

- 서버와 데이터 통신 유의점

어떤 같은 키와 값을 여러 객체에 담고 응답받을 경우가 있었다.

데이터의 형태는 다음과 같다. 아래의 예시 코드는 간략하게 표현한 것이고, 실제 운영상의 코드는 다차원 객체와 많은 키를 갖고 있다.

{
    name: "JMPark",
    mobile: "01012345678",
    apply_status: "ACCEPT"
    user_info: {
        user_name: "JMPark",
        user_mobile: "01012345678",
    },
    payment_info: {
        payer_name: "JMPark",
        payer_mobile: "01012345678",
        status: "ACCEPT",
    }
}

"name, user_info.user_name, payment_info.payer_name", "mobile, user_info.mobile, payment_info.mobile", "apply_status, payment_info.mobile.status"들은 DB의 동일한 컬럼에서 추출한 정보다.

응답 객체의 가장 바깥에 있는 name, mobile, apply_status를 보고, 응답 객체의 내부 객체들 안에서도 같은 키를 갖고 있을 것이라 유추하고 작업을 시작했다. 이 후 테스트 시 화면에 해당 데이터가 표시되지 않는 문제가 발생했고 응답 객체의 내부 객체의 키를 확인 후 해결했다.

해당 문제의 원인은, 첫번째로 프론트 작업시 응답받은 데이터를 자세히 확인하지 않았기 때문이었다.

두번째로 백엔드측에서 어떠한 알림도 없었고, 포스트맨의 도큐먼트 역시 업데이트가 늦거나 부실했다.

또한 프로젝트 기간 중 종종 백엔드측에서 응답 객체의 키를 바꾸는 경우가 있었고, 이 역시 알림이 없거나 포스트맨의 도큐먼트 갱신 문제가 있었다.

해결 방안으로 응답 객체를 자세히 확인하거나, 백엔드와 계속 커뮤니케이션 하는 방법말고는 없는 것으로 보인다.

---

- 라이브러리 선택은 신중하게

프로젝트 시작 전 기술 검토를 할 수 있는 시간이 있었다. 나는 form에 대한 기능을 알아보기로 했다.

개발시 요구되는 form 관련 기능으로는, 입력 에러 부분에 대한 스크롤, 포커스, 에러 문구 표시, 에러 해제에 대한 기능이 요구되었다.

기술 검토를 해보자

먼저 직접 구현을 해보았다,

form에 사용하는 input, select, calendar, textarea, radio등 여러가지가 있었고 각각 ref를 할당해줘야 하기 때문에 코드가 복잡해졌다. ref를 자동으로 할당할 수 있는 기능을 알았다면 직접 구현을 했을 수도 있었다.

때문에 라이브러리를 찾아보았다.

react-hook-form 라이브러리가 사용률이 많고 찾을 수 있는 정보가 많은 편으로 보였기 때문에 마음속으로는 거의 선택 확정 상태였다.

공식문서는 충실했고, 웹에서 여러 사용방법을 알아보았고 간략한 form을 구현했다.

원하는 기능이 모두 작동이 되었다. 이제 프로젝트에 적용하는 것만 남았다.

프로젝트의 시작 그리고 고난의 시작 1

곧 이어 프로젝트가 시작됐고, react-hook-form을 아주 야심차게 적용했다.

하지만 간과한 것이 있었는데 hook에 사용할 입력 항목들은 html 태그가 아닌 회사의 리액트 공통 컴포넌트라는 것이다.

<input>, <select>과 같은 html 태그가 아닌 styled-componenets로 만든 <Input>, <DropDown>과 같은 컴포넌트라는 말이다.

react-hook-form은 html 태그를 사용하는 방법과 커스텀 컴포넌트를 사용하는 방법이 달랐고, 이 사실을 프로젝트 후 알게되었다.

내가 개발해야 할 페이지는 개발기간이 3일이었는데, 갑자기 압박감이 찾아왔다.

정신이 나가지 않게 잘 부여잡고 검색해본다.

react-hook-form에서 제공하는 <Controller>라는 태그를 사용하면 커스텀 컴포넌트나 외부 컴포넌트를 사용할 수 있다고 한다.

"그럼 그렇지. 역시 방법은 있어." 라고 생각했다.

고난의 시작 2

그러나 문제는 계속 찾아온다. html 태그를 사용할 때는 react-hook-form의 register를 이용해 원하는 기능을 구현할 수 있었는데, <Controller> 태그를 사용하는 방법에서는 register를 사용할 수가 없기 때문에 기능 구현이 되지 않았다.

여차 저차해서 <Controller>태그가 field라는 객체를 전해주는 것을 알아냈다.

이 field객체는 value, focus, ref, onChange등이 들어있는 아주 작고 소중한 객체였다.

물꼬가 트이고 점점 개발이 순조로워졌다.

고난의 시작 3

form에서 사용되는 제출버튼은 두가지다. "제출하기 버튼"과 "저장하기 버튼".

제출하기 버튼은 react-hook-form이 제공하는 handleSubmit으로 해결이 가능한데, 저장하기 버튼이 문제다.

문제가 되는 부분은 유효성을 확인하는 항목이 서로 다르다는 것인데, 제출하기 버튼은 모든 입력항목의 유효성을 확인한다.

그러나 저장하기 버튼은 일부의 입력항목만 유효성을 확인하는게 문제였다.

form의 onSumbit은 form태그 내부의 button 타입이 "sumbit"인 경우 작동한다.

type="sumbit"인 버튼이 두개이고 각 버튼의 역할이 다르다면 문제가 된다. 이 부분이 내가 직면한 문제다.

제출하기 버튼을 클릭해도, 저장하기 버튼을 클릭해도 모든 입력항목의 유효성을 확인한다. 내가 원하는 기능이 아니다.

공식문서를 살펴보았다. react-hook-form에서 제공하는 기능중 trigger기능이 있는데 유효성 검사를 수동으로 가능하게 하는 함수였다. 적용 방법도 간단했지만 해당 기능을 찾는 과정이 너무 어려웠다.

유효성 검사를 수동으로 하는 기능이 없을 것이라 지레짐작하고, 직접 구현하려고 한 것이 시간을 소비하게 했다.

공식문서를 꼼꼼하게 검토했어야 했다.

그리 깔끔하지는 않은 작업

시간에 쫒기다 보니 전체적으로 코드가 지저분해졌다. 서둘러 작업을 하다 보니 주석처리된 코드도 많았고 사용하지 않는 함수나 변수도 많았다. 급해질수록 공식문서를 보지 않았다. 감으로, 지레짐작으로, 인터넷상의 도움안되는 코드를 먼저 적용한 것이 문제였다.

작업이 마무리는 되었지만 다시는 이런 일이 없게 조심하자.