»
S
I
D
E
B
A
R
«
라이브러리 vs. 프레임워크
Apr 7th, 2014 by Wegra Lee

라이브러리와 프레임워크라는 프로그래밍을 조금만 하다 보면 접하는 흔한 용어이지만 그 정의나 차이점을 물어보면 선뜻 답하지 못하는 프로그래머가 많다.

라이브러리는 자주 사용하는 기능을 미리 만들어 놓은 API 집합이다. 최대값/최소값을 구하는 간단한 함수부터 윈도우나 글상자를 그려주는 GUI 클래스 등 종류는 무궁무진하다.

당신은 자신의 프로그램을 짜며 필요할 때마다 이들 라이브러리의 기능을 호출해 사용한다.

프레임워크는 당신의 코드가 동작하는 규칙과 틀(프레임)을 규정해준다. 즉, 당신의 코드는 프레임워크가 정해준 규칙과 틀에 맞춰 짜여지고 동작한다. 이런 프레임워크의 대표적인 역할은 바로 생명주기 관리다.

비유하자면 이렇다. 아기가 태어나면 출생신고를 해야 한다. 그러면 정부는 그 아이의 일생에 걸쳐 여러 가지를 요청하고 그에 응하지 않으면 제재를 가하기도 한다. 예를 들어 나이가 차면 의무교육인 초등학교에 가게 하고 성인이 되면 주민등록증을 발급해준다. 남자라면 병역 의무도 져야 한다. 돈을 벌거나 공공 인프라(전기/수도 등)를 사용하면 세금을 내야 한다. 마지막으로 생을 마감하면 사망신고를 하고, 정부는 더는 그 사람에게 신경 쓰지 않는다. 여기서 사람은 당신이 작성한 코드, 정부는 프레임워크에 해당한다.

한 가지 더! 정부는 사람들이 공통적으로 많이 쓰는 기능을 직접 준비하고 운영하기도 한다. 철도나 버스 같은 대중교통과 전기와 수도 같은 인프라가 그렇다. 사람들은 자신이 필요할 때마다 이를 이용할 수 있으니, 사람 입장에서는 이는 라이브러리의 개념과 같다. 즉, 프레임워크는 보통 라이브러리를 포함한다.

이상을 이해하기 쉽게 도식화해보면 다음과 같다.

라이브러리_vs_프레임워크

즉,

  1. 당신의 코드 호출하면 라이브러리고
  2. 당신의 코드 호출하면 프레임워크이며
  3. 프레임워크는 라이브러리를 포함한다.
[참관노트] UXCampSeoul 2014
Mar 31st, 2014 by Wegra Lee

주제: UXCampSeoul. 5th (Behind The Curtain)
일시: 2014/03/15

  • 행사 소개
  • 진행표
    • 부트캠프
    • 바캠프
  • 0. 시작 전 이모저모

  1. Design Beyond Design, Service Design & Strategy
  2. 생활에서 발견하는 새로운 지식
  3. UX 디자이너를 위한 글쓰기
  4. Space for UX
  5. 빅데이터와 SNS 시대의 소셜 경험 전략
  6. 커뮤니티 디자인이라 쓰고 회기동 안녕마을이라 읽는다
  7. IoT 시대에 임하는 UX 디자이너
  8. 당신의 디자이너를 찾습니다
  9. UX/UI 첫걸음

행사 소개

