won-solution.com

코딩은 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가 새 기능을 완성해도 기존 기능의 조합까지 자동으로 검증했다고 가정하면 안 됩니다. 검색×빈 결과×테마×긴 제목처럼 상태를 조합한 회귀 테스트 목록을 매 변경에 함께 만들어야 합니다. 검색창 하나가 추가한 상태 검색은 입력창과 필터 함수만 있으면 되는 것처럼 보입니다. 실제 화면에는 적어도 다음 상태가 생깁니다. 검색어가 비어 있는 기본 목록 결과가 한 개 이상인 목록 결과가 없는 빈 화면 한글·영문·숫자·특수문자 검색 제목과 본문 중 어디에서 일치했는지 고정·정렬과 검색 결과의 관계 각 상태는 밝은 테마와 어두운 테마에서도 읽혀야 합니다. 검색어 강조 색상이나 빈 결과 안내 문구는 기본 목록에 없던 새 디자인 요소입니다. AI에게 정상 화면만 보여주지 않기 AI는 “검색 기능을 구현해줘”라는 요청에 정상 경로를 우선 완성합니다. 다음과 같이 실패·경계 상태를 구체적으로 요청해야 합니다. text 검색어가 없을 때 전체 목록을 보여준다. 공백만 입력하면 검색하지 않는다. 대소문자 차이를 무시한다. HTML 태그가 아니라 사용자에게 보이는 텍스트를 검색한다. 결과가 없으면 다음 행동이 분명한 안내를 보여준다. 세 가지 테마에서 입력창, 결과, 강조 색상의 대비를 확인한다. 리치 텍스트 메모라면 저장된 HTML 문자열을 그대로 검색할 때 태그 이름이나 속성이 결과에 섞일 수 있습니다. 화면 텍스트 기준으로 정규화하는 과정이 필요합니다. 조합표로 회귀 범위를 줄이기 모든 조합을 수동으로 확인하기 어렵다면 위험도가 높은 조합부터 고릅니다. 기능 반드시 함께 확인할 상태 검색 빈 결과, 긴 메...

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

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

코딩은 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 권한 목록 저장 키와 각 값의 목적 외부 네트워크 요청 목록 백업 파일의 구조 삭제와 복원 동작 연락 가능한 지원 채널 그다음 각 사실을 일반 사용자가 이해하는 섹션으로 바꾸게 했습니다. 존재하지 않는 데이터 처리를 상상하지 말고, 확인되지 않은 부분은 질문으로 남기도록 요청하는 방식이 유용했습니다. 정책과 제품을 함께 수정해야 하는 순간 정책을 쓰다가 설명하기 어려운 동작을 발견하면 문장을 고치는 것보다 제품을 고치는 편이 낫습니다. 예를 들어 불필요하게 넓은 권한은 “좋은 목적으로만 사용한다”고 길게 설명하기보다 제거하는 것이 명확합니다...