가전제품 MCU 펌웨어, AI가 100% 개발하는 시나리오 가능한가

Source: Samsung Tech Blog

삼성전자 가전제품 펌웨어 개발에 ‘하네스 엔지니어링’을 적용하여, AI 에이전트가 100% 스스로 소프트웨어를 개발할 수 있는지 확인하는 프로젝트를 진행했습니다. 사람은 ‘무엇을 만들지’와 ‘어떻게 확인할지’만 설계하고, AI가 계획·구현·검증을 자율적으로 반복하도록 한 과정과 그 결과를 공유합니다.

들어가며 - 새로운 흐름, ‘하네스 엔지니어링’

요즘 AI를 이용한 소프트웨어 개발 분야에서 빠르게 번지고 있는 말이 있습니다. 바로 ‘하네스 엔지니어링(Harness Engineering)’입니다. 2026년 2월, OpenAI에서 발표한 내용이 시작이었습니다. 인간 개발자의 코딩 없이 5개월간 AI로만 소프트웨어 제품을 만들어 베타 버전을 출시했다는 내용이었죠. 결론은 단순했습니다. ‘사람은 방향을 잡고, 에이전트가 실행한다’는 것입니다.

여기서 말하는 ‘하네스’란 무엇일까요? OpenAI의 설명을 빌리면, 하네스는 AI가 일할 수 있도록 ‘작업 환경’ 전체를 설계하는 것을 뜻합니다. AI가 알아야 하는 정보, 하지 말아야 할 것, 그리고 생성한 결과가 올바른지 스스로 검증하는 루프까지 모두 포함됩니다. 소프트웨어 프로젝트의 폴더 및 파일 구조, 제품 사양서, 코딩 스탠다드, 프로젝트 지침, 빌드 방법, 린터까지 모두 하네스의 일부입니다. 즉, 모델 자체를 더 똑똑하게 만드는 일이 아니라, 의도한 결과물을 모델이 제대로 생성할 수 있는 ‘환경’을 설계하는 일입니다.

그렇다면 이 개념을 제약이 많기로 유명한 임베디드 영역, 특히 가전제품 MCU 펌웨어 개발에 적용하면 어떨까요? 메모리도 작고, 실시간성이 요구되며, 결국 실제 하드웨어 상에서 검증해야 하는 이 분야에서 ‘AI 100% 개발’을 실현하려면 어떤 하네스가 필요할까요? 이 질문에 대한 답을 확인하기 위해 하나의 프로젝트를 진행했습니다.

가전제품 펌웨어에 하네스가 필요한 이유

이 프로젝트는 2026년 3월부터 약 2달간 ‘레인지 후드’ 제품군의 MCU 펌웨어 개발을 대상으로 진행되었습니다. 이 프로젝트를 소개하기에 앞서 ‘MCU’와 ‘펌웨어’가 무엇인지 간략히 설명드리려고 합니다. MCU는 CPU, 메모리(ROM, RAM), 그리고 외부 장치와 통신할 수 있는 다양한 입출력(I/O) 포트를 하나의 칩에 통합한 ‘초소형 컴퓨터’입니다. 우리가 임베디드 코딩 교육에서 흔히 접할 수 있는 아두이노(Arduino) 같은 것들이 이 MCU를 쉽게 제어할 수 있도록 만들어놓은 개발 키트라고 생각하시면 됩니다. 일반적인 PC가 범용적인 목적을 위해 고성능의 OS(Windows, macOS)를 구동한다면, MCU는 특정 기기를 제어하기 위한 특수 목적에 최적화되어 있습니다. MCU 펌웨어는 이 칩 위에서 동작하는 소프트웨어로, 가전제품의 하드웨어 동작을 실질적으로 제어하는 역할을 합니다.

‘레인지 후드’ 제품군을 선택한 이유는 기능이 비교적 단순해 하네스 엔지니어링 설계에 더 집중할 수 있기 때문입니다. 레인지 후드에는 전원 제어, 풍량 제어, 조명 제어, 키 입력, 사운드 출력, LED 출력, 팬 제어 등 제품 본연의 기능이 있습니다. 프로젝트의 목표는 기본 골격(Zero-Base) 소스 코드로 시작해 이러한 기능을 사람 개입 없이 100% AI가 구현하도록 하는 것이었습니다. 여기서 핵심은 사람이 코드를 직접 구현하는 대신 ‘AI가 일할 수 있는 사양’을 정의하고 ‘검증 환경’을 설계하는 데 있습니다. 개발자의 역할을 ‘코드 작성자’에서 ‘사양 및 하네스 설계자’로 전환하는 것입니다.

