won-solution.com

코딩은 AI에게 맡겼습니다 · 시즌 1 / 11 2026년 6월 22일에는 이미지 붙여넣기를 추가하고 내보내기 형식을 HTML로 바꿨습니다. 여섯 개 파일에서 160줄이 추가되고 14줄이 삭제됐습니다. 입력 기능 하나가 데이터 형식과 백업 방식까지 바꾼 사례입니다. 먼저 보는 핵심 이미지 붙여넣기를 구현할 때는 저장 용량과 내보낸 파일의 호환성도 함께 살펴야 합니다. 이미지의 출처와 저장 방식, 용량 제한을 정하고 삭제·백업·복원 뒤의 결과까지 확인해야 합니다. 이미지가 들어오면 저장 방식부터 달라진다 텍스트는 크기가 작고 검색과 내보내기가 쉽습니다. 메모에 이미지를 넣으려면 다음 항목을 결정해야 합니다. 이미지를 Base64 데이터로 본문에 포함할 것인가 별도 파일이나 서버에 올리고 URL만 저장할 것인가 클립보드 이미지와 웹페이지 이미지 URL을 다르게 처리할 것인가 큰 이미지를 압축하거나 거부할 것인가 백업 파일 하나에 이미지를 모두 포함할 것인가 서버 없는 확장 프로그램에서는 외부 업로드를 피하는 대신 브라우저 저장 용량이 부담됩니다. 외부로 보내는 데이터는 줄일 수 있지만, 메모와 이미지가 쌓일 때 저장 용량을 관리해야 합니다. 왜 HTML 내보내기로 바꿨나 일반 텍스트 파일은 이미지와 서식을 보존하지 못합니다. HTML은 리치 텍스트와 포함 이미지를 한 문서로 표현할 수 있어 당시 구조에 더 잘 맞았습니다. 하지만 HTML로 바꾸면 끝이 아닙니다. 확인할 것 이유 문자 인코딩 한국어와 특수문자 보존 문서 제목 다운로드 후 메모를 찾기 쉽게 함 위험한 태그·속성 붙여넣은 외부 HTML 정리 이미지 크기 파일과 저장소 용량 급증 방지 내보낸 파일의 표시 독립 파일로 열어도 스타일 유지 AI는 변환 코드를 빠르게 작성했습니다. 내보낸 파일을 확장 프로그램 없이 열어도 서식과 이미지가 유지되는지는 별도로 확인해야 했습니다. 기능 요청을 데이터 질문으로 바꾸기 ...

코딩은 AI에게 맡겼습니다 · 시즌 1 / 10 리치 텍스트 편집기 도입 일주일 뒤에는 글자 크기와 색상 조절 기능을 추가했습니다. 네 개 파일에서 254줄을 추가하고 67줄을 삭제했습니다. 버튼 두 개가 늘어난 것처럼 보이지만 편집 상태와 화면 상태를 함께 다뤄야 했습니다. 먼저 보는 핵심 편집 기능은 버튼을 화면에 놓는 것으로 끝나지 않습니다. 선택 영역과 현재 서식이 저장된 HTML에 반영되고, 테마를 바꾸거나 키보드로 조작해도 사용 흐름이 이어져야 합니다. UI를 만들기 전에 사용자 행동에 따라 편집기와 화면이 어떻게 바뀌는지 정리하는 것이 도움이 됩니다. 사용자가 보는 버튼과 내부 상태 사용자는 글자를 선택하고 크기나 색상을 누릅니다. 내부에서는 다음과 같은 경우를 구분해야 합니다. 선택 영역이 있는가, 커서만 있는가 선택한 여러 글자에 서로 다른 서식이 있는가 새로 입력할 글자에만 서식을 적용할 것인가 편집기를 다시 열었을 때 툴바가 현재 위치의 서식을 표시하는가 다크 테마에서 선택한 색상이 읽히는가 AI는 편집기 API를 호출하는 코드를 빠르게 만들었습니다. 선택한 글자의 서식을 툴바에 어떻게 표시하고, 새로 입력할 글자에는 어떤 서식을 적용할지는 따로 정해야 했습니다. 색상 선택이 만드는 접근성 문제 색상 팔레트를 많이 제공하면 자유도가 높아 보입니다. 그러나 밝은 배경과 어두운 배경에서 모두 읽히는 색은 제한적입니다. 사용자가 직접 지정한 색이 테마 전환 뒤 보이지 않을 수도 있습니다. 확인 항목은 다음과 같습니다. 항목 질문 대비 밝은·어두운 테마에서 읽을 수 있는가 표시 선택한 색상을 색상 이름이나 코드로도 확인할 수 있는가 키보드 마우스 없이 팔레트를 열고 선택할 수 있는가 초기화 기본 색상으로 쉽게 돌아갈 수 있는가 내보내기 지정 색상이 HTML 파일에 보존되는가 기능을 추가할 때마다 테스트 조합이 늘어납니다. 테마 3개와 글자색 8개만 있어도...

