목적·환경·경계·이해관계자

먼저, 어디까지를 한 시스템으로 볼 것인가

온라인 주문이 늦어졌다고 해 보자. 주문 접수 담당자는 접수 응답을, 주문 기록 담당자는 저장 대기를, 물류 담당자는 재고 배정을, 고객은 결제부터 배송까지의 전체 경험을 본다. 모두 같은 사건을 말하지만 각자가 머릿속에 그린 시스템의 범위가 다르다. 이 범위를 맞추지 않고 원인을 논하면 한 사람은 “정상”이라 하고 다른 사람은 “장애”라고 하는 일이 생긴다.

시스템 사고의 첫 질문은 “어떤 기술을 썼는가?”가 아니다. 먼저 무슨 목적을 위해 무엇을 한 덩어리로 보고 어디까지 책임질 것인지 물어야 한다. 이 질문에 답해야 뒤에서 배우는 아키텍처, 데이터베이스, 네트워크, 보안, 프로젝트 관리가 서로 다른 암기 과목이 아니라 같은 대상을 보는 여러 관점으로 연결된다.

한 문장으로 말하면

시스템은 어떤 목적을 이루기 위해 서로 영향을 주고받도록 묶어 본 여러 요소의 집합이다. 요소가 많다고 자동으로 시스템이 되는 것은 아니다. 요소 사이의 관계가 있고, 그 관계를 통해 개별 요소만으로는 내기 어려운 전체 결과가 나타나야 한다.

예를 들어 요청을 받아 처리하는 컴퓨터인 서버 한 대도 관찰 목적에 따라 시스템이 될 수 있다. 명령을 실행하는 장치, 작업 중인 값을 두는 기억장치, 컴퓨터를 제어하는 기본 프로그램과 주문 프로그램의 상호작용을 분석한다면 서버가 관심 시스템이다. 반대로 전국 주문 서비스를 분석할 때 그 서버는 더 큰 시스템을 이루는 한 요소일 뿐이다. 그러므로 “시스템”은 물건에 영구히 붙는 이름이 아니라 지금 해결하려는 문제에 맞춰 정한 관찰 단위다.

경계를 정하기 전에 목적과 환경을 분리한다

시스템 목적은 시스템이 만들어야 하는 가치와 관찰 가능한 성공상태다. 환경은 시스템 경계 밖에서 조건·자원·사건을 주거나 결과의 영향을 받는 대상이다. 목적은 무엇을 성공으로 볼지 정하고 환경은 직접 통제할 수 없는 조건과 교환을 드러내므로, 둘을 먼저 적어야 안과 밖을 가르는 경계를 설명할 수 있다.

경계 앞에서 되찾기

바로 위 설명을 가린 채, 고객에게 약속한 상품을 인도하는 일을 성공으로 볼 때 직접 책임질 요소와 외부 조건을 하나씩 떠올려 보자. 목적과 환경이 섞이면 경계를 정하기 전에 목적과 환경을 분리한다 항목으로 돌아간다. 아래에서는 이 구분을 정확한 정의로 연결한다.

정확히 말하면

공학에서 시스템은 보통 하나 이상의 명시된 목적을 이루도록 조직된 상호작용 요소의 결합으로 본다. 요소에는 하드웨어와 소프트웨어뿐 아니라 데이터, 사람, 업무 절차, 시설과 외부 서비스도 들어갈 수 있다. 이 정의에서 반드시 남겨야 할 말은 세 가지다.

첫째, 목적이다. 목적이 없으면 무엇이 올바른 동작인지 판정할 기준도 없다. 쇼핑 서비스의 목적을 “주문을 빠르게 접수”로만 잡으면 실제 재고가 없어도 성공 응답을 돌려줄 수 있다. “고객에게 약속한 상품을 정확히 인도”까지 포함하면 재고·결제·배송이 함께 성공해야 한다.

둘째, 요소와 상호작용이다. 요소 목록만 적으면 부품표이지 시스템 설명이 아니다. 주문 서비스, 결제 서비스, 재고 데이터베이스(DB)가 어떤 정보와 통제 신호를 주고받는지 설명해야 전체 동작이 드러난다.