기존 펌웨어 개발은 사양 정의, 구조 설계, 구현, 테스트 작성, 디버깅, 회귀검증을 사람이 순차적으로 수행했습니다. 이 과정에서 개발자의 경험과 암묵지가 품질을 좌우했고, 시간이 지날수록 사양과 코드가 조금씩 어긋났습니다. MCU 펌웨어 개발의 AI 전환을 위해서는 ‘AI가 혼자 알 수 없고 판단하기 어려운 것’을 하네스의 형태로 설계하여 보완해야 합니다. AI가 직접 확인할 수 없는 사양은 추측에 기반한 응답, 즉 할루시네이션으로 이어질 가능성이 높기 때문입니다.

핵심원칙: 문서화되지 않은 사양은 존재하지 않는 사양



“AI가 확인할 수 없는 사양은 존재하지 않는 사양이다.”라는 명제는 MCU 펌웨어 개발 방식 전환의 출발점이 ‘사양 설계’에 있음을 의미합니다. 구체적으로 사양 설계는 레거시 사양서와 개발자의 ‘암묵지’를 AI가 활용할 수 있는 형태로 체계화하는 과정입니다. 기존에는 제품 사양서가 존재하더라도 AI가 접근 불가능한 곳에 흩어져 있거나, 개발자의 경험과 암묵지에 의존하는 경우가 많았습니다. AI가 제품의 사양을 일관되게 이해하려면 이러한 정보가 모두 체계적으로 문서화되어야 합니다. 레인지 후드의 기능을 예로 들면, 풍량 사양을 Low-Mid-High로 할지 On-Off로 할지에 대한 결정 사항을 AI에게 제공하지 않으면 AI는 이를 임의로 판단하여 구현하게 됩니다. 문서화되지 않은 요구사항은 구현 기준도, 검증 기준도 될 수 없으니 프로젝트 관점에서는 ‘존재하지 않는 요구사항’과 똑같습니다.



이 프로젝트에서는 사양 재정비를 위해 docs/ 폴더 중심의 사양 체계를 갖췄습니다. 제품 동작은 Gherkin 형식(behavior/)으로 정의하고, 설계 근거는 design/에 기록하고, 하드웨어 구성과 초기화 정보는 hardware/에 담고, 통신 사양, 상태 머신, 통신 프로토콜도 각각의 폴더에 정리했습니다. 여기에 AI의 작업 규칙을 담은 AGENTS.md와 레이어 구조, 의존성 규칙을 정의한 ARCHITECTURE.md를 더하여 AI가 따라야 할 ‘하네스’의 기반을 완성했습니다.

세 가지 하네스: 사양, 구현, 검증

이 프로젝트는 세 가지 하네스를 가전제품 MCU 개발에 맞게 결합했습니다.

• 사양 하네스: docs/에 모든 제품 사양과 동작 시나리오를 정리하여, AI가 단일한 ‘진실의 원천(Source of Truth)’을 바라보도록 합니다.

• 구현 하네스: SDD·TDD·BDD 흐름으로 구현 절차를 고정하고, 계획→구현→검증을 순차적으로 진행하는 스크립트로 구성합니다.

• 검증 하네스: 빌드·테스트·린트는 물론, MCU 디버거 기반의 실제 세트 디버깅까지 하나로 연결합니다.

위 이미지는 AI의 구현 범위와 순서를 SDD, TDD, BDD 방법론으로 통제하는 구조를 설명합니다. AI가 자유롭게 코드를 생성하도록 두면 결과가 그럴듯해 보이더라도 의도한 결과와 어긋날 수 있습니다. 따라서 구현 전에 무엇을 만들고자 하는지, 어떤 테스트를 통과해야 하는지, 어떤 사용자 행동 시나리오를 충족해야 하는지를 명확히 정의해야 합니다.

