Consent Journey

Consent Journey는 겉으로만 보면 동의 화면을 만들고 이메일을 보내는 작업처럼 보일 수 있다. 하지만 실제로는 법률 검토, 대량 발송, 바운스 대응, 내부 운영 도구 정리, 반복 배포가 동시에 얽힌 프로젝트였다. 이 글은 그 경험이 단순한 기능 개발이 아니라, 운영과 규정, 시스템 제약이 한데 만나는 전형적인 전환기 프로젝트였다는 점을 남기기 위해 쓴다.

특히 이 작업은 “코드만 잘 짜면 끝나는 문제”와 가장 거리가 멀었다. 요구사항이 기능 명세서에서 확정되는 것이 아니라, 법적 문구 검토와 운영 판단, 발송 결과를 보며 계속 바뀌었기 때문이다. 그래서 이 글은 구현보다도 반복 수정과 운영 부담이 어떻게 프로젝트의 본질을 바꿨는지에 초점을 둔다.

프로젝트의 출발점은 개인정보와 동의 처리에 대한 요구를 서비스 흐름 안에 반영해야 한다는 필요였다. 그런데 이 문제는 단순히 새로운 화면 하나를 추가하는 것으로 끝나지 않았다. 어떤 문구가 법적으로 허용되는지, 사용자가 어떤 항목에 동의해야 하는지, 동의 상태를 어떻게 관리해야 하는지, 대량 이메일 발송 결과를 어디까지 추적해야 하는지가 모두 연결돼 있었다.

특히 국내법상 개인정보를 국외로 이전하려면 사용자 동의가 필요했기 때문에, Consent Journey는 있으면 좋은 기능이 아니라 전환을 진행하기 위한 필수 선행 과제였다. 즉 이 작업은 UI 개선 프로젝트가 아니라, 법적 요구를 시스템과 운영 흐름에 정확히 연결하는 작업이었다.

또한 대상 규모가 컸기 때문에 구현 난이도보다 운영 난이도가 더 크게 다가왔다. 동의 문구가 수정되면 화면도 바뀌고, 발송 준비도 다시 맞춰야 하고, 운영자가 관리해야 할 상태와 예외 케이스도 늘어난다. 결국 Consent Journey는 기능 하나가 아니라 여러 조직과 시스템이 반복적으로 맞물리는 긴 운영 프로젝트였다.

Consent Journey 실행 흐름

동의 양식과 법률 리뷰의 반복

동의 양식은 UI 요소처럼 보이지만, 실제로는 법적 정확성과 사용자 이해 가능성을 동시에 만족해야 하는 문서형 인터페이스에 가까웠다. 문제는 이 문구가 처음부터 한 번에 정리되지 않는다는 점이었다. 초안을 만들고, 외부 법률 검토 주체의 피드백을 반영하고, 다시 수정하고, 운영적으로 가능한지 확인하는 사이클이 여러 번 반복됐다. 이 반복 때문에 프로젝트 속도는 코드보다 검토 리듬에 더 크게 영향을 받았다.

개발 입장에서 중요한 것은 이 반복을 “스펙 변경”으로만 받아들이지 않는 것이었다. 법적 문구가 바뀌면 UI 배치, 동의 항목 구조, 운영 설명 방식까지 함께 흔들릴 수 있었다. 그래서 구현은 단단하게 고정하는 것보다, 반복 수정에 버틸 수 있는 구조를 만드는 쪽으로 가야 했다. 전환기 프로젝트에서는 완성형 설계보다 수정 가능한 구조가 더 중요할 때가 많다.

특정 이메일 발송 벤더와 대량 발송의 부담

대상 규모가 커지면 이메일 발송은 단순한 알림이 아니라 별도의 운영 시스템처럼 다뤄야 한다. 발송 성공률, 반송 처리, 재시도 전략, 사용자 경험까지 동시에 고려해야 하기 때문이다. 특히 특정 이메일 발송 벤더를 통해 대량 발송을 하게 되면, 우리 시스템 안쪽의 구현뿐 아니라 벤더의 처리 특성과 한계도 같이 생각해야 한다.

이 지점에서 중요한 것은 “보냈다”보다 “결과를 어떻게 관리하느냐”였다. 대량 발송은 항상 일부 실패와 예외를 동반하고, 그 예외는 다시 운영자가 설명하고 정리해야 하는 상태로 돌아온다. 그래서 발송 기능은 구현보다도 후속 관리 체계가 중요했고, 이 프로젝트가 길어진 이유도 상당 부분 그 운영 후속 작업에 있었다.

바운스 관리 로직

바운스는 기능 요구사항 문서에서는 종종 주변부처럼 보이지만, 실제 대량 발송에서는 핵심 운영 항목이었다. 유효하지 않은 주소, 일시적 실패, 스팸 처리, 수신 거부 같은 케이스가 누적되면 단순히 발송 성공률이 떨어지는 문제가 아니라, 운영자가 어떤 상태를 기준으로 다시 대응해야 하는지 불분명해진다. 그래서 바운스 관리 로직은 예외 처리라기보다 결과 해석 체계에 가까웠다.