코딩은 AI에게 맡겼습니다 · 시즌 1 / 9 2026년 6월 6일에는 일반 텍스트 입력창을 Quill 리치 텍스트 편집기로 교체했습니다. 다섯 개 파일에서 1,166줄을 추가하고 68줄을 삭제했습니다. AI가 아니었다면 쉽게 미뤘을 만한 큰 기계적 변경이었습니다. 먼저 보는 핵심 AI는 큰 교체 작업을 빠르게 수행하지만 변경 줄 수가 많다는 사실 자체가 위험 신호입니다. 새 라이브러리의 크기, 저장 형식, 보안, 내보내기, 기존 데이터 호환성과 모바일 레이아웃을 기능 완료와 별도로 검토해야 합니다. 왜 일반 입력창을 버렸나 평범한 textarea 는 단순하고 안정적입니다. 하지만 사용자가 메모에서 제목, 굵은 글씨, 목록과 강조를 원하면 표현력이 부족합니다. 리치 텍스트 편집기는 이런 기능을 빠르게 제공합니다. AI에게 교체를 맡기면 툴바, 이벤트, 스타일, 저장 경로까지 한 번에 바꿀 수 있습니다. 문제는 “화면에 글씨가 굵게 보인다”가 전체 작업의 일부일 뿐이라는 점입니다. 교체 순간에 데이터의 의미가 바뀝니다. 이전 이후 단순 문자열 HTML 또는 편집기 전용 구조 줄바꿈 문자 문단·목록 태그 텍스트 내보내기 HTML 정리와 변환 필요 검색 대상이 곧 화면 문자열 태그를 제거한 텍스트가 필요 붙여넣기 결과가 단순함 외부 서식과 이미지 처리 필요 첫 결과에서 확인할 것 AI가 교체를 완료한 뒤 정상 입력만 시험하면 놓치는 문제가 많습니다. 이전 버전에서 저장한 일반 텍스트를 열 수 있는가 빈 편집기를 저장했을 때 의미 없는 HTML만 남지 않는가 웹페이지에서 붙여넣은 스타일이 화면을 깨뜨리지 않는가 링크나 HTML 입력이 위험한 요소를 포함할 수 있는가 다크 테마에서 툴바와 선택 영역이 보이는가 편집기 라이브러리를 확장 프로그램 정책에 맞게 제공하는가 특히 Chrome 확장 프로그램은 원격 코드를 실행하는 방식에 제한이 있으므로 라이브러리 배포 형태를 확인해야...

코딩은 AI에게 맡겼습니다 · 시즌 1 / 8 첫 정책 문서를 만든 날 다시 전면 수정했습니다. 기록에는 125줄 추가, 16줄 삭제로 남아 있습니다. 처음보다 길어진 이유는 법률 문구를 더 붙였기 때문이 아니라, 제품의 실제 데이터 흐름과 사용자 선택을 구체적으로 설명했기 때문입니다. 먼저 보는 핵심 정책의 품질은 줄 수가 아니라 사용자가 자신의 데이터에 대해 답을 얻을 수 있는지로 판단해야 합니다. 저장 위치, 외부 전송, 권한 목적, 보관 기간, 삭제·복구와 변경 공지를 제품 동작과 맞춰야 합니다. 첫 문서에서 빠졌던 것 짧은 첫 정책에는 “데이터를 판매하지 않는다” 같은 큰 원칙은 있었지만 다음과 같은 실제 질문에 충분히 답하지 못했습니다. 메모는 Chrome의 어떤 저장소에 남는가 브라우저 동기화 대상이 되는 설정이 있는가 선택한 웹 문구를 가져올 때 페이지 전체를 읽는가 백업 파일에는 어떤 내용이 들어가는가 휴지통의 메모는 언제 완전히 사라지는가 정책이 바뀌면 어디에 알리는가 사용자는 법률 문장보다 자신의 메모가 어디에 있고 누가 볼 수 있는지 알고 싶어 합니다. AI에게 섹션을 늘리기 전에 준 자료 긴 정책을 생성해 달라고만 하면 제품과 관계없는 쿠키, 광고, 결제 조항이 들어가기 쉽습니다. 먼저 다음 자료를 근거로 제공했습니다. 현재 Manifest 권한 목록 저장 키와 각 값의 목적 외부 네트워크 요청 목록 백업 파일의 구조 삭제와 복원 동작 연락 가능한 지원 채널 그다음 각 사실을 일반 사용자가 이해하는 섹션으로 바꾸게 했습니다. 존재하지 않는 데이터 처리를 상상하지 말고, 확인되지 않은 부분은 질문으로 남기도록 요청하는 방식이 유용했습니다. 정책과 제품을 함께 수정해야 하는 순간 정책을 쓰다가 설명하기 어려운 동작을 발견하면 문장을 고치는 것보다 제품을 고치는 편이 낫습니다. 예를 들어 불필요하게 넓은 권한은 “좋은 목적으로만 사용한다”고 길게 설명하기보다 제거하는 것이 명확합니다...

