여러 업무의 거래와 예정일을 모아 보는 캘린더에서는 현황과 근거를 보여 주고, 작성·수정·확정은 원래 업무 메뉴에 모을 수 있다. 달력에서 발견한 항목을 어디에서 고쳐야 하는지까지 연결하는 방식이다.
요청은 캘린더를 읽기 전용으로 바꾸는 것이었다. 코드를 보면 일정 추가 버튼뿐 아니라 달력에서 여는 상세보기와 서버 저장 경로에도 같은 조건이 필요했다. 이미 보관한 일정은 계속 읽을 수 있어야 했다. 업체명과 실제 거래 자료는 제외하고 이 구조를 설명한다.
달력은 원래 기록을 모아 보여 준다
확인한 달력 코드는 기존 전표와 현장 일정, 보관된 업무 기록을 읽어 날짜별 항목으로 만든다. 원래 자료의 식별자를 남겨 전표나 관리대장으로 이동할 수 있게 한다. 달력을 한 번 열었다는 이유로 같은 거래를 새로 입력하는 구조는 아니다.
이 방식을 쓰면 달력의 배치와 거래를 확정하는 절차를 따로 다룰 수 있다. 카드에는 기록의 종류와 상태를 보여 주고, 수정하려는 사람은 실제 업무 메뉴로 이동한다. 날짜나 상태를 바꾸기 전에 어떤 원본을 고치는지 확인하게 하려는 선택이다.
예를 들어 납품 요청일과 실제 납품 기록은 같은 날짜일 필요가 없다. 소스에서도 요청일과 실제 처리 기록에 다른 식별자와 설명을 붙인다. 달력의 색이나 완료처럼 보이는 배치만으로 업무가 끝났다고 판단하지 않고 항목이 어떤 기록에서 왔는지 읽도록 했다.
연결 전표를 열어도 조회 전용이 이어진다
달력에서 일정 수정 버튼을 지워도 연결된 전표 상세에 확정·취소 버튼이 남으면 사용자는 그곳에서 거래를 바꿀 수 있다. 읽기 전용이라는 설명이 첫 화면에서만 맞는 셈이다. 확인한 상위 화면은 캘린더를 보고 있을 때 상세 컴포넌트에 readOnly 조건을 넘긴다.
상세 컴포넌트는 이 조건을 받아 수정 동작과 전표의 상태 변경 버튼을 제한한다. 화면에는 캘린더에서 연 전표는 조회 전용이며 작성·수정은 해당 업무 메뉴에서 하라는 안내도 있다. 기존 화면을 전부 새로 만드는 대신 같은 상세보기에 현재 진입 경로의 역할을 전한 구조다.
근거를 찾아가는 연결은 남는다. 카드에서 보관 원본 행이나 연결 전표를 열고 관리대장으로 이동할 수 있다. 다른 업무 메뉴로 명시적으로 이동한 뒤의 수정 권한까지 없애는 것은 아니다. 무엇을 볼 수 있고 어디에서 고쳐야 하는지 함께 안내해야 한다.
수정 권한이 있는 계정도 달력에서는 저장하지 않는다
계정 권한은 누가 수정할 수 있는지를 정한다. 캘린더를 조회 전용으로 만드는 것은 어디에서 수정할 수 있는지를 정하는 일이다. 관리 권한이 있는 사람도 달력에서 거래를 바꾸지 못하게 하려면 계정 검사 외에 경로별 제한이 필요하다.
확인한 서버의 경로 검사에는 /api/calendar와 그 하위 경로로 들어온 GET 이외의 요청을 405로 돌려주는 조건이 있다. 405는 해당 경로가 그 요청 방식을 허용하지 않는다는 HTTP 상태다. 일반적인 수정 권한을 확인하기 전에 캘린더 경로의 역할을 제한한다. 기존 시험도 수정 권한을 가진 계정에 대해 이 경로의 저장이 거절되는지를 살피도록 되어 있다.
로컬 백엔드에는 캘린더 POST 요청을 일찍 거절하는 분기와, 일정 저장 함수를 직접 불러도 거절하는 조건이 각각 남아 있다. 화면 버튼의 유무, 서버 경로, 내부 함수가 같은 역할을 표현한다. 이 코드 검토가 운영 서버의 모든 접근 경로에 대한 새 보안 검증을 뜻하는 것은 아니다.
- 화면: 일정 추가·수정 동작 대신 조회와 근거 열기를 제공한다.
- 상세보기: 달력에서 열었을 때의 조회 전용 조건을 이어 받는다.
- 서버 경로: 캘린더의 저장 요청을 일반 수정 권한과 별개로 거절한다.
- 업무 메뉴: 기존 작성·수정 절차와 계정 권한을 적용한다.
새 입력을 막는다고 옛 일정을 지우지는 않는다
조회 전용으로 바꾸기 전에 저장한 일정이 있다면 읽는 방법도 정해야 한다. 새 입력을 받지 않는다는 이유로 기존 자료까지 삭제하거나 화면에서 사라지게 하면, 사용자는 이전에 확인하던 업무를 잃을 수 있다.
확인한 구현은 옛 일정 테이블이 있을 때 그 자료를 읽고, 없으면 새 테이블을 만드는 대신 해당 항목 없이 조회를 이어 간다. 일정에 연결된 전표의 소속이 달라졌거나 취소된 경우를 설명하는 문구도 있다. 취소된 전표에 붙은 옛 일정은 다시 확인할 항목으로 보여 주도록 되어 있다.
이 처리는 옛 일정의 상태를 실제 입금이나 납품 완료로 바꾸는 기능이 아니다. 현재 자료를 어떻게 읽어 보여 줄지 정하는 과정이다. 화면을 단순하게 만드는 작업에서도 기존 기록을 보존하는 기준과 새로 금지할 입력을 따로 적어야 한다.
거절 응답과 자료 보존을 같이 확인한다
저장 요청이 오류로 끝났다는 사실만으로 자료가 그대로라는 결론을 내릴 수는 없다. 요청 중간에 테이블이나 기록을 만든 뒤 마지막에 거절했을 가능성도 검사해야 한다. 기존 격리 시험에는 요청 전후의 데이터베이스 내용을 비교하고, 새 일정 테이블이 생기지 않았는지 확인하는 항목이 있다.
화면 시험은 달력에서 일정 추가·수정 동작이 없는지, 연결 전표를 여는 동작은 남는지, 일반 업무 상세는 기존 편집 기능을 유지하는지를 나눠 확인하도록 작성돼 있다. 기존 시험이 쓰는 화면 대역은 실제 브라우저와 같지 않다. 버튼이 없는지 살피는 코드 검사와 실제 화면을 눌러 보는 검수도 구별해야 한다.
이번 집필에서는 이 코드와 기존 시험 정의, 과거 검증 기록을 읽었다. 운영 계정에 접속하거나 원제품 시험을 다시 실행하지 않았다. 당시 검증 기록도 사용자 화면 검수를 남은 일로 표시한다. 새 원고의 검사는 사실·출처 대조와 문장 편집, 관련 링크, 정적 미리보기 범위로 기록한다.
다른 조회 화면에도 같은 질문을 적용한다
대시보드나 보고서에서도 편집 경로를 한곳으로 모으고 싶다면, 먼저 원래 자료가 어디에서 작성되고 바뀌는지 적는다. 새 화면은 어떤 정보를 읽고 어떤 식별자로 원본에 연결할지 정한다. 그다음 상세보기와 서버가 같은 역할을 유지하는지 확인한다.
적용할 때는 조회 전용 계정만으로 검사하지 않는다. 수정 권한이 있는 계정에서도 해당 조회 경로의 저장은 거절되고, 원래 업무 메뉴에서는 필요한 수정이 가능한지 대조한다. 이미 보관된 항목, 취소된 원본에 연결된 항목, 날짜가 없는 항목도 읽을 수 있는지 범위에 넣는다.
이 방식은 현황을 모아 보는 화면에 적합하다. 달력에서 직접 일정을 조정해야 하는 서비스라면 원본의 어느 값을 바꿀지, 어떤 확인을 받을지 따로 설계해야 한다. 이 사례에서는 거래 입력을 원래 업무 화면에 모으기로 했다.