코드보다 README를 먼저 읽는 사용자를 뒤늦게 생각했다

코딩은 AI에게 맡겼습니다 · 시즌 1 / 5 첫 README는 2026년 6월 3일에 추가됐습니다. 한 파일에 104줄이 들어갔습니다. 기능을 만드는 동안에는 코드가 제품의 중심처럼 보이지만, 처음 방문한 사람은 코드를 실행하기 전에 설명을 봅니다. 먼저 보는 핵심 좋은 README는 파일 목록이 아니라 사용자가 설치 여부를 결정하는 화면입니다. 무엇을 해결하는지, 어떻게 설치하는지, 어떤 데이터를 다루는지, 현재 한계가 무엇인지가 첫 화면에서 보여야 합니다. AI가 만든 문서는 왜 길어지기 쉬운가 AI에게 “README를 작성해줘”라고 요청하면 기능, 설치법, 폴더 구조, 기술 스택, 기여 방법까지 빠르게 만듭니다. 형식은 그럴듯하지만 제품마다 중요한 순서가 다릅니다. Simple Side Note에서 방문자가 가장 먼저 궁금한 것은 다음 네 가지였습니다. 이 확장 프로그램이 무엇을 줄여 주는가 Chrome 어디에서 열리는가 메모가 외부 서버로 전송되는가 지금 바로 설치해 시험할 수 있는가 폴더 구조나 사용한 JavaScript 기술은 그다음입니다. README의 첫 화면을 개발자 보고서처럼 만들면 정작 사용 이유가 아래로 밀립니다. README를 사용자 흐름으로 다시 배열하기 문서의 순서는 다음처럼 잡았습니다. 순서 답해야 할 질문 1 이 도구는 누구의 어떤 불편을 해결하는가 2 핵심 기능을 한눈에 볼 수 있는가 3 설치 후 첫 사용까지 따라 할 수 있는가 4 데이터와 권한을 믿을 수 있는가 5 제한 사항과 앞으로의 계획은 무엇인가 6 개발자가 구조를 이해할 자료가 있는가 AI에게는 “기능 목록을 작성해줘” 대신 “처음 방문한 사용자가 설치를 결정하는 순서로 다시 배열해줘”라고 요청하는 것이 더 나았습니다. 코드에서 사실을 가져오게 했다 문서 초안을 만들 때 가장 위험한 것은 존재하지 않는 기능을 자연스럽게 설명하는 것입니다. AI는 계획 문서와 실제...

AI는 잘 만든 기능도 필요 없으면 지우라고 말하지 않았다

코딩은 AI에게 맡겼습니다 · 시즌 1 / 4 2026년 6월 3일 커밋에서는 테마 기능을 추가하는 동시에 드래그앤드롭을 삭제했습니다. 열 개 파일에서 483줄을 추가하고 88줄을 지운 큰 변경이었습니다. 흥미로운 부분은 추가한 기능보다 지운 기능입니다. 먼저 보는 핵심 AI는 요청한 기능을 빠르게 구현하지만, 그 기능이 제품에 필요한지는 거의 항상 요청한 사람이 판단해야 합니다. 구현 비용이 낮아진 시대에는 “만들 수 있는가”보다 “계속 유지할 가치가 있는가”가 더 중요한 질문이 됩니다. 드래그앤드롭은 정상적으로 작동했다 메모 목록을 마우스로 끌어 순서를 바꾸는 기능은 눈에 잘 띄고 데모하기도 좋습니다. AI에게 요청하기에도 명확합니다. 항목을 드래그할 수 있게 하고, 놓은 순서를 저장하면 됩니다. 문제는 실제 사용에서 자주 필요하지 않았다는 점입니다. 짧은 메모 몇 개를 저장하는 도구에서 사용자가 매번 순서를 정리할 가능성은 낮았습니다. 정렬 기능은 다음과 같은 유지 비용도 만들었습니다. 마우스와 터치 입력을 각각 확인해야 한다. 검색된 목록과 전체 목록의 순서 관계를 정해야 한다. 고정 메모가 생기면 수동 순서와 우선순위가 충돌한다. 키보드 사용자를 위한 별도 이동 방법이 필요하다. 저장 데이터에 순서 정보와 예외 처리가 추가된다. 작동 여부만 보면 성공한 기능이지만, 제품 전체로 보면 질문이 늘어나는 기능이었습니다. AI에게 “만들어줘”라고만 하면 생기는 일 AI는 대개 요청을 완수하는 방향으로 움직입니다. “메모를 드래그해서 정렬하게 해줘”라고 하면 구현 방법을 찾습니다. “이 메모장에 드래그 정렬이 필요한가?”라고 물으면 장단점을 설명할 수 있지만, 최종 판단에 필요한 실제 사용자 행동은 알지 못합니다. 그래서 기능을 요청하기 전에 다음 질문을 먼저 던지는 방식으로 바꿨습니다. text 이 기능이 해결하는 사용자의 반복 문제는 무엇인가? 기존 기능으로 해결할 수 없는가? 추가되는 상태와 예외는 무엇인가? 사...

