콘텐츠로 건너뛰기

AI에게 “앱 만들어줘”라고 하면 망하는 이유 — 왜 그렇게 정했나 (사람 편)

PAIR LOG · DESKTOP AI PET

AI에게 앱 제작을 맡길 때 첫 요청문을 왜 그렇게 정했는지, 사람 쪽 판단 근거를 남긴 기록입니다.

이 글 정보

"시메지"라는 단어를 듣고

예전 기억 속에 있던, 화면 속에서 캐릭터가 움직이는 프로그램. “시메지”라는 단어를 듣고 아, 이거 개발을 한번 해보고 싶다라고 생각하고 행동에 옮겼다.

짝이 되는 AI 편은 프로젝트 저장소에 남은 설계 문서를 읽고 쓴 글이다. 결정이 무엇이었는지는 기록에 있지만 왜 그렇게 정했는지는 없다. 그래서 AI 편은 질문을 남겼고, 이 글은 그 질문에 답한다.

왜 하필 상주하는 캐릭터였나

언젠가 화면 속을 움직이고 사용자와 커뮤니케이션할 수 있는 캐릭터를 만들고 싶었다. 그냥 간단한 희망사항이었다.

스스로 판단해 돕거나 장난을 건다는 부분은, 기본적인 시메지 기능에 로컬 LLM이 있을 경우 그 부분을 이용해서 자율 행동을 할 수 있겠구나 하고 상상한 부분이다. 장난도 거기 포함된다.

하지 않을 것을 왜 그렇게 길게 적었나

의도한 것이다. 워낙 풀어 놓으면 내가 의도한 것과 먼 프로그램이 만들어질 것 같아서 미리 제한 조건을 제시했다.

빼기로 한 네 가지 중에 제일 넣고 싶었던 건 상시 화면 관찰 기능이다. 이 부분은 생각해 보니 개인 정보, 보안, 사생활 침해 가능성이 있는 상황이 예상되어 참았다.

라이선스를 왜 첫날에 봤나

해당 앱은 개발 후 그룹에 공개할 버전이 필요해서 라이선스 문제를 먼저 생각했다.

Live2D나 Spine을 실제로 써 보고 뺐느냐면, 내가 이 분야의 도메인은 없지만 Live2D는 이전에 잠시 공부한 적이 있었고 Spine은 관련 웹사이트를 검색한 뒤 결국 제외했다.

결국 에셋을 쉽게 만들 수 있는가, 즉 AI로 생성이 쉬운가를 먼저 생각하게 됐다.

AI에게 실제로 뭐라고 시켰나

처음 시작은 이랬다.

너 "시메지"에 대해 알고있지?

그다음부터는 잘 기억이 안 난다.

구현하지 말라는 제약을 걸었느냐는 질문에는 답할 게 있다. 브레인스토밍 후 설계까지만 진행하려고 했다. 구현을 제약하지 않으면 먼저 구현을 시작하는 상황이 많았기 때문이다. 그래서 제약을 걸었고, 다행히 잘 지켜졌다.

사흘 만에 엔진을 뒤집은 일

첫날 정한 엔진이 사흘 뒤에 바뀌었다. AI 편은 이걸 두고 바꿀 조건을 미리 적어 둔 덕에 전환이 쌌다고 읽었다.

그때 내가 느낀 건 좀 달랐다. 생성되는 프로그램의 용량이 너무 크다는 것을 본 순간부터 뭔가 잘못 시작된 걸 느꼈다. 내가 원한 건 항상 화면에서 동작하고 있어야 하는 것인데, CPU와 메모리 사용량이 적으면 적을수록 좋기 때문이다.

마음을 바꾼 계기도 같다. 생성되는 프로그램의 용량이 너무 크다는 것.

다음에는 요청을 어떻게 바꿀까

첫 문장은 동일할 것 같다. 그다음 브레인스토밍을 할 때 내가 좀 더 상세화한 요청을 하고 싶다.

오늘 가져갈 템플릿

설계만 받고 구현은 막는 요청문이다. 이번에 실제로 걸었던 제약이 이 형태였고, 지켜졌다.

역할: 설계 파트너
목표: (한 문장)
out of scope: 코드 작성 금지, 파일 수정 금지, 추측으로 API 단정 금지
제약: (플랫폼 / 시간 / 공개 범위 / 라이선스)
출력 형식:
1) 문제 재진술
2) 선택지 2~3개 + 장단점
3) 추천 1개 + 근거
4) 내가 확인해야 할 질문 3개
5) 다음 작업자에게 넘길 핸드오프 초안
금지: 코드블록 구현, "일단 만들어볼까요" 제안

다음에 이어질 것

제약을 걸었더니 지켜졌다는 이야기를 여기서는 한 줄로 줄였다. 어떻게 걸었고 무엇이 걸러졌는지는 다음 편에서 다룬다.

이 블로그 더 보기

이런 기록은 시리즈로 이어집니다.

  • 새 글은 RSS로 받아볼 수 있습니다.
  • 시리즈 전체는 여기에 정리해 두었습니다.

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다