목표값을 향해 끊임없이 조정하는 기술
여러분 집의 보일러를 떠올려 보세요. 실내 온도를 23도로 맞춰놓으면, 추워지면 더 데우고 더워지면 멈추면서 계속 23도 근처를 유지하잖아요. 자동차 크루즈 컨트롤도 마찬가지고, 드론이 바람 속에서도 수평을 잡는 것도, 3D 프린터 노즐이 정확한 온도를 유지하는 것도 전부 같은 원리로 돌아가요. 그 원리의 이름이 바로 PID 제어입니다.
PID는 Proportional(비례), Integral(적분), Derivative(미분)의 앞 글자예요. 이름은 어려워 보이지만, "목표랑 지금 상태의 차이를 보고 얼마나 세게 조정할지 정하는 공식"이라고 생각하면 쉬워요. 여기서 목표값을 설정값(setpoint), 목표와 현재의 차이를 오차(error)라고 불러요.
세 명의 조언자가 함께 결정한다
PID를 세 명의 조언자가 회의하는 장면으로 비유해볼게요.
P, 비례 담당은 현재만 봐요. "지금 목표보다 10도 모자라네? 그럼 세게 데워." 오차가 크면 크게, 작으면 작게 반응하죠. 단순하고 직관적인데, 문제는 목표 근처에 가면 조정값이 약해져서 딱 목표에 도달하기 직전에 멈춰버려요. 영원히 0.5도쯤 모자란 상태로 머무는 거죠. 이걸 정상상태 오차(steady-state error)라고 해요.
I, 적분 담당은 과거를 기억해요. "아까부터 계속 조금씩 모자랐잖아. 그 모자란 걸 다 더해서 보상하자." 쌓인 오차를 누적해서 P가 못 메운 마지막 한 끗을 채워줍니다. 덕분에 정확히 목표에 도달하게 되죠. 대신 너무 욕심내면 목표를 지나쳐 버리는 오버슈트나, 오차가 과하게 쌓여 폭주하는 적분 와인드업이 생길 수 있어요.
D, 미분 담당은 미래를 내다봐요. "온도가 지금 엄청 빠르게 오르고 있네? 곧 목표를 넘겠다, 미리 살살 줄이자." 오차의 변화 속도를 보고 미리 브레이크를 밟는 거예요. 출렁임을 잡아주는 역할인데, 센서 잡음(noise)에 예민해서 값이 튀면 같이 흔들리는 단점이 있어요.
이 셋을 합치면 공식은 이렇게 돼요: 출력 = Kp×오차 + Ki×(누적 오차) + Kd×(오차 변화율). 여기서 Kp, Ki, Kd는 각 조언자의 발언권을 정하는 가중치예요.
튜닝이 진짜 실력
PID의 핵심은 이 세 가중치를 잘 맞추는 튜닝이에요. P를 너무 키우면 시스템이 들썩들썩 진동하고, I를 너무 키우면 목표를 자꾸 넘나들고, D를 너무 키우면 잡음에 예민해져요. 그래서 지글러-니콜스(Ziegler-Nichols) 같은 정해진 절차로 시작값을 잡거나, 손으로 하나씩 돌려보며 감을 잡습니다. 이 균형 잡기가 제어 엔지니어의 진짜 실력이죠.
소프트웨어에도 PID가 숨어 있다
"이거 하드웨어 얘기 아냐?" 싶겠지만, 사실 우리 개발 현장에도 PID식 사고가 깔려 있어요. 쿠버네티스의 오토스케일러가 부하를 보고 서버 개수를 늘렸다 줄였다 하는 것, TCP가 네트워크 혼잡을 감지해 전송 속도를 조절하는 것, 게임에서 카메라가 캐릭터를 부드럽게 따라가는 것 전부 "목표와 현재의 차이를 보고 조금씩 보정한다"는 같은 발상이거든요.
한국 개발자에게
웹/앱 개발자라면 PID 공식을 직접 코딩할 일은 드물어요. 하지만 피드백 루프라는 사고방식 자체는 어디서나 써먹어요. 부하에 따라 자원을 조절하는 자동 확장, 요청 폭주를 막는 레이트 리미터, 부드러운 UI 애니메이션을 만들 때 P-I-D의 직관은 그대로 적용됩니다. 로봇이나 임베디드, 드론 쪽으로 가려는 분이라면 PID는 입문 필수 과목이고요. 단 50줄 안팎의 코드로 구현할 수 있을 만큼 단순하면서도, 세상의 수많은 기계를 안정시키는 검증된 도구라는 게 매력이에요.
핵심 한 줄: PID는 "과거(I)·현재(P)·미래(D)를 함께 보며 목표를 향해 조금씩 보정한다"는, 60년 넘게 살아남은 제어의 기본기예요.
여러분 코드 어딘가에 알게 모르게 피드백 루프를 넣어본 경험이 있나요? 오토스케일링이든 애니메이션이든, "조금씩 보정"이 잘 안 돼서 출렁였던 경험이 있다면 나눠봐요.
🔗 출처: Hacker News