바이브코딩 서비스, 로그인 다음은 권한 점검입니다

로그인 버튼이 동작하고 회원 이름까지 표시되면 계정 기능이 완성된 것처럼 보입니다. 그런데 일반 회원이 관리자 주소를 직접 열거나 다른 사람의 문서 링크에 접근하면 어떻게 될까요? 화면에서 메뉴를 숨겼다는 사실만으로 데이터 접근까지 막혔다고 판단할 수는 없습니다.

로그인은 누구인지 확인하는 과정이고, 권한은 그 사람이 무엇을 할 수 있는지 판단하는 규칙입니다. 바이브코딩으로 만든 서비스를 출시할 때는 두 가지를 구분해 점검해야 합니다. 앞선 글에서 다룬 여러 사용자 조건 중에서도, 이번에는 계정과 데이터의 경계를 구체적으로 살펴보겠습니다.

1. 사용자 종류와 가능한 작업을 먼저 적으세요

일반 회원과 관리자라는 이름만 정하면 실제 개발에서 판단할 조건이 부족할 수 있습니다. 일반 회원은 자신이 만든 문서를 볼 수 있지만 팀에 공유된 문서도 볼 수 있는지, 퇴사한 팀원의 접근은 언제 종료되는지처럼 업무 상황을 정리해야 합니다.

처음에는 사용자 종류, 데이터 종류, 가능한 작업을 표로 적어 보세요. 조회와 생성, 수정과 삭제를 각각 구분하고, 소유자나 팀에 따라 달라지는 조건도 함께 기록하세요. 관리자에게 모든 기능을 열기보다 맡은 업무에 필요한 범위를 정하는 편이 검토하기 좋습니다.

규칙이 없는 경우에는 허용한다고 가정하지 마세요. 공개 페이지와 로그인 사용자만 볼 수 있는 자료를 구분하고, 새로운 기능을 추가할 때도 접근 범위를 명시해야 합니다. 기존 기능과 비슷하다는 이유로 권한 검사를 생략하면 빈틈이 생길 수 있습니다.

2. 메뉴가 아니라 서버의 판단을 확인하세요

관리자 버튼을 숨기는 것은 화면을 정리하는 데 도움이 되지만 접근 제한 자체를 대신하지는 않습니다. 서버는 요청한 사람을 확인하고, 요청 대상 데이터와 작업에 대한 권한을 검사한 뒤 처리해야 합니다. 조회 기능에만 검사를 넣고 수정이나 다운로드에서 빠뜨리지 않았는지도 살펴보세요.

OWASP의 권한 관리 지침은 최소 권한, 기본 거부, 요청마다 권한 확인을 권장합니다. 사용하는 로그인 도구가 있다고 해서 서비스 고유의 문서 소유권이나 팀 공유 규칙까지 자동으로 정해지는 것은 아닙니다.

특히 사용자가 보낸 계정 번호나 역할 값만 믿고 권한을 결정하지 않도록 구현을 검토하세요. 선택한 도구와 구조에 따라 세부 방식은 다르므로, 로그인 기능의 존재와 실제 데이터 접근 규칙을 따로 확인해야 합니다. 파일 주소를 안다는 이유만으로 비공개 첨부 파일을 열 수 있는지도 점검 대상입니다.

3. 허용되는 상황과 거부되는 상황을 함께 시험하세요

직접 소유하거나 점검 권한을 가진 서비스의 시험 환경에서 가상 계정과 테스트 자료를 사용하세요. 일반 계정 두 개와 관리자 계정을 준비하고, 각 계정이 허용된 기능을 정상적으로 사용할 수 있는지부터 확인합니다. 이어서 다른 계정의 비공개 자료에 접근하거나 권한이 없는 작업을 시도했을 때 거부되는지 검증하세요.

예를 들어 A 계정의 테스트 문서는 A에게 보이지만, 공유하지 않은 B 계정에는 보이지 않아야 합니다. B가 내용을 수정하거나 파일을 내려받는 경로에서도 같은 규칙이 적용되는지 확인하세요. 거부 안내가 나왔다는 사실뿐 아니라 실제 저장된 값이 바뀌지 않았는지도 확인해야 합니다.

역할 변경과 팀 탈퇴처럼 접근 조건이 바뀌는 상황도 포함하세요. 로그아웃하거나 접근 권한을 회수한 뒤 이전 상태가 계속 유효한지는 세션과 권한 설계를 함께 살펴봐야 합니다. 실제 고객 자료를 이용하거나 다른 서비스의 주소를 임의로 점검하는 방식은 피하세요.

수정 후에도 같은 경계를 다시 확인하세요

AI에게 수정을 요청할 때는 '보안을 강화해 줘'보다 어떤 계정이 어떤 자료에 어떤 작업을 할 수 있어야 하는지 전달하세요. 기대한 결과와 현재 결과를 기록하면 수정 범위를 판단하기 쉽습니다. 기능을 고친 뒤 기존에 허용됐던 작업과 거부돼야 할 작업을 모두 다시 확인하세요.

출시 전에는 다음 항목을 점검해 보세요.

• 로그인 확인과 작업 권한 확인을 구분했는가
• 계정·소유자·팀별 접근 규칙을 적었는가
• 조회·수정·삭제·다운로드에 규칙이 적용되는가
• 권한이 없는 요청은 실제 처리가 거부되는가
• 역할 변경과 탈퇴 이후 접근을 확인했는가
• 기능 변경 뒤 반복해서 확인할 테스트가 있는가

이 목록만으로 모든 보안 검토가 끝나는 것은 아닙니다. 다만 로그인 화면 뒤에 필요한 접근 규칙을 구체화하는 출발점이 될 수 있습니다. 바이브코딩 서비스의 계정과 데이터 경계가 불분명하다면 Ideal Web에서 현재 이용 흐름과 권한 설계를 함께 점검해 보세요.