[초급] 워치독은 왜 필요할까? 아무도 리셋 버튼을 눌러 줄 수 없을 때

[초급] 워치독은 왜 필요할까? 아무도 리셋 버튼을 눌러 줄 수 없을 때

한 줄 답: 워치독은 멈춘 기계를 스스로 다시 일으켜 세우는 "자동 리셋 버튼"이에요.

코드가 정상일 때는 정해진 시간마다 워치독에게 "나 살아 있어" 신호(클리어)를 보냅니다. 이 신호가 끊긴 채 타임아웃이 지나면 워치독이 MCU를 리셋하죠. 버그를 고쳐 주진 않지만, 기계가 멈춘 채로 영원히 서 있는 최악의 상황만큼은 막아 줍니다.

먼저 알아둘 용어

용어	원래 이름	쉽게 말하면
워치독	Watchdog Timer (WDT)	정해진 시간 안에 "나 살아 있어" 신호가 없으면 칩을 깨우는 경비견 타이머
리셋	Reset	칩을 막 전원을 켠 상태로 되돌리기. 한마디로 재부팅
클리어	Clear (Refresh, Kick, Feed라고도 해요)	경비견에게 밥 주기. 세던 시간을 처음으로 되돌려요
타임아웃	Timeout	밥 없이 버틸 수 있는 최대 시간. 넘기면 짖어요
MCU	Micro Controller Unit	제어기 속에 든 작은 컴퓨터 한 칩
큐브위성	CubeSat	한 변 10cm 정육면체를 단위로 만드는 초소형 위성
LED	Light Emitting Diode	전기를 넣으면 빛나는 작은 전구. 보드가 살아 있는지 보여 주는 신호등
무한 루프	Infinite Loop	빠져나갈 문이 없는 회전문. 코드가 같은 곳을 영원히 돌아요
발진기	Oscillator	시간을 세는 배꼽시계. 온도·전압에 따라 조금 빨라지거나 느려져요
공차	Tolerance	설명서가 "이만큼까지는 틀어져도 정상"이라고 약속한 범위. 예: ±15%
고장 주입 시험	Fault Injection Test	일부러 고장을 내서 안전장치가 제대로 도는지 보는 소방 훈련
GPIO	General Purpose Input/Output	켰다 껐다 할 수 있는 다용도 핀. 디버깅용 신호등으로도 써요
풀다운 저항	Pull-down Resistor	아무도 잡고 있지 않을 때 핀을 0V 쪽으로 살짝 끌어내리는 고무줄
로직 애널라이저	Logic Analyzer	핀이 켜지고 꺼지는 순간을 시간 순서대로 찍어 주는 고속 카메라
리셋 원인 레지스터	Reset Cause (Reset Factor) Register	왜 재부팅됐는지 적어 두는 블랙박스 메모
인터럽트	Interrupt	하던 일을 잠깐 멈추고 급한 일부터 처리하게 하는 초인종
폭주	Runaway	프로그램이 길을 잃고 엉뚱한 곳을 빙빙 도는 상태
윈도우 워치독	Window Watchdog Timer (WWDT)	너무 늦어도, 너무 일러도 짖는 깐깐한 경비견

워치독은 왜 필요할까? 누리호 큐브위성의 "껐다 켜기" 이야기

2025년 11월 27일 새벽, 누리호 4차 발사가 있었습니다. 주탑재위성과 함께 큐브위성 12기가 궤도에 올라갔는데, 며칠이 지나도록 그중 3기는 지상국과 연락이 닿지 않았습니다. 그러다 12월 4일부터 6일 사이에 세 위성이 하나씩 "저 살아 있어요" 신호를 보내왔죠.

혹시 이런 얘기 들어 보셨나요? "예정된 시간까지 교신이 안 되면 위성이 스스로 재부팅하는데, 그 덕에 다시 연락이 됐다"는 웃픈 이야기요. 다만 세 위성이 왜 늦게 연락됐는지는 공식 발표에 나오지 않았습니다. 발표에는 정확한 궤도 정보로 계속 교신을 시도했다는 정도만 있습니다. 그러니 이 이야기는 "그랬을 수도 있는 일"로 들어 주세요.

