101 lines
10 KiB
Markdown
101 lines
10 KiB
Markdown
**(사)한국인터넷자율정책기구 KSS(KISO Safeguard System)API 서비스**
|
|
## 서비스 도입 안내
|
|
|
|
### 첫번째 고려 사항
|
|
모든 IT 서비스들은 24시간 365일 정상 동작하는 것을 목표로 하지만 때로는 그렇지 못한 경우가 있습니다. KSS API 서비스를 여러분의 서비스에 이용하시려는 경우 가장 먼저 생각해야 하는 것은 언제라도 본 서비스가 동작하지 않을 수 있다는 점입니다. KSS의 모든 기술 스텝들은 최선을 다하여 시스템을 모니터링 하고 유지 하겠지만, 돌발 상황이 발생하여 시스템이 동작을 멈추는 경우라도 여러분의 서비스를 이용하는 사용자들에게는 불친절한 모습을 보이지 않도록 최대한 세심하게 도입 설계를 해 주세요. 짧게 말씀 드리자면, KSS가 응답하지 않는다고 해서 여러분의 서비스가 멈추도록 해서는 안된다는 의미 입니다. 이하의 내용은 그와 관련된 몇 가지 안내와 의견입니다.
|
|
|
|
### 서비스 가입 계정의 선택
|
|
이 문서를 둘러 보시고 서비스 이용을 해 보려 하시는 경우 가입에 사용하는 이메일은 담당자 개인 메일이 아닌 조직의 역할 이메일((예를 들면 admin@ 혹은 infra@와 같은)을 사용하시는 것을 권합니다. 그리고 로그인에 사용하는 메일 계정으로 수신되는 메일을 자주 모니터링 하지 않는 경우에는 서비스로부터의 중요한 공지 사항등을 수신할 수 있도록 서비스 내에 개인 정보 수정 항목에서 이메일 주소를 늘 모니터링 되는 이 메일 주소로 변경해 주세요.
|
|
|
|
|
|
### 인증 로고 활용의 검토
|
|
KSS를 활용하여 얻을 수 있는 장점으로 표준화된 필터와 기준의 적용을 사용자들에게 안내 하여 서비스에 대한 신뢰를 높일 수 있다는 점이 가장 크다고 생각합니다. 여러분이 본 서비스를 활용하시려는 경우에는
|
|
<a class="font-semibold text-indigo-600 hover:text-indigo-500" href="/doc/certification" >인증 로고 안내</a>
|
|
의 내용도 참고해 주세요.
|
|
|
|
|
|
|
|
### 가장 일반적인 사용의 예
|
|
웹 페이지에서 DB에 게시물을 작성하는 경우를 예로 들어 보겠습니다. 사용자측에서 작성된 내용을 DB에 저장해 달라는 요청이 들어오면 서버에서는 먼저 해당 계정이 적절한 권한을 가지고 있는지 등을 검사하고 만약 조건에 맞지 않는 요청이라면 오류 메세지를 리턴합니다. 이 과정(여러가지 권한 검사)에 KSS API 호출 과정도 추가하여 만약 검사 결과가 적절치 못하다면 이런 표현은 달리 바꿔 달라는 오류 메세지로 사용자에게 되돌려 줄 수 있습니다. 만약 특정 시점에 KSS API가 정상 동작하지 않는다면(타임아웃이 될 동안 응답이 오지 않거나 서버가 아예 응답이 없거나 등) 그 사실을 그대로 사용자에게 오류 메세지로 표시하는 결과를 되돌릴 수 있습니다.
|
|
|
|
>본문 검사 과정에서 오류가 발생하였습니다. 잠시 후에 다시 시도해 주세요.
|
|
|
|
이 경우, KSS API가 정상 동작하지 않는다면 게시물의 작성이나 댓글 등이 모두 멈춘다는 단점은 있으나 구현이 가장 단순하고 사용자에게도 혼란이 가장 적은 일반적인 적용 예라 할 수 있습니다.
|
|
|
|
|
|
### 실시간 채팅, 메세징에서 사용하는 경우
|
|
실시간 채팅이나 메세지도 결국은 중계를 위해 서버를 거치게 되는데 이 과정에서 메세지를 보낸 사용자의 자격이나 계정 등에 대해 기본적인 검사를 하게 됩니다. 이 부분에 필터 API의 호출 부분을 넣어 그 결과에 따라 필터를 적용한 메세지로 바꿔 전달하거나 혹은 전송 요청을 한 사용자에게 전송 거부의 오류 메세지를 되돌려 줄 수 있습니다. 예를 든다면
|
|
|
|
>이런 개자식을 봤나.
|
|
|
|
이런 입력은
|
|
|
|
>이런 ***을 봤나.
|
|
|
|
혹은 오류 메세지로 전송을 거부할 수 있습니다.
|
|
|
|
>부적절한 표현들이 포함되어 있습니다. '개자식'
|
|
|
|
이 경우 서버측의 회신 메세지 예는 아래와 같고, 응답시간은 33밀리초 입니다.
|
|
```
|
|
{
|
|
"TrackingId": "7408a8f2-5843-59f5-8352-9ef2f80d89ec",
|
|
"Status": {
|
|
"Code": 2000,
|
|
"Message": "OK",
|
|
"Description": ""
|
|
},
|
|
"Detected": [
|
|
[
|
|
3,
|
|
"개자식"
|
|
]
|
|
],
|
|
"Filtered": "이런 ***을 봤나.",
|
|
"Elapsed": "0 s, 10.448 ms"
|
|
}
|
|
```
|
|
|
|
|
|
### API 키를 클라이언트에서 사용하는 경우
|
|
일반적인 상황이라면 API 키는 서버측에서 사용하고 사용자측, 클라이언트측에 노출되지 않도로고 하는 것이 최선입니다. 하지만 부득이하게 클라이언트측에서 사용해야 하는 경우라면 일정 시간마다 해시값을 발생시키고 이를 API 키 호출에 추가하여 서버측에서 이 값을 검사하고 만약 복사된 키가 계속 사용된다면 오류를 되돌리도록 할 수 있습니다. 구체적인 해시 키 사용과 설정의 방법은
|
|
<a class="font-semibold text-indigo-600 hover:text-indigo-500" href="/doc/api_doc" >API 연동 안내</a>
|
|
문서를 참고해 주세요. 단, 이 기능은 바로 사용하실 수 없으며 저희 기술팀에 문의하여 키를 이 방식 처리에 대응하도록 설정해야 합니다. 관련된 문의는 [netsafe@kiso.or.kr](mailto:netsafe@kiso.or.kr)로 메일 주세요.
|
|
|
|
### KSS가 멈춘 동안 작성된 필터 되지 않은 컨텐츠의 처리
|
|
사용자가 클라이언트측에서 무언가를 입력하고 전송 버튼을 누른 경우, 게시물의 댓글을 예로 들어 보겠습니다. 댓글은 우선 서버에서 KSS API 서비스를 호출하여 부적절한 표현이 포함되어 있는지 검사하고 만약 검사 결과가 좋지 않다면 사용자에게 이 내용은 DB에 입력할 수 없다는 오류 메세지를 출력하는 것이 일반적인 흐름입니다. 그런데 만약 KSS API가 응답이 없다면 어떻게 할까요? 어떤 댓글은 모욕적인 표현이 없는 상태로 저장되었지만 어떤 운 좋은 댓글들은 모욕적인 표현들이 그대로 포함된 채로 게시될 것입니다. 이렇게 만에 하나 발생할 수 있는 간헐적인 장애로 모욕적인 표현의 필터가 동작하거나 하지 않을 수 있는 불일치가 서비스 품질에 심각한 영향을 준다면 조금 작업이 복잡해 지긴 하지만 안전 장치를 할 수 있습니다.
|
|
|
|
게시물의 댓글 DB에 현재 이 댓글이 필터가 완료된 상태인지 필터 전인지를 표시하는 플래그와 DB에 저장된 시간(이 값은 보통 이미 있겠지요)을 저장합니다. 그리고 욕설·비속어 필터가 통과되지 않은 댓글은 '처리중'이라는 텍스트가 대신 표출되도록 해 둡니다. 댓글을 저장할 때 KSS API를 비동기 방식으로 호출할 수 있으며 처리가 끝난 후 호출될 콜백 주소를 지정할 수 있습니다. 이곳에서 해당 댓글의 검사 결과가 깨끗하다면 필터 완료로 마크하고 사용자들에게 댓글은 정상 표출될 것입니다. 만약 특정 시점에 KSS API의 동작이 실패하여 일정 시간(보통 5초 이내)이 지났음에도 필터가 완료 마크되지 않은 항목들은 한번 더 KSS 검사를 동기 방식으로 요청하여 직접 그 결과를 처리할 수 있습니다. 이런 시나리오에 필요한 세부적인 API 호출 파라메타와 예시는 <a class="font-semibold text-indigo-600 hover:text-indigo-500" href="/doc/api_doc" >API 연동 안내</a> 문서를 참고해 주세요.
|
|
|
|
|
|
### DB를 직접 활용하거나 인공지능을 이용해 욕설·비속어을 검출하는 방식에 대한 의견
|
|
KSS API 서비스는 국내 대형 포털에서 오랜 기간 고객 응대를 하며 축적된 대량의 욕설·비속어 단어 DB를 기반으로 합니다. 어떤 경우에, 사업적인 판단에 의해, 여러분의 서비스에 자체적인 욕설·비속어 DB를 구축하고 유지하는 것에 대해 검토하실 수 있습니다. 저희가 본 서비스를 구축하게 된 계기도 바로 그 지점에 대한 고민이었습니다. 우선 현실적으로 한글로 된 적절한 DB를 최초 획득하는 것이 쉽지 않습니다. 어찌 하여 꽤 괜찮은 DB를 구했다 하더라도 새로운 표현이 계속 만들어 지기 때문에 결국은 이 시스템으로 일손을 던다기 보다는 그 DB를 계속 최신으로 유지하기 위한 노력이 시스템 구축의 비용보다 장기적으로는 더 많이 든다고 생각하게 되었습니다. DB 비교 방식의 장점은 특정 이슈에 즉각적으로 대응할 수 있다는 것입니다. 우리는 그 장점과 거대한 DB를 항상 최신으로 유지하며 표준적인 가이드를 제시하는 역할을 누군가 해 준다면 회원사들이 조금 더 서비스 본연에만 집중할 수 있지 않을까 생각 했습니다. 인공지능으로 전혀 새로운, 욕설·비속어을 발견하는 것이 가능은 합니다. 하지만 결국 사용자의 컴플레인으로 그 판정들을 다시 리뷰하고 그 결과를 인공지능 엔진에 적용하는 작업이 간단하지 않습니다. 결국 욕설·비속어에 대한 필터링은 고객 응대 이슈와 끊임 없이 맞물리게 되므로, 저희가 표준화된 가이드를 제공하고 회원사들이 그것을 이용하는 것이 각자 역할의 분담이 될 것이라고 생각 합니다.
|
|
|
|
|
|
|
|
|
|
### 개인 정보와 관련된 이슈
|
|
KSS API 서비스를 사용하기 위해서는 이메일 주소로 가입이 필요하며 저희가 수집하는 개인정보는 이메일 주소 뿐입니다. 나머지 항목들은 필수적인 항목이 아니며, 운영자가 사용자를 식별하기 위해 메모의 형식으로 별도 보관하는 항목들은 다음과 같습니다.
|
|
|
|
> 업체명, 담당자 이름, 직함
|
|
|
|
API 서비스를 호출하게 되면 서버는 주어진 문장을 검사하여 필터 결과만을 리턴하며 후에 통계를 생성할 목적으로 다음과 같은 내용의 로그를 남깁니다.
|
|
|
|
```
|
|
{
|
|
TrackingId: 호출 고유 아이디,
|
|
uid: API 키 소유자 내부 아이디(이메일 주소 아님),
|
|
key: API 키,
|
|
hit: 검출된 단어 수,
|
|
words: 검출된 단어들,
|
|
size: 전송된 원문의 크기,
|
|
referrer: 웹 요청 리퍼럴,
|
|
ip: 웹 요청 아이피,
|
|
|
|
}
|
|
```
|
|
|
|
|
|
### 기타 문의
|
|
본 서비스와 관련해 궁금하신 점이 있다면 [netsafe@kiso.or.kr](mailto:netsafe@kiso.or.kr)로 메일 주세요.
|