나는 AI에게 설명을 듣는 것보다 실제 파일과 화면이 바뀌는 작업을 원했다. 선택한 코드나 페이지에 대해 이야기하고, 바뀐 것을 확인하고, 필요한 부분을 다시 다듬는 방식이다.
그런 작업을 반복할수록 내가 아는 내용이 대화 안에만 있으면 다음 사람이 다시 처음부터 묻게 된다는 점이 보였다. 그래서 이번 홈페이지에는 수정할 파일과 빌드 명령, 확인한 결과와 확인하지 못한 범위를 함께 남겼다. 이 블로그도 그 연장선이다.
내가 없어도 이어지는 관계
나는 고객이 작은 수정마다 나를 찾아야만 하는 구조를 원하지 않는다. 직접 고칠 수 있는 길을 충분히 남기고, 사업에 맞는 판단이나 새로운 설계가 필요할 때 함께 일하고 싶다. 정보 공개와 연락은 자연스럽게 함께 갈 수 있다.
다음 AI가 알아야 하는 다섯 가지
- 이 사이트가 누구에게 무엇을 설명하는가.
- 문구·디자인·동작을 각각 어느 파일에서 바꾸는가.
- 이번 요청에서 보존해야 할 브랜드와 기능은 무엇인가.
- 어떤 결과를 확인해야 완료인가.
- 확인한 사실, 미확인 추정, 변경 기록은 어디에 남기는가.
AI 이름보다 실제 접근 범위를 확인한다
Codex·Claude·Gemini·Grok을 같은 능력으로 묶어 소개하지 않는다. 프로젝트 파일에 접근할 수 있는 도구와 파일을 첨부해 변경안을 받는 일반 채팅은 작업 방식이 다르다.
내가 제공하려는 것은 소유자가 선택한 AI로 운영을 이어갈 수 있는 구조다. 연결된 범위에서 수정하고 사람이 확인하는 절차를 남긴다. 특정 AI가 모든 권한을 자동으로 갖는다고 표현하지 않는다.
복사해 쓸 수 있는 작업 요청
반영된 소스와 공개 배포의 대응 관계도 적는다. 필요할 때 되돌릴 버전을 설명할 수 있어야 운영 지침이 완성된다.
코드와 구현 살펴보기
독자가 자기 프로젝트에 맞춰 쓰는 요청 형식
목표: 서비스 소개 문구를 새 내용으로 바꾼다.
수정 범위: 주요 문구 파일과 해당 HTML.
보존: 브랜드명, 문의 주소, 기존 메뉴와 기능.
완료 기준: 빌드 성공, PC·모바일 문구 확인,
링크와 관련 동작 확인.
결과 기록: 수정 파일, 실제 검사, 미확인 사항,
복구할 버전과 다음 작업의 시작점.지식을 공개하는 이유
독자가 이 글을 읽고 직접 해결한다면 이 기록은 제 역할을 한 것이다. 그 과정에서 자기 사업에 맞는 설계와 연결이 필요해지면 연락할 수 있다. 정보의 부족함으로 문의를 만들고 싶지는 않다.
함께 일하고 싶은 이유가 생기는 정보는 어느 버튼을 누르라는 설명에서 한 걸음 더 간다. 왜 그 선택을 했는지, 언제 바꿔야 하는지, 어떻게 맞다고 확인할지를 남긴다.