입력·처리·출력·상태·피드백

행동을 보기 전에 경계를 되찾기

시스템 경계는 이번 분석에서 내부 책임과 외부 환경을 가르는 판단선이다. 입력과 출력은 이 경계를 통과하는 값·사건·자원이므로 어느 경계를 기준으로 말하는지 먼저 고정한다.

같은 요청인데 왜 결과가 달라질까

사용자가 같은 상품의 주문 버튼을 두 번 눌렀다. 첫 요청은 주문을 만들지만 두 번째 요청은 “이미 처리됨”을 돌려줄 수 있다. 입력 문장만 보면 같지만 시스템이 기억한 주문 상태가 달라졌기 때문이다. 또 오류율이 높아지면 자동으로 새 요청을 줄이거나 예비 서버를 늘리는 시스템은 자신의 결과를 관찰해 다음 행동을 조정한다.

입력–처리–출력만 알면 한 번의 변환은 설명할 수 있다. 그러나 시간에 따라 달라지는 행동과 스스로 조정하는 통제를 설명하려면 상태와 피드백이 필요하다. 이 다섯 요소는 뒤에서 배울 컴퓨터 동작, 데이터 처리, 통신, 보안과 업무 관리에 반복해서 등장한다.

한 문장으로 말하면

시스템의 행동은 밖에서 받은 입력을 규칙에 따라 처리해 출력하고, 다음 행동에 영향을 줄 정보를 상태로 남기며, 실제 결과를 다시 관찰해 필요하면 처리 방식을 조정하는 과정으로 읽을 수 있다.

이 가운데 입력–처리–출력(Input–Process–Output, IPO)은 시스템 경계로 들어온 것을 규칙으로 바꾸어 경계 밖 결과를 내보내는 기본 변환 흐름이다. 앞으로 IPO라고 쓰면 이 세 단계와 그 관계를 뜻한다.

• 입력(input): 시스템 경계를 넘어 들어온 사건·데이터·자원
• 처리(process): 입력과 현재 상태에 규칙을 적용하는 변화
• 출력(output): 경계를 넘어 밖에 전달한 결과·신호·부작용
• 상태(state): 같은 다음 입력에 대한 행동을 달라지게 할 수 있는 현재의 기억
• 피드백(feedback): 출력이나 상태를 관찰한 정보를 목표와 비교해 이후 행동에 되돌리는 것

이 목록을 외우는 것보다 화살표를 읽는 편이 중요하다. 입력 + 현재 상태 → 처리 → 출력 + 새 상태가 한 번의 상태변화이고, 관찰 → 목표와 비교 → 조정이 그 변화를 계속 통제하는 피드백 고리다.

피드백에 앞선 두 개념의 정식 경계

IPO는 입력을 규칙으로 처리해 출력을 만드는 흐름이고 상태는 다음 동작에 영향을 주는 현재 기억이다. 따라서 같은 입력도 현재 상태가 다르면 다음 상태와 출력이 달라질 수 있다.

관계식 앞에서 되찾기

같은 주문 식별자의 요청이 처음 들어왔을 때와 이미 처리된 뒤 다시 들어왔을 때를 떠올려 보자. 입력은 같아도 다음 행동과 출력이 달라지는 이유를 현재 상태와 연결해 한 문장으로 설명한 뒤 아래 관계식을 읽는다.

정확히 말하면

입력–처리–출력(IPO)은 시스템 경계를 넘어 들어온 사건·데이터·자원에 처리 규칙을 적용하여 경계 밖 결과를 산출하는 기능 변환 관계다. 여기서 함수는 값을 받아 정해진 규칙에 따라 결과를 내는 관계다. 현재 시점을 t, 다음 시점을 t+1, 현재 상태를 s(t), 입력을 x(t)라고 하자. 다음 상태를 정하는 함수가 F라면 s(t+1) = F(s(t), x(t))로 나타낼 수 있다. 출력을 정하는 함수가 G라면 y(t) = G(s(t), x(t))다. 수식의 목적은 계산을 어렵게 하는 데 있지 않다. 현재 입력만이 아니라 현재 상태도 다음 상태와 출력을 결정한다는 관계를 짧게 보이는 데 있다.

상태는 저장된 모든 데이터와 같지 않다. 앞으로의 행동을 구분하는 데 필요한 기억만 상태다. 주문 화면의 글자색은 저장 데이터일 수 있지만 다음 주문 처리에 영향을 주지 않으면 주문 처리 상태가 아니다. 반대로 결제 승인됨, 재고 예약됨, 취소 요청됨은 다음 허용 동작을 바꾸므로 상태다.

수식을 읽을 때 s(t)는 “시점 t의 상태”, F(s(t), x(t))는 “현재 상태와 입력을 F라는 규칙에 넣어 얻은 값”이다. =는 이 사례에서 두 표현이 같은 값을 나타낸다는 뜻이고 t+1은 다음 관찰 차례이지 반드시 1초 뒤라는 뜻은 아니다. 예를 들어 현재 상태가 접수이고 입력이 결제승인이면 F의 결과는 결제완료, G의 결과는 고객에게 보낼 결제 완료 안내다. 다음 차례에 같은 승인 사건을 다시 받으면 이미 결제완료인 상태를 보고 새 결제를 만들지 않고 기존 안내를 돌려준다.

