»
S
I
D
E
B
A
R
«
3. 피드백이 필요한 이유(Why Feedback?)
February 25th, 2014 by Wegra Lee

이 글은 한국의 소프트웨어 개발자에게 피드백 제어(Feedback Control)란 개념을 소개하고자 Phillip Janert의 글을 번역한 것이다.


1부 – 피드백이란
2부 – 피드백 원칙
3부 – 피드백이 필요한 이유
4부 – 피드백은 다르다
5부 – 피드백 컨트롤러
6부 – 피드백 컨트롤러 튜닝
7부 – 자가적응과 피드백은 다르다


지난 두 글에서는 피드백 제어라는 개념을 소개했다. 기본적인 아이디어는 시스템(아무 시스템이나!)을 일정하게 유지하는 것이다. 시스템의 동작을 실제로 계속 관찰하여 의도치 않은 쪽으로 기울기 시작하면 원하는 쪽으로 되돌리게끔 수정 조치하는 식이다.

여기서 질문. 우리 프로그래머, 소프트웨어 엔지니어, 시스템 관리자가 여기에 관심을 둬야 하는 이유는 무얼까? 무슨 비밀이 숨겨져 있을까?

그 답은 바로 피드백이 오늘날 우리가 다루는 많은 문제에 대한 이상적인 해결책이라는 것이다. 생각해보라. 원하는 행위를 유지해야 하는 것이, 특히 엔터프라이즈 프로그래밍에서라면, 얼마나 흔한 문제인가? 다음의 예를 보자.

서버 스케일링: 웹 부하량 변화에 따른 서버 인스턴스 개수를 증가 혹은 감소시킨다.

주문 처리: 주문이 쇄도하더라도 고객의 주문이 일정한 속도로 처리되게끔 자원을 관리한다.

큐(queue) 제어: 큐의 한계 크기를 넘어서지 않도록 입력 요청의 흐름을 적절히 통제한다.

워크플로우 관리: 작업(work item)의 수가 항시 일정하도록 제어한다. 작업 완료율을 균일하게 유지하기 위해 워커(worker) 혹은 다른 자원을 동적으로 할당한다.

온도 제어: 온도를 적정히 유지하기 위해 냉각팬의 속도를 조절한다.

공급망(supply-chain) 관리: 수요가 요동치더라도 재고량을 일정하게 유지하는 시스템을 개발한다.

이상의 모든 예에서 우리는 일정한 서비스 품질(quality-of-service)을 보장해야 한다. (예를 들어 웹 트래픽이 폭주하더라도 고객에게 일정 시간 내에 응답을 줘야 한다.) 더욱이 이런 모든 상황에서 대상 시스템에 관해 100% 알고 있기는 어렵다. 폭주하는 요청을 처리하려면 ‘정확히’ 몇 대의 서버가 기동 되어야 할까? 이처럼 지식이 부족하므로 완벽히 자동화된 제어 알고리즘을 만들기는 어렵다.

피드백 제어는 이에 대한 새로운 접근법을 제시한다. 피드백 컨트롤러를 이용하면 트래픽에 대응하는 데 서버가 몇 대 필요한지 몰라도 된다. 대신 서비스 품질 수치(요청에 대한 응답 시간)를 관찰하면서 상황이 악화되면 서버 수를 늘리고 안정되면 더는 늘리지 않거나 줄이면 된다.

즉, 피드백 제어란 시스템 동작 원리를 완벽히 이해하지 못하더라도 주변 환경의 변화에 맞서 시스템을 일정하게 유지하는 방법이다. 시스템을 가동 중에 자동으로 그리고 동적으로 재설정하는 아주 간단한 방법이라 표현할 수도 있다.

피드백 제어는 원하는 동작을 유지해야 하는 모든 시스템에 도움을 줄 수 있다. 하지만 컴퓨터 시스템 분야에서 많이 쓰이는 알고리즘 기반 접근법과는 분명한 차이가 있고, 필요한 기술 역시 다르다. 다음에는 피드백과 규칙(rule) 기반 알고리즘의 차이점을 배워보자. 조금만 기다리라!


»  Substance: WordPress   »  Style: Ahren Ahimsa