모든 기사 엔터프라이즈

고객 의도를 반영하는 장소 순위 API

작성자 The Kaleidr Team · 게시일 2026년 8월 26일 · 17 분 읽기

후보 위치가 인증과 엄격한 적격성 검사를 통과한 뒤 공간, 의도, 최신성, 비즈니스 신호가 설명 가능한 지도 순위 결과를 만듭니다.

장소 순위 API는 특정 고객의 의사결정을 위해 공간 맥락, 고객 의도, 비즈니스 규칙, 데이터 최신성을 바탕으로 적격 위치의 순서를 정합니다. 권한, 이용 가능 여부, 필수 서비스, 서비스 지역 같은 엄격한 제약은 점수가 아니라 필터입니다. 언어 모델은 요청을 구조화된 요구 사항으로 해석할 수 있고, 지리공간 및 업무 시스템은 순위기가 결합할 사실을 제공합니다.

아래에서는 검색과 순위의 차이, 공급자 순위 모드, 엄격한 필터, 지리적 특성, 의도의 경계, 특성 설계, 인증, Kaleidr의 현재 공개 인터페이스, 평가를 설명합니다. 관련 글은 위치 인텔리전스 고객 경험 지도, 위치 인텔리전스 API란?, 위치 인식 예약, 지도 채팅을 갖춘 AI 매장 찾기, 지도 인식 AI 어시스턴트 구축 방법입니다.

장소 순위의 핵심

  • 점수보다 적격성 우선: 권한, 이용 가능 여부, 필수 기능, 서비스 지역은 잘못된 장소를 제거합니다.
  • 공간 특성은 과제와 일치해야 함: 직선거리, 이동 시간, 경로 우회, 영역 포함, 다중 앵커 적합도는 서로 다른 질문에 답합니다.
  • 의도는 구조화된 입력: 언어 모델은 선호를 해석하지만 장소·재고·경로 시스템이 사실의 권위 있는 출처입니다.
  • 불투명한 점수보다 이유: 이동 시간, 영업 상태, 필수 서비스처럼 검증 가능한 신호가 필요합니다.
  • 클릭뿐 아니라 결정을 측정: 후보 재현율, 제약 위반, 오래된 데이터, 후속 성과를 품질 계약에 포함합니다.

후보 위치가 인증과 엄격한 적격성 검사를 통과한 뒤 공간, 의도, 최신성, 비즈니스 신호가 설명 가능한 지도 순위 결과를 만듭니다.

장소 순위 API란 무엇인가요?

이 API는 이 고객, 이 과제, 현재 상태에서 어떤 유효한 위치가 먼저 보여야 하는지 답합니다. 검색 또는 검색 API는 보통 도시 근처 식당, 화면 안의 매장, 경로상의 호텔 같은 후보를 찾습니다. 순위는 인증과 엄격한 적격성 검사 후 남은 장소를 정렬합니다. 운영 환경의 위치 인텔리전스는 보통 ‘검색, 필터, 순위’ 세 단계를 모두 필요로 합니다. 유효하지 않은 레코드의 높은 점수는 성공이 아니라 제품 결함입니다.

유용한 출력은 불투명한 숫자 하나가 아니라 지도와 동기화된 순서 목록입니다. 각 결과에는 장소 ID, 순위, 실제 신호에 연결된 소수의 이유가 있어야 합니다. 발견은 적격 레코드를 가져오고, 비교는 이동 관계·서비스 적합도·최신성을 보여주며, 행동은 강조 표시, 길찾기, 예약·픽업 전환 또는 저장을 제공합니다.

순위는 가장 가까운 장소 검색과 왜 다른가요?

고객이 가장 가까운 적격 장소를 요청하고 다른 조건이 이미 충족됐다면 거리순은 타당합니다. 그러나 가장 가까운 매장이 픽업을 제공하지 않거나, 닫혔거나, 재고가 없거나, 크게 우회해야 하거나, 서비스 지역 밖이면 실패합니다. 올바른 흐름은 유효한 장소, 필수 서비스, 현재 이용 가능 여부, 이동 관계, 선호를 확인한 다음 정렬하는 것입니다. 거리는 전체 결정이 아닌 신호 하나입니다.

매장 찾기, 예약 후보, 통근 중심 부동산 검색, 이벤트 장소 편의시설 안내는 모두 화면에서 “내 주변”처럼 보여도 서로 다른 공간 특성을 요구합니다. 필수 규칙은 적격성에 두고 남은 후보만 순위를 매깁니다.