피드백 통제는 보통 네 부품을 가진다. ①목표 또는 기준값, ②실제 결과를 재는 관찰, ③둘의 차이를 판단하는 비교, ④차이를 줄이기 위한 조정이다. 관찰값을 되돌리기만 해서는 피드백 통제가 아니다. 목표와 비교해 행동을 바꾸는 닫힌 고리(closed loop)가 되어야 한다.

한 번의 변화와 반복되는 통제

입력과 현재 상태가 출력과 새 상태를 만든다 · 상태 따라가기

x(t)와 s(t)는 이번 처리의 입력과 시작 상태다. 모든 단계에서 현재 입력·상태·규칙·출력의 위치를 유지하며 값과 허용 조건을 함께 확인합니다.

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

현재 입력 x(t)와 현재 상태 s(t)를 함께 처리 규칙 F·G에 넣어 출력 y(t)와 다음 상태 s(t+1)를 만든다. 상태는 다음 동작을 구별하는 기억이며, t+1은 다음 관찰 차례다. 이 그림은 한 번의 기능 변화이고 아래 운영 통제 고리와 구별한다.

이 예의 조건

• 현재 입력 x(t)와 현재 상태 s(t)를 함께 처리 규칙 F·G에 넣어 출력 y(t)와 다음 상태 s(t+1)를 만든다. 상태는 다음 동작을 구별하는 기억이며, t+1은 다음 관찰 차례다. 이 그림은 한 번의 기능 변화이고 아래 운영 통제 고리와 구별한다.
• 이 원문의 교육용 사례·조건 안에서 상태를 대조합니다. 실제 구축·실험 결과나 원문에 없는 성능 보장을 추가하지 않습니다.

관계도의 보충 설명

원그림의 모든 대상과 설명

대상	원 설명
대상입력 x(t)	원 설명경계를 넘어온 사건
대상현재 상태 s(t)	원 설명행동을 바꾸는 기억
대상처리 규칙 F·G	원 설명현재 입력·상태에 규칙 적용
대상출력 y(t)	원 설명경계 밖의 결과
대상새 상태 s(t+1)	원 설명다음 차례의 기억

원그림의 모든 관계와 조건

연결	원 라벨·방향
연결입력 x(t) → 처리 규칙 F·G	원 라벨·방향라벨 없는 연결 / 정방향 / 실선
연결현재 상태 s(t) → 처리 규칙 F·G	원 라벨·방향라벨 없는 연결 / 정방향 / 실선
연결처리 규칙 F·G → 출력 y(t)	원 라벨·방향라벨 없는 연결 / 정방향 / 실선
연결처리 규칙 F·G → 새 상태 s(t+1)	원 라벨·방향라벨 없는 연결 / 정방향 / 실선

예의 값과 변화

관찰·상황	값·보충 정보	변화·이유
현재 시점 x(t)와 s(t)는 이번 처리의 입력과 시작 상태다.	값·보충 정보 현재 입력·상태: x(t),s(t) 규칙·출력: F·G 적용 전	변화·이유 다음 상태를 현재 상태로 미리 읽지 않는다.
출력 계산 규칙 G가 현재 입력·상태를 사용해 이번 출력을 정한다.	값·보충 정보 현재 입력·상태: x(t),s(t) 유지 규칙·출력: y(t)=G(x(t),s(t))	변화·이유 출력은 이 시점의 조건에서 계산하므로 뒤의 상태와 구별한다.
다음 상태 규칙 F의 결과가 s(t+1)이 되어 다음 처리의 시작 상태로 이어진다.	값·보충 정보 현재 입력·상태: s(t)→s(t+1) 규칙·출력: F의 상태 갱신	변화·이유 다음 입력 처리는 갱신한 상태를 사용한다.

입력과 현재 상태가 출력과 새 상태를 만든다 · 상태 따라가기

x(t)와 s(t)는 이번 처리의 입력과 시작 상태다. 모든 단계에서 현재 입력·상태·규칙·출력의 위치를 유지하며 값과 허용 조건을 함께 확인합니다.

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

현재 입력 x(t)와 현재 상태 s(t)를 함께 처리 규칙 F·G에 넣어 출력 y(t)와 다음 상태 s(t+1)를 만든다. 상태는 다음 동작을 구별하는 기억이며, t+1은 다음 관찰 차례다. 이 그림은 한 번의 기능 변화이고 아래 운영 통제 고리와 구별한다.

이 예의 조건

• 현재 입력 x(t)와 현재 상태 s(t)를 함께 처리 규칙 F·G에 넣어 출력 y(t)와 다음 상태 s(t+1)를 만든다. 상태는 다음 동작을 구별하는 기억이며, t+1은 다음 관찰 차례다. 이 그림은 한 번의 기능 변화이고 아래 운영 통제 고리와 구별한다.
• 이 원문의 교육용 사례·조건 안에서 상태를 대조합니다. 실제 구축·실험 결과나 원문에 없는 성능 보장을 추가하지 않습니다.

