지난 편에서는 참석자 추가, 예약 저장까지 구현하며 1:N 관계 데이터의 기본 저장 흐름을 완성했습니다. 이번 편에서는 마지막 단계로 기존 예약 데이터를 수정 화면에 불러오고 부모 테이블과 자식 테이블을 함께 수정하는 과정을 다룹니다. 단순히 입력값만 바꾸는 것이 아니라, 기존 참석자 목록을 다시 조회하고 수정 후 전체를 재저장하는 방식까지 이해하는 것이 핵심입니다.
이전 편까지의 흐름에서 Step3는 이미 수정 화면으로 사용할 준비가 되어 있습니다. Step1 목록에서 행을 클릭하면 해당 행이 Active 상태가 되고 그 상태로 Step3에 진입하는 구조입니다. 이렇게 선택된 예약 정보를 Step3에서 그대로 받아 수정하는 것이 이번 편의 출발점입니다.
먼저 Step3를 클릭한 뒤 스텝 속성에서 다음을 확인합니다. 이 설정을 통해 사용자는 수정 화면에서 작업 후 자연스럽게 이전 화면으로 돌아갈 수 있습니다.
Step3의 입력 영역 그룹을 선택한 뒤 데이터 연결을 확인합니다. 컨트롤의 컬렉션키도 Step2와 동일한 방식으로 연결합니다. 이미 등록 화면에서 사용한 구조와 같기 때문에, Step2에서 입력했던 키를 그대로 맞춰주면 됩니다.
📌 왜 Active 필터가 핵심인가?
Step1에서 클릭한 행은 reservation 카테고리 안에서 Active 상태가 됩니다. Step3가 수정 용도 + Active 필터로 연결되어 있으면 지금 선택한 예약 1건의 값만 입력 폼에 자동으로 채워집니다. 이 구조가 있어야 수정 화면이 기존 값을 불러온 상태로 동작합니다.
Step3에서 가장 번거로운 부분은 참석자 영역입니다. 그런데 이 영역은 Step2와 구조가 거의 동일하기 때문에, 직접 다시 만들기보다 복사해서 재사용하는 것이 훨씬 효율적입니다.
Step2에서 참석자 영역 그룹을 클릭한 뒤 Ctrl + C로 복사합니다. 복사 완료 토스트가 보이면 Step3로 이동합니다.
Step3의 같은 위치 영역을 먼저 선택한 뒤 Delete 키 또는 ‘더 보기 → 삭제’로 제거합니다. 그 상태에서 바로 Ctrl + V로 붙여넣습니다.
📌 복사 방식의 장점
참석자 영역은 콤보, 버튼, 목록, 배지, 삭제 버튼 등 여러 요소가 서로 연결되어 있습니다. Step2에서 이미 완성된 영역을 복사하면 데이터 연결과 이벤트 구조를 대부분 그대로 재사용할 수 있어 작업 시간을 크게 줄일 수 있습니다.
복사 후에는 참석자 목록이 아래와 같이 연결되어 있는지 확인합니다.
이 부분도 Step2와 동일합니다. Step3는 예약 정보는 reservation으로 수정하고 참석자 목록은 reservAttendee를 조회해 보여주는 구조입니다.
예약 정보는 Step1에서 선택한 Active 데이터가 있으므로 바로 폼에 채워집니다.
하지만 참석자 목록은 Step1의 목록 조회 시점에 함께 들고 오지 않기 때문에, Step3에 진입한 뒤 별도로 다시 조회해야 합니다. 이 점이 수정 화면의 가장 큰 차이입니다.
Step3를 클릭한 뒤 스텝 이벤트 사용을 체크하고 다음과 같이 설정합니다.
이후 이벤트 설정으로 이동해 서비스를 추가합니다.
서비스 설정은 다음과 같이 맞춥니다.
📌 Active 상태로 설정하는 이유
수정 화면에서는 “어떤 예약의 참석자를 가져올 것인지”를 알아야 합니다. Step1에서 클릭한 예약 1건이 이미 reservation 카테고리의 Active 상태이므로, 그 예약의 시퀀스 값을 보내면 해당 예약에 연결된 참석자만 정확히 조회할 수 있습니다.
📌 결과를 reservAttendee에 덮어쓰기로 설정하는 이유
Step3에 들어올 때마다 현재 선택된 예약의 참석자 목록으로 새로 그려야 하기 때문입니다. 누적 방식으로 받으면 이전 예약의 참석자 데이터가 남아 섞일 수 있으므로 수정 화면에서는 덮어쓰기가 안전합니다.
이제 Step3 하단의 스텝 버튼을 수정 기능에 맞게 바꿉니다.
Step3의 하단 스텝 버튼을 클릭한 뒤 다음과 같이 설정합니다.
📌 왜 ‘직전 스텝 - 새로 시작’으로 이동하는가?
수정 완료 후에는 이전 화면으로 돌아가면서 Step1의 Loaded 이벤트가 다시 실행되어 최신 목록을 재조회해야 합니다. 그래야 사용자가 수정한 결과를 목록에서 바로 확인할 수 있습니다. Step1이 메인 조회 화면이라 돌아올 때마다 최신 상태를 다시 불러오는 구조가 중요합니다.
이제 실제 수정 로직을 구현합니다. 구조는 저장 버튼의 saveReservation과 비슷하지만, SQL 내부 동작이 다릅니다.
updateReservation 이벤트에서는 서비스 액션을 추가하고 서비스 종류를 FlexSQL로 설정합니다. 이후 스크립트 네임(DEMO_updateReservation)을 등록하고 SQL을 작성·발행합니다.
이벤트 설정에서 보내는 데이터는 다음과 같이 구성합니다.
수정 서비스 한 번으로 현재 선택한 예약 1건의 부모 데이터와 현재 화면에 보이는 참석자 전체 목록을 함께 전달하는 구조입니다.
📌 왜 부모 데이터만 Active 필터를 거는가?
부모 테이블은 지금 수정 중인 예약 1건만 보내야 하므로 Active가 필요합니다. 반면 참석자 목록은 현재 화면에 보이는 전체 참석자를 다시 저장해야 하므로 reservAttendee는 전체 목록을 그대로 보내야 합니다.
이번 이벤트도 Step1 조회 화면으로 다시 이동할 예정이므로 받는 데이터는 별도로 설정하지 않아도 됩니다.
서비스 뒤에는 스크립트를 하나 더 추가해 ‘수정 완료’ 토스트 메시지를 띄워줍니다. 이 메시지가 있으면 사용자는 저장이 정상적으로 끝났는지 즉시 확인할 수 있습니다. 그리고 Step3에 복사해 온 참석자 영역의 이벤트들 중 아래 항목은 반드시 다시 점검해야 합니다. 여기서 핵심은 모두 f_ID 수정 여부 확인입니다.
여기까지 총 여섯 편에 걸쳐 1:N 관계 테이블 설계부터 화면 구성, 조회, 등록, 수정, 삭제까지 전 과정을 완성했습니다. 이번 강의 흐름만 익혀두면 이후에는 회의실 예약 예제를 넘어 실제 업무 앱에서도 훨씬 복잡한 데이터 구조를 안정적으로 구현할 수 있습니다.