won-solution.com

코딩은 AI에게 맡겼습니다 · 시즌 1 / 18 마지막 기록은 스토어 설명의 일곱 줄을 수정한 커밋입니다. 기능을 만드는 큰 커밋보다 작지만, 사용자가 실제로 보게 될 제품 설명을 현재 버전과 맞춘 작업이었습니다. 2026년 5월 29일부터 7월 17일까지 18개 커밋으로 첫 시즌이 끝났습니다. 먼저 보는 핵심 AI는 빈 폴더에서 작동 화면까지 가는 시간을 크게 줄였고 반복 수정과 문서 초안도 빨랐습니다. 그러나 기능 우선순위, 데이터 안전, 권한, 기본값, 출시 사실의 최종 책임은 자동화되지 않았습니다. 18개 커밋을 세 종류로 나눠 보니 종류 대표 작업 AI가 줄여 준 것 생성 첫 버전, 편집기, 검색, 백업 파일 작성과 API 연결 시간 판단 기능 삭제, 저장 방식, 휴지통 대안을 빠르게 비교할 자료 출시 README, 정책, 이미지, 스토어 설명 반복 문서와 형식 작업 AI가 가장 강했던 부분은 정답의 모양이 비교적 분명한 작업이었습니다. Manifest 구조, 편집기 API 연결, 문자열 변경과 문서 형식은 빠르게 처리했습니다. 반면 사용자가 무엇을 용서하지 않을지 결정하는 일은 남았습니다. 메모를 자동으로 지워도 되는지, 고정 메모를 어떻게 해석할지, 불필요한 권한을 제거할지, 저장 실패를 얼마나 크게 알려야 하는지는 제품 판단이었습니다. 가장 크게 바뀐 개발 순서 예전에는 문서를 읽고 구조를 설계한 뒤 코드를 작성하고 화면을 확인했습니다. AI와 작업하면서 순서가 다음처럼 바뀌었습니다. text 사용 장면 설명 → AI가 첫 결과 생성 → 실제 화면에서 가정 확인 → 실패·권한·데이터 질문 → 수정과 검증 → 출시 문서와 운영 기록 첫 화면이 빨리 나오면서 판단 시점도 빨라졌습니다. 이것이 가장 큰 변화였습니다. 코드를 모르는 상태에서도 결과를 보고 질문할 수 있지만, 결과를 검증하지 않아도 된다는 뜻은 아닙니다. 다음 제품에서 지킬 여덟 가지 첫 프롬프트에는 하지...

코딩은 AI에게 맡겼습니다 · 시즌 1 / 17 v1.3.0 기능을 만든 뒤 같은 날 한국어·영어 업데이트 글과 기능 스크린샷을 추가했습니다. 네 개 파일에서 223줄이 늘었습니다. 코드 커밋이 제품을 바꿨다면 콘텐츠 커밋은 사용자가 그 변화를 발견하게 했습니다. 먼저 보는 핵심 하나의 개발 기록은 릴리스 노트, 사용법, 개발 회고와 짧은 홍보 문구로 나눌 수 있습니다. 같은 내용을 복사하지 말고 독자마다 궁금한 질문을 바꾸는 것이 AI 콘텐츠 재가공의 핵심입니다. 같은 기능을 네 방식으로 설명하기 자동 정리와 휴지통이라는 한 가지 변경도 대상에 따라 강조점이 달라집니다. 콘텐츠 독자의 질문 중심 내용 릴리스 노트 무엇이 바뀌었나 새 기능과 호환성 사용자 가이드 어떻게 쓰나 설정, 복원, 주의점 개발 블로그 왜 이렇게 만들었나 판단과 실패 사례 스토어 설명 왜 설치해야 하나 결과와 신뢰 AI에게 “이 글을 네 번 바꿔 써줘”라고 하면 표현만 달라진 중복 글이 나오기 쉽습니다. 각 결과물의 독자 질문과 행동을 먼저 지정해야 합니다. 코드에서 콘텐츠 근거 뽑기 재가공할 자료는 기억보다 변경 기록에서 가져오는 편이 정확합니다. 커밋 메시지와 변경 파일 설정 화면의 실제 옵션 기본값과 보관 기간 상수 실패 처리와 제외 조건 전후 스크린샷 출시 후 발견한 수정 사항 AI에게 이 근거만 사용하고 확인되지 않은 성과 수치는 만들지 말라고 명시했습니다. “생산성이 몇 배 증가했다” 같은 문장은 실제 측정값이 없으면 쓰지 않는 편이 낫습니다. 한국어와 영어는 번역만 하지 않았다 언어가 달라지면 익숙한 용어와 설명의 길이도 달라집니다. 한국어 글은 개발 판단을 조금 더 풀어 쓰고, 영어 업데이트 글은 제품 사용 장면과 핵심 변경을 빠르게 보여주는 식으로 목적을 나눌 수 있습니다. 언어별 글을 만들 때도 다음 사실은 동일해야 합니다. 버전 번호 실제 제공 기능 기본 설정...