특히 대량 발송에서는 도메인 평판(reputation)과 화이트리스트 정책이 함께 걸린다. 바운스율이 급격히 올라가면 수신자 측 메일 시스템뿐 아니라 발송 벤더도 자기 도메인/인프라 보호를 위해 발송량을 제한하거나 일시 중지시키는 경우가 있다. 즉 바운스 관리는 “몇 건 실패했는가”의 문제가 아니라, 발송 채널 자체가 막히지 않도록 하는 가용성 관리에 가깝다.

그래서 운영에서는 사전 정제, 단계적 발송, 임계치 기반 중단 기준을 함께 운용해야 했다. 바운스율이 위험 구간으로 들어가면 즉시 속도를 낮추거나 중단하고, 원인군(무효 주소/일시적 실패/차단)을 분리해 후속 조치를 적용해야 했다. 이 기준이 없으면 발송 자체가 벤더 레벨에서 차단되어 프로젝트 일정 전체가 흔들릴 수 있다.

이 로직을 정리해두니 프로젝트를 보는 관점도 바뀌었다. 단순히 동의 화면을 노출하고 메일을 보내는 기능이 아니라, 발송 이후 상태를 어떻게 추적하고 설명할지까지 포함한 전체 여정으로 보이기 시작했다. Consent Journey라는 이름이 기술적으로도 의미를 가지게 된 건 바로 이 지점 때문이었다.

동의 상태 관리용 내부 Admin

프로젝트가 길어질수록 동의 상태 관리용 내부 Admin의 중요성이 커졌다. 운영자는 단순히 기능이 배포됐는지보다, 어떤 사용자가 어떤 상태에 있는지, 예외 케이스를 어떻게 봐야 하는지, 재확인이나 후속 조치가 필요한 대상을 어떻게 찾을지를 알고 싶어했다. 결국 내부 도구 없이는 대량 발송과 동의 상태 관리를 사람 손으로 감당하기 어려웠다.

이 내부 도구는 사용자에게 보이는 기능보다 덜 화려하지만, 실제 운영에서는 훨씬 중요했다. 반복 배포가 길어질수록 운영자는 결과를 설명하고 정리할 수 있는 도구가 필요했고, 그 도구가 없으면 기능은 있어도 프로젝트는 끝나지 않는다. 이 경험은 전환기 시스템에서 내부 운영 도구가 얼마나 큰 가치를 가지는지 다시 보여줬다.

동적 양식 UI

법적 검토와 운영 판단이 반복될수록 고정된 화면보다는 변경 가능성을 흡수할 수 있는 동적 양식 UI 접근이 더 유효했다. 항목 구성이 바뀌거나 문구가 수정될 때마다 전체 구조를 다시 뜯어고치기보다, 변경이 잦은 부분을 유연하게 다루는 편이 반복 작업 비용을 줄여줬기 때문이다. 전환기 프로젝트에서 구현의 완성도는 종종 “얼마나 예쁘게 만들었는가”보다 “얼마나 반복 수정에 덜 아픈가”로 판단된다.

이 접근은 단순히 개발 편의성의 문제가 아니었다. 법적 문구와 운영 요구가 계속 바뀌는 프로젝트에서는 변경 속도 자체가 일정 리스크를 결정한다. 따라서 동적 양식 UI는 구현 선택이면서 동시에 일정 방어 전략이기도 했다.

4개월의 반복 배포

이 프로젝트가 길어졌던 가장 큰 이유는 단발성 기능 개발이 아니라, 반복 수정과 반복 배포가 프로젝트의 본체였기 때문이다. 요구가 명확하지 않아서가 아니라, 요구가 외부 검토와 운영 결과를 거치며 계속 정교해졌기 때문이다. 그래서 일정이 길어진 것은 실패라기보다, 이 프로젝트의 본질이 한 번에 끝나는 구현이 아니었다는 뜻에 더 가까웠다.

결국 Consent Journey는 법률, 대량 발송, 예외 처리, 내부 도구, 반복 배포를 한데 묶어야 하는 운영 프로젝트였다. 앞선 글들에서 본 운영 구조와 배포 체계가 왜 중요한지 이 사례도 분명히 보여준다.

아키텍처 관점에서 본 핵심 선택

이 프로젝트의 기술적 핵심은 “한 번에 고정된 정답”을 만드는 것이 아니라 변경 비용을 줄이는 구조를 만드는 데 있었다. 동적 양식 UI와 상태 관리 도구를 함께 설계하면, 법률/운영 요구 변경이 들어와도 전체 재개발 없이 핵심 축만 수정할 수 있다.

장점은 반복 배포 속도를 유지할 수 있다는 점이고, 단점은 설계 초기에 추상화 비용이 늘어난다는 점이다. 하지만 요구 변경이 잦은 도메인에서는 초기 추상화 비용보다 반복 수정 비용이 더 크기 때문에, 결과적으로 이 선택이 일정과 품질 모두에 유리했다.

운영 경로 요약표

기술 체크포인트

• 동의 항목/문구 변경은 UI 하드코딩 대신 설정 기반으로 흡수했다.
• 발송 결과는 상태코드별(성공/일시실패/영구실패)로 분리해 운영 대응 속도를 높였다.
• 운영 도구에서 대상자 조회/재처리 기준을 함께 제공해 반복 배포 부담을 줄였다.