관계도의 보충 설명

원그림의 모든 대상과 설명

대상	원 설명
대상입력 x(t)	원 설명경계를 넘어온 사건
대상현재 상태 s(t)	원 설명행동을 바꾸는 기억
대상처리 규칙 F·G	원 설명현재 입력·상태에 규칙 적용
대상출력 y(t)	원 설명경계 밖의 결과
대상새 상태 s(t+1)	원 설명다음 차례의 기억

원그림의 모든 관계와 조건

연결	원 라벨·방향
연결입력 x(t) → 처리 규칙 F·G	원 라벨·방향라벨 없는 연결 / 정방향 / 실선
연결현재 상태 s(t) → 처리 규칙 F·G	원 라벨·방향라벨 없는 연결 / 정방향 / 실선
연결처리 규칙 F·G → 출력 y(t)	원 라벨·방향라벨 없는 연결 / 정방향 / 실선
연결처리 규칙 F·G → 새 상태 s(t+1)	원 라벨·방향라벨 없는 연결 / 정방향 / 실선

예의 값과 변화

관찰·상황	값·보충 정보	변화·이유
현재 시점 x(t)와 s(t)는 이번 처리의 입력과 시작 상태다.	값·보충 정보 현재 입력·상태: x(t),s(t) 규칙·출력: F·G 적용 전	변화·이유 다음 상태를 현재 상태로 미리 읽지 않는다.
출력 계산 규칙 G가 현재 입력·상태를 사용해 이번 출력을 정한다.	값·보충 정보 현재 입력·상태: x(t),s(t) 유지 규칙·출력: y(t)=G(x(t),s(t))	변화·이유 출력은 이 시점의 조건에서 계산하므로 뒤의 상태와 구별한다.
다음 상태 규칙 F의 결과가 s(t+1)이 되어 다음 처리의 시작 상태로 이어진다.	값·보충 정보 현재 입력·상태: s(t)→s(t+1) 규칙·출력: F의 상태 갱신	변화·이유 다음 입력 처리는 갱신한 상태를 사용한다.

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

목표와 실제 출력·상태 관찰을 비교해 편차를 판단한다. 권한 있는 조정이 다음 차례의 처리 행동을 바꾸고 그 결과를 다시 관찰할 때 통제 고리가 닫힌다. 관찰만 모으는 관제는 조정이 없으며, 현재 출력을 같은 시점의 입력으로 즉시 되돌리는 대수 루프와 구별한다.

위쪽은 한 번의 기능 동작이다. 아래쪽은 그 동작을 여러 번 관찰하고 조정하는 통제 고리다. 데이터 흐름은 값이 어디로 가는지 보여 주고, 통제 흐름은 언제 어떤 규칙을 선택할지 보여 준다. 둘을 구분하면 “관찰 자료는 모이는데 왜 자동복구가 안 되는가?”라는 질문에 답할 수 있다. 관찰 자료가 있어도 비교 기준과 조정 동작이 연결되지 않으면 고리가 닫히지 않았기 때문이다.

주문 한 건이 상태를 바꾸는 과정

주문 요청을 입력, 주문 규칙을 처리, 접수 결과를 출력으로 보자. 처음 상태가 없음이면 유효한 상품과 수량을 검사하고 접수 상태를 만든다. 결제 승인 사건이 들어오면 결제완료, 재고 예약 사건이 들어오면 출고대기로 이동한다. 취소 요청은 어느 상태에서나 같은 결과를 내지 않는다. 접수에서는 취소할 수 있지만 이미 배송완료라면 반품 절차로 보내야 한다.

주문은 사건과 허용 조건에 따라 상태를 바꾼다 · 상태 따라가기

없음 상태의 주문을 검증해 성공한 한 경로를 따라간다. 모든 단계에서 주문·사건·허용 조건의 위치를 유지하며 값과 허용 조건을 함께 확인합니다.

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

주문 검증 성공은 없음에서 접수로, 검증 실패는 거절로 간다. 접수는 결제 승인으로 결제완료가 되고 재고 예약으로 출고대기, 출고로 배송중이 된다. 그림의 결제완료 상태에서 취소 사건은 취소로 간다. 이 일부 흐름을 모든 상태에 동일한 취소를 허용하는 규칙으로 확대하지 않는다.

이 예의 조건

• 주문 검증 성공은 없음에서 접수로, 검증 실패는 거절로 간다. 접수는 결제 승인으로 결제완료가 되고 재고 예약으로 출고대기, 출고로 배송중이 된다. 그림의 결제완료 상태에서 취소 사건은 취소로 간다. 이 일부 흐름을 모든 상태에 동일한 취소를 허용하는 규칙으로 확대하지 않는다.
• 이 원문의 교육용 사례·조건 안에서 상태를 대조합니다. 실제 구축·실험 결과나 원문에 없는 성능 보장을 추가하지 않습니다.

관계도의 보충 설명

원그림의 모든 대상과 설명