셋째, 경계와 환경이다. 경계(boundary)는 이번 분석에서 시스템 안에 포함할 것과 밖에 둘 것을 가르는 결정이다. 환경(environment)은 경계 밖에 있으면서 시스템에 조건·자원·사건을 주거나 시스템의 결과에 영향을 받는 주변이다. 경계 밖이라고 중요하지 않은 것이 아니다. 오히려 외부 결제사, 법규, 전력, 사용자는 시스템이 직접 통제하기 어렵기 때문에 무엇을 어떤 형식과 시간 안에 주고받을지 정한 인터페이스, 그리고 분석을 위해 사실이라고 두는 가정이 필요하다.

경계가 보이는 한 장의 그림

다음은 이 절에서 구성한 온라인 주문 맥락도다. ‘온라인 주문 시스템 내부’ 묶음이 이번 분석의 경계 안이며, 외부 관계의 이름은 경계를 통과하는 약속이다.

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

이 맥락도는 내부 요소 전체를 하나의 경계 통과 접점으로 묶고 외부 요청·응답의 방향을 보여 준다. 내부의 다섯 연결은 다음 확대도에서 따로 보이며, 그 선에는 방향과 처리 순서를 정하지 않는다.

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

주문·결제조정·재고배정·주문상태·이력의 다섯 연결을 확대한 그림이다. 선은 내부 요소 사이의 관계이며, 처리 순서나 요청·응답 방향을 정하지 않는다.

결제·물류의 네 관계에 나오는 ‘온라인 주문 시스템’은 내부 요소를 묶은 바로 그 대상이다. 결제사와 물류사는 주문 시스템과 각각 연결되며 서로의 중계 경로가 아니다.

이 그림의 핵심은 네모의 모양이 아니다. 안쪽 요소의 책임, 바깥 참여자의 기대, 경계를 넘는 정보와 통제를 한 번에 합의한다는 데 있다. 결제사가 시스템 밖이라면 주문팀이 결제사 내부 장애를 직접 고칠 책임은 없지만, 시간초과·중복 승인·응답 위조에 대비할 책임은 남는다. 경계 결정은 책임을 없애는 행위가 아니라 통제할 것과 계약으로 다룰 것을 구분하는 행위다.

경계는 네 단계로 정한다

다음 네 단계는 이 절에서 경계 설정을 연습하도록 구성한 절차다. 경계를 그릴 때는 대상을 먼저 고르는 대신 다음 순서를 사용한다.

1. 결정을 적는다. “주문 지연의 책임과 개선 지점을 찾는다”처럼 이번 분석이 내려야 할 결정을 쓴다.
2. 목적과 성공조건을 적는다. 주문 접수뿐 아니라 중복 결제 방지, 재고 확보, 약속한 시간 안의 상태 통지처럼 관찰 가능한 결과를 쓴다.
3. 결과를 직접 만들어 내는 요소와 관계를 넣는다. 사람·절차·데이터를 기술 구성요소와 같은 수준으로 살핀다.
4. 밖에 둔 대상과 경계 통과 계약을 적는다. 누가 무엇을 보내고, 시간·형식·오류·권한을 어떻게 약속하는지 적는다.

경계는 한 번 정하면 영원히 고정되는 선이 아니다. 같은 주문 서비스도 성능을 볼 때는 애플리케이션과 DB를 중심으로 잡고, 개인정보 책임을 볼 때는 고객 화면에서 물류사 전달과 보존·파기까지 넓혀야 한다. 다만 분석 도중 불리한 요소를 슬쩍 빼거나 넣으면 결론을 조작하게 되므로, 왜 경계를 바꿨는지는 반드시 남긴다.

분석 경계와 운영 책임은 함께 적되 같은 것으로 단정하지 않는다. 고객 완료시간을 조사하려고 외부 결제 구간까지 관찰 범위를 넓혀도 주문팀이 결제사 내부를 직접 고칠 권한을 얻는 것은 아니다. 전체 결과를 볼 범위, 주문팀이 직접 변경할 요소, 외부에 약속받을 인터페이스를 각각 표시한다. 이 절의 내부·외부 도식은 그중 주문팀의 관심 시스템을 표현한 예다.

기능과 시스템은 같은 말이 아니다

기능(function)은 “무엇을 하는가”를 나타낸다. 시스템은 그 기능을 실제 환경에서 수행하는 요소와 관계의 묶음이다. 결제 승인이라는 기능은 내부 규칙과 입력·출력으로 설명할 수 있지만, 결제 시스템을 설명하려면 사용자 확인, 거래기록, 통신경로, 운영 담당자, 장애가 났을 때 되돌리는 절차와 외부 기관까지 살펴야 한다.

