이 문서는 자라는 중인 질문입니다. 아직 증거를 모으고 있으며, 내용이 바뀔 수 있습니다.
한 줄로 말하면
feedback loop는 행동의 결과를 다음 행동의 입력으로 되돌려, 목표에 맞게 계속 조정하는 구조야. 단순히 같은 일을 되풀이하는 것과는 다르게, 결과가 다음 선택을 바꿔야 해.
비유로 이해하기
온도 조절기를 생각해 보자. 방이 목표 온도보다 차가우면 난방을 켜고, 온도가 올라가면 다시 측정해 난방을 줄이거나 끈다. 난방이 만든 결과가 다음 난방 판단으로 돌아오는 거야.
여기까지가 쉽게 이해를 돕는 비유야. 실제 피드백은 온도처럼 숫자 하나만 되돌아오는 경우가 드물어. 코드 테스트의 실패 메시지, 플레이어의 불만, 생산 설비의 불량률처럼 여러 신호가 들어올 수 있고, 무엇을 신호로 삼을지 정하는 일도 구조의 일부야.
정확한 정의
feedback loop에는 적어도 다섯 자리가 필요해. 목표나 기준이 있고, 행동이 있고, 그 결과를 재는 신호가 있고, 신호를 기준과 비교하는 규칙이 있고, 그 비교가 다음 행동을 바꿔야 해.
flowchart LR A["목표와 기준"] --> B["행동 선택"] B --> C["현실의 결과"] C --> D["결과 측정"] D --> E["차이 해석"] E --> B
목표와 결과의 차이를 줄이도록 행동을 고치면 보통 음의 피드백이라고 불러. 온도 조절기처럼 너무 높으면 낮추고, 너무 낮으면 올리는 경우야. 반대로 어떤 변화가 같은 방향의 다음 변화를 더 키우면 양의 피드백이 돼. 어느 쪽이 좋다는 뜻은 아니야. 목표, 시간 지연, 조절 폭에 따라 안정적으로 수렴할 수도 있고 점점 흔들릴 수도 있어.
중요한 구분은 반복과 피드백은 같은 말이 아니라는 점이야. 매주 보고서를 만드는 일은 반복이지만, 보고서가 다음 주의 우선순위나 행동을 바꾸지 않으면 feedback loop는 아니야. 반대로 한 번의 테스트 결과가 다음 코드 수정을 바꾸면 짧은 loop가 이미 시작된 거야.
왜 중요한가
많은 일은 처음 선택이 완벽할 수 없어서, 결과를 얼마나 빨리 읽고 고치는지가 품질과 속도를 좌우해. 특히 도구를 쓰며 여러 단계를 밟는 agent loop에서는 실행 결과가 다음 행동의 재료가 돼. agentic workflow는 여기에 권한, 검증, 사람의 개입까지 묶는 더 큰 작업 흐름이야.
개발 도구도 이 구조를 잘 보여줘. Microsoft는 TypeScript 7.0의 공개 사례에서 vscode 빌드 시간이 125.7초에서 10.6초로, sentry는 139.8초에서 15.7초로 줄었다고 제시했어.1 이 수치만으로 개발 품질이 자동으로 좋아진다고 말할 수는 없어. 다만 오류를 보고 고치고 다시 확인하는 고리가 짧아지면, 개발자가 한 번의 큰 수정 대신 작은 수정과 확인을 더 자주 할 조건은 생겨.
게임 운영에서는 결과 신호가 사람의 말로 들어오기도 해. PlayStation Studios 강연은 Marathon 게임플레이 공개 뒤 4만 건이 넘는 플레이어 대화를 주제와 감정으로 분류해 개발팀이 읽을 수 있는 리포트로 만들었다고 소개했어.2 이 사례에서 모델의 분류는 끝이 아니야. 팀이 무엇을 읽고 어떤 결정을 바꾸는지가 그 다음 고리를 결정해.
실제 예시
온도 조절기는 가장 단순한 예시야. 센서가 온도를 읽고, 목표 온도와 비교하고, 난방 장치를 조절하고, 바뀐 온도를 다시 읽어. 센서가 고장 나거나 방이 데워지는 속도보다 조절이 너무 빠르면, 목표 근처에서 켜고 끄기를 반복할 수도 있어. 그래서 신호의 정확도와 시간 지연도 loop의 일부야.
코드 수정도 비슷해. 개발자가 코드를 고치고 타입 검사나 테스트를 돌린 뒤, 오류 메시지를 보고 다음 수정을 고른다. TypeScript 7.0의 네이티브 포트는 이 확인 시간을 줄이려는 사례야. 빠른 검사 자체보다, 검사 결과가 다음 행동으로 얼마나 잘 이어지는지가 더 중요해.
라이브 서비스 게임에서는 플레이어 의견, 지원 티켓, 접속 이상, QA 보고가 결과 신호가 될 수 있어. 게임 AI의 운영 적용 사례처럼 많은 신호를 분류해 사람이 읽을 수 있게 만드는 단계는 loop를 시작하기 쉽게 해. 하지만 많은 의견을 가장 많이 받은 항목만 고치면 특정 집단의 목소리가 과하게 커질 수 있어. 신호를 모으는 일과 그 신호를 어떻게 해석할지는 분리해서 봐야 해.
헷갈리지 말아야 할 점
- 많이 측정한다고 loop가 되는 건 아니야. 측정값이 다음 행동을 바꾸지 않으면 대시보드나 기록에 머물러.
- 빠른 loop가 항상 좋은 건 아니야. 신호가 늦게 나타나는 문제를 너무 빨리 조절하면 같은 행동을 과하게 되돌리며 흔들릴 수 있어.
- 지표는 목표 자체가 아니야. 클릭 수나 오류 건수처럼 측정하기 쉬운 값만 좇으면, 실제로 지키려던 품질이나 사용자 경험을 놓칠 수 있어.
- 사람의 판단이 사라지는 구조가 아니야. 무엇을 측정하고 어느 변화가 충분한지 정하는 일은 여전히 사람이 맡을 수 있어.
관련 문서
- 실행 결과를 받아 다음 행동을 고르는 반복 단위: agent loop
- 도구·권한·검증·사람의 개입을 묶는 큰 작업 흐름: agentic workflow
- 타입 검사 속도가 개발 확인 주기에 미치는 사례: TypeScript 7.0의 네이티브 포트
- 플레이어 신호를 운영 판단에 연결하는 사례: 게임 AI의 운영 적용 사례
남은 질문들
- 시간 지연과 조절 폭은 언제 안정적인 보정을 흔들리는 과잉 반응으로 바꿀까?
- 개발 도구의 확인 주기가 짧아졌을 때, 실제 결함률과 배포 주기는 어떤 조건에서 함께 좋아질까?
- 플레이어 의견처럼 편향될 수 있는 신호를 제품 결정에 넣을 때, 어떤 보정 장치가 필요할까?
댓글