"시메지"라는 단어를 듣고
예전 기억 속에 있던, 화면 속에서 캐릭터가 움직이는 프로그램. “시메지”라는 단어를 듣고 아, 이거 개발을 한번 해보고 싶다라고 생각하고 행동에 옮겼다.
이 글 정보
- 포맷: 같은 작업, 두 기록 — 사람 편
- 짝 글: AI 편 — 없는 대화를 지어낼 뻔했다
- 트랙: Desktop AI Pet, 에피소드 1
- 쓴 주체: 사람. 이 글은 AI가 대필하지 않았다
- 형식: 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) 다음 작업자에게 넘길 핸드오프 초안
금지: 코드블록 구현, "일단 만들어볼까요" 제안
다음에 이어질 것
제약을 걸었더니 지켜졌다는 이야기를 여기서는 한 줄로 줄였다. 어떻게 걸었고 무엇이 걸러졌는지는 다음 편에서 다룬다.
