관리자 페이지 개발시 고려해볼 사안들

Photo by Pietro De Grandi / Unsplash

이 글은 어드민 개발을 하며 정리한 체크리스트의 메이커로그 버전입니다.
전체 정리 글(원문)은 여기 있습니다 → https://blog.selectfromuser.com/how-to-make-great-admin/

서비스를 만들다 보면 언젠가 반드시 어드민을 만들게 됩니다.
처음에는 “운영툴 하나면 되겠지”로 시작하지만,
막상 들어가 보면 생각보다 많은 결정이 필요합니다.

• 어디까지 만들 것인가?

• 누가 관리할 것인가?

• 급하게 만들고 나중에 고칠 것인가?

• 인수인계는?

• 보안은?

최근 여러 팀과 이야기하며 정리해본
어드민 개발 시 고려할 7가지 포인트를 공유합니다.

1. 목표 설정 – 이 어드민은 무엇을 해결하려는가?

어드민은 기능 모음이 아니라,
문제 해결 도구여야 합니다.

• 반복 업무 자동화?

• 데이터 통제?

• 내부 운영 효율화?

단기 이슈 해결용인지,
장기 운영 인프라인지에 따라 설계 방향이 완전히 달라집니다.

2. 구현 범위 – 전부 직접 만들어야 할까?

CRUD, 필터, 권한, 로그, 배포…
어드민에는 기본적으로 필요한 기능들이 많습니다.

이미 존재하는 프레임워크나 로우코드 도구를 활용하면
핵심 비즈니스에 집중할 수 있습니다.

중요한 건 “우리 팀에 필요한 수준의 유연성을 제공하는가?”입니다.

3. 조직 구성 – 누가 책임질 것인가?

보통 세 가지 선택지가 있습니다.

1. 서비스 개발팀이 겸임

2. 어드민 전담팀 운영

3. 외부에 위탁

겸임은 빠르지만 우선순위에서 밀릴 수 있고,
전담팀은 안정적이지만 비용이 증가합니다.
외주는 속도는 빠르지만 인수인계 리스크가 있습니다.

팀 상황에 따라 조합형으로 가는 경우도 많습니다.

4. 협업 방식 – 최소 인력 구조를 가정하라

현실에서는

• 서버 개발자 + 요구사항 문서

• 화면 기획 없이 기능 우선

• MVP 후 점진 개선

같은 방식으로 진행되는 경우가 많습니다.

어드민은 종종 “빠르게 만들고 계속 고치는 시스템”이 됩니다.
그래서 협업 구조도 유연해야 합니다.

5. 유지보수 – 어드민은 계속 바뀐다

운영 정책은 바뀌고,
데이터 구조는 진화하고,
기능은 추가됩니다.

초기 속도를 우선할지,
확장성을 우선할지
결정이 필요합니다.

6. 인수인계 – 문서화 없이는 위험하다

외주나 단기 인력이 만든 어드민은
담당자가 바뀌는 순간 리스크가 됩니다.

구조가 명확하고,
설정이 이해 가능하고,
문서가 존재해야 합니다.

7. 보안 – 결국 권한 설계의 문제

어드민은 고객 데이터와 내부 데이터를 다룹니다.

기본적으로 고려해야 할 요소:

• RBAC(권한 그룹 기반 접근 제어)

• 데이터 레벨 제어

• 감사 로그

• MFA / SSO

• 세션 관리

초기에 보안을 미루면
나중에 구조 전체를 바꿔야 할 수도 있습니다.

직접 개발 vs 로우코드, 무엇이 맞을까?

직접 개발은 자유도가 높지만 관리 비용이 큽니다.
로우코드는 구조화와 속도에서 강점이 있습니다.

결국 질문은 이것 같습니다:

어드민은 우리 팀의 핵심 제품인가,
아니면 운영을 지원하는 인프라인가?

우리는 계속 이런 질문을 합니다.

“어드민을 더 쉽게 만드는 게 아니라,
조직이 어드민을 관리하기 쉽게 만드는 방법은 무엇인가?”

완벽한 답은 없지만,
어드민은 결국 조직의 운영 구조를 담는 시스템이라고 생각합니다.

어드민을 만들고 계신 분들,
지금 구조에 만족하시나요?
혹은 다시 만든다면 무엇부터 바꾸고 싶으신가요?

더 자세한 정리와 비교표, 구조 설명은 원문에 적어두었습니다.
→ https://blog.selectfromuser.com/how-to-make-great-admin/