선택지는 AI 가, 결정은 내가

지난 편은 "자비스 도와줘!"를 외치며 로봇 개발을 시작한 이야기였어요. 시작은 가장 익숙한 영역부터 했습니다. 앱과 서버요. 설계는 제가 하고, 구현은 AI 가 하고, 결과는 제 눈으로 판단하는 방식으로 진행했어요.(테스트는 아직 너무 초반이라 오히려 걸림돌이 되는것 같아 필요한 부분만 직접 QA 했어요)

익숙한 영역답게 속도는 빨랐어요. 이틀 만에 앱 화면 라우팅 설계가 잡혔고, 2주 뒤에는 로봇 카메라의 영상이 앱에서 실시간으로 보였습니다. 자비스와 함께 달리면서 개발 속도가 빠른게 신기하고 재밌었는데, 이렇게나 빠른 진짜 이유는 따로 있었어요. 그 이유를 살펴보기 전에 먼저, 배운 점과 배우게 된 과정을 살펴보겠습니다.

(이제부터 보여드릴 프롬프트는 세션 기록에서 그대로 가져왔어요. 오탈자도 그대로요.)

결정할 지식이 없다

앱은 익숙한 영역이었어요. 그런데 이 앱은 로봇과 BLE 로 통신해야 했습니다. 로봇에는 화면도 버튼도 없어서, 앱을 통해서 WiFi 정보를 전달해야 했어요. BLE 위에 바이너리 프로토콜을 쌓아야 했고, 프레임 포맷과 체크섬과 재전송을 결정해야 했어요. 설계를 하고 싶어도, 아는 게 없으니 설계를 할 수가 없었어요. 익숙한 영역에서 하던 방식이 처음으로 막힌 순간이었습니다.

그래서 방식을 조금 바꿨어요. 바닥부터 제가 설계하는 대신, AI 에게 선택지와 장단점을 설명하라고 한 뒤에 제가 결정했어요. 12월 23일 프롬프트를 볼게요.

reason u8 과 u16 했을때 차이점 비교분석 핵심만 간단하게 설명해줘

u8 로 가고, evt 에 u16으로 보내 baudrate 는 적절한 값으로(성능, 설계 모두충족하며 잡도록) 나머지 값들 적당하게 advertising legacy 유지 괜찮다. device_id_hash 2B 로 가자. 5분으로 하자

A로 확정하자

설명을 듣고 이해한 후에야 결정할 수 있었어요.

만약 결정하기 위한 이해가 부족하면, 그 자리에서 질문하며 더 자세히 설명 해달라고 요청해서 배웠어요.

UART 파라미터, Advertising payload 둘다 좀더 자세한 배경지식 필요해. 결정하려면. 더 설명해줘.

header 파일이란 정확히 뭐야 c언어 개발시에 지금 우리 프로젝트 기준으로

동료에게라면 조금 부끄러웠을 수도 있을 질문들인데, 부끄러움이 없으니 결정에 필요한 만큼만 빠르게 배울 수 있었어요. 그때 다시 한번 깨달았습니다. 모르는 영역에서 결정하려면, 먼저 배워야 하는구나.

논의와 구현 사이에

카메라로 찍은 영상을 서버로 보내는 기능을 만들 때였어요. 스트리밍 프로토콜을 고를 지식이 없어서, 제약 조건을 주고 비교분석을 시켰습니다. 12월 17일 프롬프트예요.

원격 수신서버가 mediamtx 가 맞다. rkipc 를 수정해서 퍼블리시 하는 방식은 없는지 검토해줘. RTMP push 와 RTSP publish 중 어떤게 더 좋을까? 상용화 관점에서 비교분석해줘

목표지연은 300ms 다. 오디오 필요 없다. 보드가 NAT 뒤에 있다.(외부 서버 pull 불가능). mediamtx 경로는 aws ec2 가 될거다. (인증은 토큰으로). 구현 가능한지 현실성도 함께 검증하며 추천해줘. 이때 필요하면 adb -s 368************* shell 로 접속해서 실제 luckfox pico zero 보드 안에 들어가서 확인해봐.(코드 수정은 아직 하지마라)

마지막 괄호가 이 무렵부터 습관처럼 붙기 시작한 말이에요. 이 요청이 왜 필요했냐면요. AI 에게 최대 권한을 주는 게 대원칙이었기에, 그때 Claude Code 는 항상 bypass permissions on 모드였어요. 그래서 시키면 일단 코드부터 작성했습니다. 그렇게 작성된 코드를 기준으로 다음 논의가 시작됐고요. 앞의 구현이 잘못됐다면 뒤에서 잘못된 코드가 눈덩이처럼 빠르게 불어나는 구조였어요.

그래서 논의와 구현 사이에 승인 단계를 추가했어요. "일단 계획만 세워줘." "검토만 해줘 문서 수정은 아직 하지말고." 계획을 세우고, 검토하고, 제가 승인하면, 그때 구현하도록이요. plan mode 가 있었는데, 모드를 전환하는 것보다 제가 직접 명령하는 게 더 편했어요.

결정이 아침마다 사라진다

어제 두 시간 동안 대화한 끝에 내린 결정을, 오늘 새로 시작한 세션은 전혀 모릅니다. 그 당시 Claude Code 가 가진 한계였어요.

그래서 결정이 끝나면 문서로 남기게 했습니다.

전체 계획에 대해 정리한 내용을 docs 폴더 하위에 provisioning_architecture.md 로 정리해줘

그리고 같은 날 새 세션의 첫 프롬프트는 이렇게 시작해요.

