30. API 기반 서비스 설계할 때 개인정보·프라이버시 관점에서 먼저 보는 것들

요즘 신규 서비스는 대부분 API를 중심으로 설계된다.
웹·앱·파트너 시스템이 모두 같은 API를 사용하고,
내부 백오피스까지 API에 의존하는 구조가 흔하다.

그런데 API 설계 단계에서 개인정보와 프라이버시를 놓치면
나중에 영향평가나 점검, 심지어 사고 대응까지
모든 단계에서 설명이 어려워진다.

실무에서 API 기반 서비스를 볼 때
개인정보·프라이버시 관점에서 먼저 정리해 보는 지점을 적어본다.

1. 엔드포인트별 데이터 맵핑: 무엇이 어디로 나가는지 먼저 그려보기

가장 먼저 하는 일은
엔드포인트별로 어떤 필드가 오고 가는지를 맵핑하는 것이다.
• /user/login, /user/profile, /user/withdraw
• /order/create, /order/list, /order/history
• /partner/user-sync, /partner/report

이런 식으로 API를 나열하고, 각 엔드포인트에 대해
• 수집·조회되는 개인정보 항목
• 토큰/세션으로 식별되는 정보
• 민감정보 또는 가명정보 사용 여부

를 표로 정리해 둔다.

이 과정은 DPIA(개인정보 영향평가)나 ISMS-P 심사에서도
설명 자료로 그대로 사용할 수 있다.
“API가 너무 많아서 정리가 안 된다”는 말은 많지만,
실제로 한 번만 그려 놓으면 이후 변경사항 반영도 훨씬 수월해진다.

2. 최소 수집·목적 제한 원칙을 API 파라미터 단위로 적용하기

개인정보보호법이나 GDPR에서 말하는
데이터 최소화(data minimization), 목적 제한(purpose limitation)은
문서가 아니라 설계 레벨에서 구현해야 한다.

API 설계 시에는 다음을 계속 의식하게 된다.
• 이 엔드포인트에서 정말 필요한 필드만 받고 있는지
• 하나의 엔드포인트에 과도하게 많은 개인정보를 몰아놓지 않았는지
• 반복해서 전송할 필요가 없는 값(예: 생년월일, 주민번호 유사 값)을
매 요청마다 송수신하고 있지는 않은지

가능하다면
민감도가 높은 필드는 별도 엔드포인트로 분리하거나,
가명식별자(pseudonymous ID)만 전달하고
실제 개인정보는 내부 시스템에서만 조회하도록 설계하는 것도 방법이다.

3. 인증·인가 토큰 설계와 스코프 정의

API 인증·인가 구조는
프라이버시 보호와 보안의 경계지점이다.
• Access token, refresh token
• OAuth2, OpenID Connect, JWT
• API key, HMAC 서명

어떤 메커니즘을 쓰든 중요한 것은
“토큰 하나가 어느 범위까지 권한을 가지는지”를 명확히 하는 것이다.

실무에서는 스코프(scope)를 쪼개는 방식이 효과적이었다.
• read:user, write:user
• read:order, write:order
• admin:*

이런 식으로 스코프를 세분화해 두면,
파트너·외부 시스템에 토큰을 발급할 때도
불필요한 개인정보 조회 권한을 줄일 수 있다.

또한 토큰에 직접 개인정보를 담기보다는
최대한 식별자·클레임 위주로 설계하고,
실제 개인정보는 내부 서비스에서만 조회하도록 분리하는 편이 안전했다.

4. 로깅·모니터링에 개인정보가 어떻게 남는지 보기

API 로그에는 생각보다 많은 개인정보가 남는다.
• Query string, JSON payload
• HTTP 헤더, 쿠키
• 오류 발생 시 덤프되는 상세 메시지

로그 설계 시에는 다음을 체크해야 한다.
• 전체 payload를 그대로 남기는지, 민감 필드는 마스킹하는지
• Authorization 헤더나 세션·토큰 값이 평문으로 남지 않는지
• 에러 로그에 불필요한 개인정보가 노출되지 않는지

특히 ELK, SIEM 같은 로그 분석 플랫폼으로 통합할 경우
다양한 담당자들이 로그에 접근하게 되기 때문에
로그 내 개인정보 처리 기준을 따로 정해 두는 것이 필요했다.

5. 외부 제공·3자 연동 API의 계약·로깅·제한 조건

파트너·외부 서비스와의 연동 API는
사실상 제3자 제공에 가까운 구조다.

그래서 다음 내용을 계약·정책에 함께 넣는 것을 추천한다.
• API를 통해 전달되는 개인정보 항목, 목적, 보존 기간
• 서브프로세서(sub-processor, 재위탁) 사용 여부와 제한
• API 호출 로그 보관 기간과 접근 권한
• 토큰 유출·오남용 발생 시 통보·차단 프로세스

이 부분이 정리되어 있으면
나중에 사고 발생 시에도
“어디까지가 우리 책임이고, 어디부터는 상대방 책임인지”를
상대적으로 명확히 설명할 수 있다.