그래도 개발자라면 이 얘기에 웃프게 공감하게 됩니다. 실제로 큐브위성 전원 장치에는 "지상에서 일정 시간 소식이 없으면 전원을 껐다 켜는" 감시 타이머를 넣는 경우가 흔하거든요. 수백 km 위에서 멈춘 위성은 누구도 리셋 버튼을 눌러 줄 수 없으니까요. "일단 껐다 켜 보세요"를 기계가 스스로 하게 만든 셈입니다.

이 감시 타이머의 칩 버전이 바로 워치독입니다. 우주만 그런 게 아니에요. 달리는 차 안의 제어기, 공장 천장에 달린 설비, 산꼭대기 통신 장비도 멈췄다고 누가 바로 달려가 전원을 뽑아 줄 수 없죠. 사람 손이 닿지 않는 기계일수록 "멈추면 스스로 다시 일어나는" 장치가 꼭 필요합니다.

이런 일 겪어본 적 있나요? 가끔 먹통이 되는 보드

집 공유기가 먹통이 돼서 전원을 뽑았다 꽂았더니 멀쩡해진 경험, 한 번쯤 있으시죠? 펌웨어도 똑같습니다. 보드의 LED가 잘 깜빡이다가 몇 시간에 한 번 딱 멈추고, 전원을 다시 넣기 전까지는 돌아오지 않아요.

원인을 찾아보면 이런 코드가 정말 자주 나옵니다.

function ReadSensor()
    SendRequest(SENSOR_TEMP)

    while ResponseReceived() == false
        // wait... forever, if the sensor never answers
    end while

    return ReadResponse()
end function

SendRequest = 센서에 값 요청, ResponseReceived = 응답이 왔는지 확인하는 함수예요. 이름은 예시라 쓰는 MCU에 맞게 바꾸면 돼요.

센서가 노이즈 때문에 응답을 딱 한 번만 놓쳐도, 코드는 이 while 문에서 영원히 기다립니다. 이게 바로 무한 루프예요. 근본 해결은 "최대 몇 ms까지만 기다린다"는 제한을 두는 것이고, 이건 꼭 하셔야 합니다. 하지만 세상 모든 버그를 출시 전에 다 찾을 수는 없잖아요. 그래서 "어떤 이유로든 멈추면 다시 일어나게" 하는 마지막 안전망이 필요한 겁니다.

비유로 보는 워치독 원리: 밥을 기다리는 경비견

워치독을 집을 지키는 경비견이라고 생각해 볼게요. 주인(정상적으로 도는 코드)은 정해진 간격으로 개에게 밥을 줍니다. 밥을 받으면 개는 배고픔 시계를 처음으로 돌려놓고 조용히 기다려요. 그런데 주인이 쓰러져서 밥이 끊기면, 배고픔이 한계에 닿는 순간 개가 크게 짖어 집 전체를 깨웁니다.

현업 용어로 바꾸면 밥 주기는 클리어, 배고픔 한계는 타임아웃, 짖어서 깨우기는 리셋입니다. 아래 그림에서 톱니 모양이 워치독이 세는 시간이에요. 밥을 줄 때마다 뚝 떨어지고, 코드가 멈추면 끝까지 올라가죠.

그림 1. 밥(클리어)을 줄 때마다 세던 시간이 0으로 떨어져요. 코드가 멈춰 밥이 끊기면 타임아웃 선에 닿고, 그 순간 리셋돼서 다시 정상으로 돌아와요.

여기서 꼭 알고 넘어가야 할 점이 하나 있습니다. 코드가 멈췄는데 워치독은 어떻게 계속 시간을 셀까요? 워치독은 코드가 아니라 MCU 안에 따로 들어 있는 하드웨어 타이머이기 때문입니다. 많은 MCU에서는 전용 발진기로 따로 돌기 때문에, 코드가 어디서 멈추든 혼자서 묵묵히 시간을 셉니다.

[예상] 코드가 멈추면 몇 ms 뒤에 다시 살아날까?

사례 보드는 타임아웃을 100ms로 두고, 10ms마다 클리어합니다. 멈춘 뒤 리셋까지 걸리는 시간은 이렇게 생각하면 됩니다.

멈춘 뒤 리셋까지 걸리는 시간 = 타임아웃 − 마지막 밥 이후 이미 지난 시간