여기서 다음 세 가지 개발 방법론으로 구현 범위를 명확하게 통제해야 합니다. SDD(Spec-Driven Development)는 ‘무엇을 만들고자 하는지’ 사양을 먼저 구조화해, AI와 사람이 같은 요구사항을 기준으로 일하게 합니다. TDD(Test-Driven Development)는 테스트를 먼저 정의하고 그 통과 여부로 구현의 정확성을 반복 검증합니다. BDD(Behavior-Driven Development)는 사용자 행동 시나리오를 ‘Given-When-Then’ 형태로 표현해 제품 동작을 검증합니다. 사양에서 출발해 Gherkin, 테스트, 구현으로 이어지는 이 흐름을 통해 품질이 코드 자체에 자연스럽게 ‘내재화’됩니다.

AI에게 ‘스킬’을 쥐여주다



위 이미지는 MCU 펌웨어를 안정적으로 구현하도록 AI에게 제공한 스킬(SKILL) 목록을 나타냅니다. 모델 성능이 아무리 향상되더라도 삼성전자에서 사용하는 MCU에 대한 정보나 디버깅 장비 사용 방법은 AI가 알 수 없는 영역입니다. 이러한 내용을 스킬 형태로 제공하면 AI가 정확한 정보를 바탕으로 MCU 펌웨어를 구현하거나 검증할 수 있어 할루시네이션이 줄어들고 결과물의 품질이 향상됩니다.

이번 프로젝트에서 AI에게 제공한 스킬은 크게 품질 검증용과 하드웨어 검증용으로 나뉩니다. 품질 검증 영역에서 validate-docs는 ‘AI가 문서만 보고 구현을 시작할 수 있는가’를 발견 가능성, 명확성, 충분성, 일관성, 유지보수성을 기준으로 점수화합니다. spec-conformance는 현재 구현된 소스 코드와 사양이 일치하는지 정량적으로 검증하고 누락, 불일치, 커버리지 부족 영역을 짚어냅니다.

하드웨어 검증 영역에서는 다음 세 가지 스킬을 더했습니다. 삼성전자 전용 MCU 사양서를 AI에게 주어 하드웨어 스펙, 레지스터, 외부 장치 지식 등을 제공합니다. T32 Debugger 스킬을 통해 브레이크포인트 설정, 메모리 덤프, 레지스터 읽기 방법과 같은 MCU 디버거 장비 사용법을 AI에게 알려줍니다. 그리고 USB Switch 스킬을 통해 220V 전원을 물리적으로 On/Off해 MCU를 강제로 초기화할 수 있게 합니다. 이렇게 하면 복구가 불가능한 상태에서도 AI가 스스로 세트를 껐다 켤 수 있습니다.

AUTOPILOT Loop: 계획-구현-검증을 자율 반복하는 워크플로우



위 이미지는 AUTOPILOT이 계획, 구현, 검증 단계를 순차적으로 수행하고, 각 단계 내부에서 반복 개선을 진행하는 구조를 설명합니다. 개발자는 AI가 어떤 과정으로 개발해야 하는지에 대한 계획·구현·검증 하네스만 정의하고 각 과정에는 개입하지 않습니다. AUTOPILOT 스크립트를 실행하면 기본 골격(Zero-Base) 소스 코드부터 시작해 계획·구현·검증 루프를 거치며 최종 산출물이 자율적으로 완성됩니다.

(1) 계획 루프: AI가 사양서를 분석하여 구현 계획을 수립합니다. 수립된 계획이 ‘개발 부적합’으로 판정되면 부적합 이유 피드백을 바탕으로 다시 계획을 수립하고, 충분한 것으로 판정되면 계획을 자체적으로 실행 가능한 세션 단위로 분할합니다. 이때 계획을 ‘수립하는 에이전트’와 ‘평가하는 에이전트’를 분리하여, 자기 결과물을 후하게 평가해 완성도가 낮은 계획을 통과시키는 상황을 원천 차단합니다.

(2) 검증 모델링: AI가 사양서를 검증 가능한 구조의 모델로 변환하고, 변환된 모델을 기준으로 검증 계획을 수립합니다. 이 검증을 진행하기 위해 제품의 제어 방법과 상태 확인 방식을 결정하는 연결 인터페이스를 설계하여 AI 검증에 활용할 수 있는 정보를 모델링합니다.

