공통 기능이 필요한 화면들

검색창과 오락실 편집기는 서로 다른 화면이지만 입력을 잠시 기다리거나 창을 닫을 때 브라우저 자원을 정리하는 과정은 반복된다. 예를 들어 같은 Dialog 종료 문제를 화면마다 따로 고치면 한 곳의 수정이 다른 곳에는 반영되지 않을 수 있다. 복사한 코드가 늘어날수록 같은 동작을 유지하는 비용도 커진다.

flowchart TD
    accTitle: 제품과 공유 패키지의 의존 방향
    accDescr: WebCore는 UIKit과 FunctionKit과 DataKit을 소비하며 DataKit은 제품 중립 FunctionKit을 사용할 수 있다.
    W["WebCore 제품 기능"] --> U["UIKit 화면 동작"]
    W --> F["FunctionKit 범용 동작"]
    W --> D["DataKit 서버 데이터"]
    D --> F

공유 패키지인 Kit은 이런 반복 처리를 한곳에서 관리하기 위한 단위다. 뮤즈캣에서는 표현과 접근성, 시간 계산, 브라우저 동작처럼 제품에 독립적인 부분을 분리했다. 검색 대상이나 편집 권한처럼 기능의 의미를 결정하는 내용은 제품 코드에서 읽을 수 있게 남겼다.

UIKit과 FunctionKit의 역할

UIKit은 Dialog, 입력, 전환과 미디어의 화면 동작을 제공한다. FunctionKit은 시간·날짜·위치 계산과 브라우저 capability처럼 여러 기능에서 쓸 수 있는 메커니즘을 맡는다. WebCore가 검색어의 의미, 허용할 행동과 저장 값을 정하고 DataKit은 서버 데이터와 인증을 처리한다. DataKit에서도 제품에 독립적인 FunctionKit을 사용할 수 있다.

sequenceDiagram
    accTitle: 검색 입력의 대기와 요청 취소
    accDescr: FunctionKit은 입력 대기를 맡고 검색 기능은 조회와 이전 요청 취소 및 결과 반영을 맡는다.
    participant I as 검색 입력
    participant F as FunctionKit
    participant S as 검색 기능
    participant A as 검색 API
    I->>F: 바뀐 검색어
    F-->>S: 대기 후 검색어 전달
    S->>A: 취소 가능한 조회
    I->>S: 다음 입력
    S->>A: 이전 요청 취소
    S->>S: 유효한 응답만 반영

의존성은 제품에서 Kit으로 향한다. 공유 패키지가 특정 오락실 경로나 권한을 불러오면 다른 소비자도 그 제품 구조에 묶이기 때문이다. 소비자는 공개 진입점으로 지원 기능을 사용하고 내부 파일 위치에는 의존하지 않도록 해, 패키지 내부 정리의 영향을 줄였다.

검색 입력의 대기와 요청 취소

검색에서는 타이핑할 때마다 즉시 요청하기보다 잠시 입력이 멈추기를 기다릴 수 있다. 이때 타이머를 만들고 이전 대기를 취소하며 화면 제거 시 정리하는 처리는 FunctionKit에서 공유한다. 조합 중인 한글을 검색할지, 빈 입력을 어떻게 다룰지와 결과 순서는 검색 기능에서 정한다.

이전 검색 응답이 늦게 와서 최신 결과를 덮지 않으려면 요청을 취소하고 응답이 현재 검색어에 해당하는지 확인해야 한다. 원문 검색과 보조 자판 보정도 실패의 의미가 다르다. 원문 요청이 실패하면 오류를 표시하지만 보조 요청만 실패하면 정상 원문 결과를 유지하고, 둘 다 성공하면 중복을 제거해 합친다.

flowchart TD
    accTitle: 검색 실패의 영향 범위
    accDescr: 검색 기능은 원문 실패를 오류로 처리하지만 보조 자판 보정 실패는 정상 원문 결과를 유지한다.
    Q["원문과 보조 조회"] --> O{"원문 성공"}
    O -->|"아니오"| E["검색 오류"]
    O -->|"예"| C{"보조 조회 성공"}
    C -->|"예"| M["중복 제거 후 병합"]
    C -->|"아니오"| K["원문 결과 유지"]

Dialog에서도 화면 표현과 닫힘 수명주기는 공유하되, 저장 뒤 어디로 이동할지와 미저장 내용을 확인할지는 기능이 전달한다. 같은 동작을 재사용하면서도 이용자의 작업 의도는 해당 화면에 남기는 방식이다.

패키지 수정과 기능 개발

공유 동작의 문제를 패키지에서 고치면 그 기능을 쓰는 화면이 같은 수정을 받을 수 있다. 공개 export와 패키지 테스트는 지원 동작을 확인하는 기준이 되어, 내부 정리가 뜻하지 않은 소비자 변경으로 이어지는 일을 줄인다.

다만 비슷하게 보인다는 이유만으로 모든 화면을 하나의 설정 객체로 만들지는 않는다. 제품의 의미가 다르면 제공된 부품을 직접 조합한다. 반복되는 메커니즘을 한 번 관리하면서도 개별 기능의 판단 과정을 따라갈 수 있는 구성이 필요하기 때문이다.

관련 글과 자료: 엔지니어링 기록