Coreline Auth

권한을 보여주려고 만든 게시판이 코어에 들어가면 안 됐습니다

Coreline Auth는 로그인과 세션, 권한, 관리자 작업을 재사용할 수 있는 Python 모듈로 만들었습니다. 기능을 설명하려면 사용자가 로그인한 뒤 무엇을 할 수 있는지 보여주는 데모가 필요합니다. 저는 게시판을 이용해 권한별로 같은 요청의 결과가 어떻게 달라지는지 확인하도록 구성했습니다.

6월 7일에는 따로 남아 있던 게시판 테스트 데모를 인증 프로젝트 안으로 옮겼습니다. 이때 데모가 잘 실행되는 것과 인증 모듈이 독립성을 유지하는 것을 함께 목표로 잡았습니다. 게시판을 넣었다는 이유로 인증 패키지까지 게시글과 댓글의 구조를 알아야 하는 상태는 피하고 싶었습니다.

게시판은 데모 전용 영역에 두고 인증 코어와 배포 패키지에서는 분리했습니다. 권한을 확인할 데모는 같은 프로젝트에서 실행하되, 인증 모듈을 쓰는 앱에 게시판 코드가 따라가지 않게 하려는 선택이었습니다.

인증 역할과 게시판 역할을 섞지 않았습니다

인증 코어의 역할과 게시판에서 쓰는 author, moderator는 같은 범위의 말이 아닙니다. 게시판 작성자와 중재자를 보여주기 위해 인증 코어의 역할 목록에 두 역할을 추가하지 않았습니다. 데모가 자체 역할과 권한 매핑을 소유하도록 했습니다.

게시판 권한은 읽기, 글 작성, 자신의 글 수정·삭제, 다른 사람의 글 수정·삭제처럼 나눕니다. author는 자신의 글을 다루고 moderator는 다른 사람의 글을 관리하는 조건을 갖습니다. viewer는 읽을 수 있지만 글을 만들 수 없습니다. 로그인했다는 조건 하나로 이 차이를 합치지 않았습니다.

이 선택은 다른 앱에도 영향을 줍니다. 인증 코어를 가져가는 앱이 게시판을 만들지 않더라도 같은 로그인과 세션 기능을 사용할 수 있어야 합니다. 도메인의 권한 어휘를 데모에서 다루면 다른 앱은 자기 업무에 맞는 어휘를 별도로 구성할 수 있습니다.

자신의 글과 모든 글의 범위를 별도로 검사했습니다

권한 비교에서는 작업 종류와 소유 범위를 나눴습니다. 자신의 글을 수정할 수 있는 권한이 다른 사람의 글까지 수정하도록 이어지면 안 됩니다. 반대로 모든 글을 관리하는 권한은 자신의 글 작업도 포함할 수 있도록 했습니다.

검수에는 작성자 자신의 글 수정, 다른 작성자의 수정 거절, 중재자의 수정, 읽기 전용 사용자의 글 작성 거절을 넣었습니다. 댓글에도 같은 종류의 소유권 조건을 따로 확인합니다. 화면에서 수정 버튼을 숨기는 일과 서버가 실제 요청을 거절하는 일을 연결해서 봐야 합니다.

비활성 계정은 높은 역할을 갖고 있어도 거절하는 조건도 뒀습니다. 권한 목록에 필요한 문자열이 있는지만 보면 계정 상태를 놓칠 수 있습니다. 계정 활성 상태, 역할과 명시 권한, 대상의 소유자를 각각 확인한 뒤 작업을 허용하는 흐름으로 정리했습니다.

데모 실행과 인증 데모 실행을 분리했습니다

게시판은 독립적인 실행 진입점으로 열도록 했습니다. 기본 인증 데모는 계정과 세션 중심의 의미를 유지하고, 게시판 검수는 별도 명령으로 시작합니다. 인증 화면만 살펴보려는 작업에 게시판의 데이터와 조작이 자동으로 따라오지 않게 한 구성입니다.

권한별 계정을 선택하는 UI와 로그인 입력 채우기 기능도 데모 안에 유지했습니다. 역할을 바꿔 가며 같은 화면을 확인할 수 있어야 소유권과 중재 조건의 차이가 드러납니다. 이 계정들은 검수용 구성으로 다루고 운영 계정과 같은 의미로 표시하지 않았습니다.

파일 위치만 옮기고 끝내지 않은 이유는 실행 경로도 의존성을 만들기 때문입니다. 기존의 이웃 게시판 패키지를 가져와야만 새 데모가 동작한다면 독립적으로 옮겼다고 보기 어렵습니다. 데모 자체가 해당 프로젝트 안의 코드만으로 권한 검수 흐름을 제공하도록 맞췄습니다.

import와 배포 파일에서도 경계를 확인했습니다

코어가 데모를 가져오지 않는지 검사하고, 데모가 이전 게시판 패키지를 가져오지 않는지도 따로 검사했습니다. 두 방향의 의존성은 서로 다른 문제입니다. 코어의 독립성과 데모의 독립 실행을 각각 확인할 수 있어야 합니다.

Python 코드를 분석하는 import 검사로 금지된 연결을 찾고, 빌드한 wheel에 게시판 데모가 들어가지 않는지도 확인 조건으로 남겼습니다. 폴더가 분리되어 보여도 배포 설정에 포함되면 사용하는 앱에 예시 도메인이 따라갈 수 있습니다. 실행 구조와 배포 구조를 모두 살핀 선택입니다.

이전 이웃 폴더를 정리할 때는 백업한 뒤 범위를 두 폴더로 제한했습니다. 현재 검수의 기준은 프로젝트 안의 게시판 데모로 모으고, 과거 작업 기록은 이력으로 남겼습니다. 중복된 실행 장소를 없애는 작업에서도 유지할 예시와 배포할 코어의 경계가 먼저 분명해야 했습니다.

재사용은 데모를 없애는 일이 아니라 책임을 분리하는 일입니다

저는 이 작업에서 게시판을 제거해 인증 모듈을 단순하게 만드는 방식 대신, 게시판을 검수 가능한 예시로 남기면서 코어의 책임에서 분리했습니다. 로그인 성공 이후의 권한 차이를 실제 조작으로 보여주는 데모는 여전히 필요했기 때문입니다.

같은 모듈을 만들 때는 예시 앱이 어떤 정책을 추가했는지, 그 정책이 코어의 역할로 들어갔는지, 배포 파일에 예시가 섞였는지 확인할 수 있습니다. 특히 ‘관리자’처럼 같은 단어라도 앱 전체의 관리자와 특정 도메인의 중재자는 다른 역할일 수 있습니다.

Coreline Auth에서 남긴 개발 경험은 재사용 가능한 코어와 풍부한 검수 화면을 동시에 유지한 선택입니다. 로그인 화면만 분리했다고 인증 모듈의 경계가 완성되지는 않습니다. 역할 어휘, import, 실행 진입점, 배포 파일까지 같은 책임을 유지해야 다른 앱에 붙일 때도 의미가 이어집니다.