(3) 구현 루프: 계획 단계에서 분할된 세션별로 AI가 순차적으로 개발을 진행합니다. 각각의 세션에서는 AI가 개발을 진행하고 결과물을 검증하는 과정을 반복합니다. 검증에 실패하면 실패 이유 피드백을 바탕으로 동일한 세션을 다시 개발하고, 성공하면 다음 세션으로 넘어갑니다. 마찬가지로 ‘개발하는 에이전트’와 ‘검증하는 에이전트’는 서로 분리하여 운영합니다.

(4) 검증 루프: AI가 사양서와 구현 결과의 일치 여부를 최종 평가하고, 불일치 항목을 수정한 뒤 다시 반영합니다. 검증 조건을 충분히 만족하면 최종적으로 AUTOPILOT 스크립트는 종료됩니다.

위 이미지는 AI 구현 결과가 Build, Test, Lint로 구성된 품질 게이트를 통과해야 다음 단계로 진행되는 구조를 설명합니다. AI가 소스 코드를 수정하더라도 결과물이 곧바로 승인되지 않으며, 빌드 가능 여부, 테스트 통과 여부, 코드 스타일 및 정적 분석 결과를 순차적으로 확인합니다. 확인 결과가 ‘Fail’이면 AI가 실패 원인을 분석하고 코드를 수정한 뒤 동일한 품질 게이트를 다시 거치는 피드백 루프로 개발을 진행합니다. 사람이 코드를 일일이 검토하지 않아도 AI가 스스로 ‘그럴듯한 답’이 아닌 ‘정확한 답’에 수렴하도록 유도하는 구조입니다.

AI가 실제 제품 기반으로 직접 검증

하네스 설계에서 가장 어려운 부분은 AI가 결과물을 실제 MCU에서 확인하는 환경을 구축하는 것입니다.



위 이미지는 AI가 실제 세트 기반의 디버깅을 진행할 수 있도록 구성한 검증 환경입니다. 이번 프로젝트에서 하드웨어는 PC의 Codex AI, JTAG 기반 MCU 디버거, 전원 제어용 USB Switch로 구성됩니다. Codex AI가 MCU 디버거와 USB Switch를 제어하는 구조입니다. MCU 디버거는 레인지 후드 MCU의 상태를 직접 읽고 쓰며, USB Switch는 220V 전원을 켜고 꺼 MCU를 물리적으로 초기화합니다. AI에게는 제품 사양, 프로토콜·패킷 정보, MCU 데이터시트, 디버거 장비 사용 방법, 소스 코드와 변수 구조, 전원 On/Off 방법이 제공됩니다.

그러면 AI는 어떻게 검증을 수행할까요? 먼저 제품 사양서를 분석해 ‘자율 의지’로 테스트 시나리오를 도출합니다. 이어 테스트 시나리오를 순차적으로 실행합니다. 디버거를 통해 실제 세트에 키 입력을 주입하고, 현재 제품의 상태 값을 변수로 읽어 각 시나리오의 Pass/Fail 여부를 판단하는 방식입니다. 결국 제품 동작 시나리오, 메모리 Write(키 입력), 메모리 Read(상태 읽기)라는 세 가지 요소가 연동될 때 AI 기반의 자율형 자동 검증을 설계할 수 있습니다. AI가 시나리오를 실행해보고 검증에 실패할 경우 스스로 원인을 분석하고 문서로 기록합니다.

이처럼 AI에게 24시간 ‘자율 의지’ 검증을 맡기면 사람은 AI가 작성한 실패 원인 기록만 확인해 잘못된 코드를 수정할 수 있습니다. 더 나아가 AI가 실패 원인을 직접 분석해 스스로 코드를 수정하고 PR(Pull Request)까지 작성하면 사람은 PR만 리뷰하는 역할을 할 수 있습니다.

실행 결과: 약 95%의 완성도

AUTOPILOT을 통한 MCU 펌웨어 개발은 Codex GPT-5.5(Extra High)를 기반으로 진행했습니다. 아래 그림은 AI가 기본 골격(Zero-Base)에서 시작해 사람의 개입 없이 스스로 펌웨어를 완성한 다섯 개의 결과를 나타냅니다.



회차당 소요시간은 약 4.5~5.5시간이었고, 소스 코드와 테스트 코드가 매회 생성되었습니다. 삼성전자의 내부 소스 코드 품질 분석 툴을 이용해 분석한 결과, AI가 작성한 코드 품질(SAM Score)이 우수하고, 테스트 커버리지(TEM Score)도 높은 것으로 확인되었습니다.

