AI 개발 7주 결산: 출시 설명 일곱 줄이 남긴 것

코딩은 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에게 구현을 ...

코드가 아닌 파일 23개가 출시를 막고 있었다

코딩은 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 문자열을 그대로 검색할 때 태그 이름이나 속성이 결과에 섞일 수 있습니다. 화면 텍스트 기준으로 정규화하는 과정이 필요합니다. 상태 조합표로 테스트 우선순위 정하기 모든 조합을...