둘 중 하나가 더 우월한 것이 아니다. 시스템 경계를 정한 뒤, 경계 안의 중요한 기능을 입력–처리–출력으로 확대해 보는 식으로 함께 쓴다. 다음 절인 입력·처리·출력·상태·피드백에서 다룰 입력·처리·출력은 시스템의 전부가 아니라 시스템 행동을 설명하는 렌즈다.

경계를 넓히거나 좁힐 때 드는 비용

경계를 넓히면 전체 최적화와 종단 간 위험을 보기 쉬워진다. 대신 조사할 요소와 이해관계자가 늘어 원인 분리와 책임 합의가 어려워진다. 경계를 좁히면 한 팀이 통제 가능한 부분을 빠르게 분석할 수 있지만, 실제 고객 결과를 바깥 탓으로 돌리거나 외부 의존 실패를 놓칠 수 있다.

따라서 좋은 경계는 가장 큰 경계도, 가장 작은 경계도 아니다. 지금 내려야 할 결정을 설명하는 데 필요한 책임과 인과관계를 모두 포함하면서도 분석 가능한 범위다. 실무에서는 넓은 맥락도 한 장과, 그 안의 관심 시스템을 확대한 내부도 한 장을 짝으로 두면 이 균형을 잡기 쉽다.

경계가 잘못되면 생기는 네 가지 실패

목적 없는 경계는 조직도나 제품 이름을 그대로 네모로 그린다. 그러면 무엇을 성공으로 볼지 정한 기준이 없어 필요한 요소를 판정할 수 없다. 먼저 결정과 성공조건을 적어 예방한다.

사람과 절차가 빠진 경계는 서버가 정상인데 서비스가 멈추는 이유를 설명하지 못한다. 승인 대기, 수동 배치, 당직 인계도 상태와 지연을 만든다. 기술·데이터·사람·절차를 한 번씩 점검한다.

외부 의존을 단순 화살표로만 둔 경계는 시간초과, 재시도, 데이터 소유권과 장애 책임을 놓친다. 화살표마다 요청자, 제공자, 데이터, 시간, 오류, 권한을 붙인다.

분석 중 움직이는 경계는 문제가 발견될 때마다 원인을 밖으로 밀어낸다. 최초 경계와 가정을 기록하고, 변경 시 결론에 미친 영향을 다시 평가한다.

실무에서는 이렇게 보인다

예시

다음은 이 절에서 구성한 주문 지연 사례다.

어느 회사가 “주문 접수 요청 1,000건 중 약 999건이 0.3초 안에 응답한다”고 보고했지만 고객은 결제 완료 화면을 8초씩 기다렸다. 접수 담당 팀의 경계에는 요청 수신부터 주문번호 발급까지만 들어 있었고, 결제사 승인과 재고 확인은 접수 응답 뒤에 따로 계속되는 후속 과정이었다. 지표 자체는 거짓이 아니었지만 고객 목적을 대표하지 못했다.

이 경우 먼저 고객 관점의 관심 시스템을 주문 제출 → 결제·재고 확정 → 결과 통지로 넓힌다. 그다음 내부 경계로 다시 내려가 주문 접수, 후속 요청을 잠시 보관해 전달하는 대기열, 외부 결제 연결, 재고 확인의 각 지연을 잰다. 넓은 경계는 무엇을 최적화할지, 좁은 경계는 어디를 고칠지 알려 준다.

채택 대안은 고객 요청 시작부터 최종 결과까지의 완료시간과 단계별 시간을 함께 관리하는 것이다. 접수 응답시간만 유지하는 대안은 팀 운영에는 편하지만 고객 지연을 숨기므로 기각한다. 반대로 모든 외부 사업자의 내부 지표까지 직접 소유하려는 대안은 통제권이 없어 실행할 수 없다. 외부 구간은 기대하는 성공수준, 기다릴 최대시간, 실패 시 사용할 다른 경로와 처리상태를 알려 주는 약속으로 관리한다.