대상	원 설명
대상없음	원 설명원그림의 대상
대상접수	원 설명원그림의 대상
대상거절	원 설명원그림의 대상
대상결제완료	원 설명원그림의 대상
대상출고대기	원 설명원그림의 대상
대상취소	원 설명원그림의 대상
대상배송중	원 설명원그림의 대상

원그림의 모든 관계와 조건

연결	원 라벨·방향
연결없음 → 접수	원 라벨·방향검증 성공 / 정방향 / 실선
연결없음 → 거절	원 라벨·방향검증 실패 / 정방향 / 실선
연결접수 → 결제완료	원 라벨·방향결제 승인 / 정방향 / 실선
연결결제완료 → 출고대기	원 라벨·방향재고 예약 / 정방향 / 실선
연결결제완료 → 취소	원 라벨·방향취소 / 정방향 / 실선
연결출고대기 → 배송중	원 라벨·방향출고 / 정방향 / 실선

예의 값과 변화

관찰·상황	값·보충 정보	변화·이유
검증 성공 뒤 접수 없음 상태의 주문을 검증해 성공한 한 경로를 따라간다.	값·보충 정보 주문: 없음→접수 사건·허용 조건: 주문 검증 성공	변화·이유 검증 실패의 거절은 별도 분기이며 접수된 주문의 후속 상태가 아니다.
결제 승인 뒤 결제완료 접수 주문의 결제 승인 결과가 확인되면 결제완료로 바뀐다.	값·보충 정보 주문: 접수→결제완료 사건·허용 조건: 결제 승인 확인	변화·이유 미확인 결제를 승인된 결제완료로 전이시키지 않는다.
재고 예약 뒤 출고대기 결제완료에서 재고 예약 사건이 충족되어 출고대기로 간다.	값·보충 정보 주문: 결제완료→출고대기 사건·허용 조건: 재고 예약됨	변화·이유 결제만으로 출고대기나 배송중이 되지는 않는다.
출고 뒤 배송중 출고대기 주문의 실제 출고 사건 뒤 배송중이 된다.	값·보충 정보 주문: 출고대기→배송중 사건·허용 조건: 출고 확인	변화·이유 출고대기는 출고가 이미 일어났다는 뜻이 아니다.
별도 분기: 결제완료에서 취소 이번 장면은 결제완료 시작점으로 돌아가 취소 사건이 있는 대안을 본다.	값·보충 정보 주문: 결제완료→취소 사건·허용 조건: 취소 사건·허용 상태	변화·이유 배송중에서 취소로 이어지는 경로를 만든 것이 아니며 다른 상태로 확대하지 않는다.

주문은 사건과 허용 조건에 따라 상태를 바꾼다 · 상태 따라가기

없음 상태의 주문을 검증해 성공한 한 경로를 따라간다. 모든 단계에서 주문·사건·허용 조건의 위치를 유지하며 값과 허용 조건을 함께 확인합니다.

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

주문 검증 성공은 없음에서 접수로, 검증 실패는 거절로 간다. 접수는 결제 승인으로 결제완료가 되고 재고 예약으로 출고대기, 출고로 배송중이 된다. 그림의 결제완료 상태에서 취소 사건은 취소로 간다. 이 일부 흐름을 모든 상태에 동일한 취소를 허용하는 규칙으로 확대하지 않는다.

이 예의 조건

• 주문 검증 성공은 없음에서 접수로, 검증 실패는 거절로 간다. 접수는 결제 승인으로 결제완료가 되고 재고 예약으로 출고대기, 출고로 배송중이 된다. 그림의 결제완료 상태에서 취소 사건은 취소로 간다. 이 일부 흐름을 모든 상태에 동일한 취소를 허용하는 규칙으로 확대하지 않는다.
• 이 원문의 교육용 사례·조건 안에서 상태를 대조합니다. 실제 구축·실험 결과나 원문에 없는 성능 보장을 추가하지 않습니다.

관계도의 보충 설명

원그림의 모든 대상과 설명

대상	원 설명
대상없음	원 설명원그림의 대상
대상접수	원 설명원그림의 대상
대상거절	원 설명원그림의 대상
대상결제완료	원 설명원그림의 대상
대상출고대기	원 설명원그림의 대상
대상취소	원 설명원그림의 대상
대상배송중	원 설명원그림의 대상

원그림의 모든 관계와 조건

연결	원 라벨·방향
연결없음 → 접수	원 라벨·방향검증 성공 / 정방향 / 실선
연결없음 → 거절	원 라벨·방향검증 실패 / 정방향 / 실선
연결접수 → 결제완료	원 라벨·방향결제 승인 / 정방향 / 실선
연결결제완료 → 출고대기	원 라벨·방향재고 예약 / 정방향 / 실선
연결결제완료 → 취소	원 라벨·방향취소 / 정방향 / 실선
연결출고대기 → 배송중	원 라벨·방향출고 / 정방향 / 실선

예의 값과 변화

