||
글. 정용욱(Eric) / 서비스웹개발팀
항공 프론트엔드 구축기: 폴더 이름 앞의 기호 하나
안녕하세요. 서비스웹개발팀의 에릭입니다.
마지막 편입니다. 폴더 이름 앞의 기호 두 개가 어떻게 규칙이 됐는지 이야기합니다. 그리고 1편에 적어 둔 걱정 다섯 가지에 답하면서 시리즈를 마무리하겠습니다.
이 파일 지워도 되나
해외선 예약 상세 화면을 만들다 보면 파일이 수십 개가 됩니다. 그중 하나를 지우려고 합니다.
폴더가 이렇게 생겼다고 해보겠습니다.
sections/
├── FlightInfo.tsx
├── PassengerInfo.tsx
├── PaymentInfo.tsx
├── RequestCancel.tsx
├── CancelPopup.tsx
├── RefundView.tsx
├── SelectCancelPassenger.tsx
└── …
SelectCancelPassenger.tsx를 지워도 되는지 알려면 어디서 쓰는지 찾아봐야 합니다. 찾으면 나오긴 합니다.
문제는 매번 찾아야 한다는 것입니다.
파일 이름은 그게 무엇인지를 말해줍니다. 그런데 어디까지 영향을 주는지는 말해주지 않습니다. 이 팝업에서만 쓰는 건지, 화면 전체가 쓰는 건지, 다른 화면도 가져다 쓰는 건지가 이름에 없습니다.
화면이 커지고 만드는 사람이 늘수록 이 질문이 잦아집니다. 그리고 답을 아는 사람이 매번 다릅니다.
같은 질문이 반대 방향으로도 나옵니다. 비슷한 게 필요해서 만들려는데, 이미 있는 걸 가져다 써도 되는지가 안 보입니다. 그래서 각자 하나씩 더 만듭니다.
둘 다 파일이 어디까지 영향을 주는지가 이름에 없어서 생기는 일입니다.
제대로 해보려고 했습니다
FSD(Feature-Sliced Design)를 도입하자는 이야기가 나왔습니다. 서비스 개발을 시작하면서 동료 한 명이 꺼낸 이야기였습니다.
여럿이 함께 만들면 구조가 필요해진다는 걸 짚은 제안이었습니다. 제가 느끼고는 있으면서 이름을 못 붙이고 있던 것에, 이미 이름이 있는 해법을 가져온 셈이었습니다.
FSD는 이 문제를 정면으로 답합니다. 코드를 레이어로 나누고, 위 레이어만 아래 레이어를 참조할 수 있게 방향을 강제합니다. 어디에 있는지가 곧 누가 쓸 수 있는지가 되고, 그 규칙은 lint로 검사할 수도 있습니다.
FSD의 레이어와 슬라이스와 세그먼트 구조도
Feature-Sliced Design 공식 문서(feature-sliced.design)의 구조도. 나누는 축이 셋이다.
필요한 게 그거였습니다. 이름에 없는 정보를 위치에 담는 것이요.
게다가 이미 자리 잡은 체계입니다. 이름이 정해져 있고 문서가 있고 쓰는 곳이 많으니, 새로 합류하는 사람에게 “우리 규칙”을 설명하는 대신 이름 하나를 말하면 됩니다. 직접 규칙을 만들면 그 설명을 매번 우리가 해야 합니다.
그런데 도입하지 못했습니다. 두 가지가 걸렸습니다.
하나, 경계를 그을 수 있는 상태가 아니었습니다. 위 그림에서 보이듯 나누는 축이 셋입니다. 레이어를 고르고, 그 안에서 슬라이스를 정하고, 다시 세그먼트로 나눕니다. 이름을 외우는 게 아니라 어디까지가 어디인지를 팀이 같이 정해야 쓸 수 있는 체계인데, 그 합의를 시작할 만큼 이해가 모여 있지 않았습니다. 저부터 그랬습니다.
둘, 새 파일을 만들 때마다 판단이 하나 붙습니다. 이건 entity인가 feature인가. FSD를 써 본 사람들이 공통으로 이야기하는 지점이고, 실제로 여기서 걸렸습니다.
일단 이 정도로 가기로 했습니다
시점도 걸렸습니다.
구조 이야기를 하기에 시작만큼 좋은 때는 없습니다. 만들어 둔 게 적을수록 옮길 것도 적으니까요. 그래서 그때 나온 게 맞는 제안이었습니다.
문제는 같은 때가 일정이 제일 급한 때이기도 하다는 것입니다. 배우고, 경계를 합의하고, 이미 잡아 둔 기반에 적용하는 일을 그때 하려면 다른 것을 미뤄야 합니다. 그리고 그 시점에 미룰 만한 게 없었습니다.
구조가 필요해지는 이유와 구조를 잡을 시간이 없는 이유가 같았습니다. 사람이 늘어서 필요해지는데, 사람이 느는 때가 제일 바쁩니다.


