K2코리아 사용성 평가 플랫폼 관리자 화면 개편

두 방식으로 나뉘어 돌던 사용성 평가 플랫폼을 권한별 관리자 화면 하나로 합쳤습니다.

고객사
K2코리아
분야
신발·의류 사용성 평가
기술
Django · MariaDB · React(Vite) · Docker · Nginx

포너즈가 한 일

  1. 기존 플랫폼 구조 분석과 API 문서화
  2. 새 관리자 화면 퍼블리싱
  3. 관리자 기능 API 확장과 역할별·그룹 권한 구현
  4. 제품 비교 리포트 데이터 연결
  5. 보안 점검·서비스 영향도 점검과 운영 서버 배포
  6. 배포 뒤 추가 요청 반영(이미지 분류, 법인·브랜드 관계, 제품 유형별 설문 항목, 설문 가져오기)

고객

아웃도어와 산업안전 브랜드를 운영하는 K2코리아

K2코리아는 아웃도어·골프·스포츠·산업안전 브랜드를 운영하는 패션 기업입니다. K2코리아 신발연구소는 개발 중인 신발의 성능을 평가합니다. 사용성 평가 플랫폼에서는 테스터가 신발·의류·용품 설문에 답하고 사진을 올립니다. 평가 대상은 케이투, 다이나핏, 케이투 세이프티 제품이고, 분석가가 결과를 제품별 리포트로 봅니다.

문제

관리자 화면과 테스터 화면이 서로 다른 방식으로 돌던 플랫폼

평가 대상이 신발에서 의류·용품으로 넓어지면서 K2코리아는 플랫폼 화면을 새로 짜기로 했습니다. 관리자·테스터·분석가가 같은 화면을 쓰는 새 구조를 원했습니다. 역할에 따라 만들고 고치고 지울 수 있는 범위만 달리하는 구조입니다.

관리자 페이지는 Django Admin 기반이었습니다. 서버가 화면을 직접 만들어 보내는 방식입니다. 설문지와 문항 유형을 만들고 고치는 일이 이 화면에서 이뤄졌습니다. 관리자는 설문지 하나를 만들 때 문항 유형과 제품을 여러 화면에서 따로 등록했습니다.

테스터와 분석가 페이지는 API로 데이터를 받아 화면을 그렸습니다. 같은 데이터를 두 방식으로 다루고 있어, 새 디자인 하나로 합치기가 어려웠습니다.

데이터에도 한계가 있었습니다. 피팅감·기능성 같은 설문 항목이 신발 기준으로 고정돼 있었습니다. 통증 부위는 좌표로만 저장돼 부위별 통계를 낼 수 없었습니다. 분석가는 의류나 용품 리포트에서도 신발용 항목을 봐야 했습니다. 제품끼리 비교할 때는 리포트를 하나씩 열어 맞춰 봤습니다.

K2코리아는 운영 중인 플랫폼은 그대로 두고 관리자 화면부터 새로 만들기로 했습니다.

해결

관리자 기능을 API로 열고 그 위에 올린 새 관리자 화면

포너즈는 기존 Django 백엔드에 관리자용 API를 더했습니다. 그 API를 쓰는 React 관리자 화면을 새로 만들었습니다.

  • 기존 구조 분석: 운영 서버의 소스를 읽고 기존 API 11개를 Swagger 문서로 정리했습니다.
  • 관리자 API: 설문지·문항 유형 등을 만들고 고치고 지우는 기능을 API로 열었습니다. 호출은 관리자 권한 계정만 할 수 있습니다.
  • 새 관리자 화면: 대시보드, 리포트, 설문, 제품·브랜드·사이즈·시즌 관리, 사용자·그룹 권한을 한 화면에 모았습니다.
  • 법인별 데이터 범위: K2코리아가 준 관계도대로 법인과 브랜드를 연결했습니다. 공통 법인은 모든 브랜드를, 자사 법인은 자기 브랜드만 봅니다.
  • 제품 유형별 설문 항목: 신발 기준으로 고정돼 있던 항목을 의류·용품에서는 다르게 조회하도록 바꿨습니다.
  • 기존 화면과 나란히 배포: 기존 관리자 페이지는 그대로 두고, 새 화면을 별도 경로에 올렸습니다. 새 화면을 확인하는 동안에도 기존 화면으로 업무를 이어 갈 수 있습니다.
  • 담당자 확인: 대시보드가 비교할 리포트를 추천하면 분석가가 직접 골라 비교합니다.
사용자마다 법인·그룹사·권한을 정하고 계정을 켜고 끈다
테스터가 올린 사진을 인증 이미지와 제품 이미지로 나누고 제품명으로 찾는다

테스터 화면과 같은 API 방식으로 맞춘 관리자 기능

두 방식을 한 디자인에 맞추려면 먼저 같은 방식으로 정렬해야 했습니다. 관리자 기능을 API로 열어 두면 이후 디자인이 바뀌어도 서버를 크게 고치지 않아도 됩니다.

그대로 둔 데이터베이스와 서버 구성

Django·MariaDB·Docker 환경과 데이터 구조를 유지했습니다. 기존 모델과 검증 로직도 그대로 썼습니다. K2코리아와 정한 우선순위는 운영 데이터와 부딪히지 않는 것이었습니다. 디자인과 기존 기능이 부딪히면 기존 기능을 따랐습니다. 서버 용량이 모자랐을 때도 같은 기준을 썼습니다. Docker를 빼면 용량은 줄지만 운영 환경이 바뀝니다. 그래서 배포 방식은 두고 서버 증설을 권했습니다.

수정 대신 미리보기로 바꾼 문항 유형 그룹 탭

새 디자인에는 설문을 등록하면서 문항 유형 그룹을 고치는 탭이 있었습니다. 포너즈는 이 탭에서 그룹의 질문을 미리보기만 하게 바꿨습니다. 그룹을 고치면 그 그룹을 쓰는 설문지 전체가 함께 바뀌기 때문입니다.

결과

새 관리자 화면으로 옮겨 간 설문지 등록

새 관리자 화면은 K2코리아 운영 서버에 기존 화면과 나란히 올라갔습니다. K2코리아는 이 화면에서 설문지를 등록하며 빠진 기능을 요청했습니다. 그 요청에 따라 새 화면에 설문 가져오기와 문항 유형 가져오기가 들어갔습니다. K2코리아는 권고에 따라 서버 용량을 늘렸고, 새 화면은 그 서버에서 돕니다.

설문지·문항 유형 등록
이전Django Admin 폼에 입력(사람) → 서버가 화면 생성(시스템)
이후새 관리자 화면에 입력(사람) → 관리자 API로 저장(시스템)
제품 비교 리포트
이전리포트를 하나씩 열어 항목을 맞춰 봄(사람)
이후비교할 리포트 추천(시스템) → 리포트 선택·비교 진행(사람)
사용자·권한 관리
이전Django Admin에서 계정 권한 지정(사람) → 법인 구분 없이 전체 데이터 조회(시스템)
이후사용자·그룹 권한 지정(사람) → 법인·브랜드 범위로 조회 제한(시스템)
점검 결과 측정 기준
운영 배포 전 영향도 점검 15개 항목 모두 정상 운영 배포 전 서비스 영향도 체크리스트, 포너즈 점검
제품 리포트를 신발·의류·용품으로 나눠 보고, 여러 개를 골라 비교 분석한다
이 사례 공유

비슷한 프로젝트를 준비하고 있다면

무엇을 만들지 아직 정리되지 않아도 괜찮습니다. 지금 상황을 알려 주시면 진행 방식과 범위를 함께 잡습니다.

상담 신청하기