코딩은 AI에게 맡겼습니다 · 시즌 1 / 16 2026년 7월 17일 v1.3.0에서는 오래된 메모 자동 정리와 휴지통을 추가했습니다. 다섯 개 파일에서 411줄을 추가하고 10줄을 삭제했습니다. 구현보다 더 오래 고민한 부분은 무엇을 지우지 않을 것인가였습니다. 먼저 보는 핵심 자동화가 사용자 데이터를 다룬다면 되돌릴 수 있어야 합니다. 현재 편집 중인 메모와 고정 메모를 제외하고, 기능을 기본으로 끄며, 바로 삭제하지 않고 휴지통에 보관하는 안전장치를 먼저 설계했습니다. “오래된 메모를 지워줘”에 빠진 질문 AI에게 오래된 메모를 자동 삭제하라고 하면 날짜를 비교하는 코드는 쉽게 나옵니다. 하지만 제품에는 다음 질문이 남습니다. 생성일과 마지막 수정일 중 어느 날짜를 기준으로 할 것인가 사용자가 지금 열어 둔 메모도 대상인가 고정한 메모는 오래돼도 지울 것인가 자동 정리 주기는 언제 실행할 것인가 잘못 정리된 메모를 되살릴 수 있는가 휴지통도 자동으로 비울 것인가 이 질문의 답은 JavaScript 문법이 아니라 사용자가 어떤 실수를 용서할 수 있는지에 달려 있습니다. 선택한 네 가지 안전장치 자동 정리는 기본적으로 꺼 둡니다. 현재 편집 중인 메모는 정리하지 않습니다. 고정한 메모는 보존 의도로 해석해 제외합니다. 삭제 대신 휴지통으로 이동하고 복원 기회를 제공합니다. 기능을 기본으로 끈 이유는 사용자가 예상하지 못한 자동 삭제의 피해가, 오래된 메모가 남아 있는 불편보다 크기 때문입니다. 휴지통도 데이터 모델이다 휴지통은 단순한 두 번째 배열이 아닙니다. 원래 메모 ID, 삭제 시각, 완전 삭제 예정일과 복원 시 충돌 정책이 필요합니다. 상황 필요한 결정 같은 ID의 메모가 이미 있음 새 ID 부여 또는 복원 거부 휴지통 보관 기간 만료 실행 시점과 사용자 안내 앱 업데이트 이전 데이터에 삭제 시각 보완 백업 휴지통 포함 여부 선택 AI에게 구현을 ...

코딩은 AI에게 맡겼습니다 · 시즌 1 / 15 2026년 7월 16일에는 스토어 자산, 아이콘과 스크린샷을 정리했습니다. 기록상 23개 파일이 바뀌고 799줄이 추가됐습니다. 제품 코드는 거의 건드리지 않았지만 출시를 위해서는 반드시 필요한 작업이었습니다. 먼저 보는 핵심 AI가 앱 코드를 완성해도 스토어에 필요한 이름, 설명, 아이콘, 스크린샷, 개인정보 응답과 버전 정보는 별도 제품입니다. 출시 자산을 마지막 날 만들면 기능과 설명이 어긋나기 쉽습니다. 코드가 끝나도 출시가 끝나지 않는다 스토어 등록에는 사용자가 설치를 결정할 자료와 심사자가 권한을 판단할 자료가 필요합니다. 여러 크기의 앱 아이콘 실제 사용 화면 스크린샷 짧은 설명과 상세 설명 기능별 사용 방법 개인정보처리방침 링크 권한 사용 목적 버전별 변경 내역 지원 주소 이 파일이 여러 폴더에 흩어져 있으면 이전 버전 이미지와 현재 설명이 섞입니다. 그래서 코드와 별도로 store-assets , icons , screenshots 구조를 정리했습니다. AI가 잘하는 일과 사람이 확인할 일 AI는 설명문 후보, 이미지에 들어갈 짧은 문구, 파일명 규칙, 체크리스트를 빠르게 만들 수 있습니다. 그러나 실제 스크린샷이 현재 버전인지, 개인정보가 보이지 않는지, 잘린 문구가 없는지는 화면을 보고 확인해야 합니다. AI에게 맡길 일 직접 확인할 일 기능을 이점 중심 문장으로 변환 실제 기능과 설명의 일치 스크린샷 촬영 목록 생성 테스트 데이터의 개인정보 제거 파일명과 버전 폴더 정리 이미지 크기와 가독성 권한 설명 초안 Manifest의 실제 권한과 일치 스크린샷은 기능 목록이 아니다 화면을 그대로 찍는 것만으로는 사용 이유가 잘 보이지 않습니다. 각 이미지는 한 가지 질문에 답해야 합니다. 웹페이지 옆에서 메모할 수 있는가 중요한 메모를 다시 찾을 수 있는가 데이터가 로컬에 남는가 백업과 복원이 가...