한국어로 만든 앱을 이틀 만에 영어 제품으로 바꾼 방법

코딩은 AI에게 맡겼습니다 · 시즌 1 / 3 첫 커밋 이틀 뒤에는 화면과 확장 프로그램 설명을 한국어에서 영어로 바꿨습니다. 기록상 네 개 파일에서 27줄을 추가하고 30줄을 삭제했습니다. AI가 가장 빠르게 처리하는 작업 중 하나가 이런 반복적인 문구 변경입니다. 먼저 보는 핵심 영어 문구로 바꾸는 것은 번역이고, 언어를 나중에도 추가할 수 있게 만드는 것은 국제화입니다. 첫 버전에서는 빠른 시장 확인을 위해 영어로 전환했지만, 화면 문구를 코드에서 분리하지 않으면 다음 언어에서 같은 비용을 다시 냅니다. 왜 영어부터 선택했나 Chrome Web Store는 한국 밖의 사용자도 접근합니다. 기능이 단순한 메모장이라면 사용법을 길게 설명하지 않아도 되므로, 초기부터 영어 화면으로 두는 것이 사용자 범위를 넓히는 가장 작은 변화였습니다. 이 단계에서 AI에게 맡기기 좋은 일은 다음과 같습니다. 버튼과 안내 문구 후보 만들기 같은 동작에 다른 용어가 섞였는지 찾기 Manifest의 이름과 설명을 화면 문구와 맞추기 지나치게 긴 문구를 좁은 Side Panel에 맞게 줄이기 하지만 자연스러운 번역과 제품에서 일관된 용어는 다릅니다. Save , Saved , Keep , Pin 은 모두 익숙한 단어지만 제품 안에서 서로 다른 행동을 뜻할 수 있습니다. AI가 제안한 문구도 실제 버튼이 하는 일과 대조해야 합니다. 문자열을 바꾸는 것보다 먼저 할 일 언어를 바꾸기 전에 화면에 노출되는 문구를 목록으로 만들면 누락을 줄일 수 있습니다. 위치 확인할 문구 Manifest 앱 이름, 짧은 설명, 툴바 제목 Side Panel 탭, 버튼, 빈 화면 안내 오류 저장 실패, 잘못된 파일, 용량 초과 데이터 기본 메모 제목, 내보내기 파일 이름 스토어 상세 설명, 개인정보처리방침, 업데이트 내역 화면에서 보이는 버튼만 번역하면 오류 메시지나 다운로드 파일 이름에 이전 언어가 남기 쉽습니...

첫 프롬프트로 크롬 확장 프로그램이 만들어졌다: 하지만 제품은 아니었다