현재 검색 공급자는 장소를 어떻게 정렬하나요?

지도 검색 API는 이미 여러 모드를 제공합니다. Google Places Nearby Search (New)는 rankPreference에 POPULARITY 또는 DISTANCE를 문서화합니다(Nearby Search (New)). Text Search (New)는 적용 가능한 범주형 쿼리에 RELEVANCE 또는 DISTANCE를 지원하고, 도시명 같은 비범주형 쿼리에는 rankPreference를 설정하지 않도록 권장합니다(Text Search (New)). 이 설정은 공급자의 후보 집합만 정렬하며 호스트의 비공개 재고, 티켓 규칙, 예약 기간은 모릅니다.

Mapbox Search Box의 rank_strategy는 distance 또는 relevance를 받으며 근접 편향, 경로 인식 검색, 선택적 ETA도 제공합니다(Search Box API). 입력 경로가 있으면 제안에 미터 단위 added_distance와 분 단위 added_time이 포함될 수 있는데, 이는 단순 근접성이 아니라 우회 신호입니다. Google Places도 searchAlongRouteParameters로 Text Search를 경로 폴리라인 쪽으로 편향할 수 있습니다(Search along route). 공급자 순위는 후보 검색에 유용하고, 제품 순위는 호스트 고유 사실을 보강할 때 시작됩니다.

API는 어떤 결정을 최적화해야 하나요?

AI 순위 모델을 먼저 요구하지 말고, 목록이 개선해야 할 결정을 정의하십시오. 소매는 방문할 적격 매장, 예약은 일정에 맞는 이용 가능한 옵션, 부동산은 위치 요구 사항에 맞는 매물, 호텔은 투숙객 요청에 편리한 승인된 파트너, 이벤트는 다음 세션 전 관련 있는 전시자나 편의시설, 마켓플레이스는 지리적으로 가장 잘 맞고 요청을 수행할 수 있는 공급자를 고릅니다.

결정은 후보, 엄격한 제약, 공간 및 비즈니스 특성, 라벨, 지표를 정합니다. 통근 중심 매물에는 여러 앵커까지 이동 시간이 필요하고, 픽업에는 편의성보다 재고와 영업 상태가 먼저이며, 경로상 편의시설에는 직선거리가 아니라 우회가 필요합니다. 테스트 가능한 한 문장으로 과제를 쓰십시오. 모호한 “관련성”은 같은 카탈로그에서도 두 고객에게 반대 순서가 옳을 수 있음을 숨깁니다.

어떤 파이프라인을 사용해야 하나요?

견고한 파이프라인은 요청 해석, 후보 검색, 권한 확인, 엄격한 적격성, 특성 계산, 순위, 이유 생성, 지도·목록 표시, 결과 측정으로 이어집니다. 무효 장소는 점수 계산 전에 제거해 편리하지만 권한이 없거나 닫혔거나 지역 밖인 레코드가 상단을 차지하지 못하게 합니다. 그 뒤 이동 시간, 우회, 선호 적합, 최신성, 비즈니스 정책을 생존 후보에만 붙입니다. 이유는 동일한 신호에서 파생해야 하며 별도 문장으로 꾸며내면 안 됩니다.

큰 카탈로그는 비용을 단계별로 나눕니다. 검색은 제한된 후보를 반환하고, 저렴한 사전 순위는 근사 거리·범주·대략적 가용성을 사용하며, 이동 시간 행렬·우회·심층 보강은 짧은 목록에만 실행합니다. 정확한 크기는 애플리케이션 선택입니다. 단계별 지연을 측정하면 “AI”보다 경로나 재고 조회가 예산을 지배하는 경우를 찾을 수 있습니다.

엄격한 적격성 필터가 무효 위치를 제거한 후 유연한 순위 신호가 남은 후보를 비교합니다.

엄격한 필터가 순위 신호보다 먼저여야 하는 이유는 무엇인가요?

엄격한 필터는 이진 판단입니다. 흔한 관문은 활성 목록, 요청 서비스, 현재 재고, 예약 가능한 객실, 서비스 지역 포함, 티켓 권한, 요청 시간대 영업, 사용자 열람 권한입니다. 순위 신호는 생존 후보의 이동 시간, 우회, 거리, 가격·범주 적합, 선호, 최신성, 비즈니스 우선순위, 과거 전환을 비교합니다. “이용 불가 -20점”으로 바꾸면 무효 장소가 여전히 이길 수 있습니다.

