260616 메딕스 내부 cso관리 디자인1
2026년 6월 16일 공유
CSO 관리·계약서 UI/정책 검토 회의
개요
콘텐츠 유형: 회의
CSO 관리 화면의 계약서 등록/수정 구조, 계약일·만료일 관리 방식, 전자계약(모두싸인) 연동 방향, 거래처 정보/명칭 정책, 권한 및 직원 관리, 연결업체 개념을 집중 검토했다.
논의 과정에서 현재 화면과 기획 간 불일치가 다수 확인되었고, 일부는 즉시 수정 방향을 정리했으며, 일부는 현업 확인이 필요한 정책 이슈로 남겼다.
참여자 및 역할
기획/운영 담당자들
- 계약 정책, 화면 구조, 현업 확인 항목 논의
프론트엔드 담당자
- 현재 개발 상태 공유
- 피그마/기획과 구현 차이점 설명
디자인/프로덕트 관련 담당자
- UX 흐름, 버튼명, 필수값, 화면 일관성 검토
결정 사항
1) 계약일 표시 및 입력 방향
등록일 옆에 실제 계약일을 표시할 필요가 있음
- 계약일 기준으로 관리하는 방향이 적절함
- 다만 계약 만료일 정책은 아직 확정되지 않아 현업 확인 필요
2) 계약일·만료일 입력 위치
기본정보가 아니라 계약서 업로드 시점에 입력하는 방향이 더 적절함
- 특히 본계약서가 등록/변경될 때 계약일, 계약 만료일을 입력하게 하는 방안에 공감대 형성
3) 거래처 명칭 정책
정식 명칭: 외부 노출용
- 내부 명칭: 시스템 내부 검색/구분용
- 내부 명칭은 선택값에 가깝고,
- 입력하지 않으면 정식 명칭을 내부 명칭으로 자동 대체
- 관련 안내 문구 또는 툴팁 제공 검토
4) 명칭 필수값 방향
정식 명칭 우선 입력
- 내부 명칭은 필요 시 수정하는 구조가 적절
- 대부분의 경우 내부 명칭은 정식 명칭을 그대로 따라가도록 설계
5) 계약서 상세/미리보기 용어 정리
- 상세 모달이 별도로 없고 문서 조회 성격이 강하므로
- **“상세” → “미리보기”**로 바꾸는 방향 검토
- 계약서 항목에서 문서 확인용 미리보기 버튼을 두는 방향 유지
6) 계약서 수정 방식
- 계약서 파일은 직접 수정보다 새 파일 등록 및 이력 관리 방식이 적절
- 따라서 “수정”이라는 표현은 혼동을 줄 수 있어,
- 전체 이력 중심 구조로 정리
- 삭제도 즉시 반영보다
- 화면상 제거 후 저장 시 소프트 삭제 반영이 적절
7) 거래처 직원 정보 정책
이메일, 연락처 모두 필수값
- 이메일은 계정 식별 성격이 강해 수정 불가 방향
- 연락처는 수정 가능
- 잘못 등록된 직원에 대한 삭제 기능 필요
8) 권한 구조 기본 원칙
- 권한은 열람을 기반으로 동작
- 일반적으로 등록/수정/삭제 권한은 열람 권한 전제
- 상위 권한 선택 시 하위 권한 자동 체크되는 방식이 자연스러움
액션 아이템
현업/내부 확인 필요
계약 만료 정책
- 계약이 1년 단위인지
- 거래처/계약 유형별로 만료일이 다른지
계약일 기준
- 모두싸인 최종 서명일 기준인지
- 계약서 문서상 명시일 기준인지
갱신 필요/계약 해지 배지 기준
- 몇 일 전부터 표시할지
- 만료와 해지를 어떻게 구분할지
본계약서/부속계약서 샘플 확보
- 제약사별 계약 구조
- 계약서별 만료/개별 관리 여부 확인
연결업체 범위 확인
- 도매업체만인지
- 약국/병원/CSO 등까지 포함하는지
화면/기획 보완
- 계약서 등록·수정 UX를 초기 등록 / 이후 수정 구조로 재정리
- 본계약서 변경 시 계약일·만료일 입력 모달 추가 검토
- 명칭 필드 안내 문구 추가
- 거래처 직원 수정 모달에 저장 버튼 명확화
- 권한 체크박스 동작 규칙 정리 후 개발 전달
논의 내용
1) 계약서 관리 구조
계약일과 만료일
- 현재는 등록일 중심 흔적이 있으나, 실제 운영에는 계약일이 더 중요함
- 계약 만료일이 API/배지/갱신 로직에 필요하므로,
- 계약서 업로드 시 계약 기간 입력 구조가 필요
- 기본정보에서 관리하면 계약과 무관한 업체에도 필드가 생기므로 부적절하다는 의견이 많았음
본계약서 등록 또는 갱신 시 계약일·만료일을 함께 관리하는 방향이 가장 유력하다.
본계약서와 부속계약서
- 계약 구조는 대체로 다음처럼 이해됨:
- 본계약서: 메딕스와 CSO 간 계약
- 부속계약서(제약사 계약서): 제약사별 계약
- 제약사별로 계약이 체결되며,
- 한 제약사에 여러 문서가 있을 수도 있음
- 따라서 계약 상태를 제약사 단위로 볼지, 문서 단위로 볼지 정책 확정 필요
계약서 업로드 UX
- 처음엔 드래그앤드롭으로 여러 파일을 올리고 구분을 나중에 지정하는 방식이 논의되었으나,
- 실제로는 문서 종류가 정해진 슬롯형 구조에 가까워
- 자유 업로드 방식이 오히려 휴먼 에러를 늘릴 가능성이 큼
- 결과적으로
- 문서 유형이 고정된 구조
- 각 유형별로 파일을 올리거나 교체하는 방식이 더 적절하다는 의견이 강했음
2) 계약서 등록/수정/이력 처리
등록과 수정의 구분
- 최초 등록 화면과 수정 화면이 현재 혼재되어 있어 사용자 혼란 가능성이 큼
- 적절한 구조:
- 최초 등록 전: 등록 중심 UI
- 등록 후: 기존 파일이 보이는 수정 UI + 전체 이력 확인
이력 관리
- 계약서 변경은 과거 이력이 남아야 하므로
- 기존 문서를 덮어쓰기보다 새 버전 등록 개념이 적합
- “수정” 버튼이 실제로는 문서 편집이 아니라 이력 확인/교체 성격이므로
- 표현을 전체 이력으로 조정한 배경이 설명됨
삭제 방식
- 개별 파일 X 클릭 시 즉시 삭제보다는,
- 화면에서 제거
- 최종 저장 시 반영
- 이 방식이 복구/실수 방지 측면에서 더 안정적임
3) 전자계약(모두싸인) 연동
연동 기본 방향
- 모두싸인의 세부 기능을 내부 화면에서 전부 재구현하지 않고,
- 필요 최소한만 연동하는 방향이 적절
- 이상적인 흐름:
- 내부 시스템에 계약 문서 업로드
- 전자계약 연동 버튼으로 모두싸인 전송
- 서명 상태는 API로 회수
- 예: 대기, 진행중, 완료
확인이 필요한 핵심 이슈
- 계약일 기준값
- 모두싸인 서명 완료일
- 계약서 본문 기재일
- 서명자 자동 세팅
- 메딕스 대표자/담당자
- CSO 대표자 및 대표 이메일
- 메일 발송 대상
- 문서 자동 업로드 가능 여부
- 모두싸인 내 세부 입력(도장, 날짜 위치 등)을 내부에서 어디까지 제어할지
UI 측면
- 현재 본계약서 영역에 전자계약 관련 UI가 누락되었을 가능성이 있음
- 피그마와 실제 구현 사이 변경 이력이 있어 추가 정합성 확인 필요
4) 계약 상태, 배지, 정책
필요한 상태값
- 갱신 필요
- 계약 해지
- 만료
- 필요 시 서명 대기/진행중/완료도 연동 가능
아직 미정인 기준
- 갱신 필요를
- 만료 며칠 전부터 띄울지
- 만료 후에만 띄울지
- 해지를
- 단순 만료와 구분할지
- 중도 종료 상태로 별도 관리할지
배지 부착 대상
- 배지가 계약서 파일 단위인지, 제약사 계약 단위인지 불명확한 부분이 있음
- 제약사별 계약에 여러 문서가 걸릴 수 있으므로
- 문서 단위와 계약 단위의 관계를 다시 정리해야 함
5) 거래처 기본정보 및 주소/구조
계약 관련 정보 위치
- 계약일/만료일은 기본정보보다 계약서 입력 프로세스 안에 두는 것이 타당
- 기본정보는 거래처·사업체 정보 중심으로 유지
주소 필드
- 사무실 주소, 사업자 주소, 발송지 등 주소 필수값 구성이 혼재되어 있어
- 생성 화면 기준으로 다시 정리 필요
- 어떤 주소를 상단 대표 주소로 노출할지도 명확히 해야 함
거래처 유형 구조
- 위탁사, 수탁사, 직거래처 등 구분에 대한 확인이 있었고,
- 사업체 구조상 필요한 값이 일부 누락된 상태로 보임
6) 명칭 체계
내부 명칭 vs 정식 명칭
- 내부 명칭
- 내부 검색, 빠른 식별, 동일 업체 구분용
- 정식 명칭
- 포털/외부 출력용
UX 정리 방향
- 사용자는 보통 정식 명칭만 입력
- 내부 명칭이 필요할 때만 수정
- 내부 명칭 미입력 시 정식 명칭을 자동 복사
- 안내 문구 예시:
- 내부 명칭을 입력하지 않으면 정식 명칭이 자동 반영됩니다.
7) 거래처 직원 관리
필수값 및 계정
- 거래처 직원은 로그인 계정과 연결되므로
- 이메일, 연락처 모두 필수
- 퇴사자 계정은 로그인 차단 필요
삭제
- 직원 삭제는 필요하지만,
- 계정/이력/연결 데이터와 연동될 수 있어 단순 삭제는 신중해야 함
- 그럼에도 운영상 삭제 기능은 필요하다는 데 의견이 모임
수정 화면
- 저장 버튼이 빠진 부분이 있어 보완 필요
- 등록 후에는 등록보다 수정 관점으로 동작하는 것이 자연스러움
8) 권한 체계
기본 원칙
- 메뉴 접근 자체가 열람 권한과 연결됨
- 따라서 열람 없는 수정/삭제는 사실상 성립하기 어려움
체크박스 동작
- 사용성 측면에서 다음 구조가 적절:
- 수정 선택 시: 열람/등록/수정 자동 체크
- 삭제 선택 시: 관련 하위 권한 포함
- 열람 해제 시: 상위 권한도 함께 해제
예외 가능성
- 일부 프로젝트 경험상 등록만 따로 주는 경우도 있었으나,
- 현재 구조에서는 열람 기반 상하위 관계가 더 자연스럽다는 의견이 우세
9) 연결업체 기능
기능 목적
- 동일 사업자나 연관 업체가 여러 도메인에 걸쳐 존재할 때,
- 한쪽 정보 수정 시 다른 쪽도 동기화되도록 하기 위한 기능
- 예:
- CSO와 도매를 병행하는 동일 사업체
- 하나의 사업체 정보가 여러 엔터티로 나뉘어 관리되는 경우
미확정 사항
- 명칭을 도매업체로 한정할지
- 더 일반적인 연결업체로 갈지
- 약국/병원/CSO까지 범위를 넓힐지
현재는 범위를 섣불리 고정하지 말고, 현업 확인 후 변경하기로 함.