코딩은 AI에게 맡겼습니다 · 시즌 1 / 2 Simple Side Note의 첫 커밋은 2026년 5월 29일에 만들어졌습니다. 파일은 여섯 개였고 추가된 코드는 218줄이었습니다. Chrome Side Panel에서 메모를 입력하고 저장하는 기본 동작을 확인하기에는 충분했습니다. 먼저 보는 핵심 첫 프롬프트의 목표는 완제품 제작이 아니라 가장 위험한 가정을 빠르게 확인하는 것입니다. 무엇을 만들지, 어디에서 동작할지, 데이터는 어디에 둘지, 이번 단계에서 하지 않을 일을 함께 적으면 AI가 만든 결과를 판단하기 쉬워집니다. 코드 대신 제품의 동작을 설명했다 첫 요청은 특정 함수나 파일 이름보다 사용 장면을 중심으로 구성했습니다. Chrome의 Side Panel에서 열리는 메모장을 만든다. 사용자가 입력한 내용은 브라우저에 저장한다. 탭을 이동해도 메모를 이어서 볼 수 있어야 한다. 별도 서버와 로그인은 사용하지 않는다. 이 요청에는 네 가지 결정이 들어 있습니다. 질문 첫 결정 어디에서 쓰나 Chrome Side Panel 핵심 행동은 무엇인가 메모 작성과 다시 열기 데이터는 어디에 두나 브라우저 로컬 저장소 무엇을 하지 않나 서버, 계정, 동기화 제외 AI는 이 정도의 요구를 Manifest V3 구조와 화면 파일, 저장 코드로 바꿨습니다. 여기서 가장 큰 이득은 코드를 218줄 대신 작성한 것이 아니라, 아이디어가 브라우저 안에서 실제로 가능한지 바로 확인한 것입니다. 작동한다는 말의 범위 첫 버전에서 확인한 것은 세 가지뿐이었습니다. 확장 프로그램을 Chrome에 불러올 수 있다. Side Panel 화면이 열린다. 입력한 메모를 다시 불러올 수 있다. 반대로 아직 확인하지 않은 것도 많았습니다. 저장 용량을 넘으면 어떻게 되는지, 확장을 삭제하면 데이터가 어떻게 되는지, 키보드만으로 쓸 수 있는지, 다른 언어의 사용자가 이해할 수 있는지, 스토어 심사에 필요한...

코딩은 AI에게 맡겼습니다: 실제 제품 하나를 출시하기까지

코딩은 AI에게 맡겼습니다 · 시즌 1 / 1 요즘 제 개발은 거의 모두 AI와 함께 진행합니다. 제가 기능을 설명하면 AI가 파일을 만들고 코드를 수정하며 오류도 찾아냅니다. 그래서 이 블로그도 이제 코드 문법을 길게 설명하기보다, AI로 실제 제품을 만드는 과정 을 기록하려고 합니다. 첫 번째 대상은 Chrome 브라우저 옆에 열어 두고 사용하는 메모장 Simple Side Note 입니다. 첫 작동 버전은 빠르게 나왔지만, 실제 출시 가능한 제품이 되기까지는 7주와 18개의 커밋이 필요했습니다. 먼저 보는 핵심 AI는 작동하는 첫 버전을 만드는 시간을 크게 줄였습니다. 하지만 어떤 기능을 버릴지, 어떤 권한이 과한지, 사용자의 메모를 어떻게 지킬지는 대신 결정하지 않았습니다. 이 연재에서는 코드보다 그 판단과 시행착오를 공개합니다. 무엇을 만들었나 Simple Side Note는 웹페이지를 보면서 Chrome Side Panel에 메모를 남기는 확장 프로그램입니다. 브라우저 탭을 벗어나 별도의 메모 앱을 열지 않아도 됩니다. 현재 제품에는 다음과 같은 기능이 들어 있습니다. 메모 자동 저장과 명시적 저장 저장한 메모 검색과 고정 밝은 테마, 어두운 테마, 따뜻한 테마 HTML·Markdown 내보내기 백업과 복원 오래된 메모 자동 정리와 휴지통 여러 언어로 표시되는 화면 기능 목록만 보면 처음부터 계획대로 만들어진 것처럼 보입니다. 실제 과정은 달랐습니다. 필요하다고 생각해 넣었다가 삭제한 기능이 있었고, 작동은 하지만 그대로 출시하면 안 되는 부분도 있었습니다. 첫 버전은 정말 빨리 나왔다 2026년 5월 29일 첫 커밋에서 작동하는 확장 프로그램이 만들어졌습니다. 여섯 개 파일, 약 218줄 규모였습니다. AI에게 필요했던 설명은 복잡한 코드 명세가 아니었습니다. 대략 다음과 같은 제품 요구에 가까웠습니다. Chrome 브라우저의 Side Panel에서 사용하는 간단한 메모장을 만든다. 입력한 내용은 ...

Chrome Side Panel 상태 관리: 닫았다 열어도 작업을 이어가는 설계