필수 접근성, 권한, 법적 서비스 지역, 재고, 필수 기능도 같은 원칙입니다. 누락값은 0이 아닙니다. 평점이 없다면 중립 기본값, 특성별 대체, 낮은 신뢰도 표시를 쓰거나 그 필드가 필수일 때만 제외하십시오. 누락 데이터 규칙을 순위 정책 버전에 문서화합니다.

어떤 지리 신호를 사용해야 하나요?

장소에는 보편적 순위가 없습니다. 도로망이 중요하지 않으면 직선거리가 저렴한 근사치입니다. 약속, 매장, 호텔, 통근에는 이동 시간이 실제 편의성을 더 잘 나타냅니다. 도로 여행, 배달 정차, 현장 서비스에는 경로 우회가 맞고 Mapbox의 added_time과 added_distance가 이를 보여줍니다(Search Box API). 포함 관계는 배송 지역, 학군, 행사 구역 내부인지 답합니다. 다중 앵커 적합도는 호텔을 공항, 회의장, 사무실에 동시에 비교합니다.

정책은 시간을 평균 내거나, 가장 나쁜 구간을 최소화하거나, 모든 앵커가 임계값 아래일 때 가격순으로 정할 수 있습니다. 같은 특성 벡터도 승자가 달라집니다. 공식의 단순함이 아니라 고객 결정에 맞춰 선택하고 지도와 목록에 같은 정책 버전을 적용합니다.

제품이 직선거리, 이동 시간, 경로 우회, 여러 지리 앵커 중 무엇을 최적화하느냐에 따라 같은 적격 장소의 순위가 달라집니다.

고객 의도는 순위에 어떻게 들어가야 하나요?

자연어 요청은 필수 제약과 선호를 섞습니다. “컨퍼런스 근처의 조용한 카페로 공항 가는 길에도 편리한 곳”에는 유형, 암묵적 영업 시간, 대화에 적합한 환경, 근접 앵커, 경로 조건이 포함됩니다. 구조화 해석은 필수 필드와 선호를 분리합니다. 언어 모델이 해석하고, 장소 시스템이 후보를 찾고, 경로 서비스가 관계를 계산하고, 순위기가 검증된 신호를 결합합니다.

의도 모델을 사실 계층으로 쓰지 마십시오. 카페 영업, 재고, 객실, 11분 우회 같은 생성 주장은 승인된 시스템이 값을 제공해야만 순위 특성이 됩니다. OWASP Top 10 for LLM Applications 2025는 모델이 제안했다는 이유만으로 연결 기능을 실행하는 위험을 LLM06:2025 Excessive Agency라고 부릅니다. 지도 인식 어시스턴트처럼 모델은 구조화 요구를 제안하고, 결정론적 코드가 허가된 특성을 결합하며, 호스트가 지도 동작을 검증합니다.

개인화는 걷기, 주차, 조용한 환경, 저장 범주, 선호 지역 등 선언된 선호를 사용할 수 있습니다. 고객이 편집, 초기화, 무시할 수 있게 하십시오. 정당한 근거 없이 민감 특성을 추론하지 말고 파생 특성으로 충분하면 원시 민감 입력을 기록하지 않습니다. NIST Privacy Framework는 프라이버시를 기업 위험 관리로 다룹니다. AI 지도 워크플로의 비공개 위치 데이터도 같은 호스트 경계를 설명합니다.

순위 특성을 어떻게 결합하고 설명해야 하나요?

특성은 과제에 의미가 있고, 사용 가능하며, 충분히 최신이고, 올바르게 정규화되고, 허용되고, 테스트 가능해야 합니다. 미터, 별점, 통화, 선호 점수는 그대로 합칠 수 없습니다. 각 신호를 비교 가능한 적합도로 변환하고 정규화를 제품 정책으로 취급합니다. 이동, 의도, 최신성, 비즈니스 적합의 투명한 가중합은 검사·디버깅·설명·변경이 쉬워 학습 모델보다 나은 첫 버전일 수 있습니다. 가중치는 정책이지 증거가 아닙니다.