코딩은 AI에게 맡겼습니다 · 시즌 1 / 14 2026년 7월 10일 v1.2.0에서는 백업·복원, 키보드 단축키와 시스템 글꼴을 추가했습니다. 네 개 파일에서 253줄을 추가하고 18줄을 삭제했습니다. 계정과 서버가 없다는 단순함을 유지하려면 사용자가 직접 데이터를 옮길 방법이 필요했습니다. 먼저 보는 핵심 로컬에 저장하면 외부 전송을 줄일 수 있지만, 데이터 유실까지 막아 주지는 않습니다. 확장 삭제, 저장소 손상, 기기 교체에 대비해 내보내기 형식, 검증, 병합 정책과 실패 시 원상 복구를 설계해야 합니다. 로컬 저장에도 백업이 필요한 이유 서버가 없으면 계정 유출과 운영 비용을 줄일 수 있습니다. 메모가 외부로 전송되지 않는다는 장점도 큽니다. 반대로 브라우저 안의 데이터에 문제가 생기면 운영자가 복구해 줄 사본이 없습니다. 일상적인 사용 중에도 다음과 같은 상황이 생길 수 있습니다. 확장 프로그램을 실수로 삭제한다. 새 컴퓨터로 이동한다. 브라우저 프로필을 초기화한다. 업데이트 중 데이터 형식이 바뀐다. 잘못된 복원 파일로 기존 메모를 덮는다. 사용자가 메모를 직접 보관하고 옮길 수 있도록 백업과 복원을 제품의 기본 기능으로 다뤄야 했습니다. 파일을 읽는 것과 안전하게 복원하는 것은 다르다 AI는 JSON 내보내기와 가져오기 코드를 빠르게 만들 수 있습니다. 복원에는 다음 정책이 더 필요합니다. 질문 가능한 선택 기존 데이터 처리 교체, 병합, 사용자 선택 중복 메모 ID 기준, 내용 기준, 모두 유지 잘못된 파일 전체 거부, 유효 항목만 복원 버전 차이 마이그레이션, 읽기 전용 안내 실패 시 상태 변경 전 스냅샷으로 되돌리기 가장 위험한 구현은 파일을 읽자마자 기존 저장소를 지우는 방식입니다. 먼저 메모리에서 전체 구조를 검증하고, 복원 계획을 보여 준 뒤, 한 번에 적용해야 합니다. 백업 파일에 버전을 넣기 파일에는 메모 배열만 넣기보다 형식과 생...

