sakyowon 위키

AI와 함께 사이트 회원등급을 설계하고 등급별 데모계정으로 점검하기

11 min read

AI와 함께 사이트 회원등급을 설계하고 등급별 데모계정으로 점검하기

요약

햇빛소득마을 통합 운영 플랫폼 「햇소자」에는 “관리자/회원” 두 권한만 있었다. 연합회가 참여 마을 전체를 봐야 하고, 가입 승인 전 사람은 공개 화면만 봐야 하는데 그 구분이 없었다. 한 세션 안에서 ① 지금 권한이 실제로 어떻게 돼 있는지 코드로 확인하고 ② 등급을 관리자·연합회·회원협동조합·손님 넷으로 나누되 메뉴와 접근권한을 표 한 곳에서만 정의하게 만들고 ③ 등급마다 데모 계정을 붙여 버튼 하나로 그 등급의 화면을 점검할 수 있게 한 뒤 ④ PR→머지→배포→실사이트 확인까지 끝냈다. 코드 한 파일 +340/−123줄.

왜 이 기술인가

마을 사업 사이트는 대개 “관리자냐 아니냐”로 시작한다. 그런데 사업이 크면 중간 조직(연합회·본부·사무국)이 생기고, 아직 승인 안 된 사람이 생긴다. 이때 흔한 실패는 두 가지다.

  • 화면마다 if(관리자) 검사를 흩뿌려 놓아, 나중에 메뉴 하나 옮기려면 대여섯 군데를 뒤진다.
  • 새 등급을 만들었는데 그 등급으로 로그인해 볼 방법이 없어 배포하고 나서야 빠진 메뉴를 발견한다.

해법은 단순하다. 등급별 메뉴를 하나의 표로 적고, 상단 메뉴·사이드바·접근검사가 전부 그 표를 읽게 한다. 그리고 등급마다 데모 계정을 두어 버튼으로 갈아타며 점검한다.

단계별 따라하기

1. 먼저 “지금 어떻게 돼 있나”를 코드로 답하게 한다

“회원등급이 어떻게 되어 있지?”라고 물으면 AI는 소스를 뒤져 답한다. 중요한 것은 등급이라고 부르는 것이 실제로는 여러 축일 수 있다는 점이다. 햇소자는 세 축이 섞여 있었다.

축값성격
계정 권한admin / member화면 접근을 가르는 진짜 축
계정 상태승인 / 승인대기 / 정지등급이 아니라 승인 단계
조합원 직위이사장 / 이사 / 감사 / 조합원명부 데이터. 권한과 무관

이걸 표로 받아 두면 “무엇을 등급으로 삼을지”를 사람이 결정할 수 있다. 이번엔 계정 권한을 넷으로 늘리고, 상태(승인 전)는 “손님”으로 흡수했으며, 조합원 직위는 그대로 뒀다.

2. 등급과 메뉴를 표 하나로 적는다

AI에게 준 요구는 “권한을 관리자·연합회·회원협동조합·손님으로 나누고, 상단에 등급별 메뉴 버튼을 달고, 기존 기능을 등급에 맞게 재배치하라”였다. 결과물의 뼈대는 이 표다(실제 코드는 자바스크립트 배열이지만 구조는 같다).

등급메뉴 묶음첫 화면
관리자플랫폼 관리 / 소통·콘텐츠 / 연합회 업무 + 등급별 화면 미리보기관리자 대시보드
연합회연합회(현황판·조합마을 현황·공모심사) / 공동업무(문서·검토·법령·수익·일정) / 소통연합회 현황판
회원협동조합종전 회원 메뉴 그대로(내 조합 / 설립·건설 / 운영관리 / 확장)우리 마을 대시보드
손님공개 메뉴만홈

핵심 규칙: 상단 메뉴바·사이드바·접근검사가 모두 이 표를 읽는다. 메뉴를 옮기려면 표만 고친다. “표 한 곳에서만 정의하라”는 문장을 요구사항에 넣어야 AI가 흩뿌리지 않는다.

