AI의 대답을 판단할 수 없을 때

지난 편은 익숙한 영역에서 첫 번째 규칙을 배운 이야기였어요. 선택지는 AI 가, 결정은 내가. 그 규칙에는 전제가 있었습니다. 결과를 제가 직접 보고 판단할 수 있다는 것이요. 이번 편은 제가 직접 보고 판단할 수 없는 영역인 펌웨어 이야기에요.

봐도 모르는 영역

1월부터 4월까지 펌웨어를 만들었어요. 보드는 2개 였습니다. 모터와 펌프를 움직이는 MCU 는 ESP32-S3 이고, ESP-IDF 위에 C 로 짰어요. 카메라와 추론과 통신을 맡는 NPU 는 Rockchip RV1106 이 올라간 Luckfox Pico 보드이고, 작은 리눅스가 돌아서 adb 나 ssh 로 들어갈 수 있어요. 시리얼 선으로 둘을 연결 했기 때문에 통신용 UART 프로토콜을 직접 만들어야 했어요. CRC 로 깨진 프레임을 걸러내고, 긴 메시지는 잘라서 보낸 후 받는 쪽에서 다시 붙이고, 응답이 없으면 재전송하는 것까지요. NPU 쪽에는 벤더 SDK 가 있었는데, 카메라 이미지가 ISP 에서 VI 로, VPSS 로, VENC 로 흘러가는 파이프라인은 저에게 낯선 영역이었어요. 어느 단계에서 무슨 일이 일어나는지, 문서를 읽어도 머리에 잘 그려지지 않았어요. 첫 커밋으로부터 두달 정도 지난 1월 30일 즈음에야, 처음으로 실기기에서 카메라 스트리밍과 AI 추론 동시 실행이 무사히 같이 돌았습니다.

익숙한 영역과 다르게 펌웨어는 화면이 전혀 없었어요. 대신 부팅 로그와 UART 프레임과 커널 메시지가 있었는데, 그건 봐도 잘 몰랐어요. 앱 화면은 보자마자 이상한 곳을 알았는데, 부팅 로그는 봐도 정상 로그와 이상 로그를 구분하기 어려웠어요. 지난 편까지는 자비스와 함께 달리는 느낌이었는데, 이 영역에서는 자비스가 하는 말이 맞는지 제가 확인할 수가 없었어요.

지난 편에서 모르는 것은 그 자리에서 배우면 되겠구나 깨달았던 것처럼 이 영역에서도 배울 수 있는 것들이 있었어요. UART 가 무엇인지, CRC 가 왜 필요한지, 상태머신을 어떻게 짜는지는 AI 가 설명해주면 이해할 수 있었어요. 배우고 나면 설계 논의를 시작할 수 있었고요. 그런데 이 영역에서 막히는 것들은 대부분 배워서 되는 종류가 아니었습니다. 이 보드에 BLE 가 있는가, 지금 도는 바이너리가 새 코드인가, NPU 가 지금 응답하고 있는가. 이런 건 일반론이 아니라 이 보드의 지금 상태였고, 직접 보드를 연결해서 확인해야만 알 수 있었어요. 모르는 걸 항상 배울수 있는건 아니었어요. 직접 확인해야 하는 것도 있었어요.

문제는 AI 가 그 둘을 구분하지 않고 말한다는 거였어요. 확인해야 알 수 있는 것을, 이미 아는 것처럼 말했어요. 확인하지 않고요. 이어지는 다섯 가지 사건은 전부 거기서 시작됐습니다.

성공 로그가 거짓일 수 있다

AI 가 짠 코드가 찍은 성공 로그는 기기의 대답이 아니어서, 믿을 수 없을 때가 있단걸 경험했어요.

2026년 1월 중순이었어요. NPU 코드를 고치고 빌드하고 배포했는데, 보드에서는 고치기 전과 똑같이 동작했어요. 빌드는 성공이었고 배포도 성공이었어요. AI 도 그렇게 얘기했고요. 그런데 로그에는 이미 지운 옛날 메시지가 그대로 찍히고 있었어요. 그래서 아래처럼 물었습니다.

npu 가 최신코드로 빌드된건지 확인해줘

