wendy-lite

wendy-lite 스킬 개요

wendy-lite는 무엇을 위한 스킬인가

wendy-lite는 ESP32-C6용 Wendy Lite 펌웨어에서 실행되는 WebAssembly 앱을 만드는 스킬입니다. 대략적인 임베디드 아이디어를 Wendy Lite의 host imports를 통해 하드웨어와 통신할 수 있는 동작하는 WASM 모듈로 옮기고 싶을 때 가장 유용합니다.

누가 사용해야 하는가

C, Rust, Swift, Zig, TypeScript, 또는 WAT으로 펌웨어 인접 앱을 개발하면서 장치 접근, 부팅 시 로딩, 콜백 기반 동작이 필요한 경우 wendy-lite 스킬을 사용하세요. 특히 “backend”가 MCU 쪽 로직, 런타임 통합, 또는 앱 오케스트레이션을 뜻하는 wendy-lite for Backend Development 맥락에서 관련성이 큽니다.

무엇이 다른가

일반적인 WASM 프롬프트와 달리 wendy-lite는 실제 런타임 모델을 기준으로 설계되어 있습니다. 즉, ESP32-C6의 WAMR, wendy 모듈 imports, 플래시에 저장되는 바이너리, 그리고 GPIO 인터럽트, 타이머, BLE 이벤트 같은 async callbacks를 전제로 합니다. 그래서 이 스킬은 “WASM을 어떻게 쓰지?”보다 “이 앱을 펌웨어 계약에 어떻게 맞추지?”가 막힐 때 훨씬 더 유용합니다.

wendy-lite 스킬 사용 방법

설치하고 관련 파일부터 확인하기

디렉터리에 대해 wendy-lite install 흐름을 실행한 뒤, 먼저 SKILL.md를 읽으세요. 저장소를 확장하는 상황이라면 frontmatter에 연결된 참조 파일도 함께 확인해야 하며, 특히 wasm-api.md, firmware-config.md, swift-sdk.md가 중요합니다. 실무적인 인터페이스 세부사항은 대개 이런 파일에 들어 있습니다.

장치 형태로 브리프를 주기

가장 좋은 입력은 “WASM 앱 만들어 줘”가 아니라, 제약이 분명한 장치 작업입니다. 예를 들면 대상 언어, 하드웨어 입력과 출력, 부팅 동작, 콜백 처리 필요 여부를 함께 적는 식입니다. 예를 들어: “ESP32-C6용 Rust WASM 모듈을 만들어서 GPIO 버튼을 읽고, NeoPixel을 토글하고, 재연결에도 버티게 해 줘.” 이런 식의 요청은 런타임 형태를 보여 주기 때문에, 막연한 wendy-lite usage 프롬프트보다 훨씬 좋습니다.

런타임 계약부터 시작하기

wendy-lite usage를 쓸 때는 다음 순서로 생각하세요. 모듈이 무엇을 export하는지, wendy에서 무엇을 import하는지, 콜백은 어떻게 처리하는지, 그리고 바이너리는 어떻게 플래시에 패키징되는지입니다. 확신이 없다면 먼저 최소 스켈레톤을 요청하고, 런타임 경로가 분명해진 뒤 하드웨어 접근과 오류 처리를 덧붙이세요.

재작업을 줄이는 실용적인 워크플로

1. 언어와 대상 보드를 먼저 적습니다.
2. 필요한 하드웨어 기능을 지정합니다: GPIO, I2C, SPI, UART, BLE, 네트워킹, LED 제어.
3. 최소 시작용, 전체 앱, 또는 기존 코드 포팅 중 어떤 결과를 원하는지 밝힙니다.
4. 필요한 빌드 노트를 요청합니다. 특히 Swift나 기본이 아닌 툴체인을 쓸 때는 더 중요합니다.
   이렇게 해야 일반적인 WASM 예제가 아니라 바로 쓸 수 있는 wendy-lite guide 결과를 가장 빨리 얻을 수 있습니다.

wendy-lite 스킬 FAQ

wendy-lite는 초보자에게 친화적인가?

네, 목적이 제한된 장치 앱이고 런타임 전용 워크플로를 따를 의향이 있다면 그렇습니다. 하지만 먼저 넓은 범위의 WASM 튜토리얼이 필요한 경우에는 초보자 친화적이지 않습니다. wendy-lite는 단순한 언어 문법보다 펌웨어 통합을 중요하게 보기 때문입니다.

wendy-lite가 적합하지 않은 경우는 언제인가?

ESP32-C6를 타깃으로 하지 않거나, 하드웨어 접근이 필요하지 않거나, 일반적인 웹 WASM 앱만 만들고 싶다면 wendy-lite skill은 건너뛰세요. 또한 프로젝트에서 WASM 바이너리를 플래시에 저장할 수 없거나 WAMR 기반 실행 모델을 사용할 수 없다면 적합성이 떨어집니다.

일반 프롬프트와 어떻게 다른가?

일반 프롬프트는 코드와 펌웨어 사이의 계약을 놓치기 쉽습니다. wendy-lite는 import/export 형태, 콜백 처리, 장치 수명 주기 가이던스가 필요할 때 더 좋습니다. 이런 부분은 일반적인 프롬프트가 대개 대충 넘어갑니다.

결과를 믿기 전에 무엇을 확인해야 하나?

제안된 코드가 저장소의 실제 host API, 콜백 진입점, 빌드 타깃과 맞는지 확인하세요. 답변에 이런 요소가 언급되지 않았다면, 기술적으로 그럴듯해 보여도 Wendy Lite 기준으로는 틀렸을 수 있습니다.

wendy-lite 스킬을 개선하는 방법

부족한 하드웨어 정보를 구체적으로 알려 주기

품질이 가장 크게 좋아지는 지점은 필요한 하드웨어 경로를 정확히 알려 주는 것입니다. 센서나 액추에이터, 알 수 있다면 핀 번호, 이벤트가 인터럽트 기반인지 여부, 재부팅 후 상태를 유지해야 하는지 등을 적어 주세요. 이렇게 해야 wendy-lite가 보드와 맞지 않는 넓은 데모를 내놓는 일을 줄일 수 있습니다.

원하는 출력 형태를 분명히 요청하기

더 빨리 배포하려면 출력 형태를 셋 중 하나로 지정하세요: 최소 동작 모듈, 주석이 포함된 빌드 가능한 예제, 또는 기존 C/Rust/Swift/Zig 프로젝트에서의 마이그레이션 계획. 특히 바로 테스트 가능한 wendy-lite install 결과가 필요할 때는 긴 프롬프트보다 출력 형태를 명확히 하는 편이 훨씬 중요합니다.

흔한 실패 모드를 점검하기

가장 흔한 실수는 표준 WASM 브라우저 API를 전제로 하거나, wendy host import 계층을 건너뛰거나, async 이벤트용 콜백 연결을 놓치는 것입니다. 첫 답변이 너무 추상적으로 느껴지면, 실제 펌웨어 라이프사이클 기준으로 다시 써 달라고 하고 지원되지 않는 가정이 무엇인지도 짚어 달라고 하세요.

컴파일 우선 피드백으로 반복 개선하기

첫 시도 뒤에는 실제 실패 지점을 그대로 피드백하세요. 예를 들면 누락된 import, 잘못된 target triple, 틀린 callback name, 빌드 단계 불일치 같은 항목입니다. 좋은 wendy-lite guide 반복 개선은 “더 자세히 써 줘”보다, 구체적인 오류 보고 1개와 더 좁혀진 목표 1개에서 나오는 경우가 많습니다.