배경: AI 서비스 꾸미의 WebView 전환
(주)알비에치에서 2개월간 프론트엔드 인턴·현장실습을 수행했습니다. Flutter 앱의 React WebView 전환과 화면·데이터 구조 개선에 참여했습니다.
모델·아티스트·스타일리스트의 결과 화면을 반복해서 고치면서, 화면마다 UI와 동작이 섞여 있는 구조가 불편했습니다.
문제 분석: 세 페이지가 같은 동작을 각각 가지고 있었다
이전에는 각 결과 페이지에서 결과 조회, 워터마크 제거, 평가 모달과 화면 조합을 처리했습니다. 같은 기능을 바꾸려면 여러 화면을 함께 확인해야 하는 구조였습니다.
| 책임 | 이전 | 변경 후 |
|---|---|---|
| 결과 화면 표현 | 서비스별 페이지에 반복 | 공통 GgumiResultPage |
| 조회·상호작용 | 각 페이지의 동작과 UI 혼재 | useResultPageLogic |
| 서비스별 문구·이미지 | 페이지 내부에 분산 | resultPage.config |
| 개별 진입점 | 큰 결과 페이지 3개 | 서비스 타입을 전달하는 래퍼 |
공통 레이아웃인 ResultLayout은 동료가 먼저 만들었습니다. 저는 그 위에서 세 결과 화면의 UI·동작·설정을 분리했습니다.
선택: 공통 동작과 서비스별 차이를 분리
- 서비스별 진입점모델 / 아티스트 / 스타일리스트
- 공통 화면결과 UI의 조합
- 공통 동작 훅조회·워터마크·평가 흐름
- 서비스별 설정이미지·문구 등 차이
서비스마다 달라지는 내용을 설정에 두고, 반복되는 화면과 동작을 공통 파일로 옮겼습니다. 개별 결과 페이지는 서비스 타입을 넘기는 9줄 래퍼가 됐습니다.
파일 수보다 중요한 것은 공통 동작과 서비스별로 달라지는 값의 위치를 구분한 점입니다. 공통화와 함께 일부 동작도 바뀌었으므로 단순한 파일 이동만은 아니었습니다.
측정: 새로 생긴 공통 파일도 모두 포함
| 파일 | 이전 | 이후 |
|---|---|---|
| ArtistResultPage.jsx | 197 | 9 |
| ModelResultPage.jsx | 192 | 9 |
| StylistResultPage.jsx | 206 | 9 |
| GgumiResultPage.jsx | 0 | 107 |
| resultPage.config.jsx | 0 | 127 |
| useResultPageLogic.js | 0 | 115 |
| 합계 | 595 | 376 |
비교 기준은 결과 공통화 커밋과 그 부모입니다. 추출한 공통 파일을 모두 합산했으며 양쪽에서 바뀌지 않은 기존 ResultLayout 등은 제외했습니다. 같은 커밋의 라우팅·App·main 변경도 이 수치에 포함하지 않았습니다.
연관 작업: API·서버 상태·화면 역할 분리
크레딧 조회·충전은 요청을 보내는 API, 조회 상태를 다루는 훅, 변경과 캐시 갱신을 다루는 훅, 화면 컨테이너로 나눴습니다. 하드코딩된 잔액·상품과 모의 구매 흐름을 실제 API 호출로 연결하는 작업이었습니다.
- API요청·응답
- 조회 훅현재 잔액·조회 상태
- 변경 훅충전·변경 후 캐시
- UI표시와 사용자 상호작용
이미지 생성 성공 후 갤러리만 갱신하던 세 mutation에는 currentCredit 무효화를 추가했습니다. 사용한 크레딧이 충전 화면 잔액에 반영되지 않던 연결 누락을 수정한 것입니다.
변경 내용을 확인한 방법
관련 파일의 변경은 결과 화면 공통화 커밋과 diff로 확인했습니다. 크레딧 잔액 갱신은 세 mutation에 추가한 currentCredit 무효화 변경으로 확인했습니다. 당시 서비스 빌드와 운영 API 재실행은 이 결과에 포함하지 않았습니다.
돌아보며: 추출한 파일까지 포함해야 비교가 된다
개별 화면의 줄 수만 보면 큰 폭으로 줄었지만, 새 공통 파일을 제외하면 변화가 과장됩니다. 관련 파일 전체를 같은 기준으로 합산한 뒤 코드량과 동작·운영 효과를 나눠 설명했습니다.
UI·로직·서비스별 설정을 분리하니, 이후 변경할 때 세 결과 화면에서 각각 손봐야 할 부분과 공통으로 바꿀 부분을 구분할 수 있었습니다.