내부 점수 87.4를 의미처럼 공개하지 말고 “도보 12분”, “요청 시간 영업”, “필수 서비스 제공”, “선택 선호 일치”를 보여주십시오. 파트너, 충성도, 수용량, 프로모션 재고, 계약 순위, 운영 분산은 순서를 조정할 수 있지만 지리적 관련성과 분리해야 합니다. 상업적 배치가 영향을 주면 해당 공개 규칙을 따릅니다.

영업시간, 재고, 행사실, 출입구, 공급자 가용성은 낡기 때문에 최신성은 핵심 특성입니다. 오래된 중요 사실은 재검증하거나 제외합니다. 인기는 피드백 루프입니다. 유사한 지점 다섯 곳이나 좁은 군집이 선택지를 주지 못하면 두 번째 단계에 다양성과 지리적 범위를 넣을 수 있습니다.

공급자 순위와 제품 순위는 어떻게 다른가요?

검색되지 않은 장소를 순위기는 복구할 수 없습니다. 후보 재현율과 순위 품질을 따로 평가합니다. Google의 rankPreference와 Mapbox의 rank_strategy, 근접·경로 필드는 각 공급자 인덱스의 순서입니다(Nearby Search (New), Text Search (New), Search Box API). 호스트는 제한된 후보를 재고·적격성·경로로 보강하고 제품 과제에 맞게 재정렬할 수 있습니다.

추상적인 place가 아니라 사용자 맥락, 과제 맥락, 현재 상태를 조건으로 place를 정렬합니다. 사전 순위와 재순위는 결정을 바꾸는 곳에만 비싼 특성을 사용하기 위한 것입니다.

순위 요청은 어떻게 인증하고 구성해야 하나요?

설계 요청은 과제, 출발지, 후보 ID, 필수 요구, 선호, 결과 제한을 담고 응답은 순서가 있는 placeId와 검증 가능한 이유를 반환할 수 있습니다. 이는 설계 예시이며 문서화된 Kaleidr 경로가 아닙니다. 브라우저에서 비공개 레코드 전체를 보내기보다 ID와 허가된 백엔드 보강을 사용하십시오. 사용자가 호스트에 인증하고 호스트가 허용 후보를 가져온 뒤 그 집합에서만 순위를 계산합니다.

Kaleidr는 브라우저에 publishable key, 신뢰할 수 있는 백엔드 작업에 server key를 사용합니다(Auth & Scopes). 전자는 짧고 출처에 묶인 세션으로 교환되며 후자는 백엔드에 남습니다. 비공개 재고, 티켓 상태, 순위 자격 증명을 페이지 소스에 넣지 않습니다. 공급자가 지원하면 후보마다 경로를 호출하지 말고 이동 시간 행렬을 일괄 요청합니다.

Kaleidr는 현재 순위를 어떻게 포지셔닝하나요?

Kaleidr Enterprise는 현대 공간 제품을 위한 추론 API, 순위 시스템, 분석을 갖춘 위치 인텔리전스 인프라로 플랫폼을 설명합니다(Location Intelligence APIs and Map SDK). 이 페이지는 Kaleidr의 자체 포지셔닝에는 권위 있지만 현재 엔드포인트 목록을 대체하지 않습니다.

공개 Platform API 참조는 https://api.kaleidr.com/inference-api/b2b/v1/ 아래 채팅, 경로, POI 보강, 디자인 경로를 문서화합니다. POST /chat/control/stream, POST /chat/control/route, GET /retrieval/poi/enrich, design 스코프의 디자인 엔드포인트가 포함됩니다(Endpoints). 전용 공개 /rank 경로는 문서화하지 않습니다. 맞춤 순위는 Enterprise 통합 요구 사항으로 취급하고 현재 배포 계약이 제공하지 않으면 POST /rank를 구현하지 마십시오.

공개 인터페이스는 대화 의도, 경로 계산, POI 보강을 입력으로 제공할 수 있지만 독립 순위기는 아닙니다. 가정한 경로를 코딩하기 전에 지원 통합을 확인하십시오(Location Intelligence APIs and Map SDK).

순위 정책을 재현율, 제약, 품질, 지리적 편향에 대해 오프라인 평가하고 고객 성과와 진단 실패를 온라인 측정한 뒤 다음 버전으로 진행합니다.

장소 순위 품질을 어떻게 평가해야 하나요?

