912바이트 편집기가 알려준 바이브코딩의 시작: 기능보다 합격 기준부터

핵심 요약 (TL;DR)

첫 앱을 만들 때는 기능 목록보다 ‘무엇을 하면 성공인가’를 먼저 정해 보세요. smallest-editor--so-far는 제작자가 Claude가 작성한 어셈블리를 사용했다고 밝힌 작은 Windows 편집기입니다. 크기 경쟁 자체보다, 열기·수정·저장이라는 좁은 목표와 실패 상황까지 확인하는 테스트가 눈에 들어옵니다.

얼마나 최근에 소개된 사례인가요?

이 프로젝트의 Show HN 게시 시각은 2026년 10월 31일 13시 29분 53초(KST)입니다. 조사 기준인 11월 1일 오전 7시 이전 48시간에 들어갑니다. 다만 이는 커뮤니티 소개 시각이며 최초 출시일을 확정하는 자료는 아닙니다. 제작자는 본문에서 Claude가 쓴 어셈블리라고 명시했습니다. AI 사용은 제작자의 자기보고로 확인했으며, 생성 대화 전체나 작업 시간은 공개 근거로 확인하지 못했습니다.[1]

작은 앱은 무엇을 포기했을까요?

공개 README에 따르면 실행 파일 크기는 912바이트이며, Windows 기본 EDIT 컨트롤이 실제 편집 기능을 맡습니다. 프로그램은 파일 선택과 읽기·저장, 메시지 처리를 덧붙입니다. 처음부터 편집 기능 전체를 새로 만들지 않고 이미 있는 기능을 활용한 셈입니다.[2]

대신 경계가 분명합니다. Ctrl+S로 저장해야 하고, 창을 닫으면 저장 여부를 묻지 않습니다. 일정 크기를 넘는 파일은 거부합니다. 그러니 이를 업무용 편집기의 완성이나 모든 환경에서의 안정성으로 읽으면 곤란합니다. 작은 실험이 무엇을 할 수 있고 무엇을 하지 않는지 밝힌 사례로 보는 편이 정확합니다.[2]

테스트는 MVP에 어떤 도움을 주나요?

저장소에는 파일 선택, 편집, 저장 실패 후 복구, 큰 파일 처리 등을 확인하는 테스트 스크립트가 있습니다. README는 23개 검사를 설명하며 실제 스크립트에도 해당 동작을 확인하는 코드가 들어 있습니다. 이번 조사에서는 문서와 코드를 읽었을 뿐 Windows에서 실행해 통과를 재현하지는 않았습니다.[2][3]

첫 앱에도 이 접근을 옮길 수 있습니다. 메모 앱이라면 ‘쓴 문장이 다시 열어도 남는다’, ‘저장할 수 없으면 사용자에게 알려준다’, ‘취소하면 원본을 바꾸지 않는다’를 먼저 적어 보세요. AI에 구현만 요청하는 대신 각 조건을 확인할 테스트도 함께 요청하는 것입니다. 이는 사례에서 얻은 실천 제안이지, 제작자가 공개한 실제 프롬프트는 아닙니다.

기능을 줄이면 시연은 쉬워지지만 누락된 동작도 생깁니다. 테스트는 그 빈틈을 없앴다고 선언하는 도장이 아니라, 어디까지 믿어도 되는지 표시하는 선에 가깝습니다. 다음 기능을 추가하기 전에 그 선이 유지되는지 확인하면 수정 결과를 판단하기도 수월해집니다.

자주 묻는 질문은 무엇인가요?

초보자도 어셈블리로 시작해야 하나요?

그럴 필요는 없습니다. 배울 점은 언어가 아니라 목표를 좁히는 방식입니다. 익숙한 웹 화면에서 입력 하나, 저장 하나부터 구현해도 같은 원칙을 적용할 수 있습니다.

작게 만들면 테스트는 생략해도 되나요?

오히려 작을 때 성공과 실패 조건을 정리하기 좋습니다. 정상 저장만 보지 말고 취소, 빈 입력, 저장 실패처럼 첫 사용자도 만날 상황을 하나씩 확인해 보세요.

출처는 어디에서 확인하나요?

[1] 제작자 소개: https://news.ycombinator.com/item?id=50313220
[2] 프로젝트 문서: https://github.com/andyrosa/smallest-editor--so-far
[3] 테스트 코드: https://github.com/andyrosa/smallest-editor--so-far/blob/main/Test-Editor.ps1