자체 제작한 디자인 시스템

@gunjo/ui
(군청／gunjo.jp) 군청을 한 번도 본 적이 없는 사전 지식 제로의 AI에게, 실제로 존재하는 업종의 실제 화면을 계속 만들게 하는—'해봤다' 연재의 총정리 본편입니다. 170개 화면(#1~#173・누락 있음)을 거치며 알게 된 점과, 그 과정에서 군청에 추가된 26개의 컴포넌트를 한데 모았습니다.

무엇을 하고 있는가

규칙은 간단합니다.

사전 지식 제로의 AI에게

⚠️ [IMG:N] 형식 토큰은 이미지 placeholder 입니다. 번역하지 말고 원래 위치에 그대로 유지하세요.

• 사전 지식 제로의 AI에게
• 약(弱): 필요한 컴포넌트가 없음 (＝부족한 컴포넌트) → 직접 구현됨. - 중(中): docs에서 컴포넌트 검색이 잘못된 것을 추천함 (오인 유도) → 사용하는 사람이 믿고 막힘. - 강(強): 기존 컴포넌트로는 HTML 구조상 어떻게 해도 만들 수 없음. 예: 다운로드 서류의 줄을 ListCard로

만들 수 없는 이유는, ListCard.onSelect가 카드 전체를 하나의 <button>으로 만들기 때문입니다. 그 안에 독립된 다운로드 버튼을 넣으면 버튼 안에 버튼 = 부적절한 HTML이 됩니다. 이것은 '확장하면 해결된다'는 식으로 풀 수 없는, 가장 반박의 여지가 없는 '만들 이유'였습니다.

3. '용도에서 컴포넌트를 찾기' 기능의 함정은 6가지가 있었다

'경로 화면이니까 Itinerary (여행 일정용 컴포넌트)'처럼 의미 키워드는 맞지만, 화면 형태(왼쪽에 A→B로 나열할지, 세로로 순서를 쌓을지)가 반대였거나, '2개 나란히 놓으려면 RelationshipRow'가 사람 전용으로 만들어져서 회사×제도에 사용하면 타입(TypeScript)이 맞지 않음 (＝다루는 대상을 착각함)인 경우였습니다. 검색 기능의 질은 타입・접근성・화면 형태・다루는 대상이 사람인지 조직인지까지 포함하여 평가해야 한다는 것을 알게 되었습니다.

4. '세 번째'는 숫자 맞추기가 아니라, 사양을 최종 확정하는 과정이었다

MatchCard (두 가지를 조합해서 보여주는 카드)가 세 번 직접 구현되었지만, 세 번째(보조금 매칭 = 회사×제도라는 종류가 다른 조합)가 결정적이었습니다. 만약 1~2회차(같은 종류끼리)로 만들었다면 '회사×회사에 고정'해버렸을지도 모릅니다. **종류가 달랐기 때문에,