밥을 준 바로 직후에 멈추면 100 − 0 = 100ms로 가장 오래 걸립니다. 다음 밥 직전에 멈추면 이미 10ms가 지난 상태라 100 − 10 = 90ms로 가장 빨라요. 그래서 [예상]은 "멈춘 뒤 90 ~ 100ms 사이에 리셋되고, LED가 다시 깜빡인다"입니다. 워치독이 없으면? 전원을 다시 넣기 전까지 영원히 멈춰 있을 거예요.

정말 그런지 확인하기: 일부러 멈춰 보기

워치독이 제대로 도는지는 일부러 고장을 내 봐야 알 수 있습니다. 현업에선 이걸 고장 주입 시험이라고 불러요. 시험 버튼을 누르면 그다음 차례에 가짜 무한 루프에 빠지게 만들고, 표시용 GPIO 핀은 살아 있는 동안 켜 둬요. 로직 애널라이저의 한쪽 입력에 버튼 신호를, 다른 쪽 입력에 이 핀을 물리면 "버튼이 눌린 순간부터 리셋으로 핀이 꺼지는 순간까지"를 잴 수 있습니다. 버튼이 눌린 순간이 곧 고장이 난 순간이에요. 그 뒤로는 밥이 한 번도 나가지 않거든요.

WDT_TIMEOUT_MS = 100
TASK_PERIOD_MS = 10

function Main()
    resetCause = ReadResetCause()          // read first, before anything else
    SaveResetLog(resetCause)

    SetAllOutputsSafe()                    // start from a safe state
    WDT_Start(WDT_TIMEOUT_MS)
    GPIO_Write(PIN_ALIVE, HIGH)            // mark: running (drops at reset)

    loop forever
        WaitUntilNextTick(TASK_PERIOD_MS)

        UpdateLed()
        CheckTestButton()

        WDT_Clear()                        // "I'm alive"
    end loop
end function

// Test build only: fake hang
function CheckTestButton()
    if TestButtonPressed()
        loop forever
            // stuck on purpose, no clear
        end loop
    end if
end function

WaitUntilNextTick = 다음 10ms 박자까지 기다리기, WDT_Clear = 워치독에게 밥 주기, PIN_ALIVE = 살아 있는 동안 켜 두는 표시용 핀이에요. 핀에 풀다운 저항을 달아 두면 리셋 순간 핀이 꺼져서 끝 지점이 보입니다. 이름은 예시라 쓰는 MCU에 맞게 바꾸면 돼요.

[결과] 워치독이 예상대로 살려 냈을까?

※ 아래 수치는 이해를 돕기 위한 사례 값이에요. 여러분 보드에서 위 방법으로 직접 재 보세요.

시험 버튼을 20번 눌러서 멈춤부터 리셋까지 시간을 쟀습니다. 비교를 위해 WDT_Start 줄을 뺀 버전으로도 한 번 시험했어요.

그림 2. 실측 범위가 예상 범위와 폭은 거의 같고, 오른쪽으로 약 4ms 밀려 있어요.

항목	[예상]	[결과]	비교
워치독 없이 멈추면	영원히 멈춤	10분 기다려도 멈춤, 전원을 다시 넣어야 복구	일치
멈춘 뒤 리셋까지	90 ~ 100ms	94.3 ~ 104.1ms	양쪽 모두 약 4ms 늦음
리셋 뒤 LED 복구	매번 복구	20회 중 20회 복구	일치
리셋 원인 레지스터	워치독	20회 모두 워치독으로 기록	일치

워치독은 예상대로 매번 보드를 살려 냈습니다. 그런데 시간이 예상보다 양쪽 모두 약 4ms씩 늦었어요. 범위의 폭(약 10ms)은 그대로인데 통째로 밀렸다는 건, 기다리는 시간 자체가 길어졌다는 뜻입니다.

범인은 워치독의 배꼽시계인 발진기예요. 이 발진기는 정밀함보다 "코드와 상관없이 혼자 살아 있는 것"이 목적이라 공차가 꽤 넓습니다. 공차는 칩 설명서가 "이만큼까지는 틀어져도 정상"이라고 약속한 범위예요. 이 보드는 그 범위 안에서 시계가 약 4% 느렸어요. 이렇게 한 보드에서 실제로 틀어진 양은 따로 오차라고 부릅니다. 느린 시계로 100ms 눈금을 세면 실제로는 100 ÷ 0.96 ≈ 104.2ms가 걸립니다. 가장 늦은 실측 104.1ms와 거의 같죠. 가장 빠른 쪽도 104.2 − 10 = 94.2ms로, 실측 94.3ms와 맞아요.

