2025년 12월 10일·6분
3개에서 30개까지 확장되는 통합 디렉토리 설계
간단한 데이터 모델, 명확한 상태, 권한, 설정 진행 UI로 3개에서 30개 통합까지 확장되는 통합 디렉토리를 설계하세요.
간단한 데이터 모델, 명확한 상태, 권한, 설정 진행 UI로 3개에서 30개 통합까지 확장되는 통합 디렉토리를 설계하세요.
사람들이 통합 디렉토리를 여는 이유는 하나입니다: 도구들을 연결하고 매일 신경 쓰지 않아도 계속 작동하게 하려는 것. 화면이 사용자가 무엇이 연결되었는지, 무엇이 고장 났는지, 다음에 무엇을 클릭해야 하는지를 추측하게 만들면 신뢰는 빠르게 떨어집니다.
통합이 3개일 때는 로고 그리드만으로도 괜찮습니다. 30개가 되면 그것으로는 안 됩니다: 사용자는 스캔을 멈추고, 지원 티켓이 늘고, "Connect" 버튼이 함정이 됩니다. 왜냐하면 각 통합이 서로 다른 상태에 있을 수 있기 때문입니다.
각 통합 카드(또는 행)는 한눈에 세 가지 질문에 답해야 합니다:
대부분의 혼란은 실제 팀에서 자주 발생하는 엣지 케이스에서 옵니다. 누군가 개인 계정으로 Google을 연결하고 회사 계정으로 연결하지 않는 경우, Stripe 토큰이 만료되어 청구 동기화가 중단되는 경우, Slack 워크스페이스는 연결되었지만 필수 채널 범위가 허용되지 않아 설정이 "절반만 완료"된 경우 등입니다.
좋은 화면은 이런 상황들을 명백하게 보여줍니다. 단순히 "Connected"라고만 표시하는 대신 "Connected (권한 필요)" 또는 "Connected to: [email protected]"처럼 표시하고 카드에 다음 단계를 바로 넣으세요. 그러면 사람들이 추측하지 않아도 되고 목록이 커져도 관리 가능하게 유지됩니다.
통합 디렉토리를 확장하는 가장 단순한 방법은 다음을 분리하는 것입니다:
이 구조는 3개의 통합에서 읽기 쉬우며 30개에서도 효과적입니다.
Integration은 카탈로그 항목입니다. 전역적이며 어떤 워크스페이스에도 묶이지 않습니다.
Install은 해당 Integration을 워크스페이스가 활성화한 것을 나타냅니다(예: "워크스페이스 A에서 Slack이 켜짐").
Connection은 실제 외부 계정이나 자격 증명을 나타냅니다(예: "OAuth로 연결된 Slack 워크스페이스 X" 또는 "API 키로 연결된 Stripe 계정 Y"). 하나의 Install에 여러 Connection이 있을 수 있습니다.
일반적으로 확장에 잘 맞는 최소 필드 세트:
사용자에게 보이는 설정(선택한 채널, 웹후크 URL 별칭, 활성 이벤트 등)은 Install이나 Connection에 평문으로 저장하세요. 비밀값(OAuth 리프레시 토큰, API 키, 서명 비밀)은 반드시 시크릿 저장소나 엄격한 접근 제어가 있는 암호화 필드에만 저장하세요.
비밀, 전체 권한 코드, 원시 웹후크 페이로드를 로그에 남기지 마세요. 로그가 필요하면 connection_id 같은 참조와 HTTP 상태, 오류 코드 같은 안전한 메타데이터만 기록하세요.
OAuth, API 키, 웹후크 전반에서 유연성을 유지하려면 인증별 필드를 Connection 내부에 두세요(토큰 메타데이터 vs 키 지문 vs 웹후크 검증 상태). UI 표시 상태(활성화 여부 및 설정 진행)는 Install에 보관하세요.
사람들이 통합 디렉토리를 여는 이유는 세 가지를 빠르게 확인하려는 것입니다: 작동 중인지, 설정이 얼마나 진행되었는지, 다음에 무엇을 해야 하는지. 상태 단어가 모호하면 지원 문의가 늘고 신뢰가 떨어집니다.
수년간 유지할 수 있는 작은 상태 집합으로 시작하세요:
유지보수가 쉬운 파생 상태를 선호하세요. 저장된 라벨은 흐려집니다: 누군가 오류를 고쳤는데 배지가 계속 빨간 상태로 남아 있을 수 있습니다. 파생 상태는 이미 추적 중인 사실들로 계산하세요(토큰 유효성, 필수 설정 단계 완료 여부, 관리자가 통합을 일시중지했는지 등). 만약 무엇을 저장해야 한다면 최종 라벨이 아니라 근본 사실(마지막 성공 동기화 시각, 마지막 오류 코드)을 저장하세요.
설정 진행은 필수와 선택적 항목을 명확히 분리한 짧은 체크리스트로 가장 잘 작동합니다. 통합별 정적 단계 정의와 설치별 단계 결과로 모델링하세요.
예: Slack은 "워크스페이스 승인"과 "채널 선택"을 필수로 요구하고 "메시지 미리보기 활성화" 같은 선택적 단계가 있을 수 있습니다. UI는 "필수 단계 3개 중 2개 완료"를 보여주면서 선택적 항목은 차단하지 않게 노출할 수 있습니다.
하나의 통합 아래 여러 연결이 있을 때 디렉토리가 엉망이 될 수 있으니 대비하세요. 카드당 하나만 유지하고 연결 수를 표시하며 상태를 정직하게 집계하세요. 어떤 연결이라도 문제가 있으면 "Needs attention"을 표시하고 "4개 중 1개 워크스페이스가 재인증 필요" 같은 힌트를 제공하세요. 개요는 깔끔하게 유지되면서 현실을 반영합니다.
모든 것을 하나의 스위치로 처리하면 통합 권한이 복잡해집니다. 다음을 분리하면 명확합니다:
처음에는 가볍고 전역에 적용되는 역할 검사로 시작하세요. 많은 제품에서 세 가지 역할( Admin, Manager, Member )이면 충분합니다. Admin은 모든 것을 할 수 있고, Manager는 팀을 위한 대부분 통합을 설정할 수 있으며, Member는 이미 활성화된 통합을 사용할 수 있지만 설정은 변경할 수 없습니다.
그다음 실제로 중요한 경우에만 통합별 권한 플래그를 추가하세요. 대부분의 통합(캘린더, 채팅)은 기본 역할 규칙을 따를 수 있습니다. 민감한 통합(결제, 급여, 내보내기)은 "Payments admin" 혹은 "Billing manager" 같은 추가 확인을 요구해야 합니다. 이걸 전체 역할 시스템 대신 Install에 단순한 불리언으로 두세요.
가독성이 유지되는 매핑 예시:
감사는 무거울 필요는 없지만 존재해야 합니다. 누가 연결했는지, 자격 증명이 언제 변경되었는지, 누가 비활성화했는지 같은 질문에 빠르게 답할 수 있을 정도의 기록을 남기세요. 세부 페이지의 "활동" 패널에 최근 이벤트 5~20개를 두는 것으로 충분한 경우가 많습니다.
예: Stripe는 모두가 볼 수 있지만 연결·키 회전·출금 비활성화는 Admin(또는 "Billing manager"로 표시된 사용자)만 할 수 있습니다. Slack은 Manager가 연결할 수 있지만, Member는 활성화되면 알림을 받을 수 있습니다.
통합이 3개일 때는 모든 것을 보여줄 수 있습니다. 30개가 넘으면 디렉토리는 한 가지 질문에 빠르게 답해야 합니다: "어떤 것이 작동하고 있고, 다음에 무엇을 해야 하는가?". 가장 깔끔한 접근은 스캔(검색)과 작업(수정)을 분리하는 것입니다.
디렉토리 뷰는 빠른 결정을 돕는 데 집중하세요. 무거운 제어는 모두 "Manage" 버튼 뒤의 세부 페이지로 밀어 넣으세요.
목록에서는 다음만 보여주면 됩니다:
카드 구성은 근육 기억을 만듭니다. 주요 액션은 항상 상태에 기반한 "다음 단계"를 의미해야 합니다: 새로 등록된 항목에는 Connect, 일부만 완료된 항목에는 Continue setup, 인증이 만료된 항목에는 Reconnect, 모두 정상인 항목에는 Manage. 카드마다 동등하게 강한 버튼을 두지 마세요. 그러면 페이지가 시끄럽게 느껴집니다.
예시:
빈 상태는 사용자를 안내하되 설명서를 다 던져주지 않게 하세요:
이렇게 하면 30개 통합에서도 각 카드가 무엇인지, 괜찮은지, 다음에 무엇을 해야 하는지를 답하기 때문에 화면이 차분하게 유지됩니다.
디렉토리 목록은 사용자를 올바른 통합으로 안내합니다. 세부 페이지는 그곳에서 설정을 마칠지, 고칠지, 끌지 결정하는 장소입니다. 백엔드가 달라도 모든 통합에서 페이지 구조는 일관되게 유지하세요.
간결한 개요로 시작하세요: 통합 이름, 한 줄 설명, 명확한 상태 라벨(Connected, Needs attention, Disabled). 사용자가 얼마나 가까운지 알 수 있게 작은 "설정 진행" 줄을 추가하세요.
간단한 마법사가 잘 작동합니다: 3~6단계, 한 화면에 하나의 단계, 항상 "뒤로" 버튼 제공. 단계 이름은 평이한 언어로(계정 연결, 워크스페이스 선택, 동기화할 데이터 선택, 확인) 작성하세요. 선택적 항목이 있으면 숨기지 말고 '선택 사항'으로 표기하세요.
설정을 중단할 수 있다면 명확히 알리세요: "나중에 마무리할 수 있습니다. 선택 내용은 보관됩니다." 이렇게 하면 중간에 나가도 두려움이 줄어듭니다.
Connections는 작은 표 형태로 보여주세요: 계정 이름, 연결한 사람, 생성일, 마지막 동기화.
"다음 동기화"에 대해서는 약속할 수 없는 구체적 시간을 피하세요. 대신 시스템이 실제로 보장할 수 있는 문구("다음 동기화: 곧 예정", "다음 동기화: 한 시간 이내")를 사용하세요.
위험한 동작은 주 경로에서 멀리 두세요. 주요 액션은 상단에(Continue setup, Reconnect). Disable 및 Disconnect는 영향 설명과 함께 하단의 "위험 구역" 섹션에 두세요. 역할을 지원하면 한 문장으로 알리세요(예: "Disconnect는 관리자만 할 수 있습니다").
작은 활동 로그를 추가하세요: 최근 이벤트(연결됨, 토큰 갱신, 동기화 실패), 타임스탬프, 지원에 붙일 수 있는 짧은 오류 메시지.
통합 추가는 작은 제품처럼 다루면 쉬워집니다. 목록에 등록, 연결 방법, 연결 저장, 성공/실패에 대한 명확한 결과가 필요합니다.
통합을 카탈로그에 추가해 누구나 디렉토리에서 볼 수 있게 하세요(아직 연결되지 않아도). 명확한 이름, 짧은 설명, 아이콘, 한두 개 카테고리(메시징, 결제 등)를 포함하세요. "계정 연결" 및 "워크스페이스 선택"처럼 설정 예상 항목을 평이하게 쓰세요. 또한 통합이 나중에 필요로 할 것들(OAuth 범위, 필수 필드, 지원 기능)을 정의하세요.
제공자에 맞는 가장 간단한 연결 방식을 선택하세요:
사용자가 흐름을 완료하면 Connection 레코드를 워크스페이스나 계정에 연결해 생성하세요(단순히 사용자에만 묶지 않음). 자격 증명은 안전하게 저장(디스크 암호화 등)하고 전체 비밀을 다시 보여주지 마세요. 지원을 위해 필요한 기본 정보는 저장하세요: 제공자 계정 ID, 생성 시각, 연결한 사람, 부여된 권한.
완료 즉시 간단한 검사를 실행하세요(예: Stripe는 계정 정보를 가져오기). 통과하면 Connected를 표시하고 진행을 완료로 표시합니다. 부분적으로 통과(연결됨, 권한 누락 등)하면 Needs attention으로 표시하고 정확한 수정 방법을 가리키세요.
한가지 명확한 메시지, 한 가지 권장 행동, 그리고 안전한 대체 방안을 제시하세요. 예: "Stripe에 연결할 수 없습니다. API 키를 확인하거나 다시 시도하세요." 하나의 통합이 고장나더라도 디렉토리는 계속 쓸 수 있어야 합니다.
Koder.ai(koder.ai)로 구축하는 경우 Planning Mode에서 카탈로그, 설정 흐름, 상태 규칙을 먼저 초안으로 작성한 다음 그 계획에서 UI와 백엔드를 생성할 수 있습니다.
통합은 단순한 이유로 실패합니다. 디렉토리가 그 이유를 명확히 설명하지 못하면 사용자는 앱을 탓하고 지원은 할 것이 없습니다.
실패를 현실적인 고치기 단위로 묶으세요: 로그인 만료, 권한 누락, 제공자 장애, 속도 제한. 내부 오류 코드는 상세히 유지하되 사용자에게는 이해하기 쉬운 짧은 라벨만 보여주세요.
문제가 발생하면 메시지는 세 가지를 알려줘야 합니다: 무슨 일이 일어났는지, 사용자가 무엇을 해야 하는지, 시스템이 다음에 무엇을 할지. 예: "Slack 연결이 만료되었습니다. 다시 연결하면 동기화를 계속합니다. 재연결 후 자동으로 재시도합니다."는 원시 API 오류보다 차분하고 실행 가능성이 높습니다.
사용자가 직접 고칠 수 없는 경우에만 자동 재시도하세요. 간단한 규칙 집합이면 충분합니다:
상태는 오래되기 쉽습니다. 토큰이 여전히 작동하는지, 마지막 동기화가 실행되었는지, 디렉토리 배지가 현실과 일치하는지 주기적으로 확인하는 가벼운 헬스체크 작업을 추가하세요.
설치별로 작은 이벤트 이력을 보관하세요. 전체 로그가 아니라도 충분한 흔적만 있으면 됩니다: 타임스탬프, 이벤트(예: "토큰 갱신", "동기화 실패"), 짧은 사유, 누가 트리거했는지(사용자 또는 시스템). 지원팀이 무엇을 바꿨는지 기록할 수 있는 내부 전용 메모 필드도 추가하세요.
앱 수가 적을 때는 목록이 빨리 지저분해집니다. 목표는 단순합니다: 사람들이 몇 초 안에 필요한 것을 찾고, 모든 카드를 열지 않고도 문제를 찾게 하는 것.
통합 이름과 카테고리에 대한 기본 검색으로 시작하세요. 대부분의 사용자는 이미 알고 있는 이름(예: "Slack", "Stripe")을 입력하기 때문에 이름 매칭이 고급 랭킹보다 더 중요합니다. 카테고리 검색은 작업(결제, 메시징)을 알 때 유용합니다.
필터는 실제 의도를 반영해야 합니다. 보통 다음 세 가지가 대부분 케이스를 커버합니다:
목록 정리는 하나의 주 그룹핑을 선택하고 일관되게 유지하세요. 카테고리 그룹핑은 많은 수에서 잘 작동합니다(CRM, 결제, 메시징). 인기순은 사용자 기반을 반영할 때만 유용합니다. 실용적인 기본값: 가장 많이 사용되는 항목을 먼저 보여주고 나머지는 카테고리로 그룹화하세요.
"모두가 모든 것을 봐야 한다"고 가정하지 마세요. 기능 플래그나 요금제 단계로 제한된 통합은 대부분의 사용자에게 숨기거나 비활성화된 상태로 짧은 이유("Business plan")를 표시하세요. 회색 처리된 카드가 가득한 페이지는 화면이 깨진 것처럼 보입니다.
목록과 세부를 별도 로드로 처리해 성능을 빠르게 유지하세요. 30개의 무거운 카드를 한 번에 렌더링하지 말고 페이징 또는 가상화를 사용하고 세부 정보는 사용자가 카드를 열 때 지연 로드하세요. 디렉토리는 요약 필드(Slack: Connected, Google: Needs attention, Stripe: Not set up)를 보여주고 세부 페이지가 전체 연결 이력을 가져오게 하세요.
팀 워크스페이스 앱 "Pinework"을 상상해보세요. 두 가지 역할이 있습니다: Admin과 Member. Admin은 도구를 연결하고 설정을 변경할 수 있습니다. Member는 연결된 도구를 사용할 수 있지만 추가하거나 제거할 수는 없습니다.
Pinework의 통합 디렉토리에서 각 카드는 명확한 라벨(Connected, Needs setup, Error), 한 줄의 "무엇을 하는지" 설명, 그리고 "2 of 3 steps"와 같은 설정 진행을 보여줍니다. 사람들은 클릭하지 않고도 무엇이 작동하고 무엇이 남았는지 알 수 있습니다.
Slack은 알림 용도로 사용됩니다. Admin이 Slack을 열면 상태: Connected, 설정: "3 of 3 steps"가 보입니다. Member도 Slack을 볼 수 있지만 주요 액션은 비활성화되어 "관리자에게 요청하세요"로 표시됩니다. Slack이 끊기면 Member도 무엇이 문제인지 볼 수 있지만 재연결 권한은 없습니다.
Google은 캘린더 용도로 사용됩니다. Pinework는 두 부서를 지원하므로 여러 연결을 허용합니다. Google 카드는 "Status: Connected (2 accounts)"처럼 표시됩니다. 아래에 "Marketing Calendar"와 "Support Calendar"가 간단히 나열됩니다. 설정이 완료되면 세부 페이지에서 두 연결 중 하나만 취소할 수 있습니다.
Stripe는 결제에 사용됩니다. 흔한 부분적 설정은 계정은 연결되었지만 웹후크가 완료되지 않은 경우입니다. 카드는 "Status: Needs setup, Progress: 2 of 3 steps"와 같이 표시되고 "Payments may not sync" 같은 경고를 제공합니다. 세부 뷰는 남은 단계를 명확히 합니다:
이렇게 하면 "연결된 것처럼 보이지만 아무것도 작동하지 않는" 상황을 피할 수 있습니다.
앱이 몇 개에서 수십 개로 성장할 때 통합 디렉토리는 보통 망가집니다. 문제는 대개 거대한 기술이 아니라 매일 사람들을 혼란스럽게 하는 작은 라벨링과 모델링 실수입니다.
흔한 문제는 'installed'와 'connected'를 섞어버리는 것입니다. Installed는 보통 "워크스페이스에 이용 가능"을 의미하고 Connected는 실제 자격 증명이 존재하고 데이터가 흐를 수 있음을 의미합니다. 이 둘이 섞이면 사용자는 준비된 것처럼 보이는 통합을 클릭하고 막다른 곳에 도착할 수 있습니다.
또 다른 실수는 상태를 너무 많이 만드는 것 입니다. 팀은 간단한 배지로 시작해 엣지 케이스들을 추가하면서 pending, verifying, partial, paused, degraded, blocked, expiring 등으로 발전시킵니다. 시간이 지나면 라벨이 현실과 어긋나기 쉽습니다. 실행 가능한 검사(예: 연결 안 됨, 연결됨, 주의 필요)로 묶은 소수의 상태를 유지하세요.
숨겨진 권한도 문제를 일으킵니다. 누군가 계정을 연결한 뒤 나중에 통합이 예상보다 광범위한 접근을 했다는 걸 발견하면 곤란합니다. 최종 "Connect" 단계 전에 범위를 명확히 보여주고 세부 페이지에서도 다시 보여줘서 관리자가 검토할 수 있게 하세요.
많은 앱은 여러 연결이 필요합니다: 두 개의 Slack 워크스페이스, 여러 Stripe 계정, 혹은 공유 Google 계정과 개인 계정. "하나의 통합 = 하나의 연결"로 하드코딩하면 나중에 보기 흉한 우회책이 필요해집니다.
계획해야 할 것들:
목록 뷰를 가볍게 유지하세요. 로그, 필드 매핑, 긴 설명으로 채우면 스캔 속도가 느려집니다. 목록은 이름, 짧은 목적, 설정 진행만 보여주고 이력과 고급 설정은 세부 페이지에 두세요.
확장 가능한 통합 디렉토리는 단순한 모델과 정직한 UI로 귀결됩니다. 사용자가 세 가지 질문에 빠르게 답할 수 있으면 시스템이 예측 가능하게 느껴집니다: 무엇이 연결되었나, 무엇이 고장났나, 다음엔 무엇을 해야 하나?
출시 전 체크리스트:
다음으로 이미 잘 알고 있는 세 가지 통합을 골라 엔드 투 엔드로 모델링해보세요: 채팅 도구(OAuth), Google 스타일 계정 연결(OAuth와 범위), 결제 도구(API 키 + 웹후크). 이 세 가지를 특별 케이스 없이 표현할 수 있다면 보통 30개로 확장해도 잘 작동합니다.
통합 카드가 무엇에 쓰이는지, 지금 작동하는지, 그리고 사용자가 다음에 무엇을 해야 하는지를 빠르게 보여주는 제어판으로 다루세요. 사용자들이 ‘이게 연결되었나?’를 확인하기 위해 클릭해야 한다면, 통합 목록은 확장될수록 신뢰를 잃습니다.
하나의 통합 카드는 보통 세 가지에 답해야 합니다: 무엇인지(이름 + 한 줄 설명), 상태(최근 동기화나 검사 시간과 함께 건강 상태), 그리고 상태에 따라 바뀌는 하나의 기본 액션 버튼. 기타는 모두 'Manage' 뒤로 숨겨서 스캔이 빠르게 유지되게 하세요.
제공 항목(카탈로그)과 워크스페이스에서 활성화된 것(설치), 그리고 실제 자격 증명(연결)을 분리하세요. 전역적인 Integration(카탈로그 항목), 워크스페이스 단위의 Install, 그리고 실제 OAuth 계정·API 키·웹후크 같은 Connection을 사용하면 ‘설치됨’과 ‘연결됨’을 혼동하는 문제를 피할 수 있습니다.
실제 팀에서는 같은 제공자에 대해 여러 외부 계정이 필요할 때가 많습니다. 예: 마케팅과 지원이 각각 다른 Google 캘린더를 연결하거나, 여러 Stripe 계정을 쓰는 경우. 하나의 Install 아래 여러 Connection을 모델링하면 목록은 깔끔하게 유지되면서 세부 페이지에서 개별 계정을 관리할 수 있습니다.
장기간 일관성을 유지할 수 있는 소수의 라벨을 사용하세요. 예: Not set up, In progress, Connected, Needs attention, Disabled. 그런 다음 토큰 유효성, 필수 설정 단계 완료 여부, 마지막 동기화 등 실제 검사 가능한 사실로부터 상태를 파생하세요. 이렇게 하면 수정됐는데도 배지가 갱신되지 않는 문제를 줄일 수 있습니다.
설정 진행은 필수 단계의 짧은 체크리스트와 차단하지 않는 선택적 단계로 구성하세요. 통합별로 단계 정의를 저장하고(정적), 각 설치별로 단계 결과를 저장하면 UI에서 "필수 단계 3개 중 2개 완료"처럼 명확하게 보여줄 수 있습니다. 사용자는 항상 다음 필요한 단계를 바로 볼 수 있어야 합니다.
먼저 전제품에 걸쳐 적용되는 단순한 역할 규칙으로 시작하고, 민감한 통합에만 추가 검사를 도입하세요. 많은 제품에서 Admin, Manager, Member 세 역할이면 충분합니다: Admin은 모든 작업 가능, Manager는 대부분의 통합 설정 가능, Member는 활성화된 통합을 사용할 수 있지만 설정은 못 함. 결제나 급여 같은 민감 항목은 별도의 '결제 관리자' 플래그 같은 단일 불리언으로 처리하세요.
사용자에게 보이는 설정(선택한 채널, 웹후크 별칭, 활성 이벤트 등)은 Install이나 Connection에 평문으로 저장하세요. 반면 리프레시 토큰, API 키, 서명 비밀 등 비밀값은 별도의 시크릿 저장소나 강력한 암호화 필드에만 보관하고 접근 제어를 엄격히 하세요. 원시 비밀이나 전체 권한 코드, 웹후크 페이로드는 로그에 남기지 마세요; 대신 connection_id 같은 참조와 안전한 메타데이터만 기록하세요.
오류 메시지는 세 가지를 답해야 합니다: 무슨 일이 일어났는가, 사용자가 무엇을 해야 하는가, 시스템은 다음에 무엇을 할 것인가. 예: "Slack 연결 만료. 다시 연결하면 동기화가 계속됩니다. 연결 후 자동으로 재시도합니다."와 같이 제공하면 사용자가 행동하기 쉽습니다. 임시 장애나 속도 제한은 백오프와 함께 조용히 재시도하고, 인증 만료나 권한 부족은 재시작이나 권한 수정을 요구하세요.
검색은 사용자가 생각하는 방식에 집중하세요: 공급자 이름(예: Slack, Stripe) 우선, 그다음 카테고리. 필터는 의도에 맞게 만들고 기본적으로 Connected, Needs attention, Not set up 같은 필터를 제공하면 문제가 있는 항목을 빠르게 찾을 수 있습니다. 또한 목록과 세부를 별도 로드로 처리하고, 30개 이상의 카드 렌더링을 피하기 위해 페이징이나 가상화와 같은 기법을 쓰세요. Koder.ai로 구축하는 경우 Planning Mode에서 카탈로그 필드, 상태 규칙, 설치 단계를 먼저 설계하면 UI와 백엔드가 일관되게 생성됩니다.