AI가 내 블로그 이름을 계속 바꾼 뒤 고유명사를 자동화하지 않기로 했다
AI 에이전트에게 블로그 이름 수정을 맡겼다가 고유명사가 계속 변형되는 문제를 겪고, 정확한 문자열은 사람이 직접 확인해야 한다는 운영 원칙을 배운 기록.
시작은 단순한 이름 수정이었다
Dev Blog 배포는 이미 거의 정상 상태였다.
GitHub Pages는 GitHub Actions workflow로 빌드되고 있었고, Chirpy도 동작했다. 홈페이지와 첫 글도 public URL에서 200을 반환했다. Contact, Privacy, Disclosure 같은 trust page도 준비되기 시작했다.
처음에는 남은 일이 아주 작아 보였다.
나태킴의 커밋로그라는 블로그 이름과 나태킴이라는 표시 이름을 설정 파일과 문서에 맞춰 두면 되는 일이었다.
코드가 깨진 것도 아니고, Jekyll front matter가 문제인 것도 아니었다. 이제는 배포 문제가 아니라 브랜드 문자열 일관성 문제였다.
그런데 이 작은 일이 생각보다 오래 걸렸다.
그런데 이름이 계속 바뀌었다
AI 에이전트에게 “이 이름이 맞다”고 알려 주고, 잘못된 문자열을 찾아 바꾸라고 했다.
문제는 AI가 문자열을 복사해야 할 대상을 고유명사로 보지 않고, 의미를 가진 한국어 이름처럼 해석하려고 했다는 점이다.
그 결과 블로그 이름이 이런 식으로 흔들렸다.
태희의 커밋로그나태이의 커밋로그나태희의 커밋로그
어떤 순간에는 public site는 잘 빌드되는데, 화면에 보이는 이름만 계속 미묘하게 달랐다.
참 애매했다. 사이트는 살아 있고, workflow도 성공이고, sitemap과 robots도 멀쩡한데, 가장 눈에 띄는 이름이 틀렸다.
기술적으로는 성공했는데, 이름표가 틀리면 사용자 입장에서는 성공한 게 아니다.
이건 꽤 좋은 교훈이었다. 배포 자동화가 아무리 잘 돌아도, 고유명사 하나가 틀리면 신뢰가 먼저 흔들린다.
문제는 코드가 아니라 고유명사였다
처음에는 설정 문제처럼 보였다.
_config.yml을 보고, social.name을 보고, About page와 HQ 문서를 검색했다. 실제로 고쳐야 할 파일도 있었다.
하지만 핵심은 파일 위치가 아니었다. 핵심은 “어떤 문자열은 해석하지 말고 그대로 복사해야 한다”는 기준이 없었다는 점이다.
AI가 잘하는 일과 조심해야 하는 일이 섞여 있었다.
1
2
정확해야 하는 문자열은 추론 대상이 아니다.
복사 대상이다.
이 차이를 명확히 하지 않으면 AI는 친절하게 도와주려다가 오히려 이름을 바꿔 버릴 수 있다. 아마 AI 입장에서는 “더 자연스러운 이름”을 고른 것처럼 보였을지도 모른다.
하지만 브랜드명은 자연스러움보다 정확성이 먼저다.
왜 이런 일이 생겼을까
이번 문제는 AI가 무능해서 생긴 일이라기보다, 작업 지시가 너무 넓어서 생긴 일에 가까웠다.
“브랜딩을 고쳐 줘”라고 하면 AI는 문맥을 읽고, 비슷한 문자열을 찾고, 더 맞아 보이는 형태를 제안하려고 한다. 보통은 그게 장점이다.
하지만 고유명사, author name, domain, verification code처럼 한 글자 차이가 의미를 바꾸는 값에서는 그 장점이 위험해진다.
| AI에게 맡기기 좋은 것 | 사람이 직접 확인할 것 |
|---|---|
| 문서 구조 잡기 | 브랜드명 |
| 초안 작성 | 작성자명 |
| 체크리스트 만들기 | 도메인 |
| 반복 작업 정리 | 인증 코드 |
| 코드 변경 후보 제안 | API 키와 시크릿 |
문서 구조나 초안 작성은 AI에게 맡겨도 된다. 오히려 빠르고 편하다.
하지만 natekeem, 나태킴, Search Console verification code, API key 같은 값은 다르다. 이 값들은 “그럴듯한 값”이 아니라 “정확히 같은 값”이어야 한다.
결국 VS Code로 직접 고쳤다
결국 마지막에는 VS Code를 열고 직접 검색했다.
전체 검색으로 잘못된 이름을 찾고, 하나씩 확인하면서 바꿨다.
솔직히 말하면 조금 웃겼다. AI 블로그 자동화 프로젝트를 만들다가, 가장 확실한 해결책이 수동 검색과 수동 치환이었다.
하지만 이게 나쁜 결말은 아니었다.
오히려 MVP 0.1에서 확인하려던 원칙과 잘 맞았다.
1
2
수동 먼저, 자동화는 나중에.
품질 기준이 먼저, 반복 자동화는 그 다음.
이번에는 수동으로 고쳤고, 그 과정에서 자동화하면 안 되는 영역을 하나 더 배웠다.
새로 추가한 운영 원칙
이 일을 겪고 나서 HQ 문서와 agent routing 파일에 새 규칙을 추가했다.
핵심은 간단하다.
- 고유명사는 사용자가 제공한 문자열을 그대로 복사한다.
- 비슷해 보이는 이름으로 바꾸지 않는다.
- 인코딩 문제처럼 보이는 문자열을 임의로 해석하지 않는다.
- 변경 전후로 전체 검색을 수행한다.
- 최종 표시 이름은 사람이 직접 확인한다.
이 규칙은 AGENTS.md, CLAUDE.md, Roo rules, 그리고 Dev Blog 운영 문서에 들어갔다.
이제 다음에 AI 에이전트가 같은 작업을 맡으면, 적어도 출발점에는 안전장치가 있다.
앞으로 AI에게 맡길 일과 맡기지 않을 일
이번 일로 AI를 덜 쓰자는 결론을 낸 것은 아니다.
오히려 반대다. AI는 여전히 문서 초안, checklist, 반복 검색, 배포 절차 정리, 글 구조 잡기에 아주 유용하다.
다만 역할을 더 선명하게 나눠야 한다.
AI에게 판단을 맡길 일과, 복사를 맡길 일을 구분해야 한다.
예를 들면 이런 식이다.
- 글의 흐름을 제안하는 것: AI에게 맡길 수 있음
- 운영 문서의 빠진 항목을 찾는 것: AI에게 맡길 수 있음
나태킴이라는 표시 이름을 다른 이름으로 “정리”하는 것: 맡기면 안 됨- Search Console verification code를 만들어 넣는 것: 절대 맡기면 안 됨
- API key나 credential을 추측하는 것: 절대 맡기면 안 됨
특히 앞으로는 Search Console, AdSense, custom domain, analytics, comments 같은 설정이 남아 있다.
여기에는 exact string이 더 많이 나온다.
- 도메인
- repository 이름
- author name
- blog brand
- verification code
- analytics ID
- AdSense publisher ID
- API key
이 값들은 한 글자만 달라도 결과가 달라진다. 그러니 “의미가 맞는지”보다 “문자열이 같은지”를 확인해야 한다.
오늘 배운 점
오늘 배운 점은 단순하다.
AI는 구조화와 반복 작업에 강하다. 하지만 고유명사와 인증값은 창의적으로 다루면 안 된다.
그리고 자동화 프로젝트일수록 수동 확인 기준이 더 중요하다.
자동화는 사람의 판단을 없애는 일이 아니다. 어디에 판단이 필요하고, 어디에는 복사만 필요한지 구분하는 일에 더 가깝다.
이번 문제는 작았다. 블로그 이름 몇 글자였다.
하지만 나중에 이게 AdSense ID나 Search Console verification code였다면 훨씬 더 골치 아팠을 것이다. 그러니 작은 실수일 때 배운 것이 오히려 다행이다.
다음 작업
다음 작업은 이 원칙을 앞으로의 설정 작업에 계속 적용하는 것이다.
Search Console, AdSense, custom domain처럼 정확한 문자열이 중요한 작업을 할 때마다 같은 기준을 확인해야 한다.
그리고 앞으로 AI에게 작업을 맡길 때는 프롬프트에 이 문장을 더 자주 넣을 생각이다.
1
2
고유명사와 exact string은 해석하지 말고 그대로 복사한다.
변경 전후 전체 검색 결과를 보고한다.
조금 귀찮아 보여도, 이런 문장이 나중에 한참을 아껴 줄 수 있다.