이전 버전의 바이너리가 돌고 있었어요. 분명 빌드가 성공했다고 했는데, 새 코드가 보드에서 돌고 있지 않았어요. 그 사이에는 빌드 산출물이 어디에 생겼는지, 그 파일이 보드로 복사됐는지, 보드가 재시작하며 그 파일을 읽었는지 같은 여러 단계가 있었고, 그 중에 하나만 삐끗해도 배포는 실패하지만, 이상하게도 "성공"이라는 로그는 그대로 찍혔어요.

알고보니 로그 자체가 잘못 설계된 거였어요. 중간에 코드를 수정하면서 로그 수정을 놓친 거에요. 그 이후부터는 AI 가 "최신으로 배포했다"고 말해도 믿지 않게 됐어요. 확실하게 확인할 방법을 찾았어요. 배포 뒤에는 로컬 빌드 산출물과 보드에 올라간 파일의 md5 를 비교하게 했어요. 결정론적으로 확인하도록, 코드가 판정하게 했습니다.

비슷한 일이 카메라에서도 있었어요. 카메라 파이프라인 초기화 단계에서 성공 로그가 찍혔는데, 프레임 카운터가 0 이었어요. 초기화는 됐다는데 이미지는 한 장도 안 나오는 상태였어요. AI 는 코드에서 원인을 찾겠다고 진단을 시작했어요. 코드를 고치고 다시 배포하고 로그를 보는 일이 몇 바퀴 돌았는데도 프레임은 여전히 나오지 않았어요. 그래서 방향을 바꿔서, 벤더가 제공한 샘플 프로그램을 같은 보드에서 그대로 돌려보게 했습니다. 그러자 샘플에서는 프레임이 나왔어요. 하드웨어는 무죄였고, 원인은 우리 코드의 초기화 순서가 문제였어요. 카메라가 준비되기 전에 다음 단계가 먼저 시작된게 원인이었어요.

이 두 사건을 겪으며 배운게 있어요. 화면이 없으니 로그를 대신 봤는데, 그 로그는 AI 가 짠 코드가 찍은 것이었어요. 코드가 틀리면 로그도 같이 틀려요. 성공했다고 찍는 코드는 성공했다고 찍을 뿐이지, 성공했다는 증거가 아닐 수 있단걸 그때 알았어요. 성공 로그는 기기의 대답이 아니라 AI 의 말이구나.

md5 는 달랐어요. 벤더 샘플도 달랐어요. 그건 AI 가 쓴 코드를 거치지 않고 기기가 직접 대답한 거였어요. 이때 처음으로 가장 신뢰할 수 있는 판단 근거는 AI 가 아닌 기기에서 바로 찾아야 하는구나 깨달았어요. 그리고 로그 설계는 특별히 더 깊이 관여하게 됐어요. 어느 시점에 무엇을 찍을지, 성공이라는 말을 어떤 조건에서만 쓸지에 대해서요. 로그를 신뢰 하려면 설계부터 중요하겠더라고요.

원인이 코드 밖에 있다

때로는 로그에서 답을 찾을 수 없고, 코드 밖에서 찾을 수 있단걸 배운 세 가지 사건이 있었어요.

첫째, 모터가 안 돌았어요. AI 는 PWM 설정과 GPIO 매핑과 드라이버 초기화 코드를 차례로 의심했어요. 하나씩 고쳐서 플래시하고 다시 돌려봤지만 여전히 멈춰있었어요. 원인은 모터 드라이버의 STBY 핀이 LOW 로 묶여 있던 것이었어요. 드라이버가 계속 대기 상태였기 때문에 모터가 돌지 않았던 거였어요. 핀에 멀티미터를 대서 전압을 재본 후에야 원인을 정확히 파악했어요. 코드에는 아무 문제가 없었고요.

둘째, 4월 초에는 NPU 보드에 MCU 와 통신하는 UART 케이블을 꽂으면 부팅이 멈췄어요. 케이블을 빼면 부팅이 됐고요. 케이블 하나로 부팅이 되고 안 되니 처음엔 배선을 의심했어요. 그런데 진짜 원인은 커널 콘솔과 MCU 통신이 같은 시리얼 포트를 쓰고 있어서였어요. 부팅 중 커널이 콘솔로 쓰는 포트에 MCU 가 무언가를 보내니 부팅이 거기서 멈춘 거예요. U-Boot 환경변수의 console=ttyFIQ0 을 console=null 로 바꿔서 해결했어요. 이건 커널 로그와 부트로더 설정에서 확인해야 알 수 있는 것이었어요.

