금융·공공을 넘어 전 분야로
개인정보 전송요구권은 정보주체가 자신의 개인정보를 본인 또는 자신이 지정한 제3자에게 보내달라고 요구할 수 있는 권리입니다. 2023년 개정 개인정보보호법에 근거 조항이 들어갔고, 실제 적용 대상과 항목·시점은 시행령을 통해 분야별로 나누어 정하는 구조입니다. 금융 마이데이터와 공공 마이데이터가 먼저 자리를 잡았고, 현재는 의료·통신·에너지 분야에서 제3자 전송요구권을 실제로 행사할 수 있습니다. 2026년 상반기에는 교육·고용 분야로 확대하는 시행령 개정안이 입법예고를 마쳤고, 문화여가와 복지·부동산·유통까지 단계적 확대가 예고돼 있습니다.
여기에 KISA 마이데이터 서비스 지원사업처럼 실증과 초기 구축을 뒷받침하는 프로그램이 붙으면서, 제도 시행일보다 시장이 먼저 움직이는 구간이 만들어지고 있습니다. "우리는 아직 대상이 아니다"라고 넘기기 어려운 이유도 여기에 있습니다. 직접 의무 대상이 아니더라도, 거래처나 플랫폼이 전송 연계를 요구하는 순간 대응 가능 여부가 곧 계약 조건이 되기 때문입니다.
전송요구에 응한다는 것의 기술적 의미
본인전송은 정보주체 본인에게 데이터를 내려주는 흐름이라, 본인확인만 확실하면 상대적으로 단순합니다. 문제는 제3자 전송입니다. 수신자가 정당한 자격을 갖췄는지, 동의 범위가 어디까지인지, 1회성인지 정기적 전송인지를 시스템이 스스로 판단해야 합니다. 금융 마이데이터가 화면 스크래핑이나 파일 전달 대신 표준 API 연계를 택한 것도, 전송 범위와 책임 경계를 기계가 검증할 수 있게 만들기 위해서였습니다.
그래서 전송요구는 단발성 조회 기능이 아니라 상태 기계로 설계해야 합니다. 요구 접수 → 본인확인 → 대상 항목 확정 → 전송 실행 → 완료 통지 → 이력 보관의 각 단계가 상태값으로 남아야, 중간에 실패하거나 철회 요청이 들어왔을 때 어디까지 나갔는지 답할 수 있습니다.
시스템에서 먼저 막히는 것들
실무에서 걸리는 지점은 대체로 법이 아니라 데이터 구조입니다.
보안 설계 체크포인트
동의는 범위와 기한을 함께 관리해야 합니다. 금융 마이데이터가 전송요구 유효기간을 최대 1년으로 두고 재동의를 받도록 한 것처럼, 동의 항목·수신자·만료일을 데이터로 저장하고 만료 시 자동 차단되도록 구현하는 편이 안전합니다.
전송 구간은 TLS 암호화와 단기 토큰을 기본으로 하되, 수신자 검증을 토큰 확인에서 끝내지 말고 사전 등록된 수신자 목록과 대조해야 합니다. 오·과전송이 발생했을 때의 절차도 미리 문서화해야 합니다. 현행법상 유출 인지 후 72시간 이내 통지 의무가 있는 만큼, 회수 요청·통지 대상 산출·재발 방지 조치를 담당자 기억에 맡길 수 없습니다.
준비 로드맵과 기회 요인
순서는 데이터 인벤토리 → 항목 표준화 → API 설계 → 동의·이력 관리 → 운영 자동화입니다. 첫 두 단계가 전체 기간의 절반 이상을 차지하는 경우가 많은데, 여기를 건너뛰고 API부터 만들면 항목 정의가 바뀔 때마다 다시 짜게 됩니다.
한 걸음 더 나가면 방어를 넘어선 기회가 보입니다. 데이터를 내보내는 쪽만이 아니라 받는 쪽 서비스를 설계하면, 고객이 다른 사업자에 흩어둔 데이터를 모아 개인화 추천이나 자동 견적 같은 신규 서비스를 만들 수 있습니다. 전송 대응을 규제 비용으로 볼지 채널 확장의 출발점으로 볼지가 갈리는 지점입니다.
POLYGLOTSOFT는 데이터 인벤토리 진단부터 항목 표준화, 전송 API 설계, 동의·이력 관리 화면 구축까지 단계별로 나누어 진행합니다. 구독형 개발로 월 단위 착수가 가능하므로 첫 달에 인벤토리와 항목 정의를 정리하고, 이후 API와 관리 화면을 붙여 나가는 방식이 부담이 적습니다. 우리 시스템이 전송요구에 답할 수 있는 상태인지 점검이 필요하시다면 언제든 문의해 주십시오.