Chrome 확장 프로그램의 팝업은 툴바 아이콘을 눌렀을 때 잠깐 열렸다가 포커스를 잃으면 닫힙니다. Side Panel은 웹페이지 옆에 계속 열어 둘 수 있고 탭을 이동해도 유지할 수 있어 메모장, 타이머, 계산기처럼 작업을 이어가는 도구에 더 잘 맞습니다. 하지만 “오래 보이는 UI”와 “메모리에 계속 살아 있는 UI”는 같은 뜻이 아닙니다. 사용자가 패널을 닫거나 확장 프로그램이 업데이트되면 문서와 JavaScript 상태는 다시 만들어질 수 있습니다. Manifest V3 서비스 워커도 유휴 상태에서 종료되므로 전역 변수만 믿을 수 없습니다. 먼저 보는 핵심 DOM은 화면 표현, JavaScript 객체는 현재 편집 상태, chrome.storage 는 복구 가능한 원본으로 역할을 나누세요. 패널이 열릴 때 저장값을 한 번 복원하고, 변경은 모아서 저장하며, 이벤트 리스너는 한 번만 연결하는 구조가 기본입니다. 팝업과 Side Panel의 수명 주기는 무엇이 다른가 Chrome의 Side Panel API 공식 문서 는 Side Panel을 웹페이지 옆에서 지속적인 경험을 제공하는 확장 페이지로 설명합니다. 설정에 따라 탭을 이동해도 열린 상태를 유지할 수 있고, 확장 페이지이므로 Chrome API에도 접근할 수 있습니다. 항목 팝업 Side Panel 일반적인 종료 시점 포커스를 잃으면 닫힘 사용자가 닫거나 다른 패널로 전환할 때까지 표시 가능 적합한 작업 빠른 명령, 짧은 조회 메모, 계산, 타이머처럼 이어지는 작업 UI 상태 전략 열 때마다 복원하는 전제가 강함 살아 있는 동안 유지하되 재생성도 견뎌야 함 탭 이동 팝업은 이미 닫힘 설정에 따라 열린 상태 유지 가능 Side Panel이 열려 있는 동안에는 해당 확장 페이지의 DOM과 메모리 상태를 사용할 수 있습니다. 그렇다고 let currentNote 같은 전역 변수만 저장소처럼 사용하면 안 됩니다. 패널 문서가 사...

Chrome 확장 프로그램에서 WebHID 사용하기: Input·Output·Feature Report

키보드와 마우스만 HID(Human Interface Device)인 것은 아닙니다. 바코드 스캐너, 커스텀 버튼 패드, 계측 장치처럼 운영체제의 범용 드라이버를 사용하면서도 제조사 고유 데이터를 주고받는 장치도 HID 프로토콜을 사용합니다. Chrome의 WebHID API를 이용하면 네이티브 드라이버용 프로그램을 별도로 만들지 않고 JavaScript에서 이런 장치를 선택하고, 리포트 구조를 확인하고, 바이트 데이터를 읽고 쓸 수 있습니다. 이 글에서는 Manifest V3 확장 프로그램의 사이드 패널에서 장치를 연결하는 흐름을 중심으로 정리합니다. 먼저 보는 핵심 장치 선택은 사용자의 클릭으로 시작하고, 연결 후에는 device.collections 에서 지원 리포트를 먼저 확인합니다. Input은 이벤트로 받고, Output과 Feature 쓰기는 장치 문서에 정의된 ID와 길이를 지켜야 합니다. WebHID가 다루는 세 가지 리포트 HID 통신을 시작하기 전에 리포트의 방향부터 구분해야 합니다. 종류 방향 일반적인 용도 Input Report 장치 → 브라우저 버튼 상태, 센서 값, 스캔 결과 수신 Output Report 브라우저 → 장치 LED, 진동, 동작 명령 전송 Feature Report 양방향 설정 교환 동작 모드, 보정값, 펌웨어 설정 읽기·쓰기 각 장치가 어떤 리포트 ID와 바이트 길이를 지원하는지는 HID 리포트 디스크립터에 의해 결정됩니다. WebHID에서는 device.collections 를 통해 컬렉션과 리포트 정의를 살펴볼 수 있습니다. 임의의 ID와 데이터를 보내기 전에 장치 제조사의 프로토콜 문서와 이 정보를 먼저 확인해야 합니다. Manifest 권한과 실행 위치 Chrome 확장 프로그램에서 WebHID 자체를 쓰기 위한 별도의 manifest 권한은 필요하지 않습니다. 대신 requestDevice() 를 호출하면 Chrome이 장치 선택 창을 ...