셋째, 보드에 전원을 넣는 방식을 바꿨더니 부팅이 안 됐어요. 코드는 한 줄도 수정하지 않았는데요. 이때도 AI 는 코드와 설정을 먼저 봤어요. 진짜 원인은 전원 라인이 문제였어요.

세가지 사건 모두 AI 는 코드를 원인으로 지목했어요. 원인이 코드 밖에 있으니 해결은 안되고, 계속 더 깊이 고민해봐 찾아봐 해도 원인을 찾을 수 없었어요. AI 가 게을러서가 아니라, AI 가 볼 수 있는 것이 코드와 코드가 찍은 로그뿐이어서 그랬던 거에요. 핀 전압과 케이블과 전원 같은 것들은 제가 손으로 직접 확인해야 했어요.

그러면서 어떤 증거를 신뢰할 수 있는지 파악하기 시작했어요. 벤더 샘플로 하드웨어를 격리해서 실험한 결과, 커널이 직접 찍은 메시지, 멀티미터로 잰 핀 전압, 바이너리의 md5. 이 넷의 공통점은 AI 가 쓴 코드를 거치지 않는다는 것이었어요. 로그를 신뢰할 수 없을 때 무엇을 봐야하는지 조금씩 감을 잡기 시작했어요.

옵션이 틀렸다

여기서부터는 지난 편에 설명한 첫번째 규칙을 보완한 이야기에요. 결정은 내가 하는데, 애초에 선택지가 틀린거면 어떻게 해야할까. 그 답을 찾아간 여정입니다.

1월에 WiFi 프로비저닝을 어느 보드가 맡을지 정해야 했어요. 앱이 BLE 로 WiFi 정보를 넘기면 보드가 받아서 접속하는 흐름이요. AI 는 이 NPU 보드에서 BLE 를 직접 구현하는 건 어렵다고 했어요. 그래서 BLE 는 MCU 가 받고, 받은 정보를 UART 로 NPU 에 넘기는 구조로 결정했습니다. 지난 편에서 설계한 BLE 프로토콜과 이번 편의 UART 프로토콜 모두 이 결정을 기반으로 구현했어요.

4월 즈음에 보드 교체를 검토하면서 보드에 대해 더 자세히 공부하던 중에, 현재 NPU 에서도 BLE 를 구현할 수 있다는 정보를 알게 되었어요. 그래서 아래처럼 시켰어요.

지금 Npu 안에서 ble 연결 가능한지 탐색해봐. 코드샘플 있는지.

AI 는 코드베이스와 웹 문서를 뒤지고 나서 1분 만에 답했어요. 이 SoC 에는 블루투스가 내장돼 있지 않아서 USB 동글을 달거나 상위 보드로 바꿔야 하고, 지금처럼 MCU 가 BLE 를 맡는 게 가장 현실적이라고요. 1월과 같은 답이었어요. 그런데 이번에는 코드베이스 말고 보드 안에 직접 들어가서 확인하라고 했어요. hciconfig 를 실기기에서 실행하니 Bluetooth 5.2 컨트롤러가 이미 올라와 있었어요. 보드의 WiFi 칩이 BT 콤보였던 거에요.

이 구조를 대대적으로 리팩토링 한다. 오직 Npu 에서 ble advertising 부터 wifi 연결까지 전부 혼자서 수행하도록. 이를 위해 계획부터 같이 세우자.

대규모 리팩토링을 시작한지 사흘 뒤인 4월 7일에 NPU 혼자 BLE 광고부터 WiFi 접속까지 전체 프로비저닝 과정이 실기기에서 정상동작 했어요. 두 달 동안 전제로 믿고 쌓아올렸던 정말 큰 결정이 처음부터 틀렸단걸 알게 된거에요.