관찰·상황	값·보충 정보	변화·이유
검증 성공 뒤 접수 없음 상태의 주문을 검증해 성공한 한 경로를 따라간다.	값·보충 정보 주문: 없음→접수 사건·허용 조건: 주문 검증 성공	변화·이유 검증 실패의 거절은 별도 분기이며 접수된 주문의 후속 상태가 아니다.
결제 승인 뒤 결제완료 접수 주문의 결제 승인 결과가 확인되면 결제완료로 바뀐다.	값·보충 정보 주문: 접수→결제완료 사건·허용 조건: 결제 승인 확인	변화·이유 미확인 결제를 승인된 결제완료로 전이시키지 않는다.
재고 예약 뒤 출고대기 결제완료에서 재고 예약 사건이 충족되어 출고대기로 간다.	값·보충 정보 주문: 결제완료→출고대기 사건·허용 조건: 재고 예약됨	변화·이유 결제만으로 출고대기나 배송중이 되지는 않는다.
출고 뒤 배송중 출고대기 주문의 실제 출고 사건 뒤 배송중이 된다.	값·보충 정보 주문: 출고대기→배송중 사건·허용 조건: 출고 확인	변화·이유 출고대기는 출고가 이미 일어났다는 뜻이 아니다.
별도 분기: 결제완료에서 취소 이번 장면은 결제완료 시작점으로 돌아가 취소 사건이 있는 대안을 본다.	값·보충 정보 주문: 결제완료→취소 사건·허용 조건: 취소 사건·허용 상태	변화·이유 배송중에서 취소로 이어지는 경로를 만든 것이 아니며 다른 상태로 확대하지 않는다.

이 그림은 상태 이름보다 전이 조건이 핵심이다. 각 화살표에는 입력 사건, 허용 조건, 수행 동작, 새 상태가 있어야 한다. 같은 요청을 한 차례씩 처리하는 이 모형에서는 현재 상태와 요청 식별값을 확인해 기존 결과를 다시 줄 수 있다. 두 요청이 동시에 도착하면 둘 다 변경 전 상태를 볼 수 있으므로, 상태 확인만으로 중복 효과가 막히지는 않는다. 확인·처리 담당 확보·상태 변경 과정에 다른 작업이 끼어들 수 없도록 보호해야 하며, 그 필요는 동시성의 첫 직관에서 실제 순서로 확인한다. 일부 단계만 끝난 뒤 실패했다면 이미 한 일을 취소하거나 반대 작업으로 맞추는 보상도 필요하다. 이후 장에서는 거래를 한 덩어리처럼 다루는 방법, 같은 요청을 반복해도 결과를 한 번 처리한 것처럼 유지하는 방법, 통신 단계의 상태 규칙으로 이 원리를 더 엄밀하게 만든다.

데이터·사건·상태·출력을 구분한다

결제 승인 통지는 입력 사건이고, 통지의 승인번호는 데이터다. 이 입력을 검증해 주문을 결제완료 상태로 바꾸고, 고객에게 결제 완료 화면을 출력한다. 네 가지를 한 단어로 “정보”라고 부르면 재시도나 오류복구에서 무엇을 다시 받아야 하고 무엇을 되돌려야 하는지 알 수 없다.

사전대응과 피드백은 경쟁 관계가 아니다

피드포워드(feedforward)는 예상되는 입력이나 외부 변화를 미리 측정해 결과가 나빠지기 전에 조정한다. 예고된 할인행사의 예상 요청량을 보고 서버를 미리 늘리는 것이 예다. 피드백은 실제 지연시간과 오류율을 보고 목표에서 벗어난 만큼 조정한다.

피드포워드는 빠르지만 예측이 틀리면 과잉 또는 부족 대응을 한다. 피드백은 실제 결과를 반영하지만 측정과 조정이 늦으면 이미 장애가 커질 수 있다. 좋은 운영은 예상 수요로 기본 용량을 준비하고 실제 관찰로 보정한다. 시험 답안에서도 “사전 예방 대 사후 대응”처럼 한쪽을 버리는 표보다 예측 고리와 관찰 고리를 결합하는 구조가 더 정확하다.

기억하고 조정하는 데도 비용이 든다

상태를 많이 저장하면 정교한 판단과 복구가 가능하지만 여러 작업의 동시 접근, 서로 다른 사본의 값을 맞추는 동기화, 보존·삭제와 개인정보 위험이 커진다. 상태를 거의 두지 않는 무상태(stateless) 처리는 서버 사본을 늘리기 쉽지만, 긴 업무 흐름이나 중복 요청을 안전하게 처리하려면 별도 저장소와 요청 식별자가 필요하다. 따라서 “무상태가 좋다”가 아니라 어떤 상태를 누가 소유하고 얼마나 오래 보존하며 사본 간 일관성을 어떻게 유지할지 결정해야 한다.

피드백을 민감하게 하면 편차에 빠르게 반응하지만 순간적인 잡음에도 계속 설정을 바꾸는 진동이 생길 수 있다. 느리게 하면 안정적이지만 실제 이상을 늦게 잡는다. 관찰 주기, 판단 임계값, 조정 폭과 대기시간을 함께 설계해야 한다. 이 관계는 자동확장뿐 아니라 프로젝트 일정 통제, 보안 경보, 데이터 품질 개선에도 같다.

