공통 관리(어드민) 메뉴를 초기 설계에 안 넣은 것

기능을 하나 완성할 때마다 같은 질문이 뒤따라왔습니다. “그런데 이건 누가 관리하지?” 분류 코드, 사용자, 역할, 접근 로그 — 관리해야 할 것은 계속 늘어났는데, 그걸 담을 공통 관리 화면이 처음 설계에 없었습니다. 그래서 어드민은 늘 업무 기능보다 한 발씩 늦게 따라붙는 사후 보강이 됐습니다.

어드민이란 무엇이고, 왜 자꾸 잊히나

용어: 어드민(공통 관리)

시스템을 운영하기 위한 화면들의 묶음입니다. 사용자가 매일 쓰는 업무 화면이 아니라, 관리자가 시스템을 굴리기 위해 쓰는 화면입니다. 분류 코드 추가·수정(코드 마스터), 사용자·역할 관리, 누가 언제 접근했는지 보는 접근 로그가 대표적입니다.

용어: 코드 마스터

공통코드를 운영자가 직접 추가·수정하는 어드민 화면입니다. 분류값을 데이터로 다루기로 했다면(공통코드), 그 데이터를 손볼 창구가 반드시 필요합니다. 코드 마스터가 바로 그 창구입니다.

어드민이 자꾸 잊히는 이유는 단순합니다. 사용자에게 직접 보이지 않기 때문입니다. 직원 등록 화면, 결재 화면, 근태 화면은 “이걸 만들면 누가 쓴다”가 명확합니다. 반면 코드 마스터나 접근 로그는 “평소엔 아무도 안 들어가는” 화면입니다. 그래서 만들 목록을 짤 때 자연스럽게 뒤로 밀립니다. 하지만 “평소엔 안 들어간다”와 “필요 없다”는 전혀 다른 말입니다. 평소엔 안 들어가지만, 막상 필요해지는 순간엔 그게 없으면 시스템을 굴릴 수 없는 화면들입니다.

화면 종류	데모에서	실제 운영에서
업무 화면(결재·근태)	박수받음 — 눈에 보임	매일 쓰임
코드 마스터	안 보임 → 우선순위 밀림	새 분류값마다 가장 먼저 필요
사용자·역할 관리	안 보임 → 우선순위 밀림	입·퇴사·권한 변경마다 필요
접근·감사 로그	안 보임 → 우선순위 밀림	문제 추적의 유일한 근거

”이건 누가 관리하지?”가 매번 늦게 왔다

업무 기능부터 만들었습니다. 직원 등록, 결재, 근태 — 사용자에게 보이는 화면이 먼저였습니다. 그런데 기능을 하나 완성할 때마다 뒤에서 같은 질문이 떠올랐습니다.

• 이 분류 코드는 누가, 어디서 추가하지?
• 이 사용자 계정과 역할은 누가 손보지? 코드를 고쳐 배포해야 하나?
• 누가 언제 무엇에 접근했는지는 어디서 보지?

그때마다 부랴부랴 관리 화면을 덧붙였습니다. 코드 마스터 관리, 사용자·역할 관리, 접근 로그 — 이 운영용 화면들이 업무 기능보다 한 발씩 늦게 따라붙었습니다. 실제로 공통코드 관리·접근 로그 메뉴를 어드민에 추가한 작업은 2026년 5월 4일에 있었는데, 그 같은 날 어드민 코드 마스터·접근 로그 경로가 서로 중복·충돌해 정리하는 수정이 또 필요했습니다. 급하게 끼워 넣다 보니, 끼워 넣은 자리에서 곧바로 충돌이 났던 것입니다.

함정 — 운영 화면은 데모에선 안 보인다

어드민·설정·로그 같은 운영 화면은 시연에서 빛나지 않습니다. 그래서 우선순위에서 자꾸 밀립니다. 하지만 시스템을 실제로 굴리는 순간 가장 먼저 필요해지는 게 바로 이 화면들입니다. “보이지 않아서 미뤘다가, 운영 직전에 급하게 만든다”가 전형적인 패턴이고, 급하게 만든 것은 급하게 만든 티가 납니다 — 일관된 틀 없이 제각각 자라고, 라우팅이 충돌하고, 인증 경로가 어긋납니다.

어드민이 뒤늦으면 생기는 비용 — 의존성 도미노

어드민을 따로따로 덧붙이면 두 가지 비용이 듭니다. 첫째는 일관성 비용입니다. 관리 화면들이 공통 틀 없이 각자 자라면, 라우팅 구조에 중복·충돌이 생기고(앞서 본 5월 4일 사례처럼), 핵심 관리 화면을 인증·경로 문제로 몇 차례 손봐야 합니다. 처음부터 “어드민 영역”이라는 한 구획을 잡아 뒀다면, 새 관리 화면은 그저 그 구획에 한 장 추가하는 일이었을 것입니다.