되돌아보면 1월의 "이 보드에서 BLE 는 어렵다"는 제가 직접 더 보드에 대해 공부해야지만 알 수 있는 것이었어요. 그걸 AI 가 제대로 모르면서 아는 것처럼 말했고, 저는 배우는 것처럼 받아들여서 두 달 동안 잘못된 전제 위에서 개발했던 거에요. 첫 번째 규칙은 선택지는 AI 가 주고 결정은 제가 하는 것이었는데, 선택지 자체가 틀린거라면 결정도 같이 틀릴 수 밖에 없었어요. 그래서 결정하기 전에 선택지도 가능한 확실하게 더 검증하게 되었어요. 특히 펌웨어 관련해서는 기기에서 직접 확인 했어요. 그게 가장 확실한 방법이었어요.

기록된 결정이 틀렸다

지난 편에서 결정을 문서로 남기게 했어요. 그런데 그 문서에 틀린 결론이 적혀 있으면, 틀린 결론을 계속 참조하게 되어요.

1월에 NPU 에서 스트리밍과 AI 추론을 같이 돌리면 추론이 실패했어요. AI 의 진단은 분명 DDR 대역폭 경합이었어요. 스트리밍이 메모리 대역폭을 다 써서 추론이 실패한다는 설명이었고, 그럴듯했어요. 저는 그걸 공부하고 결론으로 받아들여 문서에 적었고, 그 위에 최적화를 쌓았어요. 스트리밍을 잠깐 멈추고 추론하는 시분할 구조, 프레임 복사를 줄이는 제로카피 등. 실측도 가설을 지지했어요. 720p 에서는 추론 성공률 94% 였고 1440p 에서는 0% 였어요. 해상도가 높을수록 대역폭을 더 쓰니까 실패한다는게 앞뒤가 맞았어요. 이 가설은 문서에 기록된 채 두 달 동안 설계의 전제로 유지되었어요.

2월 5일 세션에서 저는 이 구조를 AI 에게 확정된 사실처럼 설명하고 있었어요.

이전 방식에서는 ai 추론을 위한 v4l2 캡쳐를 위해 rkipc 를 잠깐 멈췄어야 했다(ddr 대역폭 불충분으로 동시 불가능했기에 time slicing 아키텍처 사용)

그런데 대역폭 경합이라면 스트리밍이 없을 때는 잘 돼야 하는데, 그날은 스트리밍을 끄고도 추론이 안 됐어요. 예전에 이 보드에서 카메라 처리를 끄고 추론만 돌렸을 때는 분명 정상 동작한 기록이 있었거든요. 그래서 이렇게 시켰습니다.

이 보드에서 npu 정상동작 했었다. 가장 간단하게 확인해봐. 왜냐면 rkaiq 끄고 inference 로그 정상 찍힌 기록 있다.

가장 간단한 확인은 커널 로그였어요. 거기에 이렇게 찍혀 있었어요.

RKNPU: job timeout
RKNPU: core 0 irq status: 0x0, raw status: 0x0
RKNPU: soft reset

NPU 가 작업을 받고 인터럽트를 한 번도 올리지 않은 채 타임아웃이 나고 있었어요. 경합이 아니라 그냥 무응답이었어요. 대역폭이 모자란 게 아니라 NPU 가 대답 자체를 안 하고 있었던 거예요. 시분할과 제로카피는 애초에 필요없던 거였어요.

이 사건이 앞의 BLE 사건과 다른 점은, 틀린 결론이 심지어 문서에 적혀 있었다는 거예요. 매 세션 AI 가 그 문서를 읽고 시작하니, 문서에 적힌 결론은 프롬프트로 한 번 잘못 말한 것보다 훨씬 영향이 컸어요. 심지어 94% 대 0% 같은 실측이 붙어 있으면 더 의심하지 않아요. 그 뒤로 문서에는 두번 세번 검토하고 확실해진 결론만 적게 했어요.

이해 못 하는 결정

첫 번째 규칙에는 구멍이 하나 더 있었어요. 판단을 하는 제가 충분히 이해했다고 착각하는게 문제였어요.

카메라 파이프라인을 재설계해야 할 때였어요. AI 가 계획을 써왔는데, 읽어도 판단이 안 됐어요. VI 와 VPSS 와 VENC 가 어떤 순서로 묶이는지, 어느 그룹에 어느 해상도가 붙는지 모든게 낯설었어요. 기초가 너무 없어서요.

그래서 우선 이해될 때까지 물어봤어요. 2월 5일 프롬프트에요.

