도식·표·사례·결론의 결합
답안 그림에는 권한 확인 뒤 자료를 검색한다고 그렸다. 본문에는 모든 자료를 생성 모델에 넣은 뒤 화면에서 숨긴다고 썼다. 결론에서는 개인정보 노출을 방지했다고 선언한다. 그림·문장·결론을 따로 보면 그럴듯하지만 실제로는 서로 다른 설계다.
그림은 맞는데 본문이 다른 절차를 설명한다면
이 절의 기준 사례는 마지막 좌석을 예약한 뒤 알림 응답만 잃은 요청 R1이다. 먼저 예약의 원리와 풀이에서 업무 확정과 통지 확인을 구별하고, 같은 시점의 사실을 도식·표·본문·결론에 유지하는 방법을 연습한다. 독립 문제에서는 조건 하나를 바꾸어 무엇을 다시 확인해야 하는지 설명한다.
다른 업무에서도 같은 오류가 생긴다. 답안 그림에는 권한 확인 뒤 자료를 검색한다고 그렸다. 본문에는 모든 자료를 생성 모델에 넣은 뒤 화면에서 숨긴다고 썼다. 결론에서는 개인정보 노출을 방지했다고 선언한다. 그림·문장·결론을 따로 보면 그럴듯하지만 실제로는 서로 다른 설계다.
정의·비교·구조·절차·설계·정책형과 핵심정의에서 판단축까지를 여러 표현과 실전 문제에 적용하며, 도식·표·사례·결론이 같은 사실을 설명하는지 본다. 이 절의 예제·모의문항·배점·시간·답안은 모두 자체 교육용이다. 공식 채점표·합격 가능성·실제 구축 경험으로 사용하지 않는다.
1. 같은 사실을 서로 다른 표현으로 설명한다
답안 정합성은 도식·표·계산·본문·결론이 같은 대상·시점·조건·권한·완료기준을 유지하며 서로 모순되지 않게 같은 판단을 설명하는 상태다.
| 표현 | 맡길 역할 | 필요한 확인 |
|---|---|---|
| 도식 | 역할·경계·흐름·의존관계 | 화살표가 데이터·승인·시간 중 무엇인지 |
| 비교표 | 공통축의 대안·조건·대가 | 양쪽이 같은 질문과 범위를 비교하는지 |
| 계산·사례 | 원리의 구체 적용 | 가정·원수·단위·중간과정·해석의 일치 |
| 본문 | 관계가 성립하는 이유와 예외 | 그림에서 생략한 판단을 설명하는지 |
| 결론 | 선택·조건·남는 위험·다음 확인 | 앞 근거보다 넓게 보장하지 않는지 |
한 그림에 모든 설명을 넣으려 하면 글자가 작아지고 화살표가 엉킨다. 핵심 경로를 남기고 세부 조건은 번호나 짧은 문장으로 연결한다. 반대로 그림을 생략한 채 제품 이름을 길게 나열하면 경계와 관계가 보이지 않는다. 표현은 필요한 판단을 드러내는 만큼만 사용한다.
2. 좌석 예약은 완료됐는데 알림 응답이 없다면
R1 확정과 N1 미확인 · 상태 따라가기
A의 좌석·예약·R1 결과·N1 작업을 함께 기록한 COMMIT을 확인했다. 모든 단계에서 재고·업무 R1·통지 N1의 위치를 유지하며 값과 허용 조건을 함께 확인합니다.
좌석은 예약됐는데 알림 응답이 사라졌다
마지막 좌석은 한 개다. A가 요청 R1로 신청했고, DB에서 예약을 확정한 COMMIT 결과도 확인했다. 그런데 확정 안내 N1을 외부 발송 서비스에 보낸 뒤 응답이 돌아오지 않았다. A가 같은 R1로 다시 요청하면 좌석을 한 번 더 배정해야 할까?
이 구간에서는 재고 0·업무 확정·알림 미확인이라는 세 상태를 도식, 표, 풀이, 결론까지 같은 뜻으로 유지한다. 응답 유실을 곧 실패로 바꾸거나, 업무 확정을 알림 전달 완료로 넓히지 않는 것이 목표다.
먼저 예약이 언제 확정되는지와 무엇을 아직 모르는지 구별하자. 그 근거가 있어야 그림의 화살표와 표의 상태를 같은 사실로 읽을 수 있다.
- 같은 회차의 마지막 좌석 한 개를 A가 신청한다. 이 예에서는 취소나 다른 신청자의 변경을 추가하지 않는다.
- R1은 A의 같은 회차·같은 신청 내용에 묶인 요청 ID다. 같은 ID에 다른 내용이 들어오면 기존 결과로 덮어쓰지 않고 충돌로 처리한다.
- N1은 이 예약 결과를 알릴 작업의 ID다. 이 예의 알림 확인 기준은 외부 발송 서비스의 수락 응답을 기록한 상태이며, 이용자의 수신·열람까지 뜻하지 않는다.
먼저 세 가지를 확인한다
- DB 트랜잭션
- 이 예에서는 좌석 차감, 예약·R1 결과, N1 작업 기록을 함께 확정한다. 롤백이 확인되면 이 변경들은 함께 취소된다.
- COMMIT 확인
- DB 변경이 확정됐다는 근거다. 처리 응답이 없다는 사실만으로 COMMIT 성공이나 롤백을 판단할 수는 없다.
- 같은 요청의 재시도
- A가 같은 내용의 R1을 다시 보내는 일이다. R1의 기록된 결과를 확인해 같은 업무 효과를 반복하지 않는다. ID 문자열만으로 그 성질이 자동 구현되지는 않는다.
예약 확정과 알림 처리는 경계가 다르다
잘못된 DT-A는 신청 수신 → 확정 안내 → 잔여 확인 → 원장 저장 순서다. 저장이 실패하거나 좌석이 없으면 이미 보낸 성공 안내와 실제 예약이 달라진다. 이 예에서는 예약의 COMMIT을 확인한 뒤에 그 결과를 알린다.
DB 안에서는 R1의 고유성을 집행하고 잔여가 있을 때만 1을 차감한다. 차감과 함께 A의 예약, R1의 처리 결과, 알릴 작업 N1을 같은 트랜잭션에 기록한다. 먼저 조회해서 R1이 없었다는 사실만으로 동시 중복을 막을 수는 없으므로 고유성·조건부 갱신·충돌 처리가 필요하다.
N1 작업을 DB에 기록하는 것과 외부 발송 서비스를 호출하는 것은 다르다. 외부 발송은 이 DB 트랜잭션 밖에서 수행한다. 따라서 예약과 외부 메시지 전달이 항상 함께 성공하거나 함께 취소된다고 가정하지 않는다.
N1 응답이 유실됐다면 서비스가 수락했지만 응답만 사라졌을 수도 있고, 수락하지 못한 채 응답이 없었을 수도 있다. 지금의 근거로는 둘을 구별할 수 없어 알림 미확인이라고 적는다. 명시적 실패 응답을 확인한 경우에는 실패로 기록하며, 이번 응답 유실과 구별한다. 미확인은 성공이나 실패의 다른 이름이 아니다.
N1 이력과 발송 서비스의 기록을 같은 식별자로 맞춰 비교하는 일을 대사라고 한다. R1 조회는 예약의 근거를 확인하고, N1 대사는 외부 알림의 근거를 확인한다. 두 확인을 서로 대신 사용하지 않는다.
화살표는 처리·확인 경로다. 예약의 DB 트랜잭션과 외부 알림의 경계를 분리한다. 알림 분기는 수락 응답 확인과 응답 유실을 비교하며, 명시적 실패 응답은 별도로 처리한다. 기존 R1 결과는 재배정 근거가 아니며, N1 이력 확인도 무조건 재발송한다는 뜻이 아니다.
- 먼저 미처리 확인 → 같은 DB 트랜잭션 → DB 처리 결과 → COMMIT 확인 → 업무 확정 경로를 읽는다. 처리 결과의 결정점에서 확인된 롤백과 미확인 경로도 구분한다.
- 다음으로 N1 응답의 예·아니오 분기를 읽는다. 응답 유실 경로의 끝은 업무 실패가 아니라 알림 미확인이다.
- A가 같은 R1을 재시도하면 맨 위의 결과 조회부터 다시 읽는다. 이미 확정 분기는 좌석을 차감하는 트랜잭션을 거치지 않고 기존 업무 결과로 합류한다. 이 조회는 N1의 외부 결과를 확인한 근거가 아니다.
- DB 처리 결과의 미확인 경로는 R1 결과 조회로 돌아온다. 조회에서도 진행·미확인이면 확인 후 다시 조회하며 그 상태를 유지한다. 단순히 검색 결과가 없다는 이유로 롤백이나 미처리를 확정하지 않는다.
같은 사건을 단계별로 풀어 본다
예약의 확정 근거를 먼저 찾는다
A의 R1로 좌석을 차감하고 예약·R1 결과·N1 작업을 함께 기록했다. 이 사례에서는 COMMIT 결과를 확인했으므로 업무는 확정이다. 응답 유실이라는 말이 있어도 어느 응답인지 구별해야 한다. 지금 유실된 것은 뒤의 N1 응답이다.
재고 계산과 업무 상태를 연결한다
마지막 좌석 1개에서 A의 확정 예약 1개를 차감했으므로 1−1=0이다. 재고 0은 같은 좌석을 새로 배정할 수 없다는 뜻이고, 업무 확정은 A의 예약이 DB에 확정돼 있다는 뜻이다. 두 표현은 같은 확정 결과를 수량과 업무 상태로 설명한다.
N1 응답 유실의 의미를 한정한다
N1 작업이 DB에 있다는 사실은 발송 서비스가 수락했다는 근거가 아니다. 반대로 N1 응답을 받지 못했다는 사실도 예약의 롤백 근거가 아니다. 현재는 재고 0·업무 확정·알림 미확인으로 적고, N1의 발송 이력과 외부에서 확인할 수 있는 결과를 대조한다.
같은 R1 재시도를 기존 결과로 돌려준다
A가 같은 신청 내용으로 R1을 다시 보내면 먼저 그 요청의 기록된 결과와 현재 상태를 확인한다. 이미 확정된 예약이 있으므로 좌석을 다시 차감하거나 새 예약을 만들지 않는다. A에게는 예약 확정과 알림 미확인을 구분해 반환한다.
알림 처리에서는 같은 N1의 이력을 확인한다. 미확인 결과를 대사하고 재전송 여부는 발송 서비스의 중복 처리 조건과 정책에 따라 정한다. N1이라는 ID만으로 외부 서비스의 중복 발송이 방지되거나 메시지가 정확히 한 번 도착한다고 약속하지 않는다.
도식·표·본문·결론을 같은 근거로 맞춘다
도식에서는 외부 알림을 DB 경계 밖에 두고, 표에서는 업무 확정과 알림 미확인을 서로 다른 항목으로 적는다. 본문은 그 이유를 COMMIT 확인과 N1 응답 유실로 설명한다. 결론도 예약은 확정됐으며 알림 결과는 추가 확인이 필요하다고 한정한다.
| 항목 | 현재 상태 | 확인한 근거 | 이 상태로 말할 수 없는 것 |
|---|---|---|---|
| 재고 | 0 | 좌석 1개에서 확정 예약 1개를 차감한 COMMIT | 알림이 전달됐다는 보장 |
| 업무 | 확정 | A의 예약과 R1 결과가 DB에 확정됨 | 알림 미확인이므로 예약도 취소됐다는 판단 |
| 알림 | 미확인 | N1 작업은 있으나 수락 응답을 확인하지 못함 | 발송 성공 또는 실패의 단정 |
| 상황과 근거 | 판단 | 다음 행동 |
|---|---|---|
| COMMIT 확인 뒤 N1 응답만 유실 | 재고 0·업무 확정·알림 미확인 | R1의 기존 예약을 반환하고 N1 이력을 대사한다. 좌석을 복구하거나 다시 배정하지 않는다. |
| DB 변경의 ROLLBACK 확인 | 이 예에서는 재고 1·업무 미확정·N1 작업 없음 | 확정 안내를 보내지 않는다. 오류·권한·조건을 확인한 뒤 같은 R1의 재시도 조건을 정한다. |
| COMMIT 요청 뒤 응답 유실, 결과도 아직 미확인 | 업무 확정이나 롤백을 아직 단정할 수 없음 | R1의 처리 결과와 진행 상태를 다시 확인한다. 알림부터 보내거나 새 요청으로 재배정하지 않는다. |
독립 연습: 화면의 응답 없음으로 복구를 결정해도 될까?
위 사례에서 DB에는 A의 R1 예약 확정과 N1 작업이 기록돼 있다. N1의 수락 응답은 아직 확인되지 않는다. A는 같은 내용의 R1을 다시 보냈다. 화면에는 응답 없음이 표시되자, 좌석을 1로 되돌리고 새 요청으로 다시 배정하자는 의견이 나왔다.
답안을 열기 전에 아래 네 가지를 짧게 작성한다. 상태 이름만 적지 말고, 각 판단의 근거와 먼저 확인할 기록을 붙인다.
- 재고·업무·알림의 현재 상태를 세 줄로 쓰고, 각각 확인된 사실과 미확인 사실을 구별하라.
- 좌석을 복구해 새 요청으로 다시 배정하자는 의견을 판단하라. 같은 R1 재시도에서 어떤 기록을 먼저 확인하고 A에게 무엇을 반환할지 쓰라.
- 나중에 N1의 수락 응답을 확인했다. 세 상태 중 무엇을 바꿀 수 있으며, 이용자가 메시지를 읽었다고까지 말할 수 있는가? 같은 근거를 유지하는 결론을 두 문장으로 쓰라.
- 조건 하나를 바꿔 보자. N1 응답뿐 아니라 COMMIT 응답도 유실됐고, R1의 확정 결과도 아직 확인하지 못했다면 무엇을 미확인으로 남겨야 하는가? 기존 사례와 다른 점 및 다음 확인을 쓰라.
독립 연습의 답안과 오답 교정 보기
근거를 유지한 답안
재고는 0, 업무는 확정, 알림은 미확인이다. 앞의 두 상태는 A의 R1 예약과 차감의 COMMIT으로 확인했다. N1 작업의 존재는 확인했지만 외부 수락 응답은 확인하지 못했다. 알림 미확인을 업무 미확정으로 옮기지 않는다.
그 의견은 부적절하다. 알림 응답 유실은 DB 예약을 되돌릴 근거가 아니므로 재고를 1로 복구하지 않는다. A·같은 회차·같은 신청 내용에 묶인 R1의 기존 결과와 현재 예약 상태를 확인해 예약 확정·알림 미확인을 반환한다. 새 배정 대신 N1의 이력을 대사한다.
재고 0과 업무 확정은 유지하고 알림을 접수 확인으로 바꿀 수 있다. 발송 서비스의 수락 응답은 이용자의 수신·열람 증거와 다르다.
결론 예: A의 R1 예약은 확정돼 재고가 0이며, N1은 외부 발송 서비스의 접수를 확인했다. 이용자의 실제 수신·열람은 이 근거만으로 확인할 수 없다.
이제 업무의 커밋 결과도 미확인이다. 원래 사례는 예약 COMMIT을 확인했지만, 바뀐 사례에는 그 근거가 없으므로 업무 확정이나 롤백, 현재 재고를 단정하지 않는다. R1의 DB 처리 결과와 진행 상태를 재조회해 권위 있는 결과를 확인하며, 그 전에 새 요청으로 배정하거나 확정 안내를 보내지 않는다. 조회 결과가 없다는 사실만으로 롤백으로 확정하지도 않는다.
틀린 답은 상태를 바꾼 지점부터 고친다
- 응답이 없으니 예약도 실패했고 좌석을 복구한다.
- 어느 응답이 없는지 확인한다. N1 응답 유실은 확인된 예약 COMMIT을 취소하지 않는다. 업무와 알림을 별도 상태로 돌려놓는다.
- R1이 같으니 모든 처리가 정확히 한 번이고 알림도 한 번만 도착한다.
- R1의 DB 고유성과 결과 재사용은 예약의 반복 효과를 막는 장치다. 외부 N1 발송의 중복 처리 조건과 실제 수신·열람은 별도로 확인해야 한다.
- COMMIT 응답이 없고 R1이 조회되지 않으니 롤백됐다.
- 응답·조회 결과만으로 아직 진행 중인 처리나 확정 결과를 단정하지 않는다. R1 결과와 진행 상태를 확인하고, 알 수 없는 동안은 커밋 결과 미확인을 유지한다.
같은 사실을 끝까지 유지한다
이 사례의 결론은 재고 0·업무 확정·알림 미확인이다. 예약은 DB의 확인된 결과로 설명하고, 알림은 외부 N1의 확인 근거로 설명한다. 같은 R1 재시도는 기존 예약 결과로 돌아가며, 남은 확인은 N1의 처리 결과다. 그림·표·본문·결론 어느 곳에서도 그 범위를 넓히지 않는다.
이 예의 조건
- 같은 회차의 마지막 좌석 한 개를 A가 신청한다. 이 예에서는 취소나 다른 신청자의 변경을 추가하지 않는다.
- R1은 A의 같은 회차·같은 신청 내용에 묶인 요청 ID다. 같은 ID에 다른 내용이 들어오면 기존 결과로 덮어쓰지 않고 충돌로 처리한다.
- N1은 이 예약 결과를 알릴 작업의 ID다. 이 예의 알림 확인 기준은 외부 발송 서비스의 수락 응답을 기록한 상태이며, 이용자의 수신·열람까지 뜻하지 않는다.
- 이 원문의 교육용 사례·조건 안에서 상태를 대조합니다. 실제 구축·실험 결과나 원문에 없는 성능 보장을 추가하지 않습니다.
관계도의 보충 설명
| 풀이 | 원 설명 |
|---|---|
| 1 · 예약의 확정 근거를 먼저 찾는다 | A의 R1로 좌석을 차감하고 예약·R1 결과·N1 작업을 함께 기록했다. 이 사례에서는 COMMIT 결과를 확인했으므로 업무는 확정이다. 응답 유실이라는 말이 있어도 어느 응답인지 구별해야 한다. 지금 유실된 것은 뒤의 N1 응답이다. |
| 2 · 재고 계산과 업무 상태를 연결한다 | 마지막 좌석 1개에서 A의 확정 예약 1개를 차감했으므로 1−1=0이다. 재고 0은 같은 좌석을 새로 배정할 수 없다는 뜻이고, 업무 확정은 A의 예약이 DB에 확정돼 있다는 뜻이다. 두 표현은 같은 확정 결과를 수량과 업무 상태로 설명한다. |
| 3 · N1 응답 유실의 의미를 한정한다 | N1 작업이 DB에 있다는 사실은 발송 서비스가 수락했다는 근거가 아니다. 반대로 N1 응답을 받지 못했다는 사실도 예약의 롤백 근거가 아니다. 현재는 재고 0·업무 확정·알림 미확인으로 적고, N1의 발송 이력과 외부에서 확인할 수 있는 결과를 대조한다. |
| 4 · 같은 R1 재시도를 기존 결과로 돌려준다 | A가 같은 신청 내용으로 R1을 다시 보내면 먼저 그 요청의 기록된 결과와 현재 상태를 확인한다. 이미 확정된 예약이 있으므로 좌석을 다시 차감하거나 새 예약을 만들지 않는다. A에게는 예약 확정과 알림 미확인을 구분해 반환한다. 알림 처리에서는 같은 N1의 이력을 확인한다. 미확인 결과를 대사하고 재전송 여부는 발송 서비스의 중복 처리 조건과 정책에 따라 정한다. N1이라는 ID만으로 외부 서비스의 중복 발송이 방지되거나 메시지가 정확히 한 번 도착한다고 약속하지 않는다. |
| 5 · 도식·표·본문·결론을 같은 근거로 맞춘다 | 도식에서는 외부 알림을 DB 경계 밖에 두고, 표에서는 업무 확정과 알림 미확인을 서로 다른 항목으로 적는다. 본문은 그 이유를 COMMIT 확인과 N1 응답 유실로 설명한다. 결론도 예약은 확정됐으며 알림 결과는 추가 확인이 필요하다고 한정한다. |
| 원 항목 | 원 내용 |
|---|---|
| documentId | P9-C03-S02 |
| segmentId | p9-c03-s02-seat-case |
| sourceScope · path | dev-note/content/docs/peim/p9/c03/s02.mdx |
| sourceScope · preservedStartAnchor | p9-c03-s02-consistency |
| sourceScope · preservedNextAnchor | p9-c03-s02-numbers |
| sourceScope · existingHeading | 2. DT-A의 잘못된 신청 도식을 고친다 |
| sourceScope · replacementStartsAfter | <a id="p9-c03-s02-consistency"></a> |
| sourceScope · replacementEndsBefore | <a id="p9-c03-s02-numbers"></a> |
| sourceScope · retention | Keep the existing section anchor and heading number. Retain original advanced DT-A prose, its footnote reference and all later sections in separately labeled advanced details. Replace only the old generic flow ConceptDiagram with the shared connected diagram. |
| comparisonContract · styles 1 | 기존 교재형 |
| comparisonContract · styles 2 | 담백한 인쇄형 |
| comparisonContract · styles 3 | 단계별 해설형 |
| comparisonContract · canonicalContent | All lesson strings, case values, node and edge data, tables, exercise questions, answers and reading order come from this one object. A style changes presentation only. |
| comparisonContract · readingOrder 1 | introduction |
| comparisonContract · readingOrder 2 | prerequisites |
| comparisonContract · readingOrder 3 | explanation |
| comparisonContract · readingOrder 4 | diagram |
| comparisonContract · readingOrder 5 | worked |
| comparisonContract · readingOrder 6 | exercise |
| comparisonContract · readingOrder 7 | answer |
| comparisonContract · readingOrder 8 | misconceptions |
| comparisonContract · readingOrder 9 | conclusion |
| comparisonContract · foldedContent | Only the independent exercise answer and its misconception correction start closed. Explanation, connected diagram, worked steps and failure-condition table remain public. |
| case · actor | A |
| case · requestId | R1 |
| case · notificationId | N1 |
| case · businessState | 확정 |
| case · notificationState | 미확인 |
| case · assumptions 1 | 같은 회차의 마지막 좌석 한 개를 A가 신청한다. 이 예에서는 취소나 다른 신청자의 변경을 추가하지 않는다. |
| case · assumptions 2 | R1은 A의 같은 회차·같은 신청 내용에 묶인 요청 ID다. 같은 ID에 다른 내용이 들어오면 기존 결과로 덮어쓰지 않고 충돌로 처리한다. |
| case · assumptions 3 | N1은 이 예약 결과를 알릴 작업의 ID다. 이 예의 알림 확인 기준은 외부 발송 서비스의 수락 응답을 기록한 상태이며, 이용자의 수신·열람까지 뜻하지 않는다. |
| introduction · heading | 좌석은 예약됐는데 알림 응답이 사라졌다 |
| introduction · paragraphs 1 | 마지막 좌석은 한 개다. A가 요청 R1로 신청했고, DB에서 예약을 확정한 COMMIT 결과도 확인했다. 그런데 확정 안내 N1을 외부 발송 서비스에 보낸 뒤 응답이 돌아오지 않았다. A가 같은 R1로 다시 요청하면 좌석을 한 번 더 배정해야 할까? |
| introduction · paragraphs 2 | 이 구간에서는 재고 0·업무 확정·알림 미확인이라는 세 상태를 도식, 표, 풀이, 결론까지 같은 뜻으로 유지한다. 응답 유실을 곧 실패로 바꾸거나, 업무 확정을 알림 전달 완료로 넓히지 않는 것이 목표다. |
| introduction · paragraphs 3 | 먼저 예약이 언제 확정되는지와 무엇을 아직 모르는지 구별하자. 그 근거가 있어야 그림의 화살표와 표의 상태를 같은 사실로 읽을 수 있다. |
| prerequisites · heading | 먼저 세 가지를 확인한다 |
| prerequisites · items 1 · term | DB 트랜잭션 |
| prerequisites · items 1 · meaning | 이 예에서는 좌석 차감, 예약·R1 결과, N1 작업 기록을 함께 확정한다. 롤백이 확인되면 이 변경들은 함께 취소된다. |
| prerequisites · items 2 · term | COMMIT 확인 |
| prerequisites · items 2 · meaning | DB 변경이 확정됐다는 근거다. 처리 응답이 없다는 사실만으로 COMMIT 성공이나 롤백을 판단할 수는 없다. |
| prerequisites · items 3 · term | 같은 요청의 재시도 |
| prerequisites · items 3 · meaning | A가 같은 내용의 R1을 다시 보내는 일이다. R1의 기록된 결과를 확인해 같은 업무 효과를 반복하지 않는다. ID 문자열만으로 그 성질이 자동 구현되지는 않는다. |
| prerequisites · checkQuestion | 응답이 오지 않았다는 사실만으로 DB 변경도 취소됐다고 말할 수 있을까? |
| prerequisites · checkExplanation | 그럴 수 없다. 응답을 받았는지와 DB에 무엇이 확정됐는지는 서로 다른 질문이다. 아래 사례는 DB의 COMMIT은 확인됐고, N1 응답만 유실된 상황이다. |
| explanation · heading | 예약 확정과 알림 처리는 경계가 다르다 |
| explanation · paragraphs 1 | 잘못된 DT-A는 신청 수신 → 확정 안내 → 잔여 확인 → 원장 저장 순서다. 저장이 실패하거나 좌석이 없으면 이미 보낸 성공 안내와 실제 예약이 달라진다. 이 예에서는 예약의 COMMIT을 확인한 뒤에 그 결과를 알린다. |
| explanation · paragraphs 2 | DB 안에서는 R1의 고유성을 집행하고 잔여가 있을 때만 1을 차감한다. 차감과 함께 A의 예약, R1의 처리 결과, 알릴 작업 N1을 같은 트랜잭션에 기록한다. 먼저 조회해서 R1이 없었다는 사실만으로 동시 중복을 막을 수는 없으므로 고유성·조건부 갱신·충돌 처리가 필요하다. |
| explanation · paragraphs 3 | N1 작업을 DB에 기록하는 것과 외부 발송 서비스를 호출하는 것은 다르다. 외부 발송은 이 DB 트랜잭션 밖에서 수행한다. 따라서 예약과 외부 메시지 전달이 항상 함께 성공하거나 함께 취소된다고 가정하지 않는다. |
| explanation · paragraphs 4 | N1 응답이 유실됐다면 서비스가 수락했지만 응답만 사라졌을 수도 있고, 수락하지 못한 채 응답이 없었을 수도 있다. 지금의 근거로는 둘을 구별할 수 없어 알림 미확인이라고 적는다. 명시적 실패 응답을 확인한 경우에는 실패로 기록하며, 이번 응답 유실과 구별한다. 미확인은 성공이나 실패의 다른 이름이 아니다. |
| explanation · paragraphs 5 | N1 이력과 발송 서비스의 기록을 같은 식별자로 맞춰 비교하는 일을 대사라고 한다. R1 조회는 예약의 근거를 확인하고, N1 대사는 외부 알림의 근거를 확인한다. 두 확인을 서로 대신 사용하지 않는다. |
| diagram · id | p9-seat-confirmation |
| diagram · title | R1의 예약 결과와 N1의 알림 상태를 분리한다 |
| diagram · description | A의 요청 R1은 DB에서 좌석과 예약·요청 결과·N1 작업을 함께 처리하며, 처리 결과에 따라 확정·롤백·미확인을 구분한다. 미확인이면 R1 결과와 진행 상태를 다시 확인하고, 예약 확정 뒤의 외부 N1 응답 유실은 알림 미확인으로 남긴다. 같은 R1 재시도는 기존 예약 결과로 합류하여 좌석을 다시 배정하지 않는다. |
| diagram · type | flowchart |
| diagram · semanticIntent | transaction outcome and external notification acknowledgment |
| diagram · semanticPatternSelection | No installed named semantic pattern exactly matches this behavior; use flowchart decision grammar directly, with an explicit DB transaction boundary and a separate external notification boundary. |
| diagram · primaryDirection | top-to-bottom |
| diagram · focalNodeIds 1 | confirmed |
| diagram · focalNodeIds 2 | notifyUnknown |
| diagram · boundaries 1 · id | atomic-db |
| diagram · boundaries 1 · label | 같은 DB 트랜잭션 |
| diagram · boundaries 1 · nodeIds 1 | tx |
| diagram · boundaries 1 · meaning | 좌석 차감·예약과 R1 결과·N1 작업 기록이 함께 확정되거나 함께 롤백된다. 결과 조회 자체와 외부 발송은 이 변경 트랜잭션에 넣지 않는다. |
| diagram · boundaries 2 · id | external-notification |
| diagram · boundaries 2 · label | DB 트랜잭션 밖 · 외부 알림 |
| diagram · boundaries 2 · nodeIds 1 | notification |
| diagram · boundaries 2 · nodeIds 2 | ack |
| diagram · boundaries 2 · nodeIds 3 | accepted |
| diagram · boundaries 2 · nodeIds 4 | notifyUnknown |
| diagram · boundaries 2 · meaning | N1 발송·응답 확인은 예약을 확정한 DB 변경과 별도다. |
| diagram · nodes 1 · id | lookup |
| diagram · nodes 1 · type | decision |
| diagram · nodes 1 · title | A의 R1 처리 결과 확인 |
| diagram · nodes 1 · body | 현재 결과와 진행 상태를 조회 |
| diagram · nodes 2 · id | tx |
| diagram · nodes 2 · type | process |
| diagram · nodes 2 · title | 좌석·예약·결과를 함께 기록 |
| diagram · nodes 2 · body | R1 고유성 · 잔여 1→0 예약·R1 결과·N1 작업 |
| diagram · nodes 3 · id | confirmed |
| diagram · nodes 3 · type | state |
| diagram · nodes 3 · title | 재고 0 · 업무 확정 |
| diagram · nodes 3 · body | R1의 예약 결과 확인 |
| diagram · nodes 4 · id | rollback |
| diagram · nodes 4 · type | end |
| diagram · nodes 4 · title | 롤백 확인 · 업무 미확정 |
| diagram · nodes 4 · body | 이 예의 재고는 1 · N1 작업 없음 |
| diagram · nodes 5 · id | commitResult |
| diagram · nodes 5 · type | decision |
| diagram · nodes 5 · title | DB 처리 결과는? |
| diagram · nodes 5 · body | 확정 · 롤백 · 미확인 |
| diagram · nodes 6 · id | notification |
| diagram · nodes 6 · type | process |
| diagram · nodes 6 · title | N1 통지 처리 |
| diagram · nodes 6 · body | 같은 N1 이력 확인 후 발송·대사 |
| diagram · nodes 7 · id | ack |
| diagram · nodes 7 · type | decision |
| diagram · nodes 7 · title | N1 수락 응답을 확인했나? |
| diagram · nodes 7 · body | 확인된 근거에 따라 기록 |
| diagram · nodes 8 · id | accepted |
| diagram · nodes 8 · type | end |
| diagram · nodes 8 · title | 알림 접수 확인 |
| diagram · nodes 8 · body | N1 수락 응답 기록 · 열람과 다름 |
| diagram · nodes 9 · id | notifyUnknown |
| diagram · nodes 9 · type | end |
| diagram · nodes 9 · title | 알림 미확인 |
| diagram · nodes 9 · body | 성공·실패를 단정하지 않음 |
| diagram · edges 1 · from | lookup |
| diagram · edges 1 · to | tx |
| diagram · edges 1 · label | 미처리 확인 |
| diagram · edges 2 · from | lookup |
| diagram · edges 2 · to | confirmed |
| diagram · edges 2 · label | 이미 확정 |
| diagram · edges 3 · from | lookup |
| diagram · edges 3 · to | lookup |
| diagram · edges 3 · label | 진행·미확인: 재조회 |
| diagram · edges 4 · from | tx |
| diagram · edges 4 · to | commitResult |
| diagram · edges 4 · label | 변경 처리 후 |
| diagram · edges 5 · from | commitResult |
| diagram · edges 5 · to | confirmed |
| diagram · edges 5 · label | COMMIT 확인 |
| diagram · edges 6 · from | commitResult |
| diagram · edges 6 · to | rollback |
| diagram · edges 6 · label | ROLLBACK 확인 |
| diagram · edges 7 · from | commitResult |
| diagram · edges 7 · to | lookup |
| diagram · edges 7 · label | 미확인: R1 재조회 |
| diagram · edges 8 · from | confirmed |
| diagram · edges 8 · to | notification |
| diagram · edges 8 · label | 업무와 구분 |
| diagram · edges 9 · from | notification |
| diagram · edges 9 · to | ack |
| diagram · edges 9 · label | 처리 결과 |
| diagram · edges 10 · from | ack |
| diagram · edges 10 · to | accepted |
| diagram · edges 10 · label | 예 |
| diagram · edges 11 · from | ack |
| diagram · edges 11 · to | notifyUnknown |
| diagram · edges 11 · label | 아니요 · 응답 유실 |
| diagram · caption | 화살표는 처리·확인 경로다. 예약의 DB 트랜잭션과 외부 알림의 경계를 분리한다. 알림 분기는 수락 응답 확인과 응답 유실을 비교하며, 명시적 실패 응답은 별도로 처리한다. 기존 R1 결과는 재배정 근거가 아니며, N1 이력 확인도 무조건 재발송한다는 뜻이 아니다. |
| diagram · readingInstructions 1 | 먼저 미처리 확인 → 같은 DB 트랜잭션 → DB 처리 결과 → COMMIT 확인 → 업무 확정 경로를 읽는다. 처리 결과의 결정점에서 확인된 롤백과 미확인 경로도 구분한다. |
| diagram · readingInstructions 2 | 다음으로 N1 응답의 예·아니요 분기를 읽는다. 응답 유실 경로의 끝은 업무 실패가 아니라 알림 미확인이다. |
| diagram · readingInstructions 3 | A가 같은 R1을 재시도하면 맨 위의 결과 조회부터 다시 읽는다. 이미 확정 분기는 좌석을 차감하는 트랜잭션을 거치지 않고 기존 업무 결과로 합류한다. 이 조회는 N1의 외부 결과를 확인한 근거가 아니다. |
| diagram · readingInstructions 4 | DB 처리 결과의 미확인 경로는 R1 결과 조회로 돌아온다. 조회에서도 진행·미확인이면 확인 후 다시 조회하며 그 상태를 유지한다. 단순히 검색 결과가 없다는 이유로 롤백이나 미처리를 확정하지 않는다. |
| worked · heading | 같은 사건을 단계별로 풀어 본다 |
| worked · steps 1 · title | 예약의 확정 근거를 먼저 찾는다 |
| worked · steps 1 · paragraphs 1 | A의 R1로 좌석을 차감하고 예약·R1 결과·N1 작업을 함께 기록했다. 이 사례에서는 COMMIT 결과를 확인했으므로 업무는 확정이다. 응답 유실이라는 말이 있어도 어느 응답인지 구별해야 한다. 지금 유실된 것은 뒤의 N1 응답이다. |
| worked · steps 2 · title | 재고 계산과 업무 상태를 연결한다 |
| worked · steps 2 · paragraphs 1 | 마지막 좌석 1개에서 A의 확정 예약 1개를 차감했으므로 1−1=0이다. 재고 0은 같은 좌석을 새로 배정할 수 없다는 뜻이고, 업무 확정은 A의 예약이 DB에 확정돼 있다는 뜻이다. 두 표현은 같은 확정 결과를 수량과 업무 상태로 설명한다. |
| worked · steps 3 · title | N1 응답 유실의 의미를 한정한다 |
| worked · steps 3 · paragraphs 1 | N1 작업이 DB에 있다는 사실은 발송 서비스가 수락했다는 근거가 아니다. 반대로 N1 응답을 받지 못했다는 사실도 예약의 롤백 근거가 아니다. 현재는 재고 0·업무 확정·알림 미확인으로 적고, N1의 발송 이력과 외부에서 확인할 수 있는 결과를 대조한다. |
| worked · steps 4 · title | 같은 R1 재시도를 기존 결과로 돌려준다 |
| worked · steps 4 · paragraphs 1 | A가 같은 신청 내용으로 R1을 다시 보내면 먼저 그 요청의 기록된 결과와 현재 상태를 확인한다. 이미 확정된 예약이 있으므로 좌석을 다시 차감하거나 새 예약을 만들지 않는다. A에게는 예약 확정과 알림 미확인을 구분해 반환한다. |
| worked · steps 4 · paragraphs 2 | 알림 처리에서는 같은 N1의 이력을 확인한다. 미확인 결과를 대사하고 재전송 여부는 발송 서비스의 중복 처리 조건과 정책에 따라 정한다. N1이라는 ID만으로 외부 서비스의 중복 발송이 방지되거나 메시지가 정확히 한 번 도착한다고 약속하지 않는다. |
| worked · steps 5 · title | 도식·표·본문·결론을 같은 근거로 맞춘다 |
| worked · steps 5 · paragraphs 1 | 도식에서는 외부 알림을 DB 경계 밖에 두고, 표에서는 업무 확정과 알림 미확인을 서로 다른 항목으로 적는다. 본문은 그 이유를 COMMIT 확인과 N1 응답 유실로 설명한다. 결론도 예약은 확정됐으며 알림 결과는 추가 확인이 필요하다고 한정한다. |
| worked · stateTable · caption | N1 응답 유실 직후의 세 상태 |
| worked · stateTable · columns 1 | 항목 |
| worked · stateTable · columns 2 | 현재 상태 |
| worked · stateTable · columns 3 | 확인한 근거 |
| worked · stateTable · columns 4 | 이 상태로 말할 수 없는 것 |
| worked · stateTable · rows 1 1 | 재고 |
| worked · stateTable · rows 1 2 | 0 |
| worked · stateTable · rows 1 3 | 좌석 1개에서 확정 예약 1개를 차감한 COMMIT |
| worked · stateTable · rows 1 4 | 알림이 전달됐다는 보장 |
| worked · stateTable · rows 2 1 | 업무 |
| worked · stateTable · rows 2 2 | 확정 |
| worked · stateTable · rows 2 3 | A의 예약과 R1 결과가 DB에 확정됨 |
| worked · stateTable · rows 2 4 | 알림 미확인이므로 예약도 취소됐다는 판단 |
| worked · stateTable · rows 3 1 | 알림 |
| worked · stateTable · rows 3 2 | 미확인 |
| worked · stateTable · rows 3 3 | N1 작업은 있으나 수락 응답을 확인하지 못함 |
| worked · stateTable · rows 3 4 | 발송 성공 또는 실패의 단정 |
| worked · failureTable · caption | 어느 결과를 확인했는지에 따라 다음 행동이 달라진다 |
| worked · failureTable · columns 1 | 상황과 근거 |
| worked · failureTable · columns 2 | 판단 |
| worked · failureTable · columns 3 | 다음 행동 |
| worked · failureTable · rows 1 1 | COMMIT 확인 뒤 N1 응답만 유실 |
| worked · failureTable · rows 1 2 | 재고 0·업무 확정·알림 미확인 |
| worked · failureTable · rows 1 3 | R1의 기존 예약을 반환하고 N1 이력을 대사한다. 좌석을 복구하거나 다시 배정하지 않는다. |
| worked · failureTable · rows 2 1 | DB 변경의 ROLLBACK 확인 |
| worked · failureTable · rows 2 2 | 이 예에서는 재고 1·업무 미확정·N1 작업 없음 |
| worked · failureTable · rows 2 3 | 확정 안내를 보내지 않는다. 오류·권한·조건을 확인한 뒤 같은 R1의 재시도 조건을 정한다. |
| worked · failureTable · rows 3 1 | COMMIT 요청 뒤 응답 유실, 결과도 아직 미확인 |
| worked · failureTable · rows 3 2 | 업무 확정이나 롤백을 아직 단정할 수 없음 |
| worked · failureTable · rows 3 3 | R1의 처리 결과와 진행 상태를 다시 확인한다. 알림부터 보내거나 새 요청으로 재배정하지 않는다. |
| exercise · heading | 독립 연습: 화면의 응답 없음으로 복구를 결정해도 될까? |
| exercise · scenario | 위 사례에서 DB에는 A의 R1 예약 확정과 N1 작업이 기록돼 있다. N1의 수락 응답은 아직 확인되지 않는다. A는 같은 내용의 R1을 다시 보냈다. 화면에 응답 없음이 표시되자, 좌석을 1로 되돌리고 새 요청으로 다시 배정하자는 의견이 나왔다. |
| exercise · instructions | 답안을 열기 전에 아래 네 가지를 짧게 작성한다. 상태 이름만 적지 말고, 각 판단의 근거와 먼저 확인할 기록을 붙인다. |
| exercise · questions 1 · text | 재고·업무·알림의 현재 상태를 세 줄로 쓰고, 각각 확인된 사실과 미확인 사실을 구별하라. |
| exercise · questions 2 · text | 좌석을 복구해 새 요청으로 다시 배정하자는 의견을 판단하라. 같은 R1 재시도에서 어떤 기록을 먼저 확인하고 A에게 무엇을 반환할지 쓰라. |
| exercise · questions 3 · text | 나중에 N1의 수락 응답을 확인했다. 세 상태 중 무엇을 바꿀 수 있으며, 이용자가 메시지를 읽었다고까지 말할 수 있는가? 같은 근거를 유지하는 결론을 두 문장으로 쓰라. |
| exercise · questions 4 · text | 조건 하나를 바꿔 보자. N1 응답뿐 아니라 COMMIT 응답도 유실됐고, R1의 확정 결과도 아직 확인하지 못했다면 무엇을 미확인으로 남겨야 하는가? 기존 사례와 다른 점 및 다음 확인을 쓰라. |
| answer · summary | 독립 연습의 답안과 오답 교정 보기 |
| answer · heading | 근거를 유지한 답안 |
| answer · items 1 · paragraphs 1 | 재고는 0, 업무는 확정, 알림은 미확인이다. 앞의 두 상태는 A의 R1 예약과 차감의 COMMIT으로 확인했다. N1 작업의 존재는 확인했지만 외부 수락 응답은 확인하지 못했다. 알림 미확인을 업무 미확정으로 옮기지 않는다. |
| answer · items 2 · paragraphs 1 | 그 의견은 부적절하다. 알림 응답 유실은 DB 예약을 되돌릴 근거가 아니므로 재고를 1로 복구하지 않는다. A·같은 회차·같은 신청 내용에 묶인 R1의 기존 결과와 현재 예약 상태를 확인해 예약 확정·알림 미확인을 반환한다. 새 배정 대신 N1의 이력을 대사한다. |
| answer · items 3 · paragraphs 1 | 재고 0과 업무 확정은 유지하고 알림을 접수 확인으로 바꿀 수 있다. 발송 서비스의 수락 응답은 이용자의 수신·열람 증거와 다르다. |
| answer · items 3 · paragraphs 2 | 결론 예: A의 R1 예약은 확정돼 재고가 0이며, N1은 외부 발송 서비스의 접수를 확인했다. 이용자의 실제 수신·열람은 이 근거만으로 확인할 수 없다. |
| answer · items 4 · paragraphs 1 | 이제 업무의 커밋 결과도 미확인이다. 원래 사례는 예약 COMMIT을 확인했지만, 바뀐 사례에는 그 근거가 없으므로 업무 확정이나 롤백, 현재 재고를 단정하지 않는다. R1의 DB 처리 결과와 진행 상태를 재조회해 권위 있는 결과를 확인하며, 그 전에 새 요청으로 배정하거나 확정 안내를 보내지 않는다. 조회 결과가 없다는 사실만으로 롤백으로 확정하지도 않는다. |
| misconceptions · heading | 틀린 답은 상태를 바꾼 지점부터 고친다 |
| misconceptions · items 1 · wrong | 응답이 없으니 예약도 실패했고 좌석을 복구한다. |
| misconceptions · items 1 · correction | 어느 응답이 없는지 확인한다. N1 응답 유실은 확인된 예약 COMMIT을 취소하지 않는다. 업무와 알림을 별도 상태로 돌려놓는다. |
| misconceptions · items 2 · wrong | R1이 같으니 모든 처리가 정확히 한 번이고 알림도 한 번만 도착한다. |
| misconceptions · items 2 · correction | R1의 DB 고유성과 결과 재사용은 예약의 반복 효과를 막는 장치다. 외부 N1 발송의 중복 처리 조건과 실제 수신·열람은 별도로 확인해야 한다. |
| misconceptions · items 3 · wrong | COMMIT 응답이 없고 R1이 조회되지 않으니 롤백됐다. |
| misconceptions · items 3 · correction | 응답·조회 결과만으로 아직 진행 중인 처리나 확정 결과를 단정하지 않는다. R1 결과와 진행 상태를 확인하고, 알 수 없는 동안은 커밋 결과 미확인을 유지한다. |
| conclusion · heading | 같은 사실을 끝까지 유지한다 |
| conclusion · paragraphs 1 | 이 사례의 결론은 재고 0·업무 확정·알림 미확인이다. 예약은 DB의 확인된 결과로 설명하고, 알림은 외부 N1의 확인 근거로 설명한다. 같은 R1 재시도는 기존 예약 결과로 돌아가며, 남은 확인은 N1의 처리 결과다. 그림·표·본문·결론 어느 곳에서도 그 범위를 넓히지 않는다. |
| 관찰·상황 | 값·보충 정보 | 변화·이유 |
|---|---|---|
| R1 COMMIT 확인 A의 좌석·예약·R1 결과·N1 작업을 함께 기록한 COMMIT을 확인했다. |
|
|
| 1−1=0 대조 마지막 좌석 1에서 예약 1을 차감한 같은 결과를 수량으로 확인한다. |
|
|
| N1 응답 미확인 발송 수락 응답을 못 받아도 예약 롤백 근거가 되지 않는다. |
|
|
| 같은 R1 재시도 같은 내용의 R1은 기존 결과와 현재 상태를 반환하고 새 배정을 만들지 않는다. |
|
|
| 세 상태 유지 도식·표·본문·결론 모두 재고 0·업무 확정·알림 미확인을 유지한다. |
|
|
R1 확정과 N1 미확인 · 상태 따라가기
A의 좌석·예약·R1 결과·N1 작업을 함께 기록한 COMMIT을 확인했다. 모든 단계에서 재고·업무 R1·통지 N1의 위치를 유지하며 값과 허용 조건을 함께 확인합니다.
좌석은 예약됐는데 알림 응답이 사라졌다
마지막 좌석은 한 개다. A가 요청 R1로 신청했고, DB에서 예약을 확정한 COMMIT 결과도 확인했다. 그런데 확정 안내 N1을 외부 발송 서비스에 보낸 뒤 응답이 돌아오지 않았다. A가 같은 R1로 다시 요청하면 좌석을 한 번 더 배정해야 할까?
이 구간에서는 재고 0·업무 확정·알림 미확인이라는 세 상태를 도식, 표, 풀이, 결론까지 같은 뜻으로 유지한다. 응답 유실을 곧 실패로 바꾸거나, 업무 확정을 알림 전달 완료로 넓히지 않는 것이 목표다.
먼저 예약이 언제 확정되는지와 무엇을 아직 모르는지 구별하자. 그 근거가 있어야 그림의 화살표와 표의 상태를 같은 사실로 읽을 수 있다.
- 같은 회차의 마지막 좌석 한 개를 A가 신청한다. 이 예에서는 취소나 다른 신청자의 변경을 추가하지 않는다.
- R1은 A의 같은 회차·같은 신청 내용에 묶인 요청 ID다. 같은 ID에 다른 내용이 들어오면 기존 결과로 덮어쓰지 않고 충돌로 처리한다.
- N1은 이 예약 결과를 알릴 작업의 ID다. 이 예의 알림 확인 기준은 외부 발송 서비스의 수락 응답을 기록한 상태이며, 이용자의 수신·열람까지 뜻하지 않는다.
먼저 세 가지를 확인한다
- DB 트랜잭션
- 이 예에서는 좌석 차감, 예약·R1 결과, N1 작업 기록을 함께 확정한다. 롤백이 확인되면 이 변경들은 함께 취소된다.
- COMMIT 확인
- DB 변경이 확정됐다는 근거다. 처리 응답이 없다는 사실만으로 COMMIT 성공이나 롤백을 판단할 수는 없다.
- 같은 요청의 재시도
- A가 같은 내용의 R1을 다시 보내는 일이다. R1의 기록된 결과를 확인해 같은 업무 효과를 반복하지 않는다. ID 문자열만으로 그 성질이 자동 구현되지는 않는다.
예약 확정과 알림 처리는 경계가 다르다
잘못된 DT-A는 신청 수신 → 확정 안내 → 잔여 확인 → 원장 저장 순서다. 저장이 실패하거나 좌석이 없으면 이미 보낸 성공 안내와 실제 예약이 달라진다. 이 예에서는 예약의 COMMIT을 확인한 뒤에 그 결과를 알린다.
DB 안에서는 R1의 고유성을 집행하고 잔여가 있을 때만 1을 차감한다. 차감과 함께 A의 예약, R1의 처리 결과, 알릴 작업 N1을 같은 트랜잭션에 기록한다. 먼저 조회해서 R1이 없었다는 사실만으로 동시 중복을 막을 수는 없으므로 고유성·조건부 갱신·충돌 처리가 필요하다.
N1 작업을 DB에 기록하는 것과 외부 발송 서비스를 호출하는 것은 다르다. 외부 발송은 이 DB 트랜잭션 밖에서 수행한다. 따라서 예약과 외부 메시지 전달이 항상 함께 성공하거나 함께 취소된다고 가정하지 않는다.
N1 응답이 유실됐다면 서비스가 수락했지만 응답만 사라졌을 수도 있고, 수락하지 못한 채 응답이 없었을 수도 있다. 지금의 근거로는 둘을 구별할 수 없어 알림 미확인이라고 적는다. 명시적 실패 응답을 확인한 경우에는 실패로 기록하며, 이번 응답 유실과 구별한다. 미확인은 성공이나 실패의 다른 이름이 아니다.
N1 이력과 발송 서비스의 기록을 같은 식별자로 맞춰 비교하는 일을 대사라고 한다. R1 조회는 예약의 근거를 확인하고, N1 대사는 외부 알림의 근거를 확인한다. 두 확인을 서로 대신 사용하지 않는다.
화살표는 처리·확인 경로다. 예약의 DB 트랜잭션과 외부 알림의 경계를 분리한다. 알림 분기는 수락 응답 확인과 응답 유실을 비교하며, 명시적 실패 응답은 별도로 처리한다. 기존 R1 결과는 재배정 근거가 아니며, N1 이력 확인도 무조건 재발송한다는 뜻이 아니다.
- 먼저 미처리 확인 → 같은 DB 트랜잭션 → DB 처리 결과 → COMMIT 확인 → 업무 확정 경로를 읽는다. 처리 결과의 결정점에서 확인된 롤백과 미확인 경로도 구분한다.
- 다음으로 N1 응답의 예·아니오 분기를 읽는다. 응답 유실 경로의 끝은 업무 실패가 아니라 알림 미확인이다.
- A가 같은 R1을 재시도하면 맨 위의 결과 조회부터 다시 읽는다. 이미 확정 분기는 좌석을 차감하는 트랜잭션을 거치지 않고 기존 업무 결과로 합류한다. 이 조회는 N1의 외부 결과를 확인한 근거가 아니다.
- DB 처리 결과의 미확인 경로는 R1 결과 조회로 돌아온다. 조회에서도 진행·미확인이면 확인 후 다시 조회하며 그 상태를 유지한다. 단순히 검색 결과가 없다는 이유로 롤백이나 미처리를 확정하지 않는다.
같은 사건을 단계별로 풀어 본다
예약의 확정 근거를 먼저 찾는다
A의 R1로 좌석을 차감하고 예약·R1 결과·N1 작업을 함께 기록했다. 이 사례에서는 COMMIT 결과를 확인했으므로 업무는 확정이다. 응답 유실이라는 말이 있어도 어느 응답인지 구별해야 한다. 지금 유실된 것은 뒤의 N1 응답이다.
재고 계산과 업무 상태를 연결한다
마지막 좌석 1개에서 A의 확정 예약 1개를 차감했으므로 1−1=0이다. 재고 0은 같은 좌석을 새로 배정할 수 없다는 뜻이고, 업무 확정은 A의 예약이 DB에 확정돼 있다는 뜻이다. 두 표현은 같은 확정 결과를 수량과 업무 상태로 설명한다.
N1 응답 유실의 의미를 한정한다
N1 작업이 DB에 있다는 사실은 발송 서비스가 수락했다는 근거가 아니다. 반대로 N1 응답을 받지 못했다는 사실도 예약의 롤백 근거가 아니다. 현재는 재고 0·업무 확정·알림 미확인으로 적고, N1의 발송 이력과 외부에서 확인할 수 있는 결과를 대조한다.
같은 R1 재시도를 기존 결과로 돌려준다
A가 같은 신청 내용으로 R1을 다시 보내면 먼저 그 요청의 기록된 결과와 현재 상태를 확인한다. 이미 확정된 예약이 있으므로 좌석을 다시 차감하거나 새 예약을 만들지 않는다. A에게는 예약 확정과 알림 미확인을 구분해 반환한다.
알림 처리에서는 같은 N1의 이력을 확인한다. 미확인 결과를 대사하고 재전송 여부는 발송 서비스의 중복 처리 조건과 정책에 따라 정한다. N1이라는 ID만으로 외부 서비스의 중복 발송이 방지되거나 메시지가 정확히 한 번 도착한다고 약속하지 않는다.
도식·표·본문·결론을 같은 근거로 맞춘다
도식에서는 외부 알림을 DB 경계 밖에 두고, 표에서는 업무 확정과 알림 미확인을 서로 다른 항목으로 적는다. 본문은 그 이유를 COMMIT 확인과 N1 응답 유실로 설명한다. 결론도 예약은 확정됐으며 알림 결과는 추가 확인이 필요하다고 한정한다.
| 항목 | 현재 상태 | 확인한 근거 | 이 상태로 말할 수 없는 것 |
|---|---|---|---|
| 재고 | 0 | 좌석 1개에서 확정 예약 1개를 차감한 COMMIT | 알림이 전달됐다는 보장 |
| 업무 | 확정 | A의 예약과 R1 결과가 DB에 확정됨 | 알림 미확인이므로 예약도 취소됐다는 판단 |
| 알림 | 미확인 | N1 작업은 있으나 수락 응답을 확인하지 못함 | 발송 성공 또는 실패의 단정 |
| 상황과 근거 | 판단 | 다음 행동 |
|---|---|---|
| COMMIT 확인 뒤 N1 응답만 유실 | 재고 0·업무 확정·알림 미확인 | R1의 기존 예약을 반환하고 N1 이력을 대사한다. 좌석을 복구하거나 다시 배정하지 않는다. |
| DB 변경의 ROLLBACK 확인 | 이 예에서는 재고 1·업무 미확정·N1 작업 없음 | 확정 안내를 보내지 않는다. 오류·권한·조건을 확인한 뒤 같은 R1의 재시도 조건을 정한다. |
| COMMIT 요청 뒤 응답 유실, 결과도 아직 미확인 | 업무 확정이나 롤백을 아직 단정할 수 없음 | R1의 처리 결과와 진행 상태를 다시 확인한다. 알림부터 보내거나 새 요청으로 재배정하지 않는다. |
독립 연습: 화면의 응답 없음으로 복구를 결정해도 될까?
위 사례에서 DB에는 A의 R1 예약 확정과 N1 작업이 기록돼 있다. N1의 수락 응답은 아직 확인되지 않는다. A는 같은 내용의 R1을 다시 보냈다. 화면에는 응답 없음이 표시되자, 좌석을 1로 되돌리고 새 요청으로 다시 배정하자는 의견이 나왔다.
답안을 열기 전에 아래 네 가지를 짧게 작성한다. 상태 이름만 적지 말고, 각 판단의 근거와 먼저 확인할 기록을 붙인다.
- 재고·업무·알림의 현재 상태를 세 줄로 쓰고, 각각 확인된 사실과 미확인 사실을 구별하라.
- 좌석을 복구해 새 요청으로 다시 배정하자는 의견을 판단하라. 같은 R1 재시도에서 어떤 기록을 먼저 확인하고 A에게 무엇을 반환할지 쓰라.
- 나중에 N1의 수락 응답을 확인했다. 세 상태 중 무엇을 바꿀 수 있으며, 이용자가 메시지를 읽었다고까지 말할 수 있는가? 같은 근거를 유지하는 결론을 두 문장으로 쓰라.
- 조건 하나를 바꿔 보자. N1 응답뿐 아니라 COMMIT 응답도 유실됐고, R1의 확정 결과도 아직 확인하지 못했다면 무엇을 미확인으로 남겨야 하는가? 기존 사례와 다른 점 및 다음 확인을 쓰라.
독립 연습의 답안과 오답 교정 보기
근거를 유지한 답안
재고는 0, 업무는 확정, 알림은 미확인이다. 앞의 두 상태는 A의 R1 예약과 차감의 COMMIT으로 확인했다. N1 작업의 존재는 확인했지만 외부 수락 응답은 확인하지 못했다. 알림 미확인을 업무 미확정으로 옮기지 않는다.
그 의견은 부적절하다. 알림 응답 유실은 DB 예약을 되돌릴 근거가 아니므로 재고를 1로 복구하지 않는다. A·같은 회차·같은 신청 내용에 묶인 R1의 기존 결과와 현재 예약 상태를 확인해 예약 확정·알림 미확인을 반환한다. 새 배정 대신 N1의 이력을 대사한다.
재고 0과 업무 확정은 유지하고 알림을 접수 확인으로 바꿀 수 있다. 발송 서비스의 수락 응답은 이용자의 수신·열람 증거와 다르다.
결론 예: A의 R1 예약은 확정돼 재고가 0이며, N1은 외부 발송 서비스의 접수를 확인했다. 이용자의 실제 수신·열람은 이 근거만으로 확인할 수 없다.
이제 업무의 커밋 결과도 미확인이다. 원래 사례는 예약 COMMIT을 확인했지만, 바뀐 사례에는 그 근거가 없으므로 업무 확정이나 롤백, 현재 재고를 단정하지 않는다. R1의 DB 처리 결과와 진행 상태를 재조회해 권위 있는 결과를 확인하며, 그 전에 새 요청으로 배정하거나 확정 안내를 보내지 않는다. 조회 결과가 없다는 사실만으로 롤백으로 확정하지도 않는다.
틀린 답은 상태를 바꾼 지점부터 고친다
- 응답이 없으니 예약도 실패했고 좌석을 복구한다.
- 어느 응답이 없는지 확인한다. N1 응답 유실은 확인된 예약 COMMIT을 취소하지 않는다. 업무와 알림을 별도 상태로 돌려놓는다.
- R1이 같으니 모든 처리가 정확히 한 번이고 알림도 한 번만 도착한다.
- R1의 DB 고유성과 결과 재사용은 예약의 반복 효과를 막는 장치다. 외부 N1 발송의 중복 처리 조건과 실제 수신·열람은 별도로 확인해야 한다.
- COMMIT 응답이 없고 R1이 조회되지 않으니 롤백됐다.
- 응답·조회 결과만으로 아직 진행 중인 처리나 확정 결과를 단정하지 않는다. R1 결과와 진행 상태를 확인하고, 알 수 없는 동안은 커밋 결과 미확인을 유지한다.
같은 사실을 끝까지 유지한다
이 사례의 결론은 재고 0·업무 확정·알림 미확인이다. 예약은 DB의 확인된 결과로 설명하고, 알림은 외부 N1의 확인 근거로 설명한다. 같은 R1 재시도는 기존 예약 결과로 돌아가며, 남은 확인은 N1의 처리 결과다. 그림·표·본문·결론 어느 곳에서도 그 범위를 넓히지 않는다.
이 예의 조건
- 같은 회차의 마지막 좌석 한 개를 A가 신청한다. 이 예에서는 취소나 다른 신청자의 변경을 추가하지 않는다.
- R1은 A의 같은 회차·같은 신청 내용에 묶인 요청 ID다. 같은 ID에 다른 내용이 들어오면 기존 결과로 덮어쓰지 않고 충돌로 처리한다.
- N1은 이 예약 결과를 알릴 작업의 ID다. 이 예의 알림 확인 기준은 외부 발송 서비스의 수락 응답을 기록한 상태이며, 이용자의 수신·열람까지 뜻하지 않는다.
- 이 원문의 교육용 사례·조건 안에서 상태를 대조합니다. 실제 구축·실험 결과나 원문에 없는 성능 보장을 추가하지 않습니다.
관계도의 보충 설명
| 풀이 | 원 설명 |
|---|---|
| 1 · 예약의 확정 근거를 먼저 찾는다 | A의 R1로 좌석을 차감하고 예약·R1 결과·N1 작업을 함께 기록했다. 이 사례에서는 COMMIT 결과를 확인했으므로 업무는 확정이다. 응답 유실이라는 말이 있어도 어느 응답인지 구별해야 한다. 지금 유실된 것은 뒤의 N1 응답이다. |
| 2 · 재고 계산과 업무 상태를 연결한다 | 마지막 좌석 1개에서 A의 확정 예약 1개를 차감했으므로 1−1=0이다. 재고 0은 같은 좌석을 새로 배정할 수 없다는 뜻이고, 업무 확정은 A의 예약이 DB에 확정돼 있다는 뜻이다. 두 표현은 같은 확정 결과를 수량과 업무 상태로 설명한다. |
| 3 · N1 응답 유실의 의미를 한정한다 | N1 작업이 DB에 있다는 사실은 발송 서비스가 수락했다는 근거가 아니다. 반대로 N1 응답을 받지 못했다는 사실도 예약의 롤백 근거가 아니다. 현재는 재고 0·업무 확정·알림 미확인으로 적고, N1의 발송 이력과 외부에서 확인할 수 있는 결과를 대조한다. |
| 4 · 같은 R1 재시도를 기존 결과로 돌려준다 | A가 같은 신청 내용으로 R1을 다시 보내면 먼저 그 요청의 기록된 결과와 현재 상태를 확인한다. 이미 확정된 예약이 있으므로 좌석을 다시 차감하거나 새 예약을 만들지 않는다. A에게는 예약 확정과 알림 미확인을 구분해 반환한다. 알림 처리에서는 같은 N1의 이력을 확인한다. 미확인 결과를 대사하고 재전송 여부는 발송 서비스의 중복 처리 조건과 정책에 따라 정한다. N1이라는 ID만으로 외부 서비스의 중복 발송이 방지되거나 메시지가 정확히 한 번 도착한다고 약속하지 않는다. |
| 5 · 도식·표·본문·결론을 같은 근거로 맞춘다 | 도식에서는 외부 알림을 DB 경계 밖에 두고, 표에서는 업무 확정과 알림 미확인을 서로 다른 항목으로 적는다. 본문은 그 이유를 COMMIT 확인과 N1 응답 유실로 설명한다. 결론도 예약은 확정됐으며 알림 결과는 추가 확인이 필요하다고 한정한다. |
| 원 항목 | 원 내용 |
|---|---|
| documentId | P9-C03-S02 |
| segmentId | p9-c03-s02-seat-case |
| sourceScope · path | dev-note/content/docs/peim/p9/c03/s02.mdx |
| sourceScope · preservedStartAnchor | p9-c03-s02-consistency |
| sourceScope · preservedNextAnchor | p9-c03-s02-numbers |
| sourceScope · existingHeading | 2. DT-A의 잘못된 신청 도식을 고친다 |
| sourceScope · replacementStartsAfter | <a id="p9-c03-s02-consistency"></a> |
| sourceScope · replacementEndsBefore | <a id="p9-c03-s02-numbers"></a> |
| sourceScope · retention | Keep the existing section anchor and heading number. Retain original advanced DT-A prose, its footnote reference and all later sections in separately labeled advanced details. Replace only the old generic flow ConceptDiagram with the shared connected diagram. |
| comparisonContract · styles 1 | 기존 교재형 |
| comparisonContract · styles 2 | 담백한 인쇄형 |
| comparisonContract · styles 3 | 단계별 해설형 |
| comparisonContract · canonicalContent | All lesson strings, case values, node and edge data, tables, exercise questions, answers and reading order come from this one object. A style changes presentation only. |
| comparisonContract · readingOrder 1 | introduction |
| comparisonContract · readingOrder 2 | prerequisites |
| comparisonContract · readingOrder 3 | explanation |
| comparisonContract · readingOrder 4 | diagram |
| comparisonContract · readingOrder 5 | worked |
| comparisonContract · readingOrder 6 | exercise |
| comparisonContract · readingOrder 7 | answer |
| comparisonContract · readingOrder 8 | misconceptions |
| comparisonContract · readingOrder 9 | conclusion |
| comparisonContract · foldedContent | Only the independent exercise answer and its misconception correction start closed. Explanation, connected diagram, worked steps and failure-condition table remain public. |
| case · actor | A |
| case · requestId | R1 |
| case · notificationId | N1 |
| case · businessState | 확정 |
| case · notificationState | 미확인 |
| case · assumptions 1 | 같은 회차의 마지막 좌석 한 개를 A가 신청한다. 이 예에서는 취소나 다른 신청자의 변경을 추가하지 않는다. |
| case · assumptions 2 | R1은 A의 같은 회차·같은 신청 내용에 묶인 요청 ID다. 같은 ID에 다른 내용이 들어오면 기존 결과로 덮어쓰지 않고 충돌로 처리한다. |
| case · assumptions 3 | N1은 이 예약 결과를 알릴 작업의 ID다. 이 예의 알림 확인 기준은 외부 발송 서비스의 수락 응답을 기록한 상태이며, 이용자의 수신·열람까지 뜻하지 않는다. |
| introduction · heading | 좌석은 예약됐는데 알림 응답이 사라졌다 |
| introduction · paragraphs 1 | 마지막 좌석은 한 개다. A가 요청 R1로 신청했고, DB에서 예약을 확정한 COMMIT 결과도 확인했다. 그런데 확정 안내 N1을 외부 발송 서비스에 보낸 뒤 응답이 돌아오지 않았다. A가 같은 R1로 다시 요청하면 좌석을 한 번 더 배정해야 할까? |
| introduction · paragraphs 2 | 이 구간에서는 재고 0·업무 확정·알림 미확인이라는 세 상태를 도식, 표, 풀이, 결론까지 같은 뜻으로 유지한다. 응답 유실을 곧 실패로 바꾸거나, 업무 확정을 알림 전달 완료로 넓히지 않는 것이 목표다. |
| introduction · paragraphs 3 | 먼저 예약이 언제 확정되는지와 무엇을 아직 모르는지 구별하자. 그 근거가 있어야 그림의 화살표와 표의 상태를 같은 사실로 읽을 수 있다. |
| prerequisites · heading | 먼저 세 가지를 확인한다 |
| prerequisites · items 1 · term | DB 트랜잭션 |
| prerequisites · items 1 · meaning | 이 예에서는 좌석 차감, 예약·R1 결과, N1 작업 기록을 함께 확정한다. 롤백이 확인되면 이 변경들은 함께 취소된다. |
| prerequisites · items 2 · term | COMMIT 확인 |
| prerequisites · items 2 · meaning | DB 변경이 확정됐다는 근거다. 처리 응답이 없다는 사실만으로 COMMIT 성공이나 롤백을 판단할 수는 없다. |
| prerequisites · items 3 · term | 같은 요청의 재시도 |
| prerequisites · items 3 · meaning | A가 같은 내용의 R1을 다시 보내는 일이다. R1의 기록된 결과를 확인해 같은 업무 효과를 반복하지 않는다. ID 문자열만으로 그 성질이 자동 구현되지는 않는다. |
| prerequisites · checkQuestion | 응답이 오지 않았다는 사실만으로 DB 변경도 취소됐다고 말할 수 있을까? |
| prerequisites · checkExplanation | 그럴 수 없다. 응답을 받았는지와 DB에 무엇이 확정됐는지는 서로 다른 질문이다. 아래 사례는 DB의 COMMIT은 확인됐고, N1 응답만 유실된 상황이다. |
| explanation · heading | 예약 확정과 알림 처리는 경계가 다르다 |
| explanation · paragraphs 1 | 잘못된 DT-A는 신청 수신 → 확정 안내 → 잔여 확인 → 원장 저장 순서다. 저장이 실패하거나 좌석이 없으면 이미 보낸 성공 안내와 실제 예약이 달라진다. 이 예에서는 예약의 COMMIT을 확인한 뒤에 그 결과를 알린다. |
| explanation · paragraphs 2 | DB 안에서는 R1의 고유성을 집행하고 잔여가 있을 때만 1을 차감한다. 차감과 함께 A의 예약, R1의 처리 결과, 알릴 작업 N1을 같은 트랜잭션에 기록한다. 먼저 조회해서 R1이 없었다는 사실만으로 동시 중복을 막을 수는 없으므로 고유성·조건부 갱신·충돌 처리가 필요하다. |
| explanation · paragraphs 3 | N1 작업을 DB에 기록하는 것과 외부 발송 서비스를 호출하는 것은 다르다. 외부 발송은 이 DB 트랜잭션 밖에서 수행한다. 따라서 예약과 외부 메시지 전달이 항상 함께 성공하거나 함께 취소된다고 가정하지 않는다. |
| explanation · paragraphs 4 | N1 응답이 유실됐다면 서비스가 수락했지만 응답만 사라졌을 수도 있고, 수락하지 못한 채 응답이 없었을 수도 있다. 지금의 근거로는 둘을 구별할 수 없어 알림 미확인이라고 적는다. 명시적 실패 응답을 확인한 경우에는 실패로 기록하며, 이번 응답 유실과 구별한다. 미확인은 성공이나 실패의 다른 이름이 아니다. |
| explanation · paragraphs 5 | N1 이력과 발송 서비스의 기록을 같은 식별자로 맞춰 비교하는 일을 대사라고 한다. R1 조회는 예약의 근거를 확인하고, N1 대사는 외부 알림의 근거를 확인한다. 두 확인을 서로 대신 사용하지 않는다. |
| diagram · id | p9-seat-confirmation |
| diagram · title | R1의 예약 결과와 N1의 알림 상태를 분리한다 |
| diagram · description | A의 요청 R1은 DB에서 좌석과 예약·요청 결과·N1 작업을 함께 처리하며, 처리 결과에 따라 확정·롤백·미확인을 구분한다. 미확인이면 R1 결과와 진행 상태를 다시 확인하고, 예약 확정 뒤의 외부 N1 응답 유실은 알림 미확인으로 남긴다. 같은 R1 재시도는 기존 예약 결과로 합류하여 좌석을 다시 배정하지 않는다. |
| diagram · type | flowchart |
| diagram · semanticIntent | transaction outcome and external notification acknowledgment |
| diagram · semanticPatternSelection | No installed named semantic pattern exactly matches this behavior; use flowchart decision grammar directly, with an explicit DB transaction boundary and a separate external notification boundary. |
| diagram · primaryDirection | top-to-bottom |
| diagram · focalNodeIds 1 | confirmed |
| diagram · focalNodeIds 2 | notifyUnknown |
| diagram · boundaries 1 · id | atomic-db |
| diagram · boundaries 1 · label | 같은 DB 트랜잭션 |
| diagram · boundaries 1 · nodeIds 1 | tx |
| diagram · boundaries 1 · meaning | 좌석 차감·예약과 R1 결과·N1 작업 기록이 함께 확정되거나 함께 롤백된다. 결과 조회 자체와 외부 발송은 이 변경 트랜잭션에 넣지 않는다. |
| diagram · boundaries 2 · id | external-notification |
| diagram · boundaries 2 · label | DB 트랜잭션 밖 · 외부 알림 |
| diagram · boundaries 2 · nodeIds 1 | notification |
| diagram · boundaries 2 · nodeIds 2 | ack |
| diagram · boundaries 2 · nodeIds 3 | accepted |
| diagram · boundaries 2 · nodeIds 4 | notifyUnknown |
| diagram · boundaries 2 · meaning | N1 발송·응답 확인은 예약을 확정한 DB 변경과 별도다. |
| diagram · nodes 1 · id | lookup |
| diagram · nodes 1 · type | decision |
| diagram · nodes 1 · title | A의 R1 처리 결과 확인 |
| diagram · nodes 1 · body | 현재 결과와 진행 상태를 조회 |
| diagram · nodes 2 · id | tx |
| diagram · nodes 2 · type | process |
| diagram · nodes 2 · title | 좌석·예약·결과를 함께 기록 |
| diagram · nodes 2 · body | R1 고유성 · 잔여 1→0 예약·R1 결과·N1 작업 |
| diagram · nodes 3 · id | confirmed |
| diagram · nodes 3 · type | state |
| diagram · nodes 3 · title | 재고 0 · 업무 확정 |
| diagram · nodes 3 · body | R1의 예약 결과 확인 |
| diagram · nodes 4 · id | rollback |
| diagram · nodes 4 · type | end |
| diagram · nodes 4 · title | 롤백 확인 · 업무 미확정 |
| diagram · nodes 4 · body | 이 예의 재고는 1 · N1 작업 없음 |
| diagram · nodes 5 · id | commitResult |
| diagram · nodes 5 · type | decision |
| diagram · nodes 5 · title | DB 처리 결과는? |
| diagram · nodes 5 · body | 확정 · 롤백 · 미확인 |
| diagram · nodes 6 · id | notification |
| diagram · nodes 6 · type | process |
| diagram · nodes 6 · title | N1 통지 처리 |
| diagram · nodes 6 · body | 같은 N1 이력 확인 후 발송·대사 |
| diagram · nodes 7 · id | ack |
| diagram · nodes 7 · type | decision |
| diagram · nodes 7 · title | N1 수락 응답을 확인했나? |
| diagram · nodes 7 · body | 확인된 근거에 따라 기록 |
| diagram · nodes 8 · id | accepted |
| diagram · nodes 8 · type | end |
| diagram · nodes 8 · title | 알림 접수 확인 |
| diagram · nodes 8 · body | N1 수락 응답 기록 · 열람과 다름 |
| diagram · nodes 9 · id | notifyUnknown |
| diagram · nodes 9 · type | end |
| diagram · nodes 9 · title | 알림 미확인 |
| diagram · nodes 9 · body | 성공·실패를 단정하지 않음 |
| diagram · edges 1 · from | lookup |
| diagram · edges 1 · to | tx |
| diagram · edges 1 · label | 미처리 확인 |
| diagram · edges 2 · from | lookup |
| diagram · edges 2 · to | confirmed |
| diagram · edges 2 · label | 이미 확정 |
| diagram · edges 3 · from | lookup |
| diagram · edges 3 · to | lookup |
| diagram · edges 3 · label | 진행·미확인: 재조회 |
| diagram · edges 4 · from | tx |
| diagram · edges 4 · to | commitResult |
| diagram · edges 4 · label | 변경 처리 후 |
| diagram · edges 5 · from | commitResult |
| diagram · edges 5 · to | confirmed |
| diagram · edges 5 · label | COMMIT 확인 |
| diagram · edges 6 · from | commitResult |
| diagram · edges 6 · to | rollback |
| diagram · edges 6 · label | ROLLBACK 확인 |
| diagram · edges 7 · from | commitResult |
| diagram · edges 7 · to | lookup |
| diagram · edges 7 · label | 미확인: R1 재조회 |
| diagram · edges 8 · from | confirmed |
| diagram · edges 8 · to | notification |
| diagram · edges 8 · label | 업무와 구분 |
| diagram · edges 9 · from | notification |
| diagram · edges 9 · to | ack |
| diagram · edges 9 · label | 처리 결과 |
| diagram · edges 10 · from | ack |
| diagram · edges 10 · to | accepted |
| diagram · edges 10 · label | 예 |
| diagram · edges 11 · from | ack |
| diagram · edges 11 · to | notifyUnknown |
| diagram · edges 11 · label | 아니요 · 응답 유실 |
| diagram · caption | 화살표는 처리·확인 경로다. 예약의 DB 트랜잭션과 외부 알림의 경계를 분리한다. 알림 분기는 수락 응답 확인과 응답 유실을 비교하며, 명시적 실패 응답은 별도로 처리한다. 기존 R1 결과는 재배정 근거가 아니며, N1 이력 확인도 무조건 재발송한다는 뜻이 아니다. |
| diagram · readingInstructions 1 | 먼저 미처리 확인 → 같은 DB 트랜잭션 → DB 처리 결과 → COMMIT 확인 → 업무 확정 경로를 읽는다. 처리 결과의 결정점에서 확인된 롤백과 미확인 경로도 구분한다. |
| diagram · readingInstructions 2 | 다음으로 N1 응답의 예·아니요 분기를 읽는다. 응답 유실 경로의 끝은 업무 실패가 아니라 알림 미확인이다. |
| diagram · readingInstructions 3 | A가 같은 R1을 재시도하면 맨 위의 결과 조회부터 다시 읽는다. 이미 확정 분기는 좌석을 차감하는 트랜잭션을 거치지 않고 기존 업무 결과로 합류한다. 이 조회는 N1의 외부 결과를 확인한 근거가 아니다. |
| diagram · readingInstructions 4 | DB 처리 결과의 미확인 경로는 R1 결과 조회로 돌아온다. 조회에서도 진행·미확인이면 확인 후 다시 조회하며 그 상태를 유지한다. 단순히 검색 결과가 없다는 이유로 롤백이나 미처리를 확정하지 않는다. |
| worked · heading | 같은 사건을 단계별로 풀어 본다 |
| worked · steps 1 · title | 예약의 확정 근거를 먼저 찾는다 |
| worked · steps 1 · paragraphs 1 | A의 R1로 좌석을 차감하고 예약·R1 결과·N1 작업을 함께 기록했다. 이 사례에서는 COMMIT 결과를 확인했으므로 업무는 확정이다. 응답 유실이라는 말이 있어도 어느 응답인지 구별해야 한다. 지금 유실된 것은 뒤의 N1 응답이다. |
| worked · steps 2 · title | 재고 계산과 업무 상태를 연결한다 |
| worked · steps 2 · paragraphs 1 | 마지막 좌석 1개에서 A의 확정 예약 1개를 차감했으므로 1−1=0이다. 재고 0은 같은 좌석을 새로 배정할 수 없다는 뜻이고, 업무 확정은 A의 예약이 DB에 확정돼 있다는 뜻이다. 두 표현은 같은 확정 결과를 수량과 업무 상태로 설명한다. |
| worked · steps 3 · title | N1 응답 유실의 의미를 한정한다 |
| worked · steps 3 · paragraphs 1 | N1 작업이 DB에 있다는 사실은 발송 서비스가 수락했다는 근거가 아니다. 반대로 N1 응답을 받지 못했다는 사실도 예약의 롤백 근거가 아니다. 현재는 재고 0·업무 확정·알림 미확인으로 적고, N1의 발송 이력과 외부에서 확인할 수 있는 결과를 대조한다. |
| worked · steps 4 · title | 같은 R1 재시도를 기존 결과로 돌려준다 |
| worked · steps 4 · paragraphs 1 | A가 같은 신청 내용으로 R1을 다시 보내면 먼저 그 요청의 기록된 결과와 현재 상태를 확인한다. 이미 확정된 예약이 있으므로 좌석을 다시 차감하거나 새 예약을 만들지 않는다. A에게는 예약 확정과 알림 미확인을 구분해 반환한다. |
| worked · steps 4 · paragraphs 2 | 알림 처리에서는 같은 N1의 이력을 확인한다. 미확인 결과를 대사하고 재전송 여부는 발송 서비스의 중복 처리 조건과 정책에 따라 정한다. N1이라는 ID만으로 외부 서비스의 중복 발송이 방지되거나 메시지가 정확히 한 번 도착한다고 약속하지 않는다. |
| worked · steps 5 · title | 도식·표·본문·결론을 같은 근거로 맞춘다 |
| worked · steps 5 · paragraphs 1 | 도식에서는 외부 알림을 DB 경계 밖에 두고, 표에서는 업무 확정과 알림 미확인을 서로 다른 항목으로 적는다. 본문은 그 이유를 COMMIT 확인과 N1 응답 유실로 설명한다. 결론도 예약은 확정됐으며 알림 결과는 추가 확인이 필요하다고 한정한다. |
| worked · stateTable · caption | N1 응답 유실 직후의 세 상태 |
| worked · stateTable · columns 1 | 항목 |
| worked · stateTable · columns 2 | 현재 상태 |
| worked · stateTable · columns 3 | 확인한 근거 |
| worked · stateTable · columns 4 | 이 상태로 말할 수 없는 것 |
| worked · stateTable · rows 1 1 | 재고 |
| worked · stateTable · rows 1 2 | 0 |
| worked · stateTable · rows 1 3 | 좌석 1개에서 확정 예약 1개를 차감한 COMMIT |
| worked · stateTable · rows 1 4 | 알림이 전달됐다는 보장 |
| worked · stateTable · rows 2 1 | 업무 |
| worked · stateTable · rows 2 2 | 확정 |
| worked · stateTable · rows 2 3 | A의 예약과 R1 결과가 DB에 확정됨 |
| worked · stateTable · rows 2 4 | 알림 미확인이므로 예약도 취소됐다는 판단 |
| worked · stateTable · rows 3 1 | 알림 |
| worked · stateTable · rows 3 2 | 미확인 |
| worked · stateTable · rows 3 3 | N1 작업은 있으나 수락 응답을 확인하지 못함 |
| worked · stateTable · rows 3 4 | 발송 성공 또는 실패의 단정 |
| worked · failureTable · caption | 어느 결과를 확인했는지에 따라 다음 행동이 달라진다 |
| worked · failureTable · columns 1 | 상황과 근거 |
| worked · failureTable · columns 2 | 판단 |
| worked · failureTable · columns 3 | 다음 행동 |
| worked · failureTable · rows 1 1 | COMMIT 확인 뒤 N1 응답만 유실 |
| worked · failureTable · rows 1 2 | 재고 0·업무 확정·알림 미확인 |
| worked · failureTable · rows 1 3 | R1의 기존 예약을 반환하고 N1 이력을 대사한다. 좌석을 복구하거나 다시 배정하지 않는다. |
| worked · failureTable · rows 2 1 | DB 변경의 ROLLBACK 확인 |
| worked · failureTable · rows 2 2 | 이 예에서는 재고 1·업무 미확정·N1 작업 없음 |
| worked · failureTable · rows 2 3 | 확정 안내를 보내지 않는다. 오류·권한·조건을 확인한 뒤 같은 R1의 재시도 조건을 정한다. |
| worked · failureTable · rows 3 1 | COMMIT 요청 뒤 응답 유실, 결과도 아직 미확인 |
| worked · failureTable · rows 3 2 | 업무 확정이나 롤백을 아직 단정할 수 없음 |
| worked · failureTable · rows 3 3 | R1의 처리 결과와 진행 상태를 다시 확인한다. 알림부터 보내거나 새 요청으로 재배정하지 않는다. |
| exercise · heading | 독립 연습: 화면의 응답 없음으로 복구를 결정해도 될까? |
| exercise · scenario | 위 사례에서 DB에는 A의 R1 예약 확정과 N1 작업이 기록돼 있다. N1의 수락 응답은 아직 확인되지 않는다. A는 같은 내용의 R1을 다시 보냈다. 화면에 응답 없음이 표시되자, 좌석을 1로 되돌리고 새 요청으로 다시 배정하자는 의견이 나왔다. |
| exercise · instructions | 답안을 열기 전에 아래 네 가지를 짧게 작성한다. 상태 이름만 적지 말고, 각 판단의 근거와 먼저 확인할 기록을 붙인다. |
| exercise · questions 1 · text | 재고·업무·알림의 현재 상태를 세 줄로 쓰고, 각각 확인된 사실과 미확인 사실을 구별하라. |
| exercise · questions 2 · text | 좌석을 복구해 새 요청으로 다시 배정하자는 의견을 판단하라. 같은 R1 재시도에서 어떤 기록을 먼저 확인하고 A에게 무엇을 반환할지 쓰라. |
| exercise · questions 3 · text | 나중에 N1의 수락 응답을 확인했다. 세 상태 중 무엇을 바꿀 수 있으며, 이용자가 메시지를 읽었다고까지 말할 수 있는가? 같은 근거를 유지하는 결론을 두 문장으로 쓰라. |
| exercise · questions 4 · text | 조건 하나를 바꿔 보자. N1 응답뿐 아니라 COMMIT 응답도 유실됐고, R1의 확정 결과도 아직 확인하지 못했다면 무엇을 미확인으로 남겨야 하는가? 기존 사례와 다른 점 및 다음 확인을 쓰라. |
| answer · summary | 독립 연습의 답안과 오답 교정 보기 |
| answer · heading | 근거를 유지한 답안 |
| answer · items 1 · paragraphs 1 | 재고는 0, 업무는 확정, 알림은 미확인이다. 앞의 두 상태는 A의 R1 예약과 차감의 COMMIT으로 확인했다. N1 작업의 존재는 확인했지만 외부 수락 응답은 확인하지 못했다. 알림 미확인을 업무 미확정으로 옮기지 않는다. |
| answer · items 2 · paragraphs 1 | 그 의견은 부적절하다. 알림 응답 유실은 DB 예약을 되돌릴 근거가 아니므로 재고를 1로 복구하지 않는다. A·같은 회차·같은 신청 내용에 묶인 R1의 기존 결과와 현재 예약 상태를 확인해 예약 확정·알림 미확인을 반환한다. 새 배정 대신 N1의 이력을 대사한다. |
| answer · items 3 · paragraphs 1 | 재고 0과 업무 확정은 유지하고 알림을 접수 확인으로 바꿀 수 있다. 발송 서비스의 수락 응답은 이용자의 수신·열람 증거와 다르다. |
| answer · items 3 · paragraphs 2 | 결론 예: A의 R1 예약은 확정돼 재고가 0이며, N1은 외부 발송 서비스의 접수를 확인했다. 이용자의 실제 수신·열람은 이 근거만으로 확인할 수 없다. |
| answer · items 4 · paragraphs 1 | 이제 업무의 커밋 결과도 미확인이다. 원래 사례는 예약 COMMIT을 확인했지만, 바뀐 사례에는 그 근거가 없으므로 업무 확정이나 롤백, 현재 재고를 단정하지 않는다. R1의 DB 처리 결과와 진행 상태를 재조회해 권위 있는 결과를 확인하며, 그 전에 새 요청으로 배정하거나 확정 안내를 보내지 않는다. 조회 결과가 없다는 사실만으로 롤백으로 확정하지도 않는다. |
| misconceptions · heading | 틀린 답은 상태를 바꾼 지점부터 고친다 |
| misconceptions · items 1 · wrong | 응답이 없으니 예약도 실패했고 좌석을 복구한다. |
| misconceptions · items 1 · correction | 어느 응답이 없는지 확인한다. N1 응답 유실은 확인된 예약 COMMIT을 취소하지 않는다. 업무와 알림을 별도 상태로 돌려놓는다. |
| misconceptions · items 2 · wrong | R1이 같으니 모든 처리가 정확히 한 번이고 알림도 한 번만 도착한다. |
| misconceptions · items 2 · correction | R1의 DB 고유성과 결과 재사용은 예약의 반복 효과를 막는 장치다. 외부 N1 발송의 중복 처리 조건과 실제 수신·열람은 별도로 확인해야 한다. |
| misconceptions · items 3 · wrong | COMMIT 응답이 없고 R1이 조회되지 않으니 롤백됐다. |
| misconceptions · items 3 · correction | 응답·조회 결과만으로 아직 진행 중인 처리나 확정 결과를 단정하지 않는다. R1 결과와 진행 상태를 확인하고, 알 수 없는 동안은 커밋 결과 미확인을 유지한다. |
| conclusion · heading | 같은 사실을 끝까지 유지한다 |
| conclusion · paragraphs 1 | 이 사례의 결론은 재고 0·업무 확정·알림 미확인이다. 예약은 DB의 확인된 결과로 설명하고, 알림은 외부 N1의 확인 근거로 설명한다. 같은 R1 재시도는 기존 예약 결과로 돌아가며, 남은 확인은 N1의 처리 결과다. 그림·표·본문·결론 어느 곳에서도 그 범위를 넓히지 않는다. |
| 관찰·상황 | 값·보충 정보 | 변화·이유 |
|---|---|---|
| R1 COMMIT 확인 A의 좌석·예약·R1 결과·N1 작업을 함께 기록한 COMMIT을 확인했다. |
|
|
| 1−1=0 대조 마지막 좌석 1에서 예약 1을 차감한 같은 결과를 수량으로 확인한다. |
|
|
| N1 응답 미확인 발송 수락 응답을 못 받아도 예약 롤백 근거가 되지 않는다. |
|
|
| 같은 R1 재시도 같은 내용의 R1은 기존 결과와 현재 상태를 반환하고 새 배정을 만들지 않는다. |
|
|
| 세 상태 유지 도식·표·본문·결론 모두 재고 0·업무 확정·알림 미확인을 유지한다. |
|
|
심화: 동시 요청·대기·취소의 추가 조건
학습용 도식 DT-A는 신청 수신→확정 안내→잔여 확인→원장 저장으로 되어 있다. 이 구조는 실제 배정이 확정되기 전에 이용자에게 성공을 약속한다. 원장 저장에 실패하거나 다른 요청이 마지막 자리를 사용하면 안내와 실제 상태가 달라진다.
아래 상자는 같은 회차의 한정된 자리를 배정하는 데이터베이스(DB, Database)의 거래 경계다. 화살표는 처리 결과의 전달이며, 실제 구현 시험의 결과가 아니다. 서로 다른 대여시간의 겹침은 뒤 M01에서 별도로 다룬다.
요청 ID(Identifier, 식별자)는 요청을 구별하는 값이다. ID만 적는 대신 누구의 어떤 업무 요청인지와 같은 ID에 다른 내용이 들어왔을 때의 처리를 함께 설명한다.
원장에 배정이 확정됐다는 사실과 외부 메시지가 전달됐다는 사실은 분리한다. 외부 통지가 실패했다고 같은 자리를 다시 배정하지 않는다. 그림 밖 설명에는 같은 ID의 다른 내용, 같은 사람의 새 ID 중복, 취소 재시도와 권한 확인을 적어야 한다. 상자 하나에 ‘정합성 보장’이라고 쓰는 것으로 그 조건이 자동 구현되지는 않는다.
같은 요청이 없다는 사전 조회만으로 동시 중복을 막지는 못한다. 두 처리가 모두 ‘없음’을 읽을 수 있으므로 요청자·업무 범위에 묶인 요청 ID의 고유성을 DB에서 집행하고 충돌 처리도 정한다. 같은 ID의 다른 내용을 기존 결과로 덮어쓰지 않으며, 충돌로 중단된 거래는 부분 효과 없이 정리한 뒤 기록된 결과를 다시 확인한다. 고유성·격리수준·오류 후 재조회는 선택한 DB의 실제 동작과 함께 검증한다.1
자리 배정의 조건부 갱신 결과가 0행이라는 사실은 DB 장애와 다르다. 대상·권한·상태를 확인한 결과 자리가 없는 경우라면, 이 예에서는 자리를 차감하지 않고 대기라는 정상 업무 결과를 기록할 수 있다. 반대로 대상이 없거나 권한이 없거나 저장 오류가 난 경우까지 전부 대기로 바꾸지 않는다.
표도 같은 구조를 따라야 한다. 그림은 외부 통지를 거래 밖에 두는데 표가 ‘배정과 문자 발송은 항상 원자적’이라고 쓰면 충돌이다. 또한 업무 상태와 통지 상태는 일렬로 이어지는 하나의 상태가 아니다. 배정은 취소됐지만 과거 확정 통지는 이미 전달됐을 수 있다. 그 조합과 정정 상태를 함께 표현한다.
발송 전에 현재 결정판본을 확인하면 이미 오래된 작업을 거르는 데 도움이 된다. 그러나 그 확인 직후 취소가 확정되거나 외부 전달 순서가 바뀔 수 있으므로 옛 안내의 늦은 도착을 전부 방지한다고 약속하지 않는다. 통지에 해당 결정의 판본·기준시점과 현재 조회 경로를 연결하고, 실제 전달 이력과 취소·정정 안내를 대사한다. 이 경계는 공공 디지털서비스 전환과 같다.
3. 계산의 단위를 도식과 결론까지 유지한다
회복성 그림의 시작점은 중단시각인데 계산은 사고 선언부터 시작하면 같은 사건을 재지 않은 것이다. 단위비용 표의 분모가 성공한 업무 수인데 결론은 전체 시도 수당 비용이라면 다른 지표를 설명한 것이다. 숫자를 다시 넣기 전에 분모·시간·성공의 의미를 적는다.
오류를 줄이는 순서는 원수→정의한 식→단위→계산값→그 값으로 알 수 있는 것→알 수 없는 것이다. 반올림은 마지막에 하고, 예를 들어 69.27%를 계산한 뒤 대략 70%라는 표현으로 정한 경계와 비교하지 않는다. 정확한 경계 판단에는 반올림 전 또는 충분한 자릿수의 값을 사용한다.
계산에 없는 사실은 결론에서 추가하지 않는다. 대기 해소가 20분이라고 이용자의 실제 만족이 20% 높아졌다고 쓸 수 없다. 예상 용량이 요구를 넘었다고 실제 지연·고장·권한이 모두 검증됐다고 하지 않는다. 산술과 실제 시스템 증거를 구별한다.
이 원리를 답안으로 옮길 때는 같은 대상과 완료 기준을 먼저 적고, 거래·통지의 경계와 조건을 보여 준 뒤 예외·확인 방법·결론을 연결한다. 제품 이름을 더 쓰는 것보다 앞뒤 표현이 같은 사실을 말하는지 확인하는 것이 중요하다.
4. 자체 10점 문제와 완성 답안
도식·표·계산·결론을 결합할 때 정합성을 확인하는 방법을 DT-A로 설명하시오.
답안을 열기 전에 같은 대상·시점·권한·완료 기준을 짚고, DT-A에서 확정 안내를 어느 경계 뒤에 두어야 하는지 자신의 문장으로 설명한다. 막히면 표현의 역할과 거래 경계를 다시 읽는다.
풀이 방향과 10점 완성 답안 보기
목차: 같은 대상·상태 → 도식과 표의 역할 → 계산 단위 → 예외·결론 대조.
상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.
양방향 연결은 처리 순서가 아니라 표현 사이의 대조를 뜻한다. 다섯 표현에서 대상·시점·권한·완료 기준이 같아야 한다.
완성 답안
도식은 역할과 흐름, 표는 공통축의 조건과 비교, 계산은 원리의 적용, 본문은 이유·예외, 결론은 선택·한계를 맡는다. 각 표현이 같은 대상·시점·권한·완료 기준을 사용하는지 대조해야 한다. 화살표의 데이터 이동·승인·시간 의미를 혼용하지 않는다.
DT-A의 확정 안내가 잔여 확인·원장 저장보다 앞서는 구조는 실제 배정 전 성공을 약속하므로 잘못이다. 요청의 고유성을 집행하고 잔여 조건부 갱신·배정 또는 대기·요청 결과·알릴 작업을 같은 DB 경계에서 확정한다. 저장 결과가 미확인이면 재조회하고, 외부 통지는 별도 전달·미확인·정정으로 연결한다.
비교표와 본문도 같은 거래 경계를 유지한다. 외부 발송까지 자동 원자적이라고 쓰거나 통지 실패를 좌석 재배정 근거로 삼지 않는다. 과거 확정 통지와 현재 취소 상태가 함께 존재할 수 있으므로 판본·실제 전달·현재 조회·정정을 연결한다. 결론은 확인된 설계와 조건 안에서만 적고, 실제 구현·시험을 하지 않았으면 보장 성능으로 확대하지 않는다.
5. 자체 25점 문제와 완성 설계 답안
DT-A의 신청·확정·통지 표현을 일관된 답안으로 재설계하시오. 도식, 조건표, 예외와 확인 방법, 결론을 포함하시오.
풀이를 열기 전에 도식·조건표·예외·확인 방법·결론의 다섯 칸을 먼저 작성한다. 각 칸이 같은 요청과 완료 기준을 쓰는지 점검한 뒤 아래 예와 비교한다.
풀이 방향과 25점 완성 설계 답안 보기
목차: 원장·요청 → 거래 경계 → 통지 분리 → 조건표·예외 → 검증·결론.
상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.
오른쪽 위는 원장이 확정한 업무 결과, 아래는 커밋 뒤 따로 확인할 외부 통지다. 거래 밖의 발송 응답을 원장 확정의 증거로 바꾸지 않는다.
원래 가로 그림에서 오른쪽 위로 설명한 확정 업무 결과는 모바일의 위쪽 DB 경계에, 아래쪽 외부 통지·전달 상태는 아래쪽 외부 경계에 배치했습니다. 업무 결과와 통지 결과는 독립한 두 경로입니다.
완성 설계 답안
DT-G1은 신청의 접수와 배정 확정, 외부 통지 상태를 구별하는 구조다. 확정의 기준은 서버 원장이고 단말의 전송·메시지 수신이 이를 대신하지 않는다. 신청자는 자기 요청을, 직원은 승인된 담당 범위의 보조 업무를 처리한다. 초기 범위는 같은 회차의 접수·배정·조회·취소·안내로 두며 다른 판단 기능을 임의로 추가하지 않는다.
도식은 요청자·요청 ID·내용·권한 확인 뒤 하나의 DB 경계에 요청 고유성·잔여 조건부 갱신·배정 또는 대기·요청 결과·알릴 작업을 둔다. 동시 중복은 사전 조회만이 아니라 고유성·충돌 처리로 집행한다. 커밋 후 업무 상태를 확인하고 별도 통지 처리로 전달·실패·미확인·정정을 대사한다. 외부 효과가 원장과 자동으로 같은 거래에 들어가는 그림을 그리지 않는다.
| 조건 | 실제 처리 | 확인할 결과 |
|---|---|---|
| 마지막 자리 동시 요청 | 현재 조건부 갱신과 배정을 같은 경계에서 처리 | 확정 1건·나머지 대기, 정원 초과 없음 |
| 같은 요청 ID·같은 내용의 동시 재전송 | DB 고유성 충돌을 처리한 뒤 기록된 결과 조회 | 새 배정 효과 없음, 과거 결과와 현재 상태 구별 |
| 같은 ID·다른 내용 | 충돌 처리 | 원래 요청 결과 보존 |
| 이미 취소한 요청 재전송 | 현재 상태와 해당 취소 결과 조회 | 자리 두 번 반환·대여 부활 없음 |
| 외부 응답 소실 | 통지 ID와 실제 결과 대사 | 성공·실패·미확인 분리 |
| 발송판본 확인 직후 취소·전달 역전 | 현재 원장·판본별 이력·취소와 정정 안내 연결 | 옛 안내를 현재 확정으로 오인하지 않게 후속 조치 |
이 표의 조건은 본문·도식의 사건 식별자와 동일하게 유지한다. 새 ID의 같은 업무에는 별도의 업무 고유조건을 적용하며, 오류가 나면 잔여 차감만 남지 않게 거래를 처리한다. 자리가 없는 정상 결과와 DB 오류·대상 없음·권한 없음은 구별한다. 취소는 허용 상태에서 실제 한 번 전이된 경우에만 자원을 반환한다.
발송 전 결정판본 확인은 필요하지만 그 직후 취소되는 경쟁까지 없애지는 못한다. 이미 전달했거나 전달 여부를 모르는 옛 안내는 기록을 지우지 않고 현재 상태 조회·취소 안내·정정으로 관리한다. 가정하지 않은 DBMS·통지업체의 보장을 임의로 추가하지 않는다.
업무·개발/데이터·운영·지원 담당은 규칙, 거래·권한, 전달·장애, 정정·이의를 맡는다. 각 예외를 실제 시험에서 확인하고 원장·요청·통지·최종 자원 수를 대사하도록 계획한다. 도식의 보기 좋은 모양이 아니라 요구가 어떤 통제와 결과로 연결되는지 확인한다. 결론은 이 설계가 지키려는 경계와 검증 필요를 밝히며, 외부 발송까지 완벽히 한 번이라고 선언하지 않는다.
6. 자체 실전 모의 M-1: 여섯 문제 중 네 문제 선택
이 모의는 100분에 6문제 중 4문제를 선택해 각 25점의 학습문제로 작성하는 자체 연습 설정이다. 실제 국가시험의 회차·출제예측·시행 공고를 뜻하지 않는다. 처음에는 시간 제한 없이 여섯 문제를 모두 공부해도 되고, 다시 연습할 때 네 문제를 골라 제한시간을 적용할 수 있다.
배분 예는 선택·전체 계획 5분, 네 답안 각각 21분으로 84분, 최종 점검 11분이다. 합계 100분이다. 21분 안에서도 요구 확인·골격·작성·점검을 나눈다. 한 문제에 배정한 시간을 초과하면 나머지 계획이 달라지므로 실제 사용시간을 기록한다. 이 배분이 모든 사람의 손글씨 속도에 맞는다고 보증하지 않는다.
문제의 수치는 서로 별도 사례다. 선택하지 않은 문제의 해설도 뒤에서 모두 제공한다. 정답을 먼저 본 경우에는 미리 보지 않은 시험처럼 성능을 보고하지 말고 학습 후 재연습으로 기록한다. 계산·정의·판단의 근거는 앞 본문 안에 있으며 추가로 가정한 조건은 답안에 표시한다.
M01. 모바일·공공서비스의 중복과 상태
장비는 1개이며 같은 장비의 이용 시간이 겹치는 대여를 함께 확정할 수 없다. 웹·모바일·창구가 같은 서버 원장을 쓰며 단말은 연결이 끊길 수 있다. A는 10:00~11:00, B는 10:30~11:30을 동시에 요청한다. 시각은 같은 날·시간 기준이고 구간은 시작 포함·끝 제외이며 별도 정리시간은 없다. A는 응답을 받지 못해 같은 요청 ID로 재전송한다. 대여 확정 뒤 외부 안내 응답도 소실되거나 발송판본 확인 직후 취소가 확정될 수 있다. 오프라인 사전 할당은 없다.
가. 입력·접수·확정·통지를 구별하시오. 나. 동시 요청·재전송·겹치는 기간·취소를 처리할 경계를 설계하시오. 다. 권한·도움 채널과 장애 시 운영을 제시하시오. 라. 검증 시나리오와 최종 상태를 설명하시오.
M02. RAG의 정확성·권한·사람 감독
평가 질문 100개 중 80개는 접근 가능한 자료에 관한 질문이고 20개는 요청자에게 권한이 없다. 접근 가능한 80개 중 60개에는 충분한 답이 있고 20개에는 없다. 답 가능한 60개에서 근거를 찾은 48개에 응답해 42개는 정확하고 6개는 틀렸다. 답이 없는 20개와 검색누락 12개에는 보류했다. 권한 없는 20개에서는 1개가 금지 자료를 노출했다. 나머지 19개의 구체적인 응답·거부 품질은 이 자료에 제시하지 않는다.
가. 검색·생성·전체의 분모를 구별하여 계산하시오. 나. 도입 확대 여부를 판단하시오. 다. 원문·권한·모델·파생자료의 관리를 설계하시오. 라. 별도 작업량 가정으로 허용집단의 초안 48건에 건당 3분 검토가 필요하고 가용시간이 120분일 때 감독의 제약과 대안을 제시하시오.
M03. 장애·침해 의심과 복구·정상화
서비스가 15:00에 중단됐다. 마지막 검증된 일관된 복구점은 14:57이다. 서버는 15:25에 켜졌지만 필요한 업무·권한·정합성이 확인되어 재개된 때는 15:42다. 목표는 RPO 5분·RTO 30분이며 RTO는 중단부터 정한 업무 재개까지다. 관리자 계정 오용이 의심되지만 영향 범위는 미확인이다. 재개 때 대기 480건이 있고 신규 12건/분·처리 36건/분이 일정하다. 같은 단위의 유효 업무를 처리하며 추가 중단·재작업은 없다고 가정한다.
가. 두 복구목표를 판정하시오. 나. 침해 의심·복제·백업·재개 승인을 연결하시오. 다. 대기 정상화 시각과 대체접수 대사를 설명하시오. 라. 안내·권리·소통과 후속 검증을 제시하시오.
M04. 스마트팩토리의 생산성·품질·보전
한 품목의 계획생산시간 480분 중 정지 60분, 가동 420분이다. 이상사이클은 0.5분/개, 총생산 700개, 최초양품 665개다. 별도 안정된 정규 공정의 길이 규격은 49~51mm, 평균 50.4mm, 표준편차 0.2mm라고 가정한다. 관리자는 생산수를 늘리기 위해 원격으로 속도를 즉시 올리자고 제안한다.
가. OEE와 손실을 계산하시오. 나. Cp·Cpk와 중심 이동의 의미를 설명하시오. 다. 트윈·예지보전을 활용하는 개선안을 설계하시오. 라. OT보안·품질·안전·제한 시험과 중단 기준을 포함하시오.
M05. 클라우드 단위경제성과 공유책임
같은 길이의 두 비교기간에 총비용은 2백만 원에서 2.4백만 원으로, 성공한 동일 업무의 수는 8,000건에서 12,000건으로 바뀌었다. 비용에는 같은 범위의 반복 운영비를 포함하고 일회성 이관비는 제외한다. 새 환경은 계약상 공급자가 물리설비·운영체제·기반 런타임을 맡고, 이용기관이 응용코드·권한설정·자료·업무운영을 맡는 관리형 플랫폼이라고 가정한다. 자료와 복구에 필요한 설정을 다른 환경으로 옮길 수 있어야 한다.
가. 총비용과 성공 업무당 비용의 변화를 계산하시오. 나. 공유책임을 사례에 대입하시오. 다. 회복성·접근·자료·종료를 포함한 운영안을 설계하시오. 라. 도입 효과의 한계와 추가 검증을 제시하시오.
M06. 장애 시 용량과 네트워크 설계
정상 첨두 수요는 360Mb/s다. 같은 역할의 두 링크가 각각 400Mb/s이고, 정상에는 둘 다 사용할 수 있지만 한 링크 고장 뒤에도 같은 수요를 처리해야 한다. 요구는 ‘장애 후 남은 링크 용량의 25%를 사용하지 않는 여유로 남긴다’이다. 수요와 용량의 단위·관찰 범위는 같으며 부가량은 이 산술에서 제외한다. 다른 공통 전원·사업자·경로 의존성은 아직 조사하지 않았다.
가. 정상 합계와 장애 시 잔존 용량을 구별하시오. 나. 필요한 용량과 현재 설계의 적합성을 계산하시오. 다. 상호운용·QoS·보안·독립성을 포함한 개선안을 제시하시오. 라. 실제 검증과 결론의 한계를 설명하시오.
7. 여섯 문제의 완성 답안과 해설
아래 답은 앞 원리로 구성한 하나의 타당한 예다. 다른 안도 같은 사실·제약·근거를 만족하고 대가와 확인 방법을 설명하면 비교할 수 있다. 제품 이름이나 그림 모양을 그대로 복사하는 것이 학습 목표는 아니다.
M01 완성 답안과 해설 보기
M01 완성 답안 — 한 원장과 서로 다른 완료
M01의 기준은 서버 원장의 장비·시간구간별 배정이다. 단말의 입력 저장은 접수·확정과 다르며, 오프라인 사전 할당이 없으므로 단말 잔여만 보고 즉시 확정하지 않는다. 연결이 없으면 임시 요청 ID·내용을 보존한 전송대기로 표시한다. 서버가 저장한 접수번호·기록된 요청 결과·현재 대여 상태와 외부 통지 상태는 각각 조회하게 한다. 창구 보조도 승인된 직원 권한으로 같은 원장을 사용한다.
서버는 요청자·업무 범위·요청 ID와 내용을 확인하고, 같은 ID의 동시 처리를 DB의 고유성·충돌 처리로 통제한다. 같은 ID·같은 내용은 부분 효과 없이 기록된 결과를 다시 확인하고, 다른 내용은 충돌로 처리한다. 과거의 확정 응답을 현재 상태인 것처럼 재표시하거나 이미 취소한 대여를 부활시키지 않는다. 새 ID로 같은 업무를 반복하면 별도의 업무 고유조건을 적용한다.
A의 [10:00,11:00)과 B의 [10:30,11:30)은 30분이 겹친다. 정확히 같은 시작·끝만 금지하는 고유조건은 이 충돌을 막지 못한다. 이 답안은 앞 핵심정의에서 판단축까지의 학습용 설계 AX-G1처럼 모든 배정·취소 경로가 항상 존재하는 장비 기준 행을 먼저 잠그고, 기다린 뒤 현재 확정 구간을 다시 조회하여 겹침을 판단하는 안을 택한다. 실제 격리수준·조회 시점에서 새로 확정된 구간을 보는지 확인하고, 실패·직렬화 충돌에는 거래 전체의 재시도 규칙을 둔다. 지원되는 DB의 구간 배타 제약도 대안이다.2
PostgreSQL 18의 Read Committed에서는 조회 명령마다 시작 시점의 커밋 상태를 읽는다. 따라서 이 설계에서는 장비 행 잠금의 대기를 마친 뒤 별도 조회 명령으로 확정 구간을 확인하는지 살핀다. 같은 잠금 명령 안에서 읽는 다른 행까지 자동으로 최신화된다고 가정하지 않는다. Repeatable Read의 이미 고정된 조회 시점도 잠금만으로 새로 바뀌지 않는다. 이 구분은 선택한 DB의 실제 격리수준과 조회 순서를 확인하기 위한 것이며, 여기서 동시 실행을 시험했다는 뜻은 아니다.
대여·요청 결과·알릴 작업은 같은 DB 거래로 확정하고 사람 승인이나 외부 발송을 기다리며 잠금을 잡아 두지 않는다. 겹침이 없을 때만 확정하며, 충돌한 요청은 이 사례의 업무 규칙에 따른 대기 또는 거절로 기록한다. A가 항상 승자라고 가정하지 않는다. 조건 미충족이라는 정상 결과와 DB 장애·권한 없음은 구별한다. 취소는 허용된 현재 배정에서 실제 한 번 상태가 전이된 때만 점유를 해제하고, 재전송은 결과 조회로 처리한다.
외부 통지는 통지 ID·해당 결정판본·제공자의 실제 결과를 대사한다. 응답 소실은 전달 실패로 확정하지 않는다. 발송 직전 판본 확인으로 이미 취소된 작업을 걸러도, 확인 직후 취소나 전달 순서 역전은 남을 수 있다. 따라서 현재 원장 조회·판본별 이력·취소 및 정정 안내를 연결한다. 주민은 자기 요청만, 직원은 승인된 업무만 접근하며 필요한 개인정보·기록의 범위를 제한한다.
검증에는 같은 ID의 동시 재시도, 다른 내용 재사용, 새 ID 중복, 부분적으로 겹치는 구간, 서로 맞닿은 [10:00,11:00)·[11:00,12:00), 앱 재시작, 취소 경합, 권한 없는 조회와 발송 확인 직후 취소를 포함한다. 두 요청의 겹치는 시간에는 동시 확정 수가 1을 넘지 않아야 한다. 확정 취소 뒤의 가용 여부는 그 구간의 다른 확정 대여까지 다시 판단한다. 다른 대여가 없다는 조건에서만 해당 구간이 비게 되며, 하루 전체에 단일 잔여값 0·1을 무조건 적용하지 않는다.
해설·복습: 요청 ID의 중복, 같은 업무의 반복, 물리 자원의 시간 겹침은 서로 다른 조건이다. 공공 디지털서비스 전환, 핵심정의에서 판단축까지의 구간 설명을 다시 읽는다. 외부 통지를 같은 거래에 넣었다거나 옛 안내의 도착을 항상 막는다고 썼으면 정정·현재 조회까지 보완한다.
M02 완성 답안과 해설 보기
M02 완성 답안 — 더 많은 정답과 필수 경계
M02는 100개 질문을 접근 가능 80·권한 없음 20으로 나누고, 접근 가능한 집단 안에서도 답 가능 60·답 없음 20을 구별한다. 검색 성공은 48/60=80%, 검색한 근거로 응답한 집단의 정확성은 42/48=87.5%다. 답 가능한 집단의 정답은 42/60=70%, 전체 질문에서 허용된 정답 제공은 42/100=42%다. 적절한 보류·거부는 정답 생성 수와 다른 평가축이므로 나머지 58개를 모두 오류로 세지 않는다. 미제시된 권한 없는 19개의 응답 품질도 자동으로 통과 처리하지 않는다.
권한 없는 20개 중 1개에서 금지 자료가 노출됐다. 해당 시험의 위반비율 5%와 전체 1%는 같은 사건의 다른 분모이지만 작은 전체비율로 피해나 필수 조건 위반을 없앨 수 없다. 이 사례의 확대는 보류하고 원문·색인·검색 필터·모델 문맥·도구·로그에서 노출된 범위와 원인을 확인한다. 다른 질문의 좋은 점수로 상쇄하지 않는다.
자료 담당은 원문 ID·판본·적용일·이용근거·권한을 조각·색인·캐시·평가자료와 연결한다. 삭제·정정 때 파생자료와 이미 안내한 내용의 영향을 추적한다. 검색 색인 삭제를 학습 내용의 완전 제거와 동일시하지 않는다. 모델·임베딩·프롬프트·도구·권한·평가의 릴리스를 관리하고 외부 문서의 지시를 사용자 승인으로 취급하지 않는다.
사람 감독의 별도 작업량은 허용집단의 초안 48건×3분=144분이다. 가용 120분이면 같은 고정 가정에서 40건만 검토할 수 있어 8건이 남는다. 이 계산은 금지 자료 노출 1건의 사고 처리시간을 포함하지 않는다. 감독 범위를 제한하거나 자원을 확보하고, 검토자가 근거를 읽고 수정·거부·중단 요청을 할 수 있게 한다. 남은 8건을 검토 없이 통과시키거나 이름뿐인 승인 절차로 부족시간을 덮지 않는다.
업무·자료/권리·개발·운영/보안·검토자의 책임과 실제 증거를 연결한다. 수정된 조합에서 권한 변경·답 없음·검색 누락·오독·삭제·주입·기록을 대조한 뒤 제한 적용 여부를 다시 판단한다. 이미 노출·오안내가 있었다면 필요한 영향·정정·권리 조치를 별도로 처리한다. 모델 교체나 새로운 평가표만으로 과거 사건이 해소됐다고 쓰지 않는다.
해설·복습: 48건과 권한 위반 1건을 한 감독 집단으로 몰래 합치지 않는다. 질문마다 답할 수 있는지와 답해도 되는지가 다르다. 기반모델·RAG·에이전트 구조, 데이터·AI 생명주기 거버넌스를 복습한다.
M03 완성 답안과 해설 보기
M03 완성 답안 — 자료점·업무 재개·미처리 해소
M03의 복구점 14:57과 중단 15:00의 간격은 3분으로 RPO 5분 안에 든다. 서버 기동 15:25는 25분이지만 정한 업무 재개 15:42는 42분이므로 RTO 30분을 12분 초과한다. 두 목표를 따로 판정하고 서버 기동이나 사고 선언부터의 시간으로 완료 기준을 바꾸지 않는다. 3분의 공백만으로 손실 건수를 확정할 수는 없다.
관리자 계정 오용 의심과 서비스 중단은 확인 수준이 다르다. 사실·의심·미확인을 나누고 증거·계정·설정·자료의 영향과 복구환경의 신뢰를 확인한다. 복제에는 잘못된 변경이 전파될 수 있으므로 가장 최신 사본을 자동으로 안전한 복구점으로 간주하지 않는다. 검증된 자료·권한·최소거래와 필요한 의존서비스를 확인한 범위에서 책임자가 재개를 승인한다.
대체접수와 기존 요청은 원래 식별자·시각·내용·처리상태를 보존한다. 복원된 원장·외부 통지·사용자 확인과 대사하여 이미 처리된 신청을 다시 실행하지 않는다. 누락·충돌·확인 필요는 별도 보정으로 관리하며 기억으로 순서·결과를 채우지 않는다. 대기 480건은 처리 36−신규 12=24건/분으로 줄어 20분 뒤 16:02에 해소된다. 15:42의 재개와 16:02의 대기 정상화는 다른 완료다. 이 값은 같은 업무 단위·일정한 실제 처리·추가 중단과 재작업 없음의 가정에 따른다.
서비스 안내에는 가능한 기능·대체 행동·현재 확인 범위·문의 경로를 담는다. 실제 사고의 정보주체 통지·기관 신고는 적용법의 사실·대상·인지 시점·예외에 따라 담당자가 별도 판단한다. RTO나 장애 공지로 이를 대신하지 않으며 미확인을 유출 없음 또는 확정 유출로 바꾸지 않는다.
업무총괄·보안·인프라/데이터·응용검증·지원/법규가 목표와 증거를 나누어 맡는다. 훈련에는 인증·키·복구점·정합성·외부응답 소실·대체접수·실제 거래를 포함한다. 42분의 단계별 원인을 고치되 검증을 생략해 30분을 맞추지 않는다. 사건 종료는 업무·보안·데이터·권리·정정·개선의 실제 결과와 잔여를 함께 확인한 상태로 정한다.
해설·복습: RPO 충족과 RTO 미달이 동시에 가능하다. 480/36으로 계산하면 신규 유입을 빠뜨린다. 장애·침해·재해 통합 회복성의 두 시간축과 대기를 다시 계산한다.
M04 완성 답안과 해설 보기
M04 완성 답안 — 생산량과 유효한 양품의 차이
M04의 가동률은 420/480=87.5%, 성능률은 0.5×700/420=350/420≈83.33%, 양품률은 665/700=95%다. OEE는 그 곱인 133/192≈69.27%이며 양품의 이상시간 332.5분을 계획 480분으로 나눈 값과 같다. 정지 60분, 성능손실 420−350=70분, 품질손실 35×0.5=17.5분을 빼도 332.5분으로 대사된다. 재작업 합격을 최초 양품에 소급하여 더하지 않는다.
주어진 안정된 정규 공정의 Cp는 (51−49)/(6×0.2)=2/1.2≈1.67이다. Cpk는 상한측 (51−50.4)/0.6=1과 하한측 (50.4−49)/0.6≈2.33의 작은 값인 1이다. 같은 산포로 평균이 50이 되면 양쪽이 1.67로 같아지지만 변동 폭을 줄인 것은 아니다. 실제 측정·표본·안정성·정규성·고객 규격의 요구를 확인하고 지수를 양품률로 변환하지 않는다.
개선안은 작업·제품판본·재료로트·장치·시각·정지사유·최초품질·재작업을 먼저 연결한다. 트윈은 관측·추정·예측·목표를 구별하고 모형의 구현과 실제 용도 타당성을 평가한다. 보전 제안은 이상 신호·원인·고장 예측과 선행시간·점검 인력·부품·작업 창을 함께 판단하며 경보가 없다는 이유로 기존 안전 점검을 생략하지 않는다.
현재 자료만으로 원격 속도 향상을 승인하지 않는다. 속도가 병목인지와 재료·검사·설정·품질 손실의 원인을 조사한다. 허용된 운전·품질·안전 범위에서 제한 시험을 정하고 생산·품질·정비·정보·보안 담당자가 변경과 결과를 확인한다. 측정 오차나 모형의 적용 범위 이탈을 기계의 확정 고장으로 바로 처리하지 않는다.
OT 연결은 필요한 자료·권한·원격지원 경계로 제한하고 읽기·분석 단계부터 기존 승인된 제어를 유지한다. 패치·시험·변경은 현장·공급자의 운영 조건과 복구 경로를 갖춰 수행한다. 새 설정의 속도만이 아니라 최초 양품·납기·에너지·정비·보안·안전 영향을 확인하고 기준 위반·정합성 상실에서는 확대를 중단한다. 좋은 평균이나 대시보드의 증가 화살표가 현장 변경의 승인 증거는 아니다.
해설·복습: OEE는 가동률 하나가 아니고 Cp와 Cpk도 같은 정보를 주지 않는다. 디지털트윈·예지보전·품질최적화, 상호운용·OT보안·단계적 전환을 연결해 계산과 승인 경계를 확인한다.
M05 완성 답안과 해설 보기
M05 완성 답안 — 총비용·단위성과·역할·종료
동일한 비교기간과 비용 범위에서 총비용은 2→2.4백만 원으로 20% 늘었다. 성공한 업무당 비용은 2,000,000/8,000=250원에서 2,400,000/12,000=200원으로 20% 줄었다. 성공 업무는 50% 늘었으므로 총비용 증가와 단위비용 개선이 함께 존재한다. 다만 업무의 난도·품질·비교집단이 같은지와 일회성 이관비·외부 부담을 확인하지 않아 전체 투자효과나 인과효과를 확정하지 않는다.
주어진 계약에서 공급자는 물리설비·운영체제·기반 런타임을, 이용기관은 응용코드·권한·자료·업무운영을 맡는다. 따라서 공급자 보안 기능이 있다는 이유로 잘못된 자료 공개나 응용 취약점을 공급자 책임으로만 돌리지 않는다. 각 영역의 실제 계약·설정·통보·지원과 증거를 확인하며 다른 클라우드 상품에 이 표를 무조건 복사하지 않는다.
운영안은 자원 소유자·업무별 비용과 성공 업무 정의를 연결한다. 미사용 자원·예산 초과·실패 재시도를 관찰하되 비용을 줄이기 위해 필요한 백업·권한·검토를 임의로 제거하지 않는다. 탄력적 확장에는 한도·지연·용량·기준과 실패를 확인하고, 공급자 관리영역과 이용기관의 조치·연락을 정한다. 예산 수치와 실제 서비스 수준을 함께 본다.
회복성은 업무별 RTO·RPO·기능수준을 정하고 인증·키·자료·응용·외부 의존까지 복구시험으로 확인한다. 복제본의 존재를 유효한 과거 복구점으로 대신하지 않는다. 권한·보존·삭제와 자료의 처리 위치·접근 주체를 확인하고, 주권·관할 문제는 위치만으로 결론 내리지 않고 실제 법규·계약을 대조한다.
종료·전환에는 원문 데이터뿐 아니라 설정·식별자·권한·이력·복호화 수단과 다음 환경의 사용 가능성을 포함한다. 키를 직접 반출할 수 없는 서비스라면 허용된 복호화·재암호화·데이터 반환 경로를 검토하고, 비밀키의 무조건 복사를 이관 완료 조건으로 삼지 않는다. 반환 호출과 실제 활용 가능한 회수를 구별하고 전환 후 옛 접근·쓰기·계약·사본을 근거에 따라 종료한다. 기술·업무·재무·보안 담당자가 단위성과·품질·복구·전환의 결과를 함께 판단한다. 반복 단위비용 200원이라는 수치 하나로 최종 도입 승인을 내리지 않는다.
해설·복습: 250→200원은 20% 감소이며 총비용 20% 증가는 모순이 아니다. 다른 분모·기간·비용 경계를 섞지 않는다. 서비스·배치 모델과 공유책임, FinOps·회복성·보안·주권을 재검토한다.
M06 완성 답안과 해설 보기
M06 완성 답안 — 합계 용량보다 장애 후의 요구
정상 링크 명목 합계는 800Mb/s지만 한 링크가 고장 나면 400Mb/s만 남는다. 요구한 25% 여유는 수요에 25%를 더하는 것이 아니라 잔존 용량의 25%를 비워 두는 조건이다. 필요한 용량 C는 0.75C≥360이므로 480Mb/s 이상이다. 현재 400의 75%는 300으로 360보다 작아 해당 여유 요구를 충족하지 못한다. 단순히 수요 360이 400보다 작다고 적합 판정하지 않는다.
한 개선 후보는 각 600Mb/s의 두 경로다. 하나가 남아도 용량의 75%가 450으로 수요 360을 수치상 수용한다. 이는 부가량·실제 처리·장애변동을 제외한 계산의 후보이지 서비스 품질 보증이 아니다. 정상 800 또는 후보 1,200을 단일 흐름의 실제 대역폭으로 표시하지 않고 트래픽 분산 편향·장치 처리·다른 병목을 확인한다.
논리 구조는 업무·공개·데이터·관리의 허용 흐름과 주소·경로·정책을 정한다. 이중 장치·링크가 같은 전원·사업자·경로·설정에 의존하는지 조사하고 공통 실패를 줄인다. 독립성을 확인하지 못한 상태는 미확인으로 남긴다. 물리·운영 조건에 따라 다른 대안의 비용·회복·지원 부담을 비교한다.
QoS는 트래픽별 지연·손실을 관리하는 수단이지 새로운 용량을 만드는 방법이 아니다. 중요 흐름의 분류·표시·큐·수락·제한과 각 구간의 정책 일치를 확인하고 백업 등 유예 가능한 작업의 부담을 통제한다. 장애 우회경로도 같은 인증·접근·감시 경계를 유지하며 관리 경로를 무조건 열어 두지 않는다.
검증은 정상 첨두와 링크·장치·전원 등 정한 실패 조건에서 잔존 용량, 수렴시간·지연·손실·부하분산·허용 경로·정책 우회 여부를 본다. 구성 파일 존재가 실제 복구 성능을 대신하지 않는다. 현재 설계는 여유 조건에 미달했고 후보는 산술상 조건을 만족하되 독립성과 실제 종단 품질은 검증이 남는다는 결론으로 닫는다.
해설·복습: 360×1.25=450은 ‘수요를 25% 늘린다’는 다른 조건의 값이다. 이 문제는 360/0.75=480이다. 요구에서 토폴로지·주소·라우팅·QoS·이중화까지의 여유율 두 분모를 확인한다.
8. 모의를 채점 대신 먼저 진단한다
이 책은 공식 부분점수표를 제공한 것이 아니다. 각 답안에서 요구를 충족한 증거가 어디에 있는지 먼저 표시한다. 다음 여섯 가지를 ‘있음·부족·오류·미작성’으로 구별해 보면 같은 점수처럼 보이는 답도 고칠 위치가 달라진다.
| 진단 축 | 확인할 실제 문장·계산 |
|---|---|
| 요구 충족 | 가·나·다·라의 질문에 각각 답했는가 |
| 원리·정의 | 비슷한 말을 구별하고 의미를 바꾸지 않았는가 |
| 조건·산술 | 원수·분모·단위·시간·가정을 유지했는가 |
| 구조·선택 | 구성·역할·경계·대가·기각한 대안을 설명했는가 |
| 실패·검증 | 정상뿐 아니라 미확인·예외·복구·실제 결과를 확인하는가 |
| 표현·결론 | 도식·표·본문이 일치하고 근거 밖 보장을 하지 않았는가 |
예를 들어 M06에서 480을 얻었지만 후보의 독립성·검증을 쓰지 않았다면 산술은 맞고 설계 요구는 부족하다. M02에서 48/60을 42/100과 같은 정확도로 설명하면 단순 오탈자가 아니라 단계·분모의 이해 오류다. M01에서 통지 실패 때 장비를 다시 배정하거나 정확히 같은 구간의 중복만 금지하면 구조가 부족하다.
오답은 원문을 그대로 베끼는 대신 원인별로 다시 쓴다. 개념이 틀렸으면 앞 정의와 작은 예제로, 산술이 틀렸으면 원수·단위로, 요구를 놓쳤으면 네 칸 해석으로 돌아간다. 다음 연습에서는 같은 문제의 숫자만 바꾸지 말고 가정·권한·실패 조건을 하나 바꾸어도 판단이 유지되는지 확인한다.
9. 자기교정과 조건 변경
| 오답·습관 | 왜 부족한가 | 수정 예 | 복습 |
|---|---|---|---|
| 그림은 권한 확인 먼저, 본문은 전체 검색 먼저 | 서로 다른 설계를 설명 | 검색·문맥·출력의 실제 경계 일치 | 표현 |
| 원장 확정 전 성공을 알리거나 발송 전 확인만으로 옛 안내를 모두 막는다고 한다 | 거래 경계와 취소·전달 경쟁을 생략 | 커밋·현재 상태·판본별 전달·정정 분리 | DT-A |
| 점수가 높으면 권한 오류를 감수한다 | 필수 경계를 평균으로 상쇄 | M02의 확대 보류·원인 확인 | M02 답안 |
| 서버 기동이 곧 RTO 완료다 | 목표한 기능·승인 누락 | M03의 42분과 25분 구별 | M03 답안 |
| 가동률 87.5%가 OEE다 | 성능·품질 손실 누락 | OEE 69.27%와 손실 대사 | M04 답안 |
| 총비용 증가면 무조건 비효율이다 | 업무량·단위성과·품질 누락 | 총비용 20% 증가·단위비용 20% 감소 분리 | M05 답안 |
| 용량 25% 여유는 수요×1.25다 | 분모가 다른 계산 | 360/0.75=480 | M06 답안 |
| 해설을 본 뒤 잘 썼으니 독립 모의 성공이다 | 학습과 미리 보지 않은 수행이 다름 | 학습 후 재연습으로 표시 | 진단 |
부족한 답안: “필요한 용량은 480Mb/s이므로 도입해도 된다.”
고칠 이유: M06은 계산뿐 아니라 개선 설계와 실제 검증도 요구한다. 계산값 하나로 공통 실패의 독립성이나 실제 지연·손실까지 확인했다고 결론 내릴 수 없다.
개선한 답안: “현재 400Mb/s 링크는 장애 후 잔존 용량의 25%를 남기는 조건을 충족하지 못한다. 각 600Mb/s인 두 경로는 주어진 산술 가정에서는 후보가 될 수 있다. 다만 공통 전원·사업자·경로 의존성과 실제 지연·손실·보안 우회 여부를 확인하기 전에는 최종 도입을 승인했다고 쓰지 않는다.”
조건 1 — M03의 신규 유입이 처리 36건/분과 같아지면: 대기 순감소는 0이므로 총 대기량 480건이 해소되지 않는다. 처리능력·수요 관리·업무 우선순위의 대안을 실제 제약과 비교한다. 총 대기량이 남는 것과 기존 개별 요청이 차례로 처리되는 것은 다르며, 정상화 시각을 임의로 쓰지 않는다.
조건 2 — M04에서 생산시간·총생산·최초양품·산포를 그대로 두고 평균만 50.0mm가 되면: OEE는 69.27% 그대로이고 Cpk는 약 1.67로 바뀐다. 공정 중심과 시간·양품 효율의 지표가 서로 다른 대상을 재는 것을 설명한다.
조건 3 — M06의 요구가 ‘수요에 25%를 더한다’로 바뀌면: 필요량은 450Mb/s다. 현재 400은 여전히 미달하지만 이전의 480과는 다른 답이다. 단어 하나의 조건 변경을 식에 반영한다.
면접 연결: 답안의 결론을 방어한다
질문: “모의에서 가장 중요한 결론 하나를 말하고 조건이 바뀌면 어떻게 달라지는지 설명해 보세요.”
면접 응답 예 보기
응답 예: “M06의 현재 400Mb/s 링크는 장애 후 용량의 25%를 남기는 조건을 만족하지 않습니다. 필요한 값은 480입니다. 수요에 25%를 더하는 조건으로 바뀌면 450이므로 문구와 분모를 먼저 확인해야 합니다. 후보 600은 산술상 가능하지만 경로 독립성과 실제 지연·손실까지 검증됐다는 뜻은 아닙니다.”
후속 질문: “그럼 숫자만 맞으면 됩니까?”
후속 질문의 대응 예 보기
후속 응답 예: “아닙니다. 질문은 개선 설계와 검증까지 요구합니다. 수량상 이중화와 공통 실패의 독립성을 나누고, 장애 우회경로의 보안·QoS·운영 증거를 함께 제시해야 합니다.”
근거와 연습 범위
모든 M01~06·DT-A/G1·도식·숫자·배점·100분 배분과 완성 답안은 자체 작성했다. 실제 기출·공식 채점·출제예측·현장 실험·제한시간 사용자 시험이 아니다. 각 원리는 거래·네트워크·연속성·개인정보·규범·윤리·AI·클라우드·제조와 앞 통합 사례의 본문·출처로 연결한다. 이 절의 비용·대역폭·정비 조건은 실제 제품 가격·법적 안전 기준·성능 보증이 아니다.
이 모의는 자체 교육용 사례이며 독립 기술·시험·권리 감수나 초보 독자 검토를 대신하지 않는다. 모의 풀이의 확인 범위와 실제 기출 원문·공식 채점기준의 확인 범위를 구별한다.
회독의 핵심
도식·표·계산·결론은 같은 사실을 각기 다른 방식으로 설명해야 한다. 모의를 풀 때는 문제 선택과 시간뿐 아니라 요구의 충족, 가정·분모·실패 경계, 실제 선택과 한계를 확인한다. 외운 문장보다 조건이 바뀌어도 유지되는 설명을 만든다.
조건 전이 연습: 표의 근거를 결론까지 유지한다
다음 세 문제는 자체 작성한 보충 연습이다. 앞 좌석 사례와 모의의 조건을 비교하지만 실제 DB·통지 서비스의 실행 결과나 공식 채점기준을 추가하지 않는다.
연습 1. ‘응답 없음’ 세 사건을 같은 실패로 묶지 않는다
좌석은 처음 1개이고 A의 같은 내용 R1만 처리한다. 다른 신청·취소는 없다. 아래 사건은 서로 별도 시행이다.
| 사건 | 확인한 근거 |
|---|---|
| C1 | 좌석 차감·예약·R1 결과·N1 작업의 COMMIT을 확인했다. 이후 N1의 수락 응답만 소실됐다. |
| C2 | 같은 변경의 COMMIT 요청 후 응답이 소실됐고, R1 조회에서도 확정 여부와 진행 상태를 아직 확인하지 못했다. |
| C3 | 같은 변경의 ROLLBACK을 권위 있는 DB 결과로 확인했다. 외부 발송은 시작하지 않았다. |
각 사건의 재고·업무·통지 상태와 다음 행동을 표로 작성하라. “C2에서 R1이 조회되지 않으므로 좌석은 1개다”와 “C1에서 N1을 확인하려면 R1을 새 ID로 다시 배정한다”를 각각 판단하라.
연습 1 풀이: 결과의 근거가 어느 경계에 있는가
| 사건 | 재고 | 업무 | 통지와 다음 행동 |
|---|---|---|---|
| C1 | 0 | 확정 | N1 작업은 있으나 외부 수락은 미확인이다. 같은 R1의 기존 결과와 현재 상태를 반환하고 N1 이력·외부 기록을 대사한다. |
| C2 | 미확인 | 커밋 결과 미확인 | N1 작업의 확정 여부도 아직 단정하지 않는다. R1의 권위 있는 결과·진행 상태부터 확인하며 새 배정이나 확정 안내를 시작하지 않는다. |
| C3 | 1 | 미확정 | N1 작업은 이 거래에 남지 않고 외부 발송도 없었다. 오류·권한·업무 조건과 재시도 규칙을 확인한다. |
C2의 조회 부재는 권위 있는 롤백 확인과 다르다. 진행 중 처리나 조회 시점·경로의 한계가 아직 해소되지 않았으므로 0·1 중 하나를 임의로 채우지 않는다. C1의 통지 대사는 예약을 다시 만드는 작업이 아니다. 새 배정은 이미 확인한 원장의 상태를 바꾸므로 제안은 부적절하다.
C1에서 나중에 N1 수락 응답을 확인하면 통지만 ‘발송 서비스 접수 확인’으로 바꿀 수 있다. 재고 0·예약 확정은 유지한다. 수락 응답의 확인 기준은 이용자의 수신·열람과 다르다. C3의 재고 1은 다른 신청·취소가 없다는 이 문제의 조건에서만 쓴 값이다.
연습 2. 표시용 반올림과 통과 판단을 분리한다
두 독립 사례를 검토한다. 제조 사례의 정확한 OEE는 앞 M04처럼 133/192이고, 자체 관리 기준은 OEE 70% 이상이다. 대시보드는 정수 퍼센트를 표시한다. 네트워크 사례의 수요는 375Mb/s이고 장애 후 잔존 용량의 22%를 비워 두어야 한다. 용량 후보는 25Mb/s 단위로만 선택할 수 있으며 부가량·변동·다른 병목은 이 산술에서 제외한다.
제조 기준의 통과 여부와 네트워크 최소 용량 후보를 계산하라. 용량 480Mb/s가 충분한지도 설명하고, 산술상 충분한 후보를 최종 도입 승인으로 쓸 수 있는지 판단하라.
연습 2 풀이: 임계값에는 원수와 올림 방향을 적용한다
OEE는 133/192 × 100 ≈ 69.270833%로 70%보다 작다. 정수 표시도 통상 반올림하면 69%이며, 표시 방식이나 자릿수를 바꿔 기준을 통과시킬 수 없다. 중간 가동·성능·양품률을 각각 반올림한 뒤 곱하지 않고 정확한 원수로 마지막 비교를 한다.
네트워크에서는 0.78C ≥ 375, 따라서 C ≥ 375/0.78 = 6250/13 ≈ 480.769231Mb/s다. 480의 사용 가능량은 374.4로 수요보다 0.6Mb/s 부족하다. 정수 단위만 고르면 최소 481이지만, 제시한 25Mb/s 단위 후보 중 최소는 500Mb/s다. 그 사용 가능량은 390, 산술상 여유는 15Mb/s다.
from fractions import Fraction
oee = Fraction(133, 192)
required = Fraction(375) / Fraction(78, 100)
steps = required / 25
candidate = ((steps.numerator + steps.denominator - 1) // steps.denominator) * 25
assert oee < Fraction(70, 100)
assert Fraction(480) * Fraction(78, 100) < 375
assert Fraction(candidate) * Fraction(78, 100) >= 375
print(f"OEE기준충족={oee >= Fraction(70, 100)}")
print(f"최소후보={candidate}Mb/s, 산술여유={Fraction(candidate) * Fraction(78, 100) - 375}Mb/s")출력은 OEE기준충족=False와 최소후보=500Mb/s, 산술여유=15Mb/s다. 이 표준 라이브러리 계산은 원수·후보 단위의 산술만 확인한다. 실제 링크의 처리량·공통 실패·지연·손실·보안·비용은 아직 검증하지 않았으므로 최종 도입 승인으로 결론을 넓히지 않는다. 제조의 자체 기준도 법적 안전 기준이나 공식 시험 기준을 뜻하지 않는다.
연습 3. 한 시행의 기록으로 전체 경합과 전달을 보증하지 않는다
다음은 결론 작성 연습을 위한 가상의 시험 기록이다. T1에서는 R1 한 건의 COMMIT을 확인했고, 같은 내용 R1을 차례로 두 번 조회해 예약 1건·재고 0을 확인했다. 동시 요청·다른 ID·다른 내용·취소는 시험하지 않았다. T2에서는 해당 N1의 외부 수락 응답을 기록했지만 이용자의 수신·열람은 관찰하지 않았다. 개발자는 “모든 경합을 막고 알림을 정확히 한 번 전달하므로 운영 도입이 완료됐다”고 썼다.
도식의 두 경계에 T1·T2의 증거를 대응시키고, 잘못된 결론을 세 문장 이내로 다시 쓰라. 다음 시험 두 가지와 각각 대사할 결과도 제시하라.
연습 3 풀이: 시험한 조건과 남은 조건을 함께 쓴다
T1의 근거는 DB 업무 결과와 순차 재조회에 대응한다. 이 기록에서는 예약 1건·재고 0을 확인했지만 동시 고유성 충돌이나 모든 업무 경합을 확인한 것은 아니다. T2는 DB 밖 N1 수락 응답에 대응하며 수신·열람 또는 다른 재시도의 외부 중복 방지 증거가 아니다.
수정 결론 예: “가상의 T1에서는 R1의 COMMIT과 순차 재조회에서 예약 1건·재고 0을 확인했다. T2에서는 N1의 발송 서비스 수락을 확인했으며 이용자의 수신·열람은 미확인이다. 동시 요청·취소·응답 소실과 운영 조건의 검증이 남아 최종 도입 완료를 판단할 수 없다.”
첫 후속 시험은 마지막 좌석에 서로 다른 요청 ID 두 개를 동시에 넣는 것이다. 현재 권한·업무 조건을 만족하는 두 요청에 대해 원장·요청 결과·알릴 작업·최종 재고를 대사하여 확정 수가 1을 넘지 않고 나머지 정상 대기나 거절 결과가 규칙과 맞는지 확인한다. 승자를 미리 고정하지 않는다.
둘째 시험은 확정 후 발송판본 확인 직후 취소와 외부 응답 소실을 결합하는 것이다. 원장의 현재 취소 상태·자원 반환 횟수·판본별 N1 이력·외부에서 확인할 수 있는 결과·취소 및 정정 안내를 대사한다. 옛 안내의 도착을 완전히 막았다고 가정하지 않고 미확인 전달은 미확인으로 남긴다. 이 두 계획 역시 실제 시험 수행의 증거가 아니며, 수행 뒤 확인한 조건과 잔여를 다시 기록한다.
Footnotes
-
PostgreSQL 18 공식 문서, §5.5.3 Unique Constraints, §13.2.1 Read Committed, §13.3.2 Row-Level Locks. https://www.postgresql.org/docs/18/ddl-constraints.html ; https://www.postgresql.org/docs/18/transaction-iso.html ; https://www.postgresql.org/docs/18/explicit-locking.html . 2026-09-20의 내용 통합 대조에서 고유성·조건 재평가·잠금의 경계만 확인했다. 제품의 실제 동시 실행시험이나 모든 DBMS의 동일 보장을 주장하지 않는다. ↩
-
PostgreSQL 18 공식 문서, §8.17.3 Inclusive and Exclusive Bounds, §8.17.10 Constraints on Ranges. https://www.postgresql.org/docs/18/rangetypes.html . 부분 겹침과 단순 UNIQUE의 차이를 대조했으며 M01의 시간·장비는 자체 예제다. 실질적인 설명·선행 예제는 핵심정의에서 판단축까지의 구간 설명에 있다. ↩