AI를 여러 개 켜기 전에: 앱을 만들며 나눈 일과 함께 하면 꼬이는 일

앱 코드, 게임 그림, 홈페이지 글, 스토어 등록. 나인투식스랩에서 AI와 함께 처리하는 일은 한 종류가 아니었습니다. 작업을 나누다 보니 “어느 AI가 더 잘하나”보다 “이 결과물을 누가 끝까지 맡나”를 먼저 정해야 했습니다.

예를 들어 게임 코드를 만드는 작업과 홈페이지 소개를 쓰는 작업은 나눌 수 있습니다. 하지만 아직 출시되지 않은 앱을 홈페이지에서 출시됐다고 소개하면 두 결과물이 어긋납니다. 각자 일을 하는 것만으로는 부족하고, 어디까지 확인했는지 전달하는 과정이 필요했습니다.

여기서 말하는 세션은 AI와 대화하는 작업방 하나를 뜻합니다. 같은 AI라도 채팅을 새로 열면 별도 작업방이 됩니다. 이 글은 그 작업방을 처음 나눌 때의 이야기입니다. 설치 명령이나 복잡한 개발 지식은 없어도 됩니다.

함께 해도 되는 일부터 골랐다

두 작업이 서로의 결과를 기다리지 않아도 된다면 나눠 볼 만합니다. 앱 소개 글의 자료를 찾는 동안, 별도 작업에서 이미 준비된 게임 화면의 크기를 확인하는 식입니다.

반대로 출시 상태를 확인하기 전에 출시 경험담부터 쓰게 하면 나중에 문장을 다시 고쳐야 합니다. 먼저 자료가 필요한 일은 기다렸다가 이어갑니다. 여러 AI를 쓰는 목적이 채팅 수를 늘리는 것은 아니니까요.

하나의 요청을 조사 작성 검수 역할로 나눈 뒤 최종 결과 폴더에 모으는 네 단계 흐름
요청 접수 → 역할별 작업 → 결과 모으기 → 최종 확인의 네 단계만 지켜도 혼선이 크게 줄어듭니다.

우리에게 필요했던 구분은 만드는 쪽과 보는 쪽이었다

슈팅게임은 게임 코드를 만드는 담당과 이미지 자산을 만드는 담당을 나눴습니다. 홈페이지 글과 공개 페이지는 홈페이지 담당이 맡습니다. 검토하는 작업은 잘못된 곳을 찾되, 다른 담당의 원본을 직접 고치지 않는 방식입니다.

이 구조를 작은 블로그 작업에 옮기면 더 간단합니다. 글을 쓰는 채팅 하나를 두고, 다른 채팅에는 원고와 근거를 함께 줘서 사실이 맞는지 읽게 합니다. 검토 의견이 돌아오면 작성하던 채팅이 고칩니다. 두 채팅이 같은 원고를 동시에 바꾸게 하지 않습니다.

역할마다 새 AI 계정이 필요한 것은 아닙니다. 같은 도구의 채팅을 나눌 수도 있고, 작은 일은 한 채팅에서 순서대로 끝내도 됩니다. 오타 한 군데를 고치는 데 조사·작성·검토 채팅을 모두 만들 필요는 없습니다.

“알아서 해 줘”에 빠져 있던 말

요청할 때는 만들 결과, 사용할 자료, 저장할 곳을 함께 적습니다. 설명용으로 앱 소개 글을 맡긴다면 다음 정도면 시작할 수 있습니다.

첨부한 출시 기록으로 앱 소개 글 초안을 써 줘.
출시가 확인된 플랫폼만 공개됐다고 적어 줘.
본문은 짧은 문단으로 쓰고 실제 화면을 넣을 위치도 표시해 줘.
초안.md에 저장한 뒤, 확인하지 못한 내용은 따로 남겨 줘.

검토하는 채팅에는 “좋은 글인지 봐 줘”보다 “출시 기록과 본문의 플랫폼·날짜가 일치하는지 봐 줘”라고 맡깁니다. 무엇과 비교할지가 있어야 확인 결과를 다시 읽을 수 있습니다.

이 문장은 작업 예시입니다. 실제로 파일을 읽거나 저장할 수 있는지는 사용하는 AI의 연결 기능과 권한에 따라 다릅니다. 파일 접근이 안 되는 환경에서는 자료를 첨부하고 결과를 받아 저장하는 과정이 필요합니다.

끝났다는 말에 공개까지 포함되는지 물었다

파일이 만들어진 상태와 홈페이지에 올라간 상태는 다릅니다. 공개한 다음에도 이미지가 안 뜨거나 모바일에서 글이 잘릴 수 있습니다. 그래서 결과를 받을 때 파일 경로, 공개 주소, 확인하지 못한 환경을 구분합니다.

여러 작업을 쓰면서 가장 피하고 싶은 것은 같은 일을 다시 시키는 상황이었습니다. 누가 작성했고 다음에 무엇을 확인하면 되는지 한 줄이라도 남겨 두면, 다른 채팅에서 처음부터 설명할 일이 줄어듭니다.

처음 시작한다면 작성 한 곳과 검토 한 곳이면 충분합니다. 이 구분을 계속 유지할 파일은 업무 분장 MD 만들기에서, 이미 하던 일을 옮기는 방법은 세션 인계 기록에서 이어 설명했습니다.

댓글 남기기