vpss group 0 에 2560 이 없는데 어떻게 venc 가 그다음순서로 올수있어?

계획서의 앞부분과 뒷부분이 맞지 않는 곳을 찾아서 물었어요. 앞에서는 VPSS 그룹 0 에 2560 해상도가 없다고 해놓고 뒤에서는 그 뒤에 VENC 를 붙인다고 하니, 둘 중 하나가 틀린 거에요. 이런 질문을 몇 번 하면 계획의 틀린 부분을 발견하거나, 제가 이해하거나 둘 중 하나였어요. 이 질문 뒤에 AI 는 벤더의 샘플 코드를 찾아와서 VI 에서 VPSS 로 다운스케일하고 VENC 로 넘기는 흐름으로 수정했어요.

두 번째로 한 건 승인의 단위를 작게 줄이는 것이었어요. 이해가 안 되는 큰 계획을 한번에 승인하기 보다는, 방법을 찾는 단계와 코드를 고치는 단계를 나눴어요. 12월 31일, NPU 보드에서 스트리밍과 추론을 처음 같이 실행하던 날에 프롬프트에요.

계속해서 방법만 찾아. 코드수정은 절대하지마 아직.

지난 편의 "코드 수정은 아직 하지마라"가 여기서는 더 잘게 쪼갰어요. 방법만 찾게 하고, 찾은 방법을 제가 하나씩 확인하고, 그중 이해되는 것만 구현으로 넘겼어요. 이해되지 않는 것은 구현 전에 다시 물어봤고요.

그래도 끝까지 이해가 안 되는 결정도 있었어요. 스트리밍 얘기에요. 보드는 벤더의 rkipc 프로그램으로 카메라 영상을 RTMP 서버에 보내는데, 보드가 여러 대면 각자 다른 경로로 보내야 해요. 그런데 서버 주소와 경로가 rkipc 바이너리 안에 하드코딩 되어 있었어요. 소스가 없으니 다시 빌드할 수도 없었고요. AI 가 낸 방법은 RTMP 핸드셰이크 패킷에서 경로 이름이 담긴 자리 세 곳을 찾아 바이트 단위로 치환하는 것이었어요. 왜 그 세 곳인지, 길이가 다른 문자열을 넣어도 되는지, 그게 안전한지 판단할 수 없었어요. 배우고 싶은데 어디서부터 어떻게 배워야할지도 모르겠더라고요.

그때 두가지 질문을 했어요. 되돌릴 수 있는가. 실기기에서 즉시 증명되는가. 바이트 패치는 rkipc 원본은 그대로 두고 나가는 패킷에만 적용하니 되돌릴 수 있었고, 보드에 올려서 스트리밍이 서버에 붙는지 바로 볼 수 있었어요. 둘 다 예스 였어요. 그래서 이해하지 못했지만 승인했고, 실기기에서 증명 됐고, 그 뒤로 여러 대의 보드가 각자의 경로로 스트리밍하는 데 문제없이 잘 돌았어요.

이해하지 못한 채 승인한 결정은 부채로 남아요. 나중에 그 부분이 문제를 일으키면 저는 결국엔 이해해야 하니까요. 그래도 특정 상황에서는 넘어가야할 때가 있었어요. 시간내에 완성은 해야 했기 때문에요. 결국 되돌릴 수 있고 기기가 바로 증명해주는 결정이면 이해가 조금 모자라도 진행하는걸 택했어요.

두 번째 규칙, 증거

다섯 가지 사건을 통해 세운 두번 째 규칙은 다음과 같아요. AI 의 말은 가설이고, 기기의 대답만 증거다.

여기서 AI 의 말의 의미는 꽤 범위가 넓어요. 선택지도, 전제도, 진단도, 성공 보고도 모두 AI 의 말에 포함해요. 그리고 AI 가 짠 코드가 찍는 로그까지도요. 기기의 대답은 AI 가 쓴 코드를 거치지 않고 기기에서 직접 찾은 거에요. hciconfig 의 출력, 벤더 샘플의 프레임, 커널 메시지, 핀 전압, 바이너리 md5 등. 그리고 그 대답을 찾기 위해 가장 간단한 확인을 먼저 해요.

