»
S
I
D
E
B
A
R
«
2. 피드백 원칙(The Feedback Principle)
February 25th, 2014 by Wegra Lee

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


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


앞의 글에서 피드백의 기본적인 개념은 소개하였으니, 이제 본격적인 이야기를 시작해보자.

피드백이란 시스템을 정상 궤도에 있게끔 유지하는 방법이다. 다시 말해 시스템이 기대한 바대로 동작함을 보장하는 방법이다. QoS(Quality of Service)를 제공해야 한다면 피드백은 시스템을 원하는 서비스 수준으로 유지해주는 믿을만한 수단이 되어줄 것이다. 심지어 불확실성과 많은 변화가 존재하는 상황에서도 말이다.

캐시를 예로 들어보자. 웹 캐시건 DB 캐시건 마찬가지다. 어떤 캐시이건 QoS 지표는 적중률(hit rate)이 될 거다. 요청받은 아이템이 캐시 안에 있을 확률 말이다. 우리가 보장하고자 하는 적중률은 여러 외부 상황에 따라 다르겠지만, 편의상 여기선 85%라 치자. 이 값을 우리는 참조값(reference value) 혹은 설정값(setpoint)라 한다.

이제 이 목표 달성을 위해 우리가 조절할 수 있는 변수에는 무엇이 있을지 생각해보자. 다행히 캐시는 단순한 편이다. 캐시의 크기. 즉, 캐시가 보관할 수 있는 아이템의 총 개수가 그것이다.

출력량(캐시 적중률)을 원하는 만큼 키우려면 이 입력 변수(캐시 크기)를 어느 방향으로 조절해야 하는지도 알아야 한다. 이 역시 캐시 예에서는 어려울 게 없다. 캐시 크기를 키우면 적중률이 높아진다.

janert-feedback-loop1

앞의 그림과 같은 폐루프(closed-loop) 시스템을 생각해보자. 우리가 제어하고자 하는 캐시는 우측에 있는 붉은 박스다. 캐시는 들어온 요청(녹색 물결선)을 처리한 결과로 평균 적중률을 산출하게 된다. 이 적중률은 앞으로 “되돌아가” 원하는 적중률(desired hit rate)과 비교하는 입력으로 쓰인다(그림 좌측). 그 결과는 바로 원하는 적중률과 실제 적중률의 차이를 뜻하는 추적 오차(tracking error)다.

추적 오차는 “컨트롤러(controller)”에 입력된다. 컨트롤러의 역할은 추적 오차가 줄일 수 있는 캐시의 크기를 계산하는 것이다. 기본적으로 적중률이 낮으면 캐시를 키우고, 적중률이 높으면 캐시를 줄이면 된다. 캐시의 크기가 새로 정해지면 적중률에 변화가 생길 것이다. 그럼 그 값을 다시 원하는 적중률과 비교하고, 추적 오차를 계산하고, 컨트롤러는 캐시의 크기를 새로 정한다. 이러한 과정이 영원히 반복된다.

이상이 피드백 제어의 기본 아이디어이지만, 물론 여기서 끝은 아니다. 이를 어설프게 적용할 경우 상당히 만족스럽지 못한 결과만이 기다릴 것이다.

이유는 이렇다. 우리는 주어진 적중률 차이에 따른 적절한 캐시 크기 변화 정도도 알아내야 하고, 캐시 크기의 변화가 얼마나 빠르게 적중률에 반영되는지도 알아야 한다. 이러한 정보를 얻기 위해서는 실험이 필요한 것이 보통이다. 예컨대 캐시 크기를 특정 값만큼 변화시킨 후 적중률이 안정화되기까지의 시간과 안정화된 값을 관찰하여 그 정보를 컨트롤러 개선(혹은 튜닝)에 사용할 수 있다. 컨트롤러 설계와 튜닝은 곧이어 다루게 될 중요 주제다. 하지만 프로그래머가 피드백에 관심을 가져야 하는 이유를 먼저 알아보기로 하자. 채널 고정!!


»  Substance: WordPress   »  Style: Ahren Ahimsa