260622 메딕스 내부 디자인 리뷰
2026년 6월 23일 공유
거래처 관리·등록 프로세스 정리 회의
개요
콘텐츠 유형: 회의
- 거래처 관리 기능 전반을 검토하며, 특히 CSO-도매업체 관계 표현, 약국/병의원 등록 플로우, 필수값 및 조회 정책, 문서화 방식(PRD), 일정/WBS 재정비를 논의했다.
- 주요 방향은 다음과 같다.
- CSO와 도매업체 관계는 N:N 구조로 관리
- 도매업체 화면에서도 CSO 등록/수정 가능
- 약국 등록은 조회 기반 + 수기 입력 시나리오를 분리해 UX 재설계
- 사업자 중복/개업 확인은 국세청 기준으로 통합 처리
- 기획 기준 문서(PRD)와 메뉴 구조를 먼저 확정한 뒤 디자인/개발 진행
- 전체 일정 및 WBS 재조정 필요
참여자 및 역할
기획/PM
- 디자인
프론트엔드 개발
- 기타 프로젝트 참여자
고객사/현업 대응 담당
정확한 이름과 역할은 명확히 식별되지 않았으나, 회의는 기획·디자인·개발이 함께 참여한 실무 조율 성격이었다.
결정 사항
1) CSO-도매업체 관계 및 화면 표시
CSO와 도매업체는 N:N 관계로 본다.
- 한 사람이 여러 업체를 운영할 수 있음
- 대표자가 같아도 사업적으로는 서로 다른 업체일 수 있음
- 도매업체 상세 화면에는 연결된 CSO도 함께 표시되어야 한다.
- 파트너 상세에서 새 CSO를 추가하면, 관련 상세 화면에도 즉시 반영되어야 한다.
- 도매업체가 폐업하더라도 연결된 CSO가 자동 폐업되는 것은 아님.
도매업체 관리 화면에서도 CSO 등록/수정 가능하게 한다.
- 기존의 리스트형 연결 구조를 유지하고, 과거 화면(기존 운영 화면)의 리스트 방식을 참고해 반영한다.
- 용어는 **‘연결업체’ 대신 ‘연결 도매업체’**로 명확히 표기한다.
2) 거래처/CSO 공통 데이터 정책
- 사업자 기준 식별은 사업자번호 기준으로 본다.
- 공통 관리 대상 필드는 정리 필요하나, 논의상 핵심은 다음과 같았다.
- 정식명칭
- 대표자명
- 연락처
- 사업자 주소
- 기타 공통 식별 정보
대표자명은 공통 정책으로 맞추는 방향으로 정리했다.
- CSO/도매업체/구매업체 간 필수 여부 차이가 있어 정리 필요
- 구매업체에서도 대표자명은 필수값으로 보는 의견이 우세함
- 사업자번호는 기준값이므로 임의로 분리하거나 완화하지 않는다.
3) 연결/동기화 UI 정책
- 연결된 도매업체 목록은 앞에서 이미 연결된 업체만 노출한다.
- 동기화 대상 업체 수는 보통 1~2개 수준으로 많지 않다.
- 검색 기능은 꼭 필요하지 않을 가능성이 있으나, 화면 구조에 따라 재검토한다.
4) 약국/병의원 등록 정책
- 약국 등록 시 심평원 조회 기반 등록과 수기 입력을 모두 고려해야 한다.
- 다만 현재 구조는 사용자 입장에서 헷갈리므로,
- 조회 시나리오
- 수기 입력 시나리오
를 명확히 분리하는 방향이 적절하다는 의견이 제시되었다.
- 등록 화면은 다음을 분리해서 설계하는 방향으로 정리되었다.
- 심평원/외부 정보 조회
- 사업자 정보 검증
- 나머지 필드 직접 수정/입력
대표자명은 심평원/국세청에서 자동 제공되지 않는 것으로 보고 수기 입력 처리한다.
5) 사업자 중복 확인 / 개업 확인
심평원에서는 개업 여부 확인이 어렵다고 정리되었다.
- 사업자 중복 확인과 개업 확인은 국세청 기준으로 처리한다.
- 버튼을 두 개로 나누기보다 한 번에 처리하는 방식으로 가는 방향이 적절하다고 봤다.
6) 가등록 정책
가등록과 정식 등록을 구분한다.
- 가등록 시 필수값 후보:
- 정식명칭
- 주소
- 사업자번호
- 등록 시점에 위 필드에 대한 유효성 검사가 필요하다.
- 가등록은 조회 없이도 가능하도록 보는 의견이 있었으나,
- 정식 등록은 조회/검증 절차 필수
- 어떤 필드가 가등록 기준인지 문서화 필요
지역구분 필수 여부는 개발/정책 관점에서 추가 협의가 필요하다.
7) 은행명 입력 방식
은행명은 드롭다운 방식으로 구현한다.
- 은행 목록은
- 시중은행
- 지방은행
- 특수은행 등을 기준으로 리스트업 후 고객사에 확인 요청한다.
신협, 저축은행 포함 여부는 리스트 검토 후 반영
- 예금주/명의 항목은 우선 추가하지 않음
8) 종병/지역구분 관련
종병(종합병원) 구분은 병원 쪽에서 계속 사용할 가능성이 있어 유지하는 방향이다.
- 다만 약국 등 다른 거래처 유형에서의 사용 여부는 추가 확인이 필요하다.
- 지역구분 값은 화면 유형에 따라 프론트에서 노출 제어하는 방식도 가능하다고 봤다.
9) 요양기관번호 처리
- 요양기관번호는 외부에서 암호화된 형태로 제공되는 경우가 있어 자동 활용이 제한적이다.
- 따라서 현재로서는 수기 입력 또는 고객사 확인 후 별도 처리가 필요하다.
- 이 부분은 고객사에 별도로 확인 요청하기로 했다.
10) 기획/문서화 방식
- 현재 문제의 핵심은 기획 기준 문서 부재와 정보 분산이다.
- 회의 결과, 다음 방향에 공감대가 형성되었다.
- 메뉴 구조 먼저 확정
- 화면별 PRD(Product Requirements Document) 작성
- PRD 기반으로 디자인/개발 진행
- PRD에는 최소한 다음이 포함되어야 한다.
- 화면 목적
- 고객사 요구사항
- 주요 사용자 시나리오
- 필드 정의
- 필수 여부
- 입력 형식(input, dropdown 등)
- 조회/수기 여부
- 정책 및 예외 처리
- 피그마는 최신 화면 확인용으로 중요하지만, 초기 단계의 유일한 기준 저장소(SSOT)로 쓰기에는 위험하다는 의견이 있었다.
- 대안으로
- PRD를 기획 기준 문서로 사용
- 피그마는 Draft / Final 구분
- 확정된 화면에만 설명을 정리 하는 방향이 제안되었다.
- AI는 기획을 대체하기보다 정리 보조 도구로 활용한다.
11) 일정 및 운영 방식
- 기존 일정은 현실적으로 맞지 않아 WBS 재조정이 필요하다.
- 우선순위는 다음과 같다.
- 메뉴 구조 확정
- WBS 재수립
- PRD 양식 정의 및 시범 작성
- 메인 프로세스 범위는 대체로 다음을 포함한다.
- 마스터 데이터
- EDI
- 도매 매출
- 지급/정산 관련 핵심 흐름
- 당초 목표보다 지연되어, 7월 말까지 메인 기획 정리 수준으로 다시 보는 분위기였다.
- 회의가 너무 잦아 개발 시간이 잠식되고 있으므로,
- 기획 회의 빈도 조정
- 파트별 분업
- 개발 가능한 단위를 끊어서 병행 이 필요하다고 정리했다.
- 고객사에는 완성 전이라도 개발된 부분을 테스트/개발 서버에서 빠르게 보여주고 피드백을 받는 방식이 필요하다.
액션 아이템
- CSO-도매업체 관계 화면
- 도매업체 상세에 연결 CSO 노출 방식 정리
- 도매업체 화면에서 CSO 등록/수정 가능하도록 설계 반영
- 명칭 정리
- ‘연결업체’ → **‘연결 도매업체’**로 용어 수정
- 약국 등록 UX
- 조회 기반 등록과 수기 입력 시나리오를 분리한 화면안으로 수정
- 조회 후 재조회 버튼 필요 여부 포함 재설계
- 사업자 검증
- 국세청 기준으로 중복/개업 확인 정책 정리
- 단일 버튼 처리 여부 명세화
- 고객사 확인
- 요양기관번호 암호화 이슈 및 수기 입력 허용 여부 문의
- 종병/지역구분 값의 실제 사용처 재확인
- 은행명 드롭다운 후보 목록 전달 및 필요 항목 확인
- 문서화
- PRD 양식 먼저 작성
- 샘플 대상으로 약국 화면 또는 품목관리 화면 PRD 시범 작성
- 운영 관리
- 메뉴 구조 우선 확정
- 이후 WBS 일정 재작성
- 개발/고객사 시연용 서버 운영 방식 정리
- 소통 방식
- 현업 질문은 가급적 조기 취합해 전달하고, 슬랙 기반으로 빠르게 답변받는 운영 룰 검토
논의 포인트
CSO 관리 구조에 대한 시사점
- 기존에는 도매업체만 보이는 구조가 중심이었으나, 실제 업무상으로는 대표자 동일/복수 법인/다중 관계가 많아 단순 1:1 구조로는 설명이 어렵다.
- 따라서 연결 관계를 단순 속성값이 아니라 실제 관계 테이블 수준으로 관리해야 하는 방향이 더 적절하다.
약국 등록 UX의 핵심 문제
- 현재 화면은 사용자가
- 무엇을 먼저 입력해야 하는지
- 조회가 필수인지
- 직접 입력이 가능한지
를 직관적으로 알기 어렵다.
- 따라서 단일 폼에서 모든 것을 해결하려 하기보다, **사용자 의도(조회 / 수기)**를 먼저 선택하게 하는 방식이 더 자연스럽다.
조회가 필수 정책이라면, UI도 그 정책을 드러내야 한다.
문서 부재로 인한 반복 논의
- 회의 중 반복적으로 나온 문제는 정책이 문서화되어 있지 않다는 점이었다.
- 필수값, 조회 정책, 예외 처리, 거래처 유형별 차이 등이 정리되지 않아
- 기획은 회의마다 바뀌고
- 디자인은 UX를 확정하기 어렵고
- 개발은 구현 기준이 흔들리는 상황이다.
AI 활용 방식
- AI를 회의 요약이나 초안 작성에 쓰는 것은 가능하지만, 기획 판단 자체를 AI에 맡기면 오히려 기준이 흔들릴 수 있다는 우려가 있었다.
- 따라서 AI는
- 고객사 요구사항 정리
- PRD 초안 생성
- 구조화 보조 정도로 활용하고, 최종 판단은 사람이 문서 기준으로 검수해야 한다.
일정 관리 리스크
- 현재 병목은 단순 개발 속도가 아니라,
- 메뉴 미확정
- 기획 기준 없음
- 회의 과다
- 현업 회신 지연
이 복합적으로 작용하는 구조다.
- 따라서 일정 문제는 개발팀만의 문제가 아니라, 기획·고객 커뮤니케이션·운영 방식 전체의 문제로 보고 풀어야 한다.