첫번째 두번째 사건은 AI 에게 맡긴 후에 이야기고, 나머지는 맡기기 전 이야기여서요. 뒤의 셋은 첫 번째 규칙을 보강하는 과정이기도 했어요. 결정 전의 선택지에도 같은 규칙을 적용할 수 있었어요. 선택지도, 기록할 결정도 정말 참인지 기기에 한번더 확인하고, 이해 못 하는 결정을 할 때는 되돌릴 수 있는가와 즉시 증명되는가를 묻는 것으로요.

배운 것

지난 편에서 익숙한 영역이 빨랐던 진짜 이유가 결과를 보고 직접 판단할 수 있어서라고 했는데요. 펌웨어 영역에서는 판단 주체가 AI 로 어느새 변해 있었어요. 화면이 없으니 로그를 봤고, 로그를 제대로 못 읽으니 AI 의 해석을 들었고, AI 가 성공이라고 하면 성공이 되었어요.

그 변화를 캐치하는게 먼저였어요. 그리고 근거를 AI 의 말에서 기기의 대답으로 옮기는 것, 그게 두 번째 규칙이었습니다. AI 가 기기에서 직접 확인해야 아는 것을 확인도 안하고 아는 것처럼 말하는 건 여전했어요. 대신 제가 직접 확인하는 습관을 갖게 됐습니다. 결국 내가 다시 판단의 주체가 되려는 과정이었어요.

규칙 적용 후, 어디까지 갔나

두번째 규칙을 적용했더니, 이전 규칙만으로는 못 갔던 곳까지 갈 수 있게 됐어요.

• MCU 쪽: FSM 으로 부팅부터 청소까지의 흐름을 설계했어요. 크래시가 연달아 나면 RTC 메모리에 횟수를 남겨 두고 다음 부팅 정책을 바꾸는 crash streak 처리, 로봇에 화면이 없으니 LED 색과 깜빡임으로 상태를 말하게 하는 기능, 그리고 모터와 펌프 제어까지 성공했어요.
• UART 프로토콜: 시리얼 선으로 통신하는 프로토콜이에요. CRC8 로 프레임 검증, 긴 메시지의 분할조립, ACK 를 못 받으면 재시도, 같은 메시지가 두 번 오면 걸러내는 중복 캐시 등도 만들었어요.
• NPU 쪽: 벤더 RKMPI 로 카메라 파이프라인을 잡았고, 다섯번째 사건에서 바이트 패치로 보드 여러 대가 각자의 경로로 RTMP 스트리밍을 하게 했고, 두번째 사건에 U-Boot 환경변수 패치로 UART 케이블을 꽂은 채 부팅이 가능하게 했어요.
• 프로비저닝 이관: Npu 보드의 커널 블루투스 스택이 LE 명령을 막아서 일반적인 BlueZ 경로를 쓸 수 없었고, raw HCI 를 직접 잡아 그 위에 GATT 서버를 올렸어요. 이것도 기기에 직접 확인해서 안 것이었어요. 결국 MCU 없이 NPU 혼자 BLE 광고부터 WiFi 접속까지 끝냈습니다.
• 메인루프 소유권 리팩터: 추론과 스트리밍을 켜고 끄는 결정이 여기저기 흩어져 있던 걸 메인루프 하나가 소유하게 바꿨어요. 커밋 메시지는 "main loop owns inference/streaming decisions (validated on board)" 예요. 보드에서 검증했다는 말을 보면 두번째 규칙 덕분이에요.

마무리

여기까지의 규칙은 두가지에요.

익숙한 영역에서는 첫번째 규칙이면 충분했어요. 봐도 모르는 낯선 영역에 오니 판정의 근거를 기기에서 직접 찾아야 했어요. 그게 두 번째 규칙이에요. 첫 번째 규칙도 보완이 필요했어요. 선택지와 기록된 결정에 대해서도 기기에서의 확인이 필요했으니까요.

다음 편도 같은 펌웨어 영역이에요. 판정의 근거를 기기에서 찾으려 하니 판정이 느려졌어요. 증거를 매번 직접 수집했더니 하루에 개발 싸이클을 몇 바퀴 못 돌았거든요. 그걸 어떻게 기기에게 맡겼는지 이어서 이야기할게요.