피그마랑 구현을 비교해서 빠진 분기 찾기
회사 작업이랑 개발 도구 작업을 같이 한 날이었다.
회사에서는 새 코스 분류의 첫 단계 디자인 구현을 다듬었다.
개발 도구에서는 에디터에서 ESLint가 안 돌던 문제를 빌드 파이프라인 수정으로 해결했다.
회사 작업은 새 코스 분류 도입의 디자인 구현이었다.
지난번에 코스 분류 옵션이랑 기본 설정을 구현했다.
이번에는 피그마 디자인이랑 구현을 비교해서 빠진 분기를 찾아 넣었다.
디자인에 있는 분기가 코드에 없는 경우가 있었다.
예를 들어 새 코스 종류는 기간 설정이 없다.
무제한으로 수강하는 코스다.
그래서 기간 설정 UI를 이 코스 종류에서는 비활성화해야 한다.
근데 이 분기가 빠져 있었다.
피그마를 보면 분명히 비활성화되어 있는데, 코드에는 반영이 안 된 거다.
그리고 안내 문구도 다듬었다.
운영 기간이랑 분류 설정에 대한 안내 문구가 코스 종류마다 달라야 하는데, 이것도 빠져 있었다.
피그마에 있는 문구를 확인하고 분기 처리했다.
피그마랑 코드를 비교하는 게 왜 중요한가
이 프로젝트는 피그마랑 픽셀 단위로 일치하는 걸 기준으로 삼는다.
디자인에 있는 분기가 코드에 없으면, 그건 버그다.
사용자가 보는 화면이 디자인 의도랑 달라진다.
그래서 구현할 때마다 피그마를 꼼꼼히 비교한다.
빠진 분기가 없는지, UI 상태가 디자인이랑 같은지. 이 과정을 건너뛰면 나중에 디자인 리뷰에서 다시 고치게 된다.
ESLint가 에디터에서 안 돌던 문제
개발 도구 쪽에서는 며칠 전에 도입한 ESLint가 에디터에서 안 돌던 문제를 잡았다.
며칠 전에 ESLint v9 플랫 설정이랑 엄격한 규칙을 도입했다.
근데 에디터에서 ESLint가 안 돌고 있었다.
터미널에서는 돌아가는데, 에디터에서는 표시가 안 됐다.
원인을 추적해보니 경로 별칭 문제였다.
코드에서 @/ 별칭을 쓰고 있는데, 이 별칭이 런타임에서 해석되지 않았다.
별칭은 빌드 도구가 해석하는 건데, 에디터는 그걸 모르니까 실패한 거다.
tsup으로 빌드할 때 해석하기
해결은 빌드 도구를 바꾸는 거였다.
tsup이라는 번들러를 써서 빌드할 때 경로 별칭을 해석하게 만들었다.
그러니까 빌드 결과물에는 별칭이 아니라 실제 경로가 들어간다.
에디터에서도 경로를 찾을 수 있고 빌드도 제대로 된다.
빌드 결과물의 진입점도 바꿨다.
빌드된 파일을 가리키게 만들어서 npm에서 설치한 사용자도 제대로 동작한다.
이 수정 덕분에 에디터에서 린트 에러가 바로 보인다. 게이트를 도입해놓고 에디터에서 안 보이면 결국 안 지키게 된다.
에디터에서 바로 보여야 규칙이 의미가 있다.
셸 스크립트 에러 처리 강화
마지막으로 셸 스크립트도 강화했다.
서브에이전트가 실행하는 스크립트들이다.
HTTP 에러 처리를 강화했다.
curl로 서비스를 호출할 때 응답 코드를 확인해서 실패하면 제대로 처리하게 만들었다.
그리고 파일 삭제 안전장치도 추가했다.
임시 파일을 삭제할 때 안전하게 삭제하도록 가드를 넣었다.
서브에이전트가 자주 스크립트를 실행한다.
그런데 스크립트가 실패해도 조용히 넘어가면, 나중에 이상한 곳에서 문제가 터진다.
그래서 에러 처리를 빡세게 잡는 게 중요하다.
마무리
내가 이날 배운 핵심은 다음과 같다.
이날은 디자인이랑 코드를 일치시키는 작업이랑, 개발 도구의 빌드 파이프라인을 고치는 작업을 했다.
피그마랑 코드를 비교하는 건 품질 보증의 기본이다.
디자인에 있는 분기가 코드에 없으면 버그다.
이걸 꼼꼼하게 비교하지 않으면, 디자인 리뷰에서 다시 고치게 된다.
처음부터 비교하면서 구현하는 게 더 빠르다.
tsup 빌드 수정은 에디터 경험을 개선한 거다.
개발 도구가 에디터에서 잘 동작해야 생산성이 올라간다.
린트가 안 보이면 규칙을 안 지키게 되고 결국 품질이 떨어진다.
도구가 제대로 동작하게 만드는 게 품질의 기반이다.