어디서 실패하는가

숨은 상태는 문서에 없는 임시 저장값, 사용자별 기억값, 운영자 메모가 결과를 바꾸는 경우다. 시험 환경에서는 재현되지 않고 특정 서버에서만 오류가 날 수 있다. 상태 소유자·저장 위치·수명·전이 규칙을 명시한다.

불법 전이는 현재 상태에서 허용되지 않은 사건을 받아 모순된 상태가 되는 경우다. 배송완료 뒤 주문취소로 곧바로 가면 물류와 환불이 분리된다. 상태별 허용 사건과 보상 절차를 검증한다.

관찰 지연은 실제 결과가 늦게 측정돼 이미 지난 상황을 기준으로 조정하는 경우다. 서버가 처리 작업으로 바쁜 정도를 늦게 보고 서버 수를 늘렸다 줄이면 진동한다. 측정시각·전송지연·판단에 사용한 시간범위를 함께 기록한다.

지연 없는 직접 되먹임은 현재 출력이 같은 시점의 현재 입력을 즉시 다시 결정하는 경우다. 어느 값을 먼저 계산해야 하는지 정할 수 없는 직접 대수 루프가 되어 인과적인 계산 순서가 깨질 수 있다. 이산시간 모델에서는 한 단계 뒤의 입력으로 되돌아가도록 상태나 지연을 두거나, 현재 입력과 현재 출력 사이의 직접 의존성을 끊는다.

잘못된 목표는 측정은 정확하지만 최적화 방향이 틀린 경우다. 평균 응답시간만 낮추면 소수 사용자의 긴 지연이나 실패율을 숨길 수 있다. 사용자 결과와 내부 자원지표를 연결한다.

고리가 끊긴 관제는 대시보드와 경보만 있고 담당자·권한·조치·결과확인이 없는 경우다. 관찰–비교–조정–재관찰의 책임과 시간을 정해 고리를 닫는다.

실무에서는 이렇게 보인다: 자동확장

자동확장은 요청량에 맞춰 실행 중인 서버 사본 수를 자동으로 늘리거나 줄이는 기능이다. 서버가 처리 작업으로 바쁜 비율이 70%를 넘으면 사본을 늘리도록 설정했다고 하자. 입력은 요청과 자원 사용량, 처리는 요청 처리와 확장 규칙, 출력은 응답과 서버 사본 수, 상태는 현재 사본·대기 요청·최근 관찰값이다. 피드백 고리의 목표는 단순히 바쁜 비율을 낮추는 것이 아니라 목표 지연과 오류율을 유지하면서 과도한 비용을 쓰지 않는 것이다.

바쁜 비율이 오르는 즉시 서버를 하나씩 늘리고 낮아지면 바로 줄이는 대안은 단순하지만 시작 지연과 측정 잡음 때문에 증설·축소를 반복할 수 있다. 채택 대안은 지연시간·대기 요청·오류율을 함께 보고, 일정 시간 지속된 편차에 단계적으로 반응하며, 증설 뒤 안정화 대기시간을 두는 것이다. 최대 용량과 축소 속도도 제한한다.

운영 지표는 고리의 각 부품을 보여 줘야 한다. 목표: 허용할 지연시간과 오류율, 관찰: 시간대별 지연·대기 요청·오류율, 판단: 조정을 시작할 기준과 지속시간, 조정: 서버 사본 증감 수와 상·하한, 검증: 조정 뒤 목표 회복 여부다. “자동확장을 적용한다” 한 줄은 메커니즘이나 실패대책을 설명하지 못한다.

이를 교육용 수치로 끝까지 진행해 보자. 서버 사본은 처음 2개, 상한은 4개이고 서버를 추가한 뒤 준비까지 1분이 걸린다고 가정한다. 운영팀은 1분마다 그 1분 동안의 요청 100건을 관찰하고, 95건 이상이 2초 안에 완료되며 실패가 1건 이하인지를 목표로 삼는다. 두 관찰 차례 연속으로 완료 목표에 못 미치고 대기 요청도 증가하면 사본을 1개 추가한다. 추가 뒤 2분 동안 추가 조정을 기다리면서 결과를 관찰한다. 이 수치는 제품 권고가 아니라 고리의 계산과 책임을 드러내기 위한 가정이다.

각 행의 완료 건수는 비율을 읽기 쉽게 요청 100건으로 고정한 가상 관찰값이며 실패는 모두 1건 이하라고 둔다. 증설이 항상 이런 개선을 보장한다는 뜻은 아니다. 4개까지 늘려도 회복되지 않으면 운영 담당자가 외부 결제 지연과 저장 지연을 확인하고 유입을 제한하거나 복구 경로를 선택한다. 상한 없이 계속 늘리는 대안은 비용만 늘리고 외부 병목을 해결하지 못할 수 있어 기각한다.