둘째는 더 무거운 의존성 비용입니다. 어드민은 혼자 서지 못합니다. 다른 토대 위에 섭니다.

의존성 사슬(개념도). [공통코드](/lessons/common-code/)와 [권한 체계](/lessons/permissions/)가 어드민을 떠받치고, 어드민이 실제 운영을 떠받칩니다. 맨 아래 토대가 늦으면 그 위가 전부 도미노처럼 뒤로 밀립니다.

이 사슬이 핵심입니다. 어드민의 코드 마스터 화면은 공통코드 구조가 있어야 의미가 있고, 사용자·역할 관리 화면은 권한 체계가 있어야 동작합니다. 그런데 이 글의 형제 글들에서 보듯, 공통코드도 권한도 처음에 안 깔았습니다. 그러니 어드민이 늦는 건 필연이었습니다. 토대가 늦으니 어드민이 늦고, 어드민이 늦으니 그 위의 운영이 늦습니다. 시작점의 누락 하나가 세 칸을 뒤로 민 셈입니다.

어드민이 늦으면	구체적 증상
관리 화면이 제각각 자람	공통 틀 없는 라우팅 → 경로 중복·충돌, 인증 경로 어긋남
코드 마스터가 늦음	분류값을 운영자가 못 넣음 → 새 값마다 개발자 호출
사용자·역할 관리가 늦음	권한 배정을 코드/시드로만 → 런타임 운영 불가
접근 로그가 늦음	”누가 언제 했나”를 사후에 추적할 근거가 없음

지금이라면 — 어드민을 1번 모듈로

되돌아보면, 첫 화면 중 하나가 어드민이었어야 했습니다. 화려한 업무 기능을 만들기 전에, 다음 셋을 한 구획으로 먼저 세웁니다.

1. 코드 마스터 — 분류값을 데이터로 추가·수정하는 화면. 공통코드의 운영 창구. (이게 있으면 새 상태값마다 개발자를 부를 필요가 없습니다.)
2. 사용자·역할 관리 — 계정과 권한을 런타임에 다루는 화면. 권한 체계의 운영 창구.
3. 접근·감사 로그 — 누가 무엇을 언제 했는지 보는 화면. 운영의 눈.

“어드민 구획”을 먼저 잡으면 생기는 일

처음에 (admin) 같은 어드민 영역을 하나의 구획으로 못 박아 두면, 그 다음부터 새 관리 화면은 “거기에 한 장 더”가 됩니다. 라우팅도 인증도 그 구획의 규칙을 자동으로 물려받으니, 5월 4일에 겪은 경로 충돌 같은 사고가 구조적으로 줄어듭니다. 토대를 먼저 깔면, 그 위의 모듈은 “관리는 어디서 하지?”를 다시 묻지 않습니다.

절제가 도미노를 막는다

어드민을 먼저 짓는 일은 일종의 절제입니다. 보이는 것(화려한 업무 화면)을 잠시 미루고, 보이지 않는 것(운영 토대)을 먼저 짓는 결정이기 때문입니다. 데모에서 박수받는 화면이 아니라, 시스템을 실제로 굴릴 때 가장 먼저 손이 가는 화면을 먼저 짓는 것 — 그 절제가 나중의 도미노를 막습니다.

이건 이 회고 시리즈 전체를 관통하는 패턴이기도 합니다. 디자인 토큰도, 공통코드도, 권한도, 어드민도 — 전부 “보이지 않아서 미뤘다가 비싸게 갚은” 토대들입니다. 공통점은 하나입니다. 처음 30분이면 구획을 잡을 일을, 나중엔 며칠짜리 보강 공사로 치렀습니다.

교훈

어드민(공통 관리)은 마지막에 붙이는 부록이 아니라 첫 번째로 세우는 토대입니다. 업무 화면을 그리기 전에 코드 마스터·사용자/역할·로그를 담을 어드민 구획을 먼저 잡으세요. 운영 화면은 데모에선 안 보이지만, 시스템을 굴리는 순간 가장 먼저 손이 갑니다. 그리고 어드민은 공통코드와 권한 위에 서므로, 그 토대들이 늦으면 어드민도 도미노로 밀립니다. 보이지 않는 것을 먼저 짓는 절제가 나중의 도미노를 막습니다.

---

이 글은 SL.AIMS를 만들며 겪은 현장 회고 중 하나입니다. 전체 그림은 〈사례연구: SL.AIMS〉에, 이어지는 이야기는 〈메뉴/기능 권한 설계를 초기에 안 한 것〉에 있습니다.