오프라인 평가에는 쿼리, 출발지, 엄격한 규칙, 선호 신호를 고정한 과제 집합이 필요합니다. 후보 재현율, 적격성 정확도, Top-K 품질, 제약 충족률, 설명 정확성, 지리적 편향을 측정합니다. “이 과제에서 A가 B보다 위여야 하는가?”라는 쌍 라벨은 절대 점수보다 수집하기 쉽고 향후 학습 순위기에도 유용합니다. 영업 중, 픽업 가능, 지역 내라는 필수 조건 중 하나라도 위반한 상위 결과는 클릭률과 무관하게 실패입니다.

온라인에서는 선택한 장소, 연 길찾기, 시작한 예약·픽업, 저장, 문의, 재검색을 측정할 수 있습니다. 클릭에는 위치 편향이 있어 첫 결과가 최선이었다는 증거가 아닙니다. 결과 없음, 엄격 규칙 위반, 오래된 데이터, 단계별 지연, 필수 특성 누락을 진단으로 유지하고 롤백 가능한 버전 정책에 반영합니다. 공간 분석 KPI 가이드도 단순 상호작용보다 과제 완료를 우선합니다.

20분 전에 닫은 매장, 비활성 출입구, 중단된 목록, 품절 재고가 어제의 인기로 상단에 남지 않도록 최신성 테스트도 포함합니다.

제품 팀이 예상해야 할 실패 유형은 무엇인가요?

실수 결과 더 나은 방법
적격성보다 먼저 순위 계산 무효 장소가 상단에 표시 엄격한 제약을 먼저 필터링
가장 가까운 곳을 최선으로 간주 과제 맥락 무시 결정에 맞는 공간 특성 사용
필수 규칙을 가중치로 처리 무효 옵션이 승리 가능 엄격 필터로 유지
모델이 사실을 창작 근거 없는 순위 영업시간·재고·경로를 권위 시스템에서 읽기
누락을 0으로 처리 희소 레코드가 불이익 누락 데이터 정책 정의
공급자 순서만 사용 제품 맥락 손실 호스트 사실로 재순위
클릭만 최적화 위치 편향을 품질로 오인 성과와 제약 위반 측정
이유를 모두 숨김 신뢰와 디버깅 붕괴 검증 가능한 신호 공개
순위 버전 무시 실험 추적 불가 정책 버전 관리와 롤백
Kaleidr /rank 경로 가정 존재하지 않는 통합 현재 Enterprise 계약 확인

모바일에는 큰 터치 영역, 읽기 쉬운 이유, 모델이나 비싼 특성이 시간 초과되어도 쓸 수 있는 지도가 필요합니다. 매장명 직접 검색도 계속 작동해야 합니다. 기본 형상과 라벨을 캐시하고 보강을 통제해 축소하십시오. 모호한 이름, 반대 출발지, 닫힌 장소, 오래된 재고를 지도·목록·이유가 함께 갱신될 때까지 테스트합니다.

제품에 장소 순위 API 구축하기

운영 패턴은 검색, 권한 확인, 엄격한 제약 필터링, 공간 특성 계산, 순위, 설명, 측정입니다. 거리, 인기, 의미적 관련성은 모두 유용할 수 있지만 보편적으로 옳지는 않습니다. 정책은 고객의 결정을 반영하고 지도에 검증 가능한 이유를 제공해야 합니다.

위치 인텔리전스 API, 순위 시스템, 배포 지원을 논의하려면 **Kaleidr Enterprise 살펴보기**를 이용하십시오. 통합 경로를 고정하기 전에 Kaleidr 개발자 문서에서 현재 추론, 검색, 인증, SDK 인터페이스를 검토하십시오.

자주 묻는 질문

장소 순위 API란 무엇인가요?

엄격한 적격성 규칙 후 지리, 비즈니스, 고객 맥락 신호를 사용해 특정 과제의 후보 장소를 정렬하는 API입니다.

가장 가까운 장소 검색과 같은가요?

아닙니다. 근접 검색은 주로 거리순이지만 장소 순위는 이동 시간, 우회, 가용성, 적격성, 선호, 최신성, 비즈니스 규칙도 고려할 수 있습니다.

이용 불가 장소는 낮은 점수만 주면 되나요?

가용성이 필수라면 다른 신호로 상쇄될 수 있는 감점 대신 순위 전에 제거해야 합니다.

검색과 순위의 차이는 무엇인가요?

검색은 후보를 찾고 순위는 유효 후보를 정렬합니다. 검색되지 않은 관련 장소를 순위기가 되살릴 수 없습니다.

공급자 순위를 사용한 뒤 재정렬할 수 있나요?