조건을 바꾸어 1분째 90건, 2분째 97건이 제시간에 완료되었다면 2분째에 증설할까? 연속 미달이 끊겼으므로 증설하지 않고 관찰한다. “한 번 95건보다 적었으니 곧바로 증설”이라는 답은 지속시간 조건을 빠뜨린 것이다. 위 표와 기억하고 조정하는 데도 비용이 든다의 진동 설명으로 돌아가 목표·관찰·판단·조정을 분리한 뒤 아래 설계 문제를 풀면 된다.

시험에서는 어떻게 묻는가

먼저 자체 제작 10점 문제로 핵심 관계를 확인한다.

시스템의 입력·처리·출력·상태·피드백을 정의하고, 상태와 피드백이 없는 모델의 한계를 설명하시오.

정의는 다섯 용어를 낱말풀이로 나열하라는 뜻이 아니다. 입력 + 현재 상태 → 처리 → 출력 + 새 상태와 목표–관찰–비교–조정 관계를 보여 줘야 한다. 한계에는 같은 입력의 다른 결과, 시간에 따른 전이, 오류복구와 자율조정의 설명 불가능성이 들어간다.

25점 문제에서는 이 관계를 설계와 실패대책으로 확장한다.

대규모 온라인 주문 시스템을 대상으로 입력·처리·출력·상태를 모델링하고, 서비스 수준을 유지하기 위한 피드백 통제구조와 설계 시 고려사항을 제시하시오.

요구는 ①주문 상태 모델, ②서비스 수준 통제 고리, ③상태 일관성·관찰 지연·진동·비용의 판단으로 나뉜다. 정의만 길게 쓰고 이 세 산출물 중 하나를 빠뜨리면 문제를 다 받지 못한다.

10점·25점 풀이 방향과 모범답안 보기

10점과 25점 목차 전환

10점 목차

1. IPO·상태·피드백 정의
2. 상태전이와 통제 고리 도식
3. 상태·피드백 누락의 한계

25점 목차

1. 개념과 모델링 원칙
   • 시스템 경계, 입력+상태→출력+새 상태, 닫힌 통제 고리
2. 온라인 주문의 기능·상태 모델
   • 주문·결제·재고 사건, 허용 전이, 출력과 보상
3. 서비스 수준 피드백 구조
   • 목표, 관찰, 편차 판단, 용량·유입 조정, 재관찰
4. 설계 고려사항과 실패대책
   • 상태 소유·일관성·수명, 관찰 지연, 진동, 상·하한, 담당자 승인·직접 복구
5. 결론
   • 고객 결과와 내부 지표를 연결한 안정적 폐루프 운영

10점에서 25점으로 갈 때 정의를 세 배로 늘리지 않는다. 실제 대상의 모델, 선택조건, 실패모드와 운영지표를 더한다.

답안 도식

주문·결제·재고 사건과 현재 주문상태를 한 번의 기능 변화에 넣어 검증·처리 후 고객응답·새 주문상태로 연결한다. 업무 상태전이와 운영 통제는 따로 읽는다. 지연·대기열·오류율을 관찰해 서비스 목표와 편차를 판단하고 유입제어·용량조정·복구를 수행한 뒤 조정 결과를 재관찰한다. 목표·관찰·조정 권한·재확인이 모두 이어져야 운영 통제 고리가 닫힌다.

첫 줄은 업무 상태전이, 아래 고리는 운영 피드백이다. 업무 데이터 흐름과 운영 통제 흐름을 분리해 그리면 주문의 정확성과 서비스 수준을 각각 어떤 상태와 지표가 지키는지 보인다.

10점 모범답안

입력은 시스템 경계를 넘어 들어오는 사건·데이터·자원, 처리는 입력과 현재 상태에 규칙을 적용하는 변화, 출력은 경계를 넘어 전달되는 결과다. 상태는 같은 다음 입력에 대한 행동을 달라지게 하는 현재의 기억이며, 피드백은 실제 출력·상태를 관찰해 목표와 비교하고 이후 행동을 조정하는 정보다.

한 번의 행동은 입력 x(t) + 상태 s(t) → 처리 → 출력 y(t) + 새 상태 s(t+1)로 나타낼 수 있다. 반복 통제는 목표 → 관찰 → 편차 비교 → 조정 → 재관찰의 닫힌 고리다. 주문 요청이 같아도 상태가 없음이면 주문을 만들고 결제완료이면 기존 결과를 돌려주는 것처럼, 상태는 시간에 따른 행동 차이를 설명한다.

상태를 빼면 중복처리, 허용 전이와 복구를 설명할 수 없고, 피드백을 빼면 결과가 목표에서 벗어나도 스스로 조정할 수 없다. 따라서 상태의 소유자·수명·전이 규칙을 명시하고, 피드백에는 목표·관찰지표·판단 임계값·조정권한·재검증을 연결해야 한다.

25점 모범답안

대규모 온라인 주문 시스템은 고객이 원하는 상품을 중복 없이 접수하고 결제·재고·배송 상태를 일관되게 전환하며 약속한 시간 안에 결과를 알려야 한다. 분석 경계는 주문 제출부터 확정 결과 통지까지로 두고, 결제사·물류사는 명시적 인터페이스를 가진 외부 환경으로 둔다.