코딩은 AI에게 맡겼습니다 · 시즌 1 / 13 2026년 7월 4일 v1.1.0에서는 명시적 저장, 제목, 고정과 정렬, Markdown, 설정을 한꺼번에 추가했습니다. 다섯 개 파일에서 617줄을 추가하고 77줄을 삭제했습니다. 그중 눈에 띄지 않지만 사용 흐름을 크게 바꾼 것은 저장 버튼이었습니다. 먼저 보는 핵심 자동 저장만으로는 사용자가 “이 메모의 작성이 끝났는가”를 구분하기 어렵습니다. 입력 중인 초안을 보존하는 동작과 완성한 메모를 목록에 보관하는 동작을 나누면 저장 버튼의 역할이 분명해집니다. 자동 저장이 있는데 왜 저장 버튼이 필요한가 처음 메모장은 입력할 때마다 내용을 보존했습니다. 사용자가 버튼을 누르지 않아도 된다는 장점이 있습니다. 그러나 메모가 하나의 긴 초안인지, 여러 개의 저장된 기록인지 구분하기 어려웠습니다. 저장 버튼에 부여한 역할은 다음과 같습니다. 현재 편집 중인 내용을 이름 있는 메모로 보관한다. 저장 시점을 기준으로 목록에 추가한다. 이후 새 메모를 시작할 수 있다. 사용자가 완료감을 느낀다. 자동 저장은 작업 중 손실을 막고, 저장 버튼은 하나의 메모를 확정합니다. 같은 단어를 사용해도 역할이 다릅니다. 기능 묶음이 만든 새로운 규칙 제목, 고정, 정렬이 함께 들어오면서 데이터 모델도 달라졌습니다. 필드 필요한 이유 id 제목이 같아도 메모를 구분 title 목록에서 내용을 빠르게 찾기 createdAt 생성 순서 표시 updatedAt 최근 수정 기준 정렬과 자동 정리 pinned 일반 정렬 순서보다 고정한 메모를 우선 표시 content 리치 텍스트 본문 AI에게 기능별 코드를 따로 요청하면 같은 메모 객체를 여러 방식으로 수정할 수 있습니다. 먼저 공통 데이터 구조와 편집·저장 시의 상태 변화를 정한 뒤 구현하는 편이 안전합니다. 저장 중·완료·실패를 화면에서 구분하기 버튼을 눌렀는데 아무 변화가 없으면 사용...

코딩은 AI에게 맡겼습니다 · 시즌 1 / 12 2026년 6월 27일에는 저장한 메모를 찾는 검색 기능을 추가하고 다크 테마를 다시 수정했습니다. 네 개 파일에서 154줄을 추가하고 19줄을 삭제했습니다. 검색창과 결과 안내가 추가되면서 기존 테마에서도 글자와 배경이 잘 구분되는지 다시 확인해야 했습니다. 먼저 보는 핵심 새 기능이 동작해도 기존 화면과 함께 사용할 때 문제가 생길 수 있습니다. 검색 결과가 없거나 제목이 긴 상황을 각 테마에서 확인하는 식으로, 기존 동작이 깨지지 않았는지 점검하는 회귀 테스트 목록을 변경할 때마다 갱신해야 합니다. 검색창 하나가 추가한 상태 검색은 입력창과 필터 함수만 있으면 되는 것처럼 보입니다. 실제 화면에는 적어도 다음 상태가 생깁니다. 검색어가 비어 있는 기본 목록 결과가 한 개 이상인 목록 결과가 없는 빈 화면 한글·영문·숫자·특수문자 검색 제목과 본문 중 어디에서 일치했는지 고정·정렬과 검색 결과의 관계 각 상태의 문구와 입력 내용은 밝은 테마와 어두운 테마 모두에서 읽기 쉬워야 합니다. 검색어 강조 색상이나 빈 결과 안내 문구는 기본 목록에 없던 새 디자인 요소입니다. AI에게 정상 화면만 보여주지 않기 “검색 기능을 구현해줘”라는 요청만으로는 결과가 없거나 입력이 비정상적인 상황이 빠질 수 있습니다. 다음처럼 예외 상황과 확인 기준까지 구체적으로 적는 편이 좋습니다. text 검색어가 없을 때 전체 목록을 보여준다. 공백만 입력하면 검색하지 않는다. 대소문자 차이를 무시한다. HTML 태그가 아니라 사용자에게 보이는 텍스트를 검색한다. 결과가 없으면 다음 행동이 분명한 안내를 보여준다. 세 가지 테마에서 입력창, 결과, 강조 색상의 대비를 확인한다. 리치 텍스트 메모라면 저장된 HTML 문자열을 그대로 검색할 때 태그 이름이나 속성이 결과에 섞일 수 있습니다. 화면 텍스트 기준으로 정규화하는 과정이 필요합니다. 상태 조합표로 테스트 우선순위 정하기 모든 조합을...

코딩은 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 탭, 버튼, 빈 화면 안내 오류 저장 실패, 잘못된 파일, 용량 초과 데이터 기본 메모 제목, 내보내기 파일 이름 스토어 상세 설명, 개인정보처리방침, 업데이트 내역 화면에서 보이는 버튼만 번역하면 오류 메시지나 다운로드 파일 이름에 이전 언어가 남기 쉽습니...