서론
AI 진단 재생성 화면에는 '재생성 이유' 입력란이 있었고, 그 내용은 저장되어 이력 화면에도 표시되었습니다.
하지만 확인해 보니, 재생성 이유는 생성 프롬프트(generation prompt)로 전달되지 않았습니다.
'영업 범위가 다르니 수정해 줘'라고 입력해도 AI는 그 지적을 알지 못한 채, 같은 조건으로 진단을 다시 만듭니다.
이 글은 재생성 이유가 수집되고 저장되며 표시되더라도, 생성 처리 과정에 연결되어 있지 않으면 기능하지 않는다는 것을 깨달은 개발 로그입니다.
이런 분들께 추천합니다
- AI 생성 기능에 피드백 입력란을 추가하는 분
- 입력값이 저장이나 이력 화면까지 도달했음을 확인하고 안심하는 분
- 재생성 또는 수정 지시를 프롬프트로 전달하는 설계를 재검토하고 싶은 분
이 글에서 알 수 있는 것
- 재생성 이유가 생성 처리까지 도달하지 못했던 구조
- 저장/표시와 AI 입력이 다른 경로가 되는 문제
- 수정 지시를 생성 프롬프트에 연결할 때의 확인 포인트
무엇을 만들었나
만들고 있던 것은 AI 진단을 재생성하는 기능입니다.
진단 결과에 수정하고 싶은 부분이 있을 경우, 사용자가 '재생성 이유'를 입력합니다.
입력된 이유는 다음 흐름으로 처리되고 있었습니다.
이 흐름만 보면 피드백을 활용하고 있는 것처럼 보입니다.
하지만 AI가 실제로 참조하는 생성 프롬프트에는 그 이유가 포함되어 있지 않았습니다.
왜 만들었나
재생성 이유를 입력할 수 있다면, 그 내용을 다음 생성에 반영해야 합니다.
예를 들어, 영업 대응 영역의 인식이 달랐다고 가정해 봅시다.
사용자가 '영업 범위가 다르니 수정해 줘'라고 이유를 써도, 그 문자열이 AI에게 도달하지 않으면, AI는 영업 범위가 다르다는 것을 알지 못합니다.
결과적으로, 같은 정보에서 같은 조건으로 진단을 다시 만드는 것만 하게 됩니다.
여기서 까다로운 점은 UI가 갖춰져 있었기 때문에 기능하는 것처럼 보였다는 것입니다.
- 입력란은 표시된다
- 저장도 이루어진다
- 이력 화면에도 표시된다
- 그럼에도 AI의 수정 내용에는 반영되지 않는다
이번 구성에서는, 저장소와 AI가 실제로 참조하는 입력이 분리되어 있었습니다.
즉, 이번에 발생한 문제는 재생성 이유를 저장/표시하는 경로와 그 값을 생성 프롬프트에서 사용하는 경로가 연결되어 있지 않았다는 것입니다.
막혔던 점 및 해결책
저장되는 것과 사용되는 것은 다르다
확인 대상을 '저장되었는지'에만 두면 문제를 놓치게 됩니다.
이번에 필요했던 확인은 다음 경로였습니다.
실제 수정에서는, 재생성 이유를 생성 프롬프트에 1개의 블록을 추가했습니다.
이 추가를 통해, 재생성 이유가 AI 입력에 포함되도록 했습니다.
'표시된다'가 아니라 '생성 처리가 읽는다'까지 확인한다
입력값에 대한 확인은 최소한 다음 3단계로 나누면 정리하기 쉽습니다.
| 단계 | 확인할 것 |
|---|
| 수집 | 화면에서 입력된 값을 받고 있는가 |
| ... | |
| 이번에는 수집, 저장, 표시까지는 갖춰져 있었습니다. | |
부족했던 것은 AI 생성 처리에서의 활용이었습니다.
화면이나 이력은 정상적으로 작동하더라도, 최종적인 처리에 값이 연결되어 있지 않으면 기능적으로 미완성입니다.
확인할 때는 값의 행방을 추적한다
재생성 이유와 같은 입력값을 추가했을 때는, 저장된 것만으로 확인을 끝내지 않도록 합니다.
다음 순서로 추적합니다.
- 화면이나 API에서 입력값을 받는 곳을 확인한다
- 저장용 데이터에 들어가는지 확인한다
- 생성용 프롬프트를 조립하는 곳을 확인한다
- AI 호출의 입력에 포함되는지 확인한다
- 다른 수정 지시를 전달하여 출력 차이를 확인한다
특히 4번이 빠지면, 저장만 되어 있는 데이터가 남게 됩니다.
결과 및 배운 점
이번 수정은 생성 프롬프트에 재생성 이유를 추가하는 1개의 블록으로 끝났습니다.
하지만 문제 발견에 필요했던 것은 화면이나 저장소만 보는 것이 아니었습니다.
입력값이 정말로 기능하고 있는지 확인하려면, 다음 질문이 도움이 됩니다.
그 값은 최종적으로 어떤 처리의 입력으로 사용되고 있는가?
재생성 이유라면, 이력에 표시되는 것이 목표가 아닙니다.
AI가 그 이유를 읽은 후 진단을 다시 만드는 것이 목표입니다.
비슷한 기능을 만들 때는, 구현 후에 '저장되었는지'뿐만 아니라 '생성 처리에 도달했는지'까지 확인해 두면, 이번처럼 겉모습만 작동하는 상태를 찾기 쉬울 것입니다.
참고로, 이 글에서는 동작 결과의 수치나 출력 품질의 변화까지는 확인하지 않았습니다.
확인된 것은 재생성 이유를 생성 프롬프트로 전달하는 경로가 추가되었다는 점입니다.
관련 기사
저는 개인적으로 AI 도구나 업무 자동화를 만드는 Miyoki라고 합니다.
AI 진단처럼, 저의 작업을 쉽게 만들기 위한 작은 도구들을 만들고, 그 개발 로그를 Zenn과 Qiita에 작성하고 있습니다.
제가 만든 것들과 포트폴리오는 여기에서 확인하실 수 있습니다.
토론