가능합니다. 관련성, 인기, 거리, 근접성, 경로로 얻은 후보를 애플리케이션이 보강·필터링·재정렬할 수 있습니다.

어떤 공간 신호를 사용해야 하나요?

결정에 맞는 신호를 씁니다. 단순 근접성은 직선거리, 실제 편의성은 이동 시간, 경로상 검색은 우회, 서비스 지역은 포함 관계가 적합합니다.

다중 앵커 순위란 무엇인가요?

호텔을 공항과 컨퍼런스 장소 모두에 비교하는 것처럼 여러 중요 위치를 기준으로 후보를 평가합니다.

언어 모델이 순위 점수를 계산해야 하나요?

자연어 선호는 해석할 수 있습니다. 검증된 특성은 결정론적 코드 또는 통제된 모델이 결합하며 시간, 재고, 가용성은 권위 시스템에서 가져옵니다.

순위를 어떻게 설명해야 하나요?

원시 내부 점수 대신 이동 시간, 픽업 가능, 요청 시간 영업 등 실제 신호에 연결된 짧은 이유를 반환합니다.

순위를 어떻게 평가해야 하나요?

후보 재현율, 엄격한 제약 충족, Top-K 품질, 라벨이 지원할 때 NDCG나 MRR, 후속 고객 성과를 평가합니다.

Kaleidr에 공개 장소 순위 엔드포인트가 있나요?

Kaleidr Enterprise는 순위와 분석을 제공하는 시스템과 API를 설명하지만 현재 공개 Platform API 참조에는 독립 /rank 엔드포인트가 없습니다. 지원되는 Enterprise 통합을 확인하십시오.

참고 문헌

@misc{google_nearby_search_2026_08_26,
  title  = {Nearby Search (New)},
  author = {{Google Maps Platform}},
  note   = {Places API; accessed 26 August 2026},
  url    = {https://developers.google.com/maps/documentation/places/web-service/nearby-search}
}

@misc{google_search_along_route_2026_08_26,
  title  = {Search along route},
  author = {{Google Maps Platform}},
  note   = {Places API; accessed 26 August 2026},
  url    = {https://developers.google.com/maps/documentation/places/web-service/search-along-route}
}

@misc{google_text_search_2026_08_26,
  title  = {Text Search (New)},
  author = {{Google Maps Platform}},
  note   = {Places API; accessed 26 August 2026},
  url    = {https://developers.google.com/maps/documentation/places/web-service/text-search}
}

@misc{kaleidr_auth_scopes_2026_08_26,
  title  = {Auth \& Scopes},
  author = {{Kaleidr}},
  note   = {Kaleidr Developer Docs; accessed 26 August 2026},
  url    = {https://docs.kaleidr.com/platform-api/auth-and-scopes}
}

@misc{kaleidr_endpoints_2026_08_26,
  title  = {Endpoints},
  author = {{Kaleidr}},
  note   = {Kaleidr Developer Docs; accessed 26 August 2026},
  url    = {https://docs.kaleidr.com/platform-api/endpoints}
}

@misc{kaleidr_enterprise_2026_08_26,
  title  = {Location Intelligence APIs and Map SDK},
  author = {{Kaleidr}},
  note   = {Accessed 26 August 2026},
  url    = {https://kaleidr.com/enterprise}
}

@misc{mapbox_search_box_2026_08_26,
  title  = {Search Box API},
  author = {{Mapbox}},
  note   = {Accessed 26 August 2026},
  url    = {https://docs.mapbox.com/api/search/search-box/}
}

@techreport{nist_privacy_framework_2020,
  title       = {NIST Privacy Framework: A Tool for Improving Privacy through Enterprise Risk Management, Version 1.0},
  author      = {{National Institute of Standards and Technology}},
  number      = {NIST.CSWP.01162020},
  institution = {National Institute of Standards and Technology},
  year        = {2020},
  month       = jan,
  url         = {https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.01162020.pdf}
}

@misc{owasp_llm_top10_2025,
  title  = {OWASP Top 10 for LLM Applications 2025},
  author = {{OWASP Gen AI Security Project}},
  note   = {Accessed 26 August 2026},
  url    = {https://owasp.org/www-project-top-10-for-large-language-model-applications/assets/PDF/OWASP-Top-10-for-LLMs-v2025.pdf}
}

관련 콘텐츠

지도를 비즈니스 성장의 동력으로 바꾸세요