로그인 버튼 뒤의 책임 — 읽을 수 있는 약관을 만들기까지

계기는 로그인이었다

지난 편에서는 실제 리뷰를 작성하기 위해 로컬 에디터를 만들고, 로그인과 미디어 업로드를 연결한 과정을 기록했다. 로그인은 업로드 권한을 확인하기 위해 필요한 기능이었지만, 이를 만들면서 기능 밖의 일도 생각하게 됐다.

이용약관과 개인정보처리방침이었다.

이전에 다녔던 회사에서의 경험 때문에 이 문서들을 나중으로 미뤄도 되는 일로 생각하기 어려웠다. 기능을 만드는 데 집중하다 보면 귀찮은 작업처럼 느껴질 수 있다. 하지만 빠뜨린 내용 때문에 문제가 생겼을 때 작은 회사도 감당하기 어렵다면, 개인으로 서비스를 운영하는 나는 어떨까.

로그인 버튼을 붙이는 것과 함께, 이용자에게 어떤 내용을 알려야 하는지도 준비해야겠다고 생각했다.

Geek Story 다음의 서비스도 생각했다

Geek Story 외에도 로그인이 필요한 온라인 서비스를 만들 계획이 있고, 이미 개발 중인 서비스도 있다.

당장 통합 로그인 환경을 만드는 것은 아니다. 그래도 여러 서비스를 운영할 생각이라면, 이용 조건과 개인정보를 다루는 방식을 정리하는 일을 계속 뒤로 미루고 싶지는 않았다.

우선 약관과 개인정보처리방침을 작성해 이용자가 확인할 수 있도록 해두기로 했다. 앞으로의 구상과 현재 서비스에서 실제로 제공하는 것은 구분해서 생각할 필요도 있었다. 계획하고 있다는 이유로 아직 없는 기능을 이미 운영하는 것처럼 설명할 수는 없기 때문이다.

먼저 한국에서 적용되는 법부터

내 서비스들의 주된 이용 무대는 한국이다. 그래서 한국에서 적용되는 법과 관련 정보를 먼저 살펴봤다.

자료를 모으면서 반드시 다뤄야 할 내용과, 명확하게 정리하지 않으면 문제가 될 수 있는 내용을 구분하려고 했다. 다른 서비스의 문서를 그대로 가져오기보다, 내가 운영할 서비스에 어떤 내용이 필요한지 이해하는 것이 먼저라고 생각했다.

쉽지는 않았다. 일상에서 사용하는 말과 거리가 있는 표현이 많았다. 문장을 읽어도 정확히 무엇을 뜻하는지 바로 이해되지 않았고, 그 내용을 내 서비스에 어떻게 적용해야 할지도 고민해야 했다.

어찌저찌 자료를 읽고 내용을 정리해나갔다. 이 글은 그 과정에 대한 개발 기록이다. 내가 작성한 문서가 법적으로 충분한지에 대한 판단과는 구분해서 남기려고 한다.

쉽게 쓰되, 의미를 흐리지 않기

조사하면서 일반적인 서비스들의 이용약관도 살펴봤다. 사용자 입장에서 읽기에 너무 어렵다는 생각이 들었다.

내 서비스의 문서는 보기 쉽고 이해하기 좋게 만들고 싶었다. 문장을 간단하게 쓰고, 필요한 내용을 찾기 편하게 구성하는 방향이었다.

하지만 쉽게 쓰는 일은 생각보다 어려웠다. 설명을 줄이면 중요한 조건이 빠질 수 있고, 익숙한 말로 바꾸다가 원래 전달해야 하는 의미가 흐려질 수도 있었다.

돌려 말하지 않으면서도 오해가 생기지 않게 써야 했다. 간단하게 설명한다는 이유로 내용까지 대충 정리할 수는 없었다. 표현 하나를 바꿀 때에도 무엇을 전달하려는 문장인지 다시 생각하게 됐다.

문서를 화면에 보여주는 방식까지

문장만 쉽게 바꾸는 것으로는 충분하지 않았다.

보통의 약관 페이지는 흰 배경에 검은 글씨가 이어지고, 제목과 부제목을 다른 글씨보다 크게 표시한다. 내 눈에는 그 방식으로 구성된 긴 문서가 잘 들어오지 않았다. 어디가 중요하고 어떤 설명들이 함께 묶이는지 빠르게 파악하기 어려웠다.

그래서 내용을 화면에 배치하는 방법도 바꿨다.

중요한 내용은 강조했다. 서로 관련된 설명은 하나의 상자에 묶어서, 같은 주제의 내용을 함께 읽을 수 있도록 했다.