기능 행동은 입력 + 현재 상태 → 처리 → 출력 + 새 상태로 모델링한다. 입력은 주문·결제승인·재고예약·취소 사건, 처리는 형식·권한·업무규칙 검증과 상태전이, 출력은 주문번호·처리결과·후속 요청이다. 상태는 없음–접수–결제완료–출고대기–배송중–완료의 흐름과 취소·보상 상태로 구성한다. 각 전이는 허용 사건, 전제조건, 수행 동작과 실패 시 보상을 가져야 하며, 중복 사건에는 상태와 요청 식별자를 확인해 기존 결과를 재사용한다.

서비스 수준은 폐루프 피드백으로 통제한다. 목표는 종단 간 지연·오류율·처리량과 비용 상한, 관찰은 시간창별 지연분포·대기열·오류율·현재 서버 사본 수와 상태다. 비교·조정 단계는 목표와 관찰의 편차가 일정 시간 지속되는지 판단하고, 용량 증감·유입 제한·대체 경로·장애복구를 수행한 뒤 결과를 다시 관찰한다. 예고 수요에 따른 사전 증설은 피드포워드로 결합한다.

설계 시 첫째, 업무 상태와 운영 상태의 소유자·저장 위치·수명·일관성 수준을 분리한다. 둘째, 불법 전이와 중복 사건을 차단하고 부분실패에는 보상·재처리와 담당자가 승인해 직접 복구하는 경로를 둔다. 셋째, 측정 지연과 잡음에 대비해 편차 지속시간과 조정 뒤 안정화 대기시간을 두고 증감 상·하한으로 진동과 비용 폭증을 막는다. 넷째, 평균만 보지 않고 상위 지연·실패율과 고객 완료율을 함께 사용한다.

결국 상태 모델은 업무 결과의 정확성을, 피드백 고리는 운영 결과의 안정성을 지킨다. 두 구조를 경계와 목적에 연결해야 국소 자원 최적화가 고객 주문완료를 해치지 않는 시스템을 만들 수 있다.

이 답안의 구체 설계로 앞의 교육용 자동확장 사례를 채택한다. 운영팀이 1분마다 요청 100건의 완료·실패와 대기를 측정하여 95건 이상 2초 내 완료·실패 1건 이하를 확인하고, 2회 연속 미달과 대기 증가 때 사본 2개에서 3개로 늘린다. 1분 준비시간과 2분 안정화 관찰, 최대 4개를 두며, 상한에서 회복하지 못하면 담당자가 외부 의존과 저장 병목을 확인하고 유입제어·복구를 선택한다. 산출물은 주문 전이표, 시간별 관찰표, 조정 이력과 회복 확인이며, 임계값만 보고 즉시 증감하는 대안은 진동 때문에 제외한다. 이런 가정·역할·조정 결과가 있어야 통제구조를 실제 설계한 답안이 된다.

근거와 표현 범위

상태의 수식은 유한상태기계와 동적 시스템에서 공통적으로 쓰는 관계를 초보자 수준으로 단순화한 것이다. 실제 시스템에서는 확률, 동시성, 분산된 상태와 시간 지연 때문에 (F)와 (G)가 하나의 단순 함수처럼 보이지 않을 수 있다. 이 절은 그 복잡성을 부정하지 않고 이후 이론을 읽기 위한 관계 뼈대만 제공한다.

피드백의 목표–관찰–비교–조정 관계는 MIT OpenCourseWare의 6.01SC 교재, §1.2.3 Models(2011-04-25 판, 인쇄면 14–15쪽)의 목표·실제 관찰값 차이로 행동을 조정하는 예로 확인할 수 있다. 상태와 다음 상태·출력의 관계는 같은 교재의 §4.1 State Machines와 연결된다. 원문의 그림이나 문장을 복제하지 않았으며, 자동확장 사례의 구체 임계값은 제품별 권고가 아니라 자체 설계 예시다.

기존 참고 표기인 Control Fundamentals §11.1.1·§11.7.2는 판본과 원문 위치가 확인되지 않아 이 절의 검증된 직접 근거로 사용하지 않는다. 확인된 위 교재의 지원 범위는 상태 관계와 목표·관찰 차이에 따른 조정이며, 주문 중복 방지나 자동확장 운영정책 전체의 보장을 대신하지 않는다.

30초 정리

1. 한 번의 행동은 입력 + 현재 상태 → 처리 → 출력 + 새 상태이며, 상태는 저장 데이터 전체가 아니라 다음 행동을 구분하는 기억이다.
2. 피드백 통제는 결과를 모으는 데서 끝나지 않고 목표–관찰–비교–조정–재관찰의 고리를 닫아야 한다.
3. 상태는 정확한 업무 전이를, 피드백은 안정적인 운영을 돕지만, 상태 동기화와 관찰 지연·진동·비용이라는 대가를 함께 설계해야 한다.

이제 어떤 시스템을 보더라도 목적과 경계 → 입력·상태·처리·출력 → 피드백과 실패 순으로 읽을 수 있다. 다음 절에서는 이 공통 틀을 비즈니스·서비스·애플리케이션·데이터·플랫폼·인프라의 여러 층에 적용한다.