3. 기존 값·서버 값과의 호환을 미리 적는다

새 등급 이름(coop)을 만들면 예전에 저장된 member 값이 남아 있는 브라우저가 있고, 서버는 staff 같은 값을 준다. “읽을 때 정규화” 함수를 하나 두고 모든 입구(로그인·저장값 읽기·회원 목록 표시)가 그것을 거치게 했다. 승인 전(pending)은 손님으로 떨어진다.

여기서 서버가 모르는 등급이 드러난다. 연합회는 서버 계정에 값이 없어서 실계정으로는 아직 못 쓴다. 이런 건 AI가 “본부 협의 필요”로 표시해 주므로, 그 자리에서 편지 초안이든 후속 과제든 남기면 된다.

4. 등급마다 데모 계정을 붙인다

“등급 버튼을 누르면 해당 등급의 기능을 테스트할 수 있게 데모 계정을 하나씩 만들어 바로 로그인되게 해달라”고 했다. 결과:

  • 로그인 창에 등급 버튼 4개 — 누르면 그 등급으로 들어간다.
  • 로그인 뒤 상단 노란 띠에 “등급 바꿔 보기” 버튼 4개 — 로그아웃 없이 즉시 전환.
  • 관리자 사이드바에 “등급별 화면 미리보기” — 관리자 계정을 잃지 않고 다른 등급 화면을 보고 돌아온다.

이 세 개가 있으면 배포 전 점검이 “네 등급 × 메뉴 전부”로 기계적으로 된다. AI는 브라우저에서 이 버튼을 스스로 눌러 등급별 첫 화면·메뉴·차단 리다이렉트를 표로 보고했다.

5. 배포하고 “정말 반영됐는지” 확인한다

PR을 만들어 머지하면 GitHub Pages 빌드는 자동으로 돈다. 그런데 빌드가 성공했다고 사이트가 바뀐 것은 아니다. 이 사이트의 실제 주소는 GitHub이 아니라 자체 서버가 저장소를 내려받아 내주는 구조라, 관리자가 서버에서 배포 스크립트를 한 번 돌려야 바뀐다. 처음엔 머지 3분 뒤 바뀐 것을 보고 “자동 전파가 느린가 보다”라고 오해했는데, 알고 보니 그 시각에 다른 일로 스크립트가 돌아간 것이었다. 두 번째 수정은 10분을 기다려도 그대로였다. 확인은 응답 헤더의 Server가 무엇인지 보고(자체 서버면 기다려도 소용없다), “새 코드에만 있는 문자열”이 실제 주소에서 나오는지 확인한 뒤, 브라우저로 4등급을 한 번 더 눌러 본다. “배포 완료”는 이 시점에만 쓴다.

교훈

  1. “등급이 어떻게 돼 있냐”부터 코드로 답받는다. 등급이라 불리던 것이 실제로는 권한·상태·직위 세 축이었다. 이걸 모르고 설계하면 상태를 등급으로 오해해 승인 로직을 망가뜨린다.
  2. 메뉴·권한은 표 한 곳. 요구사항에 이 문장을 명시하면 이후 재배치가 표 편집으로 끝난다.
  3. 새 등급에는 데모 계정을 같이 만든다. 로그인해 볼 방법이 없는 등급은 점검이 안 된 등급이다.
  4. 호환 함수를 입구에 둔다. 옛 저장값·서버 값·새 값을 한 함수가 받아 넷 중 하나로 바꾼다. 서버가 모르는 등급은 여기서 드러나니 그 자리에서 후속 과제로 적는다.
  5. 빌드 성공 ≠ 라이브. 누가 실제 주소를 내주는지(Server 헤더)부터 보고, 고유 문자열로 확인한다. 우연히 바뀐 것을 “자동 반영”으로 믿으면 다음번에 헛기다린다. 이전에 열어 둔 브라우저는 강력 새로고침.

참고

그래프 뷰