이번 보드의 결론: 타임아웃 100ms 설정을 그대로 씁니다. 멈춘 뒤 길어야 약 0.1초 안에 되살아나니, LED 보드에는 충분히 빨라요.

다만 설계할 땐 보드 한 장의 실측이 아니라, 칩 설명서에 적힌 공차 전체를 넣어서 가장 늦게 되살아나는 시간까지 확인해야 합니다.

현장 팁: 워치독 처음 쓸 때 흔한 실수

타이머 인터럽트 안에서 밥을 주지 마세요. 코드 리뷰에서 자주 지적받는 부분이기도 합니다. 메인 코드가 무한 루프에 빠져도 인터럽트는 꼬박꼬박 살아 있을 수 있어요. 그러면 워치독은 "주인이 멀쩡하네" 하고 속아 넘어갑니다. 밥은 메인 흐름이 한 바퀴를 제대로 돌았을 때 주세요.

"살아났으니 됐다"로 끝내지 마세요. 워치독 리셋은 어딘가에 버그가 있다는 증거입니다. 부팅하자마자 리셋 원인 레지스터를 읽어 기록해 두면, 현장에서 몇 번 되살아났는지 나중에 확인할 수 있어요.

되살아난 뒤엔 안전한 상태부터 시작하세요. 모터나 히터처럼 움직이는 출력은 리셋 직후 일단 꺼 두고, 상태를 확인한 뒤에 다시 켜는 게 안전합니다.

개발 중 꺼 둔 워치독은 출시 전에 꼭 다시 켜세요. 디버깅이 편하다고 꺼 두었다가 그대로 나가는 경우가 생각보다 많습니다. 출시 점검 목록에 한 줄 넣어 두세요.

자주 묻는 질문 (FAQ)

Q. 워치독이 있으면 버그를 안 고쳐도 되나요?

아니요. 워치독은 넘어진 뒤 일으켜 세워 줄 뿐, 넘어지는 이유를 없애 주진 않습니다. 되살아나는 동안 잠깐 멈추는 것도 사용자에겐 고장이에요. 위의 센서 대기 코드처럼 기다리는 시간에 제한을 두는 식으로 원인도 함께 고쳐야 합니다.

Q. 타임아웃은 얼마로 정하면 되나요?

정상일 때 가장 오래 걸리는 작업보다는 넉넉히 길게, 기계가 멈춘 채 버텨도 괜찮은 시간보다는 짧게 잡습니다. 예를 들어 이 글의 사례처럼 10ms마다 도는 코드라면 주기의 10배인 100ms로 잡을 수 있어요. 너무 짧으면 멀쩡한데도 리셋되고, 너무 길면 늦게 되살아나요.

Q. 워치독이 못 잡는 경우도 있나요?

있어요. 코드가 폭주해서 엉뚱한 곳을 돌다가 밥 주는 코드를 우연히 계속 부르면, 워치독은 정상이라고 착각합니다. 이런 경우까지 잡으려고 "너무 일찍 줘도 짖는" 윈도우 워치독이 있어요.

Q. 디버깅하려고 코드를 멈춰 두면 리셋돼요.

코드를 멈추면 밥도 끊기니 당연한 결과입니다. 많은 MCU가 디버깅 도구로 멈춘 동안 워치독도 같이 멈추는 설정을 제공하니, 칩 설명서에서 찾아보세요.

정리: 워치독은 멈춘 기계를 위한 마지막 안전망

사람 손이 닿지 않는 곳에서 기계가 멈추면, 누군가 리셋 버튼을 눌러 줄 때까지 영원히 멈춰 있습니다. 워치독은 코드와 따로 도는 경비견이라서, 밥(클리어)이 타임아웃보다 오래 끊기면 스스로 MCU를 깨웁니다. 버그를 고쳐 주는 장치는 아니니 원인은 따로 고치고, 리셋 원인 레지스터로 "몇 번 되살아났는지" 꼭 기록해 두세요. 그리고 출시 전엔 고장 주입 시험으로 정말 되살아나는지 직접 확인해 보시길 바랍니다.