작은 글씨로 표시할 만한 내용 중에도 중요한 조건은 있었다. 그런 부분에는 일반 텍스트와 다른 색을 넣어 눈에 띄도록 했다. 글씨가 작다는 이유로 중요성까지 작아 보이지 않게 하고 싶었다.

모든 문장을 똑같이 강조하기보다, 필요한 내용이 눈에 들어오도록 구성하려고 했다. 문장의 의미를 명확하게 쓰는 일과 그 문장을 발견하기 쉽게 보여주는 일은 함께 필요했다.

서비스가 바뀌면 문서도 다시 살펴봐야 한다

약관을 한 번 작성해두면 이후 기능을 추가할 때도 그대로 사용할 수 있을까. 내가 운영하려는 서비스가 늘어나고 로그인이나 개인정보 처리 방식이 달라진다면, 처음 작성한 설명이 계속 맞는지 다시 확인해야 한다.

이번에 당시 작성한 문안을 다시 보니 그 점이 더 구체적으로 보였다. 이름과 비밀번호로 작성하는 익명 댓글, 접속 IP 수집, 삭제한 댓글의 임시 보관 같은 내용이 들어 있었다. 이런 문장은 표현을 쉽게 고치는 것만으로 완성되지 않는다. 실제로 제공하는 기능인지, 어떤 정보를 저장하는지, 삭제 요청 뒤에 무엇이 남는지를 구현과 함께 확인해야 한다.

특히 보관 기간이 “30일 또는 최대 90일”처럼 적혀 있다면 적용 조건과 실제 기간을 먼저 정해야 한다. 글을 짧게 다듬어도 미정인 운영 기준까지 해결되지는 않는다. 여기서 확인한 문안이 현재 구현과 모두 일치하는지까지 검증한 것은 아니다. 글을 개정하며 다시 점검할 항목으로 남긴다.

내가 앞으로 재검토의 계기로 삼으려는 것은 두 가지다.

• 서비스 변경: 로그인 수단, 댓글 방식, 수집 정보, 데이터 이용 목적이나 보관·삭제 방식이 달라질 때 실제 동작과 문서를 비교한다.
• 관련 법령 개정: 서비스에 적용되는 규정이 바뀌면 시행 시점과 영향을 확인하고, 문서뿐 아니라 기능과 운영 절차도 수정해야 하는지 검토한다.

변경이 생길 때마다 모든 문장을 무조건 고치겠다는 뜻은 아니다. 어떤 문서와 기능에 영향을 주는지 확인하고, 수정이 필요하다면 구현과 문서가 서로 다른 상태로 남지 않도록 맞추려 한다. 법령 변경을 지속적으로 확인하는 체계나 변경 사항을 빠짐없이 반영하는 절차까지 갖춘 상태는 아니다.

새 문서로 덮어쓰는 것만으로는 부족했다

약관 화면에는 변경 이력과 과거 버전을 열람하는 기능도 만들었다. 버전별 문서를 JSON으로 보관하고, 버전과 시행일, 변경 내용을 함께 보여주는 구조다. 개정 이력의 문서는 화면 전체를 덮는 모달에서 문서 종류를 선택해 읽도록 바꿨다.

이 구조에서는 현재 문서를 고치는 일과 과거 내용을 보관하는 일을 함께 챙겨야 한다. 새 버전을 추가할 때 문서 원문, 시행일, 변경 요약이 서로 맞는지도 확인할 필요가 있다. 버전 번호만 달리 붙인다고 변경 관리가 끝나는 것은 아니다.

과거 버전 열람 기능이 있다는 것과 실제 개정 때 필요한 안내를 모두 수행했다는 것도 구분해야 한다. 화면에 이력을 남기는 기능은 마련했지만, 변경 내용에 따라 어떤 안내나 절차가 필요한지는 개정할 때 별도로 검토해야 한다.

읽기 쉬운 화면과 정확한 설명 사이

중요한 내용을 강조하고 관련 설명을 묶은 것은 내가 읽기 불편했던 부분을 개선하려는 선택이었다. 실제 이용자가 더 쉽게 찾고 이해하는지 사용자 검증을 했다는 기록은 없다. 화면을 구성한 의도와 효과를 확인한 결과를 같은 것으로 쓰지는 않으려 한다.

로그인에서 시작한 작업은 문서를 작성하고 화면에 올리는 데서 끝나지 않았다. 앞으로 기능을 바꾸거나 관련 법령이 개정되면, 이용자에게 설명한 내용과 실제 서비스가 여전히 맞는지 다시 살펴보려 한다. 읽기 쉬운 표현을 유지하면서도 그 설명을 오래된 상태로 두지 않는 일이 남아 있다.