이제 같은 사례에서 결제사의 응답만 늦고 내부 주문번호 발급은 정상이라고 조건을 바꿔 보자. 어떤 범위를 조사하고 누가 어떤 조치를 맡아야 할까? 먼저 직접 통제할 조치와 외부에 요청할 조치를 나누어 적어 보자.

조건 변경 사례의 풀이 보기

고객 완료시간을 볼 때는 결제 응답을 포함한 전체 흐름을 조사하고, 내부 개선 책임을 정할 때는 주문팀이 관리하는 대기시간·재시도·상태통지와 결제사의 승인 처리를 나누어 적는다. 결제사 내부를 직접 고칠 수 없어도 주문팀은 기다릴 최대시간을 정하고 확인된 처리 상태를 고객에게 알릴 수 있다. 응답 시간초과만으로 결제 실패나 취소를 확정하지 않는다. 결제사가 승인했지만 응답만 유실됐을 수 있으므로 결과 미확인 상태를 남기고 기존 거래의 결과를 확인한다. 재시도는 제공자의 계약에 따라 같은 논리적 거래임을 식별해 중복 승인을 막아야 한다.

부족한 답안	부족한 이유	조건을 반영한 개선 답안
외부 결제사가 원인이므로 시스템 분석에서 빼면 된다.	환경의 영향을 책임과 함께 지워 버린다.	고객 완료시간 분석에는 결제 응답을 포함하고, 주문팀의 대기시간·재시도·상태통지와 결제사의 승인 처리를 나누어 적는다.
결제사 내부도 모두 주문팀 책임이다.	주문팀의 통제권을 넘긴다.	결제사 내부는 직접 통제 범위 밖에 두되, 주문팀이 정할 최대 대기시간과 고객 상태 통지는 남긴다. 시간초과는 결과 미확인으로 구별하고 실제 승인·거절 결과를 확인한다.

두 오답은 경계는 네 단계로 정한다 항목으로 돌아가 직접 책임질 요소와 외부 계약을 다시 나누면 고칠 수 있다. 이 구분을 스스로 설명한 뒤 아래 시험 문제에서 정의·문제·개선방안을 묶어 본다.

시험에서는 무엇을 묻는가

다음은 이 절의 이론을 확인하기 위한 자체 제작 10점 문제다. 실제 기출이나 공식 배점 기준을 인용한 문제가 아니다.

시스템의 목적·경계·환경을 정의하고, 온라인 주문 시스템의 경계를 잘못 설정했을 때 발생하는 문제와 개선방안을 설명하시오.

요구어는 세 개다. 정의에는 목적·요소·상호작용·경계가 들어가야 한다. 문제에는 잘못된 경계가 만든 인과관계가 필요하다. 개선방안에는 단순히 “경계를 명확히 한다”가 아니라 결정–성공조건–요소–외부계약의 절차가 필요하다. 주문 사례는 이 세 논점을 구체화하는 증거이지 별도의 장식이 아니다.

답안을 보기 전에 정의·문제·개선방안을 각각 한 문단으로 써 보자. 정의가 막히면 정확히 말하면, 원인과 개선이 연결되지 않으면 실무에서는 이렇게 보인다와 경계는 네 단계로 정한다로 돌아간다.

풀이 방향과 완성 답안 보기

10점 답안 목차

1. 시스템과 경계의 정의
   • 목적을 위해 상호작용하는 요소의 결합
   • 관심 시스템과 환경을 가르는 책임·분석 범위
2. 온라인 주문 맥락도
   • 내부: 주문·상태·재고조정
   • 외부: 고객·결제사·물류사와 경계 계약
3. 잘못된 경계의 문제
   • 국소 지표 최적화, 외부 의존 누락, 책임 공백
4. 개선방안
   • 결정과 성공조건 → 요소·관계 → 인터페이스 → 경계변경 기록

답안 도식

온라인 주문 시스템의 경계와 계약을 목적·성공조건을 기준으로 읽는다. 외부 환경이 보내는 조건은 입력 계약으로 경계를 통과하고, 관심 시스템 안의 요소와 관계가 결과를 만든다. 밖으로 나가는 결과와 영향은 출력·책임 계약으로 명시한다. 내부 관계는 처리 순서를 정하지 않는 연결이며, 경계 설정의 기준은 물리 위치가 아니라 이번 목적에 필요한 책임과 인터페이스다.