코드 전체를 먼저 파악해줘. 그리고 robopet-mcu/docs/provisioning_architecture.md 문서를 꼼꼼하게 읽고, 이 문서의 내용대로 기존 코드를 수정 및 보완해줘.

결정을 저장하는 곳이 파일 시스템이 됐어요. 문서가 확실한 기억장치였습니다. (이 문서들이 나중에 어떤 체계를 갖추는지 6편에서 다룰게요.)

하나의 AI 만 믿기에는 불안해

프로토콜처럼 되돌리기 어려운 설계는, AI 하나의 안만 그대로 믿기 불안했어요. 그래서 같은 설계를 Claude Code 와 Codex 둘에게 각각 시켰습니다. 그리고 두 안을 제가 직접 비교해서 좋은 점만 취합한 스펙으로 결정했어요. 12월 23일, Codex 에게 보낸 프롬프트에 그 흔적이 있습니다.

아래는 Codex 안을 베이스로 하고, Claude 안의 구조적 장점만 흡수하여 충돌 요소를 제거하고 프로덕션 기준으로 잠근 v1.2 최종 스펙이다.

결정에는 방향 교정도 포함돼요. 1월 초에 CI/CD 를 맡겼더니 SSH 배포로 구현했길래 이렇게 물었습니다.

왜 ssm 배포로 안해? ssm 배포로 돌려노면 더 편하잖아? 무슨 이유에서 ssh 배포로 간거야?

짚어주지 않으면 AI 는 알고 있는 익숙한 길로 갑니다. 다른 AI 와 대화하며 ssm 을 알게 되었고, 그걸 짚어주니 더 나은 길을 찾았어요. 선택지를 하나의 AI 에게만 물어보면 그게 최선인지 알 수 없다는 걸 이때 배웠어요.

정리된 규칙

앞에서 살펴본 네 순간은 모두 결정에 관한 순간이었어요. 결정할 지식이 없어서, 결정하기 전에 AI 가 먼저 손대서, 어제 내린 결정이 사라져서, 묻는 AI 가 하나뿐이어서, 충분히 좋은 결정을 하지 못할 뻔했습니다.

그 과정을 통해 몸으로 겪으며 한가지 규칙을 배웠습니다. 선택지는 AI 가, 결정은 내가.(결정하기 전에는 진행하지 않게 하고, 결정한 것은 문서로 남긴다.)

그때는 이걸 규칙이라고 생각하지 않았어요. 매번 프롬프트로 말하는 습관이었을 뿐이에요. 지나고 나서야 규칙으로 정리했어요.

눈은 손보다 빠르다

이제 익숙한 영역에서 빨랐던 진짜 이유를 살펴보며 이야기를 정리하려 합니다.

앱 화면이 이상하면 보자마자 알았고, API 설계가 틀어지면 읽자마자 알았어요. 결과를 제가 직접 보고 판단할 수 있었기 때문에, AI 가 아무리 빨리 만들어도 의심되는 부분만 짚어서 확인하고 고쳤어요. 병목이 덜 생겼던 거예요. 그렇게 12월 한 달 동안 앱 화면 전체와 라우팅, BLE 프로비저닝의 앱 쪽, HLS 라이브 플레이어, NestJS 와 MQTT 와 Supabase 서버, EC2 와 Docker 와 스트리밍 서버, SSM 기반 CI/CD 까지 만들었어요.

직접 볼 수 없는 곳은 AI 가 대신 들어가서 보게 했어요. 12월 16일에는 보드에 들어가는 법을 알려줬고, 직접 들어가서 확인하게 했습니다.

adb -s 38~~ shell 하면 luckfox 칩으로 접속 가능해. 접속해봐.

열흘 뒤인 12월 26일에도요.

너가 직접 adb -s 368************* shell 들어가서 확인해봐.

처음 EC2 를 띄우던 날에는 콘솔 스크린샷을 직접 찍어 주었어요. "스크린샷 보고 이렇게 런칭하면 될지 확인해줘" → "이렇게하면 될까?" → "이렇게 간다?" 빌드가 깨지면 에러 로그를 통째로 붙여넣었고요.

그런데 이것들은 제가 직접 보는 범위를 넓힌 것뿐이었어요. 판단은 여전히 제가 보고 했으니까요.

빨랐던 진짜 이유는 AI 가 빨라서가 아니라, 결과를 보자마자 제가 판단할 수 있어서였습니다. 익숙한 영역에서의 결정이었으니까요. 결정이 틀려도 결과를 보면 바로 알았어요. 그렇게 스스로 판단할 수 있으니 스스로 결정할 수 있었고, 그래서 결정만 잘하면 됐어요.

익숙한 영역에서 모르는 것에는 한 가지 공통점이 있었어요. BLE 프로토콜처럼 판단할 수 없는 것도 그 자리에서 배우면 판단할 수 있게 됐고, 배운 게 맞는지도 앱이 돌면 보고 알 수 있었습니다. 모르는 것이 전부 배우면 해결할 수 있는 것들 이었어요.

첫 번째 규칙에는 "결과를 내가 보고 판단할 수 있다"는 전제가 있었습니다. 다음 편은 그 전제가 없는 영역, 펌웨어에 대한 이야기에요. 부팅 로그를 봐도 몰랐고, 모르는 것을 배워서 되는게 아니었어요. 이 보드에 BLE 가 있는지, 지금 도는 코드가 새 코드인지는 배우는 게 아니라 직접 확인해야 아는 것이었고, AI 도 모르는 것이었습니다. 그곳에서 기존 규칙은 어떻게 변했는지, 새로운 규칙이 생겼는지에 대해 이어가 볼게요.