이 글은 이런 분께
- AI한테 뭔가 시킬 때, 해결 방법까지 내가 다 생각해내야 한다고 느끼는 분
- ChatGPT랑 Claude(또는 다른 코딩 AI)를 각각 따로만 써봤지, 둘을 이어서 써본 적은 없는 분
- 검색어만 살짝 바꾸는 땜빵 말고, 구조 자체를 고치고 싶었던 적 있는 분
Before — 검색어를 아무리 다듬어도 한계가 있었다
지난번엔 “자동화” 태그에 자동차 사진이 붙는 식의 오류를, 검색어를 구체적인 사물로 바꿔서 하나씩 해결했다. 그런데 그 방식은 글이 이미 올라간 뒤에 사람이 눈으로 확인하고 나서야 고칠 수 있었다. 새 글을 쓸 때마다 사진이 이상하지 않은지 매번 봐야 했고, “검색어 하나 → 결과 한 장, 확인 없이 그대로 채택”하는 구조 자체는 그대로였다.
어떻게 1 — 이번엔 GPT한테 설계를 먼저 물어봤다
코드를 고치기 전에, ChatGPT한테 “이 문제를 구조적으로 어떻게 풀면 좋을지” 물어봤다. 검색어를 조금 손보는 수준이 아니라 이렇게 물었다.
지금은 태그·제목으로 Pexels를 검색해서 대표 이미지로 넣는데,
글 내용과 관련 없는 사진이 자주 뽑힌다.
검색어를 조금 고치는 방식 말고, 구조적으로 개선하고 싶어.
GPT가 준 답은 예상보다 훨씬 구체적이었다. 대략 이런 흐름이었다.
- 글 내용(제목+요약+태그+본문 일부)을 분석해서 “사진 장면” 검색어를 여러 개 만들 것
- 검색어 하나당 후보 사진을 여러 장 가져와서 합칠 것
- 후보들 중 관련도가 제일 높은 걸 점수로 골라낼 것
- 관련도가 일정 기준보다 낮으면, 억지로 사진을 넣지 말고 기본 커버로 대체할 것
- 기존 글·기존 UI는 최대한 건드리지 않고, 점진적으로 개선할 것
여기에 “한국어 제목을 영어로 직역하지 말 것”(예: “AI가 확신에 차서 틀렸다” → “AI mistake”가 아니라 “person verifying information on laptop”), 실제로 테스트해볼 제목 4개, 점수 기준(0~100, 기준선 70) 같은 세부 사항까지 다 딸려 있었다.
어떻게 2 — GPT 답변을 그대로 프롬프트로 만들어 클로드한테 넘겼다
GPT 답을 요약하거나 다시 쓰지 않고, 거의 그대로 클로드(코딩용 AI)한테 명령으로 넘겼다. 두 AI 사이에서 내가 한 일은 “이 설계를 실제 내 프로젝트 코드에 맞게 구현해줘”라고 이어준 것뿐이었다.
[GPT가 준 설계안 전체를 그대로 붙여넣고]
내 프로젝트의 현재 코드를 먼저 분석한 뒤, 기존 Pexels 이미지 자동화
기능을 이 구조로 개선해줘. 기존 기능과 UI는 최대한 유지하면서
점진적으로 수정해줘.
어떻게 3 — 클로드가 구현하고, 실제 숫자로 검증했다
클로드가 먼저 한 일은 코드를 바로 고치는 게 아니라 기존 구조부터 파악하는 것이었다. Pexels 호출 위치, 검색어 만드는 방식, 이미지: 수동 지정 기능이 이미 있다는 것까지 확인한 뒤에 코드를 고쳤다. 구현한 흐름은 이랬다.
generateImageSearchQueries() → 글 내용으로 장면 검색어 3개
↓
searchPexelsPhotos() × 3 → 검색어마다 후보 여러 장 (최대 12장)
↓
deduplicatePhotos() → 중복 제거
↓
selectBestImage() → 관련도 점수 제일 높은 사진
↓
threshold(70) 검사 → 미달이면 버림
↓
Pexels 사진 or 기본 커버
막힘 → 해결: 점수 공식이 너무 깐깐했다
처음 만든 점수 공식으로 실제 글 4개를 돌려봤더니, 사람이 봐도 꽤 괜찮은 사진(예: “최종 리허설” 글에 붙은, 노트북으로 웹사이트 보는 사진)까지 70점을 못 넘어서 죄다 기본 커버로 떨어졌다. 원인을 보니, Pexels 사진 설명(alt 텍스트)은 사람이 자유롭게 쓴 문장이라 “website” 대신 “web”이라고 쓰는 식으로 뜻은 같은데 단어만 다른 경우가 흔했다. 그런데 점수 공식은 단어가 정확히 겹쳐야만 점수를 줬다.
그래서 “Pexels 자체가 이미 그 검색어로 의미 기반 정렬을 해준 순서”를 더 신뢰하는 쪽으로 가중치를 바꿨다. 완벽한 단어 일치보다 Pexels 검색 결과에서 몇 번째로 나왔는지를 더 큰 신호로 삼은 것이다. 바꾸고 나서야 진짜 괜찮은 사진들이 통과하기 시작했다.
After — 실제 제목 4개로 확인한 결과
| 제목 | 결과 |
|---|---|
| AI가 확신에 차서 틀렸다 | ✅ 사람이 메모하는 사진 (점수 100) |
| 5일차 최종 리허설 | ✅ 노트북으로 웹사이트 보는 사진 (점수 70) |
| API Key를 GitHub에 올리면 안 되는 이유 | ✅ 키보드 클로즈업 사진 (점수 100) |
| 물결표 하나가 취소선이 됐다 | ✅ 코드 화면 사진 (점수 92) |
마지막 글은 사실 “억지로 맞는 사진이 없을 테니 기본 커버가 나오는 게 정답 아닐까” 싶었는데, 실제로는 코드 화면 사진이 꽤 그럴듯하게 골라졌다. 처음엔 “예상이 틀렸나” 싶었지만, 다시 보니 틀린 게 아니라 예상보다 잘 된 쪽이었다. 마크다운·Astro 버그 글에 코드 화면 사진은 실제로 안 어울릴 이유가 없었다. 기준선을 일부러 넘겨서 기본 커버 화면도 따로 확인했고, 정상적으로 나오는 것까지 봤다.
기존에 있던 51개 글은 전부 사진을 수동으로 지정해둔 상태라서, 새 기능이 배포된 뒤에도 그 글들은 하나도 안 바뀌었다. 새 로직은 앞으로 사진을 안 정해주는 새 글부터만 적용된다.
배운 것 / 재사용 자산
AI한테 “어떻게 고칠지”까지 내가 다 설계해줄 필요는 없었다. 문제 상황만 정확히 설명하면 GPT한테 구조적인 해결책을 먼저 물어볼 수 있고, 그 답을 그대로 코딩 AI한테 넘겨도 될 만큼 구체적인 설계가 나온다. 나는 “이 문제가 있다”와 “이 설계를 내 프로젝트에 맞게 구현해줘”만 이어주면 됐다.
AI 둘을 릴레이로 쓰는 프롬프트 구조
1단계 (설계 담당 AI)
"[문제 상황]을 땜빵 말고 구조적으로 해결하고 싶어.
어떻게 접근하면 좋을지 단계별로 설계해줘."
2단계 (구현 담당 AI)
[1단계 답변 전체를 그대로 붙여넣기]
"내 프로젝트의 현재 코드를 먼저 분석한 뒤,
위 구조로 기존 기능을 점진적으로 개선해줘.
기존 기능과 UI는 최대한 유지해줘."
예상과 다른 결과가 나왔을 때 판단하는 법도 하나 배웠다. “이 케이스는 기본 커버가 나올 줄 알았는데 사진이 나왔네?”처럼 예상과 다르면 일단 의심부터 하게 된다. 예전에 AI 판단을 의심 없이 따라갔다가 틀렸던 경험과는 반대로, 이번엔 결과를 직접 뜯어보고 나서야 예상이 틀렸을 뿐 결과 자체는 괜찮다는 걸 확인할 수 있었다. 내 예상 쪽을 의심해보는 것도 검증의 한 방법이었다.