코딩은 AI에게 맡겼습니다 · 시즌 1 / 7 첫 개인정보처리방침을 만든 직후 문의 주소를 저장소의 이슈 페이지로 바꿨습니다. 코드 변화는 한 줄뿐이었습니다. 그러나 1인 개발 제품에서 사용자의 질문을 어디로 받을지는 기능만큼 오래 영향을 주는 결정입니다. 먼저 보는 핵심 지원 채널은 많이 만드는 것보다 실제로 확인하고 답할 수 있는 곳 하나를 정하는 것이 중요합니다. 공개 이슈는 같은 문제의 중복 문의를 줄이지만, 개인정보가 포함될 수 있는 질문을 위한 별도 경로도 필요합니다. 왜 이메일을 바로 공개하지 않았나 개인 이메일은 시작하기 쉽지만 제품 문의와 개인 메일이 섞입니다. 해결 과정이 다른 사용자에게 보이지 않아 같은 질문에 반복해서 답하게 됩니다. 스팸과 민감한 첨부 파일을 처리하는 문제도 생깁니다. 공개 저장소의 이슈 페이지는 다음 장점이 있었습니다. 버그와 기능 요청을 제목별로 관리할 수 있다. 이미 보고된 문제를 사용자가 검색할 수 있다. 수정 커밋과 문의를 연결할 수 있다. 해결 상태와 우회 방법을 공개할 수 있다. 별도의 고객지원 시스템을 운영하지 않아도 된다. 반면 모든 질문을 공개 이슈로 받으면 안 됩니다. 메모 내용, 계정 정보, 결제 정보처럼 민감한 자료가 포함되는 제품이라면 비공개 연락 경로가 필요합니다. AI가 정해 주지 못한 운영 문제 AI는 문의 문구와 이슈 양식을 만들 수 있습니다. 하지만 실제로 얼마나 자주 확인할지, 어떤 언어로 답할지, 답변 시간을 약속할 수 있는지는 운영자가 정해야 합니다. 지원 채널을 선택할 때 다음 질문을 사용했습니다. 질문 결정 기준 사용자가 계정 없이 접근할 수 있는가 대상 사용자의 GitHub 사용 여부 확인 공개해도 안전한 문의인가 개인정보 포함 가능성 구분 내가 꾸준히 확인하는 곳인가 새 알림 시스템을 늘리지 않기 해결 기록이 다른 사람에게 도움이 되는가 공개 검색 가치 확인 서비스가 커져도 옮길 수 있는가...

코딩은 AI에게 맡겼습니다 · 시즌 1 / 6 README를 만든 날, Chrome Web Store를 위한 첫 개인정보처리방침도 추가했습니다. 첫 문서는 26줄이었습니다. 서버가 없고 메모가 브라우저 안에만 남으니 설명할 내용도 적어 보였습니다. 먼저 보는 핵심 정책 문서는 그럴듯한 법률 문장을 만드는 일이 아니라 제품의 데이터 흐름을 사실대로 설명하는 일입니다. AI에게 초안을 맡길 수는 있지만, Manifest와 저장 코드, 외부 라이브러리, 삭제 방식을 직접 대조해야 합니다. “수집하지 않습니다”만으로 충분하지 않았다 Simple Side Note는 계정을 만들지 않고 별도 서버도 사용하지 않습니다. 하지만 데이터가 전혀 존재하지 않는 것은 아닙니다. 사용자가 작성한 메모와 설정은 브라우저 저장소에 기록됩니다. 정책에는 최소한 다음 질문의 답이 있어야 했습니다. 어떤 데이터를 저장하는가 데이터는 어느 장치와 저장 영역에 남는가 외부 서버로 전송하는가 제3자와 공유하거나 판매하는가 사용자가 데이터를 내보내거나 삭제할 수 있는가 확장 프로그램을 제거하면 무엇이 일어나는가 문의는 어디로 해야 하는가 “개인정보를 수집하지 않는다”는 문장만 쓰면 로컬 메모와 설정이 어디에 저장되는지 설명하지 못합니다. 사용자에게 중요한 것은 법률 용어보다 자신의 데이터가 어디로 가는지입니다. AI에게 문장을 쓰기 전에 흐름을 찾게 했다 정책 초안을 바로 요청하는 대신 코드에서 데이터 흐름을 먼저 정리하는 편이 안전합니다. 데이터 발생 위치 저장 위치 외부 전송 메모 본문 Side Panel 편집기 Chrome 로컬 저장소 없음 테마·설정 설정 화면 Chrome 저장소 구현 방식에 따라 확인 웹페이지에서 가져온 문구 사용자의 명시적 동작 현재 메모 없음 오류 정보 브라우저 개발자 도구 별도 수집 없음 없음 이 표를 만든 다음 AI에게 사용자에게 이해되는 문장으로 바꾸게 하...

코딩은 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에게 맡겼습니다 · 시즌 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에게 맡겼습니다 · 시즌 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은 웹페이지 옆에 계속 열어 둘 수 있고 탭을 이동해도 유지할 수 있어 메모장, 타이머, 계산기처럼 작업을 이어가는 도구에 더 잘 맞습니다. 하지만 “오래 보이는 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 같은 전역 변수만 저장소처럼 사용하면 안 됩니다. 패널 문서가 사...

키보드와 마우스만 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이 장치 선택 창을 ...