도식 아래에는 “경계는 단순한 물리선이 아니라 목적에 필요한 책임과 인터페이스를 정하는 분석 결정”이라고 해석을 붙인다. 이 한 문장이 없으면 그림은 네모와 화살표 목록으로 끝난다.

10점 모범답안

시스템은 하나 이상의 목적을 달성하도록 조직된 상호작용 요소의 결합이며, 시스템 경계는 분석 대상인 관심 시스템과 그 환경을 구분하는 범위 결정이다. 경계 안에는 목적 달성에 직접 책임지는 기술·데이터·사람·절차를 두고, 밖의 대상은 중요하지 않은 것이 아니라 명시적 인터페이스와 가정으로 관리한다.

온라인 주문을 주문번호를 발급하는 내부 기능으로만 좁히면 응답시간은 좋아도 결제·재고 확정과 고객 통지가 늦는 종단 간 실패를 놓친다. 반대로 결제사와 물류사의 내부 운영까지 모두 포함하면 통제권이 없는 범위 때문에 책임과 측정이 흐려진다. 고객 목적을 기준으로 주문 제출부터 결과 통지까지를 상위 관심 시스템으로 두고, 내부에는 주문·결제조정·재고배정·상태이력을, 외부에는 고객·결제사·물류사를 둔다.

경계는 ①분석할 결정, ②목적과 성공조건, ③결과를 만드는 요소와 관계, ④외부 인터페이스의 데이터·시간·오류·권한 순으로 정한다. 종단 간 완료시간과 내부 단계별 시간을 함께 측정하고, 외부 구간은 서비스 수준·시간초과·대체경로·상태통지 계약으로 통제한다. 경계를 바꿀 때는 이유와 결론 변화를 기록해 원인을 임의로 밖으로 밀어내지 않아야 한다.

경계와 책임을 직접 판단하는 세 연습

연습 1. 접수 요청 1,000건 중 999건이 0.3초 안에 주문번호를 받았지만 고객의 결제·재고 확정 화면은 8초 뒤에 나타났다. 접수 응답의 비율을 계산하고, 이 값만으로 고객 완료시간 목표를 달성했다고 말할 수 있는지 설명하자. 측정의 시작·끝도 각각 적자.

연습 2. 결제 요청을 보낸 뒤 3초가 지나도록 응답이 없었다. 주문팀은 결제사 내부를 바꿀 수 없다. 고객에게 바로 “결제가 실패했습니다”라고 알리고 새 거래로 다시 결제해도 될까? 직접 할 조치와 외부 계약으로 확인할 조치를 나누자.

연습 3. 주문 서버와 DB는 정상인데 담당자의 수동 재고 승인이 10분 지연됐다. “서버가 정상이므로 주문 시스템도 정상”이라는 답을 고치자. 목적이 약속한 상품의 인도일 때 포함할 요소, 단계별로 관찰할 시간, 개선 책임을 적자.

세 연습의 판단 과정과 해설 보기

1. 999/1,000×100=99.9%는 요청 수신부터 주문번호 응답까지 0.3초 안에 끝난 접수 요청의 비율이다. 결제·재고 확정까지의 성공 비율이나 8초 완료시간을 대신하지 않는다. 고객 측정은 주문 제출에서 최종 결과 통지까지로 정하고 같은 요청을 단계별 기록과 연결한다. 시간초과·오류는 완료 표본에서 조용히 빼지 않고 별도로 기록해야 한다.

2. 응답이 없다는 관찰만으로 승인 여부는 알 수 없다. 주문팀은 결과 미확인을 기록·통지하고 기존 거래 식별자로 결과를 확인하며 기다릴 기한과 후속 조치를 관리한다. 결제사에는 결과 조회와 재시도 식별 계약을 확인한다. 같은 거래의 재시도에 제공자가 지원하는 멱등성 식별자를 유지할 수 있지만, 새 식별자로 무조건 다시 요청하면 중복 결제 위험이 있다. 이는 결제사 내부를 직접 수정할 책임과 구별된다.

3. 서버 상태만으로 상품 인도라는 목적의 성공을 판정할 수 없다. 승인 담당자·승인 절차·승인 대기 상태도 결과를 만드는 요소다. 고객 완료시간에는 수동 승인 대기를 포함하고, 내부 조사에서는 승인 요청·확인·처리 시간과 인계 기록을 나눈다. 운영 책임자는 승인 절차·기한·대체 담당을 개선하고 기술 담당자는 필요한 상태·통지·측정 지원을 맡는다. 담당자의 개인 오류로 단정하기 전에 실제 대기 기록과 업무 조건을 확인한다.