UXCamp는 UX(User eXperience)관련 전문가, 교육자, 학생 혹은 UX에 관심 있는 모든 사람들이 자유롭게 생각을 공유하는 행사입니다.
UXCamp는 미국, 캐나다, 유럽 등 전 세계에서 수차례 진행되었으며, 국내에서는 ’UXCampSeoul’이란 이름으로 2010년, 2011년 봄과 가을, 2012년 여름에 이어 다섯 번째 행사입니다. (from http://www.uxcamp.co.kr/#section_aboutus)

나머지는 PDF로 대체.. (귀찮음은 혁신의 어머니랄까ㅡㅡ)

[다운로드] [참관] UXCampSeoul 2014_UX캠프_20140315

[참관노트] 사물인터넷과 웨어러블 기술 (IoT & Wearable Technology)
Mar 19th, 2014 by Wegra Lee

주제: 사물인터넷과 웨어러블 기술 (IoT & Wearable Technology)
일시: 2014/03/13
주최: 플랫폼전문가그룹(PAG)
발표자: 최윤석 (오라클 전무, 플랫폼 형태로 나올 수 있는 제품 총괄)
발표자료: coming soon(really?)

용어 설명

사물인터넷(Internet of Things)

갖가지 주변 사물에 네트워크 기능을 추가하여 서로 연계한 서비스를 제공하는 기술이다. 과거 유비쿼터스(Ubiquitous) 컴퓨팅, 퍼베이시브(Pervasive) 컴퓨팅이라 불리던 기술/트랜드의 새로운 이름이라 생각해도 무방하다.

만물인터넷(Internet of Everything)

시스코(Cisco)에서 주창한 용어로, 사물뿐 아니라 동물/인체에까지 사물인터넷 개념을 확장한 것이다. 하지만 원래의 사물인터넷 개념에도 동물/인체가 포함되어 있었기 때문에 시스코의 마테팅용 용어라는 비판이 있다.

웨어러블 기술(Wearable Technology)

IT 기기를 옷처럼 입거나 악세서리처럼 몸에 걸칠 수 있는 형태로 만드는 기술로, 사물인터넷 시대로 가기 위한 주요한 기술 분야 중 하나이다. 현재는 나이키 Fuel Band, 삼성 갤럭시 기어(손목시계), 구글 글래스 등이 대표적이다.

0. 주요 메시지

  • 사물인터넷/웨어러블 시대가 ‘실제로’ 도래하고 있다.
  • 유비쿼터스/퍼베이시브를 외치던 시기엔 기술이 따라오지 못해 열풍이 금세 수그러들었다. 하지만 지금은 다양한 산업 현장에서 센서 네트워크가 적용되고 있고 웨어러블 소비자 제품이 팔리고 있다.
  • 클라우드 컴퓨팅과 동급 혹은 그 이상의 시장 규모로 성장할 것으로 전망된다.
  • 기술적으로는 아두이노와 라즈베리 파이, 센서 및 센서 네트워킹, 빅데이터 분석, 데이터 시각화, 인포그래픽, 보안, UX 등이 밀접하게 연관되어 있으며 사생활 보호와 법적 이슈가 있을 수 있다.

1. 전망

  • PC -> 모바일/타블릿 -> Other 순으로 시장이 변하고 있다. Other는 과연 무엇인가?
  • 클라우드와 동급 혹은 그 이상의 시장 가치로 평가된다.
  • 클라우드 펀딩 순위에서도 상위에 랭크되어 있다.

2. 분야

센서 + connectivity

  • 의학: 원격진료
  • 가정: 홈 오토메이션, 독거노인 보호
  • 도시 관리: 재활용품 수거, 주차, 오염도 측정, 가로등 관리, 전력 사용량 효율화(Smart Grid)
  • 산업: 공장 로봇 유지보수, 작업 환경 모니터링/안전 (Smart Manufactoring)

3. 사례/시도

4. 고려사항

  • 입는(혹은 걸치는) 부위에 따라 사람이 수용하는 정도가 다름(예를 들어 팔목은 괜찮지만 발목에 차는 것은 대부분 싫어함)
  • 법이 늦게 따라감 (구글 글래스 착용 시 교통 법규를 위반할 수도)
  • 수많은 주변 사물 같의 관리/연동 문제
  • 돈이 되는가?
  • 보안 및 사생활 보호

5. 레퍼런스 플랫폼

파라미테 객체
Mar 11th, 2014 by Wegra Lee

(원문) Introduce Parameter Object

Effective Unit Testing의7.3.9절에서 인용한 블로그 글이다.

파라미터 객체란?

항시 같이 몰려다니는 파라미터들이 있다. 그렇다면 이들을 묶는 객체를 만들어 대체하라.

Parameter Object

“파라미터 객체 추출”이라 알려진 리펙토링 기법이다.

메서드 호출이 연쇄적으로 일어난다면?

랄프 존슨(Ralph Johnson)은 리팩토링 책이 제시한 일반적 상황이 잘 이해되지 않는다 하였다. 거기서 말하는 일반적인 상황이란 이렇다. 서로를 호출하는 메서드가 한 뭉터기가 있다. 그리고 이 메서드들은 각각 수많은 파라미터를 가지고 있어서  파라미터 객체 추출 기법으로 리팩토링하고 싶은 상황이다. 하지만 각각에 파라미터 객체 추출을 적용하면 새로운 객체가 너무 많이 생길테니 고민이 된다. 우리는 객체 하나만을 주고받고 싶다.

그렇다면 연쇄적 호출이 시작되는 메서드에만 파라미터 객체를 적용하라. 그다음에 다른 메서드에는 다음의 ‘전체 객체 보존’ 기법을 적용하면 된다.

전체 객체 보존

한 객체에서 복수의 값을 얻은 후, 이를 다른 메서드를 호출할 때 입력 인자로 넘긴다.

그렇다면 차라리 객체를 통체로 넘겨라.

Preserve Whold Object

[책리뷰] 폴리글랏 프로그래밍
Mar 11th, 2014 by Wegra Lee

x9788968480867

폴리글랏(Polyglot)이란 여러 언어를 사용한다는 의미로, 아직 많은 국내 개발자에게 낯선 용어일 것이다. 나도 작년에 <Effective Unit Testing>을 번역하며 처음 접하게 되었는데, 그 책에서는  그루비 같이 자바가 아닌 언어로 자바 애플리케이션용 테스트를 만들면서 폴리글랏 시대라는 말을 사용했다.

다시 본론으로 돌아와,

한때나마 다양한 프로그래밍 언어를 사용할 줄 아는 것을 자랑으로 생각했던 사람으로서, 임백준씨의 <폴리글랏 프로그래밍>이란 책은 참으로 많은 생각을 떠올리게 해주었다.

짤막한 프롤로그에서는 저자의 이런저런 경험과 프로그래밍 언어 역사 중 재미난 이야기들을 빌어 폴리글랏 프로그래밍 시대가 도래했음을, 그리고 현재 대표적인 대세 언어 중 하나인 자바의 시대가 끝나감을 알린다. 아니! 어느 때보다도 호황인 듯한 자바가 죽어간다니!? 현실에만 안주하고 있는 자바 프로그래머는 자칫 자바 언어와 함께 도태될 수 있음을 지적한다.

본론은 크게 세 부분으로 구성된다. 자바, C#, 그리고 스칼라.

혜성처럼(?) 등장하여, 한 시대를 풍미하고 있는 자바! 하지만 노쇠함을 보여주는 증가가 이미 오래전부터 속속 드러나고 있었다. 매력적이던 이 언어는 이제 유행에 뒤처지고 갑갑한 기성세대가 되었다.

자바 때문에 위기감을 느낀 마이크로소프트가 J++ 이후 부랴부랴 내놓은 언어인 C#. 많은 면에서 자바를 모방한 아류 언어로 첫울음을 터뜨린 이 언어는 어느새 자바를 저만치 앞질러버렸다. 지금의 자바는 C#을 따라가기도 바쁘다.

아직 확실한 대세라고 부르기에는 점유율이 매우 초라하지만, 의미 있는 커뮤니티 규모와 성공 스토리를 확보한 함수형 언어 스칼라. 스칼라는 자바의 1/4 수준의 언어 명세만으로 자바 이상의 표현능력을 갖추고, 훨씬 간결한 소스코드로 사람들을 유혹하고 있다. 자바는 스칼라가 제공하는 기능을 일부라도 흉내 내고자 수년째 절치부심이다.

책 전체적으로 자바의 위기와 그렇게 된 재미난 역사적 사실과 철학적인 이야기들, 그리고 자바의 미래를 당장 엿볼 수 있는 다른 언어의 특징이 일관되게 묘사되고 있다. 하지만 저자가 에필로그에서도 밝혔듯, 자바는 낡았으니 다른 언어로 갈아타라는 메시지를 던지고자 하는 것은 아니다.

임백준씨가 말끔히 정리해놓은 문장이 있지만, 내식대로 표현해보자면 이렇다.

자바 세계에서 잠시 눈을 돌리면 새로운 패러다임의, 혹은 훨씬 진보한 (그래서 자바도 흉내 내려 부단히 노력 중인) 언어가 많이 있다. 그러한 언어들을 함께 쓸 줄 아는 프로그래머는 더 생산적이고 유연하여 어떠한 환경에서건 쉽게 적응하고 살아남을 것이다.

개인적으로는 2005년 이후 자바로부터 떠나 지내던 약 5년 동안의 이야기를 많이 들을 수 있어서 즐거웠다.

IT 트랜드 따라잡기
Mar 6th, 2014 by Wegra Lee

최신 IT 트랜드를 쫓아가고 싶은 이들을 위한 팁을 몇 가지 정리해 보았다.

통계 서비스

각종 통계/추이 정보를 제공하는 서비스들이다. 일부는 특정 시점의 스냅샷만 보여주지만, 일부는 실시간으로 살아 있는 정보를 제공하고 검색 기능도 갖추고 있다. 후자는 링크를 잘 기억해 두었다가 궁금한 것이 생길 때마다 찾아보면 큰 도움이 될 것이다.

  • TIOBE Index
    • 많이 사용되는 개발 언어의 순위와 추이를 보여준다.
  • Ohloh
    • 많이 사용되는 개발 언어의 순위와 추이를 보여준다.
    • 원하는 언어만 선택하여 비교할 수 있다.
  • LangPop 차트
    • 많이 사용되는 개발 언어의 순위와 추이를 보여준다.
    • StackOverflow 질문과 GitHub 프로젝트 정보를 기반으로 한다.
  • Indeed.com
    • 미국의 구인/구직 사이트이다.
    • 기업체가 요구하는 언어/플랫폼/기술의 순위를 볼 수 있다.
  • 구글 트랜드
    • 지정한 키워드를 포함하는 뉴스 수의 추이를 보여준다.
    • 복수 키워드를 입력하여 서로 간에 비교할 수 있다.
  • StackOverflow 태그 통계
    • 사이트에 올라온 질문에 사용된 태그(tag)들의 빈도, 즉 해당 태그를 포함한 질문의 수를 일/주/월/연별로 통계 내어 보여준다.

피드(feed) 서비스

가입 혹은 궁금한 키워드를 등록해두기만 하면 이슈가 생겼을 때 알아서 정보를 제공해주는 서비스들이다.

  • 데브멘토
    • 강좌/세미나/행사 정보를 제공한다.
    • RSS 혹은 (회원 가입 시) 이메일로 받아볼 수 있다.
  • Google Alerts
    • 관심 키워드를 등록하면, 구글이 해당 키워드를 포함하는 최신 뉴스/블로그 등의 정보를 요약해서 이메일로 보내준다.
  • SlideShare
    • 프리젠테이션 자료 공유 사이트이다.
    • 회원 가입 후,
      이메일 설정에서 ‘With featured and other useful content tailored for me’ 항목 선택
      자신의 likes, follows 정보에 기반하여 추론하는 듯
    • 회원 가입 후, 이메일 설정에서 ‘With featured and other useful content tailored for me’ 항목을 선택하면 주기적으로 관심 분야의 최신 프리젠테이션을 이메일로 보내준다.
    • (자신의 likes, follows 정보를 기초로 추론하는 듯하다.)

모바일 앱

관심사별로 좋은 뉴스를 추려주는 모바일 앱들이 많다. 앱 설치 후 Technology, Programming, Agile 등 IT 관련 섹션을 선택해주면 끝! 출퇴근 길에 짬짬히 체크하면 따끈따끈한 정보를 얻을 수 있다.

  • Zite
    • 내가 주로 이용하는 앱이다.
    • 방금 Flipboard에 6천만 달러에 팔렸다는 기사가…
  • Flipboard
    • 아이패드 초기 시절의 킬러 앱 중 하나였다. (요즘은 모르겠다.)

위의 두 앱은 iOS와 Android를 모두 지원한다. 이 외에도 좋은 뉴스 서비스 앱이 많을테니 취향에 맞는 것을 선택해 사용하길 바란다.

관련 기사

최신 기사 중 재미난 것 하나를 소개하겠다.

‘메타프로그래밍’이란?
Feb 27th, 2014 by Wegra Lee

메타?

나중에 더해져서 다른 개념을 보강 혹은 완성하는 것
A concept which is an abstraction from another concept, used to complete or add to the latter.

메타 데이터?

다른 데이터를 기술하는 데이터

metadata

책이라는 ‘실체를 훼손하지 않고’ ‘언제건’ 정보를 ‘더하거나 수정’할 수 있다.
‘실체에 접근하지 않고도’ 메타 데이터만으로 대상을 다룰 수 있다.
예> 분류, 검색, 정렬 등

메타 프로그래밍?

프로그래밍에 메타 정보를 활용하는 것!
즉, 프로그램 본체 작성 후에 새로운 기능을 추가하거나 다른 용도로 사용할 수 있게 정보를 제공할 수 있다.

활용 예>

* 자바 어노테이션 (참고 – JUnit 4, 60초만에 익히기)
* AOP(Aspect-oriented programming): 로깅, 동기화, 권한 확인 등
* C++ 템플릿 메타프로그래밍
* Ruby: 런타임에 객체 인스턴스에 새로운 메서드 추가

장점

부차적인 요소 혹은 변경될 소지가 있는 요소를 메타 정보로 추출하여 핵심 로직만 남겨둘 수 있다.
따라서 소스 코드의 가속성과 프로그램의 유연성이 높아진다.

단점

자칫 전체 로직의 연결 고리 일부가 사라져서 프로그램을 이해하기 어렵게 만들 수 있다.

7. 자가적응과 피드백은 다르다(Self-Adaptive is Not The Same as Feedback)
Feb 25th, 2014 by Wegra Lee

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


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


이전까지의 글에서 불규칙하게 변화하는 환경에서 시스템을 일정하게 유지하는 방법인 피드백 제어의 개념을 열심히 소개했다.

그런데 조금 의문인 건 피드백이란 것도 결국 변화하는 환경에 자신의 동작을 맞추는 “반응형 시스템”이 아닌가 하는 점이다. 하지만 꼭 그렇지는 않다. 이 둘은 관찰하는 대상이 서로 다르다. 피드백 시스템은 환경의 변화가 아니라, 자신의 동작 변화에 반응한다. 이는 커다란 차이점이다.

시스템을 제어하는 상황을 가정해보자. 이 시스템은 입력과 출력이 있다. 피드백의 경우 제어 행동을 결정짓는 건 바로 자신의 출력이다. 즉, 시스템의 실제 동작에 반응한다. 반면 주변 환경(시스템 입력 포함)을 관찰하여 제어하는 전략은 “피드포워드(feedforward)”에 해당한다.

더 명확히 알아보자. 웹 요청을 처리하는 서버 팜(server farm)이 있다. 이 경우 많이 쓰이는 서비스 품질 지표는 평균 응답 시간이다. 즉 요청이 아무리 많아도 평균 응답 시간은 일정하게 유지되길 원한다.

피드백 제어에서라면 (실제 서비스 품질 지표인) 응답 시간 모니터링은 필수이며, 이를 기반으로 제어 행동을 결정한다. 즉, 응답 시간이 늘어지기 시작하면 서버 개수를 늘릴 것이다. 하지만 서버로 들어오는 요청의 트래픽만 고려하여 제어한다면 이는 피드백이 아니라 피드포워드다. 왜냐고? 시스템의 실제 동작이 아닌 환경 요인만을 고려했기 때문이다.

피드백 방식은 시스템에 대한 깊은 지식이 없어도 된다는 커다란 장점이 있다. 응답 시간이 길어지면 서버를 늘린다는 단순한 사실만으로 충분하다. 반면 피드포워드 방식에서는 증가한 트래픽을 처리하려면 몇 대의 서버가 필요한지 구해야 하는데, 그 정확한 값을 계산하기 우해 필요한 정보를 다 얻기 불가능한 상황이 적지 않다. 이는 피드포워드 방식에서는 큰 난관이지만, 피드백 방식에는 전혀 문제가 되지 않는다. 처음 조치로 해결되지 않으면 다시 한 번 늘려주면 그만이다.

하지만 피드백에도 단점은 있다. 언제나 피드포워드 시스템의 동작이 더 간결하다. 반면 피드백 시스템의 행동은 그리 간단하지 않을 수 있다. 피드백은 시스템의 출력에 기반하여 동작하기 때문에 다소의 지연은 피할 수 없다. 그 사이에 상황이 변하면 피드백 시스템은 완전히 잘못된 순간에 완전히 잘못된 조처를 해버린다. 이리되면 시스템은 잠시 휘청이거나(서버를 추가했다고 곧이어 다시 줄인다.) 완전히 오동작할 수 있다.

불행하게도 어설프게 만들어진 피드백 컨트롤러는 이러한 악몽을 안겨줄 가능성이 높다. 이런 일을 겪고 싶지 않다면 피드백 루프의 동작을 제대로 이해하고 대상 애플리케이션용 컨트롤러에 적합하게 튜닝해야 한다. (이에 대한 내용은 바로 앞 글에서 설명했다.)

정리하면, 피드백은 자가적응 시스템의 특수한 형태지만, 모든 자가적응 시스템이 피드백 원칙을 따르지는 않는다. 피드백 원칙을 따르는 시스템은 환경 요소에만 의존하는 시스템보다 안정적이지만, 동작 측면에서는 더 복잡하고 적절한 튜닝을 가해줘야 제대로 동작한다.

그렇다면 피드백의 목적은 “최적의” 동작을 보장하기 위함일까? 그 대답은 다음 글에서 밝혀질 것이다. (역자주: 이렇게 끝내놓고 저자가 다음 글을 쓰지 않고 있다.)

6. 피드백 컨트롤러 튜닝(Feedback Controller Tuning)
Feb 25th, 2014 by Wegra Lee

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


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


앞의 글에서 피드백 루프에 사용할 PID 컨트롤러를 소개했다.

이를 수식으로 나타내면 다음과 같으며

janert-feedback-controller

비연속적 시간 형태로 바꿔 소프트웨어로 구현한 모습은 다음과 같다.

sum += error
output = kp * error + DT * ki * sum + kd * (error – prev) / DT
prev = error

컨트롤러 상수인 Kp, Ki, Kd는 컨트롤러를 운영 환경에 적응하기 위한 값이다. 캐시의 예에서 보면, 출력(제어하려는 지표)은 0.0 ~ 1.0 사이의 값이지만, 입력(컨트롤러가 계산해야 할 양)은 훨씬 큰 정수값이다. 이제 이러한 범위의 차에 적응할 수 있는 적절한 컨트롤러 상수를 선택해야 한다.

janert-feedback-loop2

자! 앞으로 입력과 출력이라는 용어는 항시 제어 입력과 제어 출력을 의미할 것이다. 즉 우리 관심사인 지표가 출력이고, 그 값에 움직이기 위해 우리가 조절할 수 있는 양은 입력이다. 이런 제어 입력이나 출력은 물론 캐시에 아이템을 넣고 빼는 요청과는 아무런 상관이 없는 개념이다.

우리는 다음 질문의 답을 찾아야 한다. 시스템의 출력에 원하는 만큼의 변화를 주려면 입력은 얼마나 변경해야 하는가? 캐시에서라면 ‘적중률을 0.1만큼 조정하려면 캐시 크기에 어느 정도의 변화를 줘야 할까?’ 정도의 질문이 될 것이다.

대게 가장 간단한 (아마도 가장 정확하기도 할) 답변은 직접 측정해보는 것이다. (피드백 루프 없이) 캐시를 잠시 운영해보고 크기를 바꾼 후 적중률이 안정되기를 기다란 다음 새로운 적중률을 이전 값과 비교해본다. 이렇게 구한 컨트롤러 상수의 첫 후보는 다음과 같다.

k = (size_after – size_before) / (hitrate_after – hitrate_before)

초기의 캐시 크기가 1,000에 적중률은 0.7이었고, 이를 1,200으로 키우니 적중률이 0.9까지 올랐다고 치자. 그 결과는 다음과 같다.

k = (1200 – 1000) / (0.9 – 0.7) = 200 / 0.2 = 1000

첫 시도 치곤 나름 괜찮다. 일반적으로 컨트롤로 상수가 클수록 변화에 민감하게 반응하지만, 안정성이 떨어져서 자칫 불안정한 상태로 빠질 가능성이 커진다. 결국, 절대적으로 옳은 값이 있는 것은 아니다. 대신 반응속도와 안정성을 적절히 조화시켜야 하는 문제라, 응용 분야가 달라지면 최적의 제어 전략도 바뀌게 된다.

적절한 컨트롤러 상수를 구하는 일(컨트롤러 튜닝)이 정말 중요하다. 잘못 선택한 상수는 만족스럽지 못한 동작을 낳는다. 변화에 너무 굼떠서 답답한 시스템이 되거나 너무 쉽게 요동치는 불안정한 시스템이 될 것이다. 컨트롤러 튜닝이 중요한 만큼 업계는 이 값을 구하는 다양한 기법을 개발해 왔다. 물론 완벽한 방법이란 존재하지 않는다. 최적의 상수는 시스템 자체뿐 아니라 우리가 그 시스템을 활용하는 방식에도 영향을 받기 때문이다.

튜닝 방식 중 하나는 앞서 논의한 방식과 유사하다. 시스템 입력을 한 단위만큼 변경하고 시스템의 출력을 관찰한다. 다른 점이라면 출력의 변화를 시간을 두고 관찰한다는 것이다. 그 결과는 다음 그림처럼 보일 것이다. 입력 한 단위의 변경에 따른 이처럼 동적인 반응을 ‘공정 반응 곡선(process reaction curve)’이라 한다.

janert-feedback-step

이 그래프는 정적인 입출력 관계뿐 아니라 시스템이 얼마나 빠르게 새로운 값으로 안정화되는가 하는 정보도 담고 있다. 시스템이 다시 안정되기까지의 이 시간을 공정의 “시간 상수(time constant)”라 하며, 컨트롤러 상수에 반드시 반영되어야 할 값이다. 기본적으로 느리게 반응하는 시스템일수록 더 강하게 조치해야 하며 이 곡선의 여러 속성으로부터 컨트롤러 상수를 구하는 다양한 휴리스틱을 개발해 왔다.

컨트롤러 튜닝은 피드백 루프가 올바로 작동하기 위한 핵심이다. 항상 최적값을 내어주는 절대 규칙도 없고, 방금 언급한 휴리스틱 역시 너무 다양하다. 이 모든 것은 어쩌면 예술, 아니 마법의 영역일 지도 모른다. 하지만 원리만 잘 이해한다면 이러한 어려움도 이겨낼 수 있다.

다음 글에서는 피드백의 기본 개념을 다시 상기하며 더 일반적인 개념인 “자가 적응(self-adaptive)” 시스템과 어떻게 다른지 논해보겠다.

5. 피드백 컨트롤러(Feedback Controllers)
Feb 25th, 2014 by Wegra Lee

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


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


지금까지는 설계 원칙 혹은 패러다임 관점에서 피드백을 소개했다. 한 마디로, 피드백은 불규칙하게 변화하는 환경에서 시스템이 정상궤도를 유지하게끔 도와준다. 그럼 이번 글에서는 이것이 실제로 의미하는 것이 무엇인지 더 자세히 살펴보기로 하자.

janert-feedback-loop2

그림의 피드백 루프를 보자. 제어 대상 시스템은 이번에도 캐시다. 컨트롤러는 목표 캐시 적중률을 유지하기 위해 캐시의 크기를 조절한다. (캐시 크기를 키우면 적중 횟수가 많아지고 자연히 적중률이 높아질 것이다.) 목표 캐시 적중률은 참조값 혹은 설정값(setpoint)이라 부르며 그림 가장 좌측의 입력으로 쓰인다. 컨트롤러의 입력값인 추적 오차는 설정값과 실제 적중률의 차이다.

추적 오차 = 설정값 – 실제값

(측정한 적중률은 -1을 곱한 후 참조값에 더한다. 이 값이 바로 설정값과 측정된 값의 차이인 추적 오차다.)

컨트롤러는 추적 오차를 입력받아 새로운 캐시 크기를 산출한다. 이 과정은 정확히 어떻게 이루어질까? 추적 오차가 음수면(실제 적중률이 목표한 적중률보다 높음) 캐시 크기가 줄어야 함을 기억해두고 계속 진행해보자.

이때 가장 최근의 측정 결과가 중요하다. 그 순간의 추적 오차가 캐시의 현재 크기를 목표 수준으로 조정하는 데 쓰인다. 즉, 제어 알고리즘은 다음과 같이 요약할 수 있다.

새로운 크기 = 이전 크기 + k * 추적 오차

추적 오차가 음수면(실제 적중률이 목표치보다 높음) 캐시 크기는 줄어들 것이다. 반대로 추적 오차가 양수면(실제 적중률이 목표치보다 낮음) 캐시 크기는 줄어들 것이다.

상수 k는 증감의 민감도를 결정한다. 적중률의 범위는 0.0 ~ 1.0 사이기 때문에 추적 오차 역시 0.0 ~ 1.0 사이의 실수(floating point number)여야 한다. 반면 캐시의 크기는 정수이며, 요청 트래픽에 따라 매우 큰 값이 될 수도 있다. k는 이러한 차이와 무관하게 어떠한 환경에서도 피드백 루프를 튜닝할 수 있는 값이어야 한다. 환경이 바뀐다고 새로운 컨트롤러를 쓰고 싶어하는 사람은 없기 때문이다.

적절한 컨트롤러 k를 구하려면 잠시 제어 알고리즘의 구조를 살펴볼 필요가 있다. 이 알고리즘은 적중률이 너무 높거나 너무 낮아도 항시 유효해야 한다. 이 공식에 따르면 수정치는 추적 오차에 비례한다. 끝으로, 추적 오차가 사라지면(실제 적중률이 목표 적중률과 일치함) 캐시 크기는 변하지 않아야 한다.

이쯤되면 대다수의 피드백 컨트롤러가 위와 같은 간단한 공식을 사용한다는 사실은 전혀 놀랍지 않다. 하지만 다른 속성을 고려해야 할 때도 있다. 가장 널리 쓰이는 소위 “세 단어(three-term)” 컨트롤러 혹은 PID (”proportional, integral, derivative”) 컨트롤러의 출력을 좌우하는 속성은 다음과 같다.

  • 현재 오차(현재)
  • 지금까지의 모든 오차의 누적합(과거)
  • 가장 최근 오차의 변화량(예측된 미래)

수학적으로는 누적합(cumulative sum)은 적분(integral), 최근 변화는 미분(derivative)으로 표현된다. 즉, PID 컨트롤러의 출력 공식은 다음과 같다.

janert-feedback-controller

여기서 컨트롤러 상수인 Kp, Ki, Kd는 모두 숫자 값이고, e(t)는 현재 오차다. 미분의 경우 무시될 때도 잦다(즉, Kd = 0). 여기에 Kp = 0으로 정하면 앞의 한 줄짜리 간단한 공식과 같아진다.

이를 컴퓨터로 구현하려면 시간의 흐름이 비연속적인 값으로 바꿔야 한다(다음 공식의 DT). 따라서 PID 컨트롤러의 구현은 다음과 같다.

sum += error
output = Kp * error + DT * ki * sum + kd * (error – prev) / DT
prev = error

이제 됐다! 이것이 그 유명한 PID 컨트롤러다! 바로 업계 90% 이상에서 활용한는 대표 컨트롤러다.

피드백 제어는 복잡한 구조를 단순한 컨트롤러로 대체한다. 이것이 피드백 시스템의 핵심이다. 피드백 시스템이 잘 작동하는 이유는 단순히 컨트롤러가 영리해서가 아니라, 정보를 루프 앞단으로 돌려보내 컨트롤러의 입력으로 재사용(feed back)하기 때문이다.

이제 컨트롤러 상수(Kp, Ki, Kd)를 정하는 방법을 알아볼 차례다. 그럼 다음 포스팅을 기대하기 바란다.

»  Substance: WordPress   »  Style: Ahren Ahimsa