하지만 기본 동작 완성도는 약 95% 수준으로 나타났습니다. 단위 테스트(Unit Test)가 충분히 정의된 상위 레이어인 Application Layer는 ‘사양→Gherkin→테스트→구현’ 흐름 덕분에 완성도가 높았습니다. 남은 약 5%의 문제는 주로 HAL(Hardware Abstraction Layer)에서 발생했습니다. UART, Timer, WatchDog, Clock과 같이 실제 MCU에서 HW 동작을 확인해야 하는 영역의 완성도가 약간 부족했습니다. 기본 골격(Zero-Base) 소스 코드부터 시작해 하위 레이어에서 상위 레이어로 순차적인 구현을 진행하다 보니 HAL에 대한 검증 과정이 다소 불안정했습니다. 다만, AI가 생성한 최종 결과물을 사람이 AI와 함께 1~4시간 디버깅하면 이 부분 역시 빠르게 보완할 수 있음을 확인했습니다. 앞으로 HAL 테스트 설계 부문에서 중점적으로 하네스를 고도화해야 합니다.

무엇이 달라지는가?

하네스 엔지니어링 방식이 자리 잡으면 개발의 무게중심이 완전히 옮겨집니다. 기능 추가 시 문서화된 사양을 추가하여 AI 에이전트에 요청하기만 하면 AI가 알아서 코드를 수정합니다. 사양 변경 시 변경된 사양을 수정해 반영을 요청하는 것만으로 소스 코드 수정부터 검증까지 자동으로 진행됩니다. 결과적으로 문서가 ‘단일 진실 공급원(Single Source of Truth)’ 역할을 하게 되며, AI는 동작 기준과 구현 기준을 하나의 사양서 안에서 일관되게 확인할 수 있습니다.

하네스 엔지니어링 방식을 적용하면 MCU 펌웨어 개발 기간을 평균 50%~70% 단축할 수 있습니다. 전체 개발 기간은 기존 6주에서 2주로 줄어들며, 기능 추가·변경은 3일에서 1일로, 결함 수정은 2일에서 6시간 수준으로 단축될 가능성이 확인되었습니다. 다만, 이 데이터는 프로세스상의 승인·리뷰·릴리스 절차를 제외한 ‘순수 개발 투입 시간’ 기준의 AI 추정치입니다. 향후 제품 복잡도나 사양 품질, 검증 환경 성숙도에 따라 실제 단축 폭은 달라질 수 있습니다.

앞으로의 과제, 그리고 가능성

결론은 긍정적이지만, 실제 확산을 위해서는 초기 투자와 명확한 검증 기준 정립이 필요합니다. 먼저 개발 방법론을 바꾸려면 초기에 상당한 시간을 투입해야 하고, 높은 수준의 AI 활용 경험과 도메인 지식이 요구됩니다. 또한 AI가 생성하는 코드의 결과물이 예측 가능하도록 하네스를 촘촘하게 설계해야 합니다. 특히 사람이 코드를 리뷰할 필요가 없도록 완벽한 검증 기준을 마련하는 것이 중요합니다. AI가 생성한 코드를 사람이 일일이 검토해야 한다면, 오히려 직접 구현하는 것보다 더 많은 시간이 소요될 수 있기 때문입니다.

향후 복잡도가 높은 제품군까지 하네스 엔지니어링 적용 범위를 확장할 예정입니다. 이번 프로젝트를 수행한 경험을 바탕으로 부족한 부분을 보완하여, 실제 제품 양산에 적용 가능한 수준으로 AI 에이전트의 활용도를 높이는 후속 프로젝트를 기획하고 있습니다.

결론적으로 이 여정의 방향은 분명합니다. ‘AI가 코드를 생성하는 길’만이 아니라, ‘AI가 그 결과를 실제 MCU 환경에서 검증하는 길’까지 함께 정의하는 것입니다. 사양, 구현, 검증이라는 세 가지 하네스를 꾸준히 튜닝해 나간다면, 가전제품 펌웨어 개발에서도 AI 에이전트가 계획, 구현, 검증을 스스로 반복하는 개발 방식이 현실적인 대안이 될 것입니다. 그 가능성을 실현하기 위해 한 걸음씩 나아가고 있습니다.