내 답안을 고치는 기준

작성한 답안을 다음 기준으로 고친다. 이 절의 자체 연습을 확인하는 기준이며 공식 채점표가 아니다.

• 목적·환경·경계를 서로 구별하고, 요소 목록에 그치지 않고 상호작용을 설명했는가? 빠진 개념은 정확히 말하면 항목에서 확인한다.
• 좁은 경계가 고객 완료시간을 놓치는 이유와 지나치게 넓은 경계가 통제권을 흐리는 이유를 사례의 조건으로 설명했는가? 실무에서는 이렇게 보인다 항목과 대조한다.
• 주문팀이 직접 바꿀 조치와 결제사에 약속받을 계약을 나누고, 개선방안이 앞서 쓴 문제의 원인을 해결하는가? 경계는 네 단계로 정한다 항목을 되짚는다.

답안에서 빠진 조건을 고친 뒤, 풀이를 다시 접고 ‘넓은 경계로 무엇을 찾고 좁은 경계로 무엇을 찾는가’를 한 문장으로 회상해 보자.

근거와 표현 범위

시스템의 목적·요소·관계·환경 설명은 NIST SP 800-160 Vol. 1 Rev. 1, §2.1.1 Systems and System Structure(2022-11-16 최종 공개, 인쇄면 7–8쪽)을 기준으로 삼는다. 시스템 범위와 외부 인터페이스·환경의 실무 구분은 NASA Systems Engineering Handbook, Rev. 2, Appendix J / J.3 / 3.5 Boundary of Technical Effort(인쇄면 227쪽)로 교차 확인한다. NASA 문서 번호는 NASA/SP-2016-6105 Rev. 2이고, 공식 기록의 발행일은 2017-02-17이다.

위 절과 판본은 2026-10-04에 공식 자료에서 확인했다. NIST는 시스템 구조의 설명이고 NASA의 해당 절은 시스템 엔지니어링 관리계획에 넣을 경계 설명 안내다. 이 절의 네 단계, 주문 사례·도식, 10점 문제·답안은 그 개념을 연습하기 위한 저자 구성이지 공식 고정 절차나 채점 기준이 아니다. 두 자료에 포함된 제3자 표준의 문구·표·도식은 이 교재의 직접 근거로 복제하지 않는다.

NASA의 직접 통제 구분은 시스템 엔지니어링 관리계획에서 기술적 노력의 경계를 설명하는 문맥이다. 이를 모든 분석 경계의 보편 정의로 넓히지 않는다. 결제 시간초과 사례는 Stripe의 네트워크 오류 안내와 멱등 요청 안내로 결과 미확인과 같은 거래 재시도의 구분을 대조했다(2026-10-09 확인). 해당 API의 보장과 키 보존 조건은 제공자·연산에 따라 확인하며 모든 결제 시스템의 영구적 단 한 번 실행을 뜻하지 않는다. 이 교재가 특정 결제사를 사용한다는 뜻도 아니다.

이 절의 입력–처리–출력 표현은 국제표준의 시스템 정의를 대체하지 않는다. 복잡한 시스템의 행동을 초보자가 추적하기 위한 기능 분석 틀로만 사용하며, 사람·환경·상호작용과 창발적 결과를 누락하지 않는다.

30초 정리

1. 시스템은 목적을 위해 상호작용하는 요소의 결합이며, 요소 목록만으로는 시스템 설명이 되지 않는다.
2. 경계는 이번 결정에서 무엇을 시스템과 환경으로 볼지 정하는 분석 범위다. 그 범위에 직접 통제할 책임과 외부 계약을 함께 표시한다.
3. 넓은 경계로 고객 결과를 찾고 좁은 경계로 수정 지점을 찾되, 경계 변경의 이유를 기록한다.

다음 절인 입력·처리·출력·상태·피드백에서는 경계 안의 행동을 입력 → 처리 → 출력으로 펼치고, 같은 입력에도 결과가 달라지는 이유를 상태, 결과를 다음 행동에 되돌리는 구조를 피드백으로 설명한다.