법적 페이지 한영 이중 언어 전환
목차
법적 페이지(약관·개인정보·환불) 전체를 한/영 이중 언어로 전환하면서, AI가 초안을 뽑아준 면책 문구를 전부 걷어냈다.
왜 지금 이 작업을 했나
서비스 초기엔 빠르게 런칭하는 게 우선이었다. 약관이나 개인정보처리방침 같은 법적 페이지는 솔직히 말하면 "일단 AI가 뽑아준 걸 붙여 넣고 나중에 다듬자" 식으로 처리했다. 흔한 패턴이고, 초기에 팀 리소스를 제품 핵심 기능에 집중하기 위한 트레이드오프였다.
근데 시간이 지나면서 문제가 세 가지로 좁혀졌다.
- 언어 커버리지 부재: 서비스가 영어권 사용자도 유입되기 시작했는데, 한국어 단일 페이지는 그냥 이탈 요인
- AI 초안 면책 문구: "이 내용은 법적 효력이 없을 수 있습니다" 식의 문구가 약관 페이지에 그대로 노출되고 있었음. 사용자 신뢰도 측면에서 최악이고, 실제로 법적으로도 애매한 문구들이 섞여 있었다
- 컴포넌트 구조 부재: 각 법적 페이지가 완전히 독립된 HTML 덩어리라 수정하려면 세 파일을 각각 건드려야 했음
팀 차원에서 "이 상태로 B2B 고객 미팅에 링크 보내도 되냐"는 질문이 나왔고, 답이 "아니요"라면 지금 해야 한다는 결론이 나왔다.
변경 파일별 역할 분리
| 파일 | 역할 | 이번 변경 핵심 |
|---|---|---|
src/components/legal-shell.tsx |
법적 페이지 공통 레이아웃 | 신규 추출. KO/EN 토글 UI 포함 |
src/lib/i18n.ts |
언어 감지 / 문자열 관리 | legal 네임스페이스 추가 |
src/app/terms/page.tsx |
이용약관 | KO/EN 분기 + AI 문구 제거 |
src/app/privacy/page.tsx |
개인정보처리방침 | KO/EN 분기 + AI 문구 제거 |
src/app/refund/page.tsx |
환불 정책 | KO/EN 분기 + AI 문구 제거 |
src/app/home-client.tsx |
홈 클라이언트 컴포넌트 | 법적 페이지 링크 노출 방식 조정 |
legal-shell.tsx를 새로 뽑아낸 게 이번 작업의 핵심 구조 결정이었다. 세 페이지가 결국 "헤더 + 본문 + 언어 토글" 구조를 공유하는데, 이걸 각자 들고 있으면 나중에 디자인 변경이나 언어 추가할 때 또 세 파일을 동시에 건드려야 한다. 컴포넌트 하나로 묶어두면 그 비용이 사라진다.
// legal-shell.tsx 구조 예시 패턴
type LegalShellProps = {
titleKo: string;
titleEn: string;
contentKo: React.ReactNode;
contentEn: React.ReactNode;
};
export function LegalShell({ titleKo, titleEn, contentKo, contentEn }: LegalShellProps) {
const { lang } = useI18n(); // i18n.ts에서 감지
return (
<main>
<h1>{lang === 'ko' ? titleKo : titleEn}</h1>
<LangToggle />
{lang === 'ko' ? contentKo : contentEn}
</main>
);
}
각 페이지는 이제 LegalShell에 KO/EN 콘텐츠만 주입하면 끝. 구조 결정을 한 곳에서 관리한다.
AI 초안 면책 문구를 걷어낸 이유
이 부분은 팀 내에서도 "그냥 두면 안 되나?"는 의견이 잠깐 있었다. 면책 문구 자체가 뭔가를 보호해준다는 착각이 있어서다. 근데 현실은 반대다.
법적 페이지에서 "이 내용의 정확성을 보장하지 않습니다"라는 문구가 보이면 사용자는 두 가지 중 하나를 느낀다. 서비스가 아직 미완성이거나, 아니면 책임을 회피하려는 거라고. 둘 다 신뢰 하락이다. 게다가 실제 법무 검토를 거친 내용이라면 그 문구 자체가 불필요한 노이즈고, 검토를 안 거쳤다면 그건 다른 문제다.
AI 초안을 쓰는 것 자체는 문제가 아니다. 빠른 초안 생성 도구로는 충분히 유효하다. 다만 그 출력물이 최종 사용자에게 "AI가 썼습니다"라는 흔적을 남긴 채 노출되는 건 별개 문제다. 팀에서 코드 리뷰할 때 AI가 제안한 코드를 그냥 머지하지 않는 것과 같은 논리다.
i18n 구조에서 legal 네임스페이스를 분리한 이유
i18n.ts에 legal 네임스페이스를 따로 뽑은 건 번들 사이즈 관점도 있고, 관리 편의도 있다. 법적 문서는 일반 UI 문자열과 달리 분량이 크고, 수정 주기가 다르고, 담당자가 달라질 수 있다. 한 파일에 UI 문자열이랑 법적 본문이 뒤섞이면 두 관심사가 충돌하기 시작한다.
나중에 법무팀이나 외부 번역가가 검수해야 하는 상황이 와도, 네임스페이스가 분리되어 있으면 그 파일만 넘기면 된다. 이런 구조 결정이 실제로 빛을 발하는 건 항상 "나중에"다.
작은 feat처럼 보이지만, 법적 페이지는 서비스 신뢰도의 바닥을 깔아주는 영역이다. 빠르게 치운 부채를 제때 갚은 것에 가깝다. 다음 단계는 실제 법무 검토 반영.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.