
일기마다 비슷한 데서 막히고 있었다
바이브코딩 일기를 한곳에 모아 놓고 보니 자꾸 되풀이되는 이야기가 있었습니다. 처음에는 화면이 금방 나오는데, 기능을 붙일수록 원하는 것과 조금씩 멀어진다는 이야기요. 예전 글에는 자기 브랜드 홈페이지를 만들던 친구의 사례도 남아 있습니다. 첫 화면이 나왔을 때의 신기함과, 그다음 수정에서 꼬이던 과정이 같이 적혀 있어요.
이번에 그 글들을 다시 읽으면서 저는 AI에게 건넨 설명 쪽을 오래 봤습니다. 원하는 결과를 다 말하지 않은 채 일단 만들어 달라고 한 건 아닌지. 제가 정하지 않은 부분까지 AI가 적당히 채우면, 나중에 그걸 고치는 일이 또 생깁니다.
처음엔 잘되다가 점점 꼬이던 때의 일기첫 요청에 기능을 다 넣을 필요는 없었다
만들고 싶은 걸 적기 시작하면 목록은 금방 길어져요. 회원가입도 있어야 할 것 같고, 알림도 있으면 좋겠고, 관리 화면도 필요합니다. 그런데 그걸 한꺼번에 늘어놓으면 정작 첫 방문자가 무엇부터 해야 하는지는 흐려집니다.
기획을 다룬 일기에서 다시 가져온 기준은 간단합니다. 누가 들어와서 무슨 일을 마치고 나가는지 먼저 적는 것. 예약 사이트라면 날짜를 보고 신청을 마치는 흐름부터 연결해 보는 거죠. 그 흐름을 적고 나면 지금 만들 화면과 나중에 붙여도 되는 기능이 조금씩 갈립니다.
본업과 병행해 작업하다 보니 한 번에 만들 부분을 좁히는 게 제게는 중요해요. 첫 화면에서 무엇을 보여줄지, 버튼을 누르면 어디로 갈지 정해 두면 컴윗 모바일 바이브코딩에 맡길 일도 구체적이 됩니다.
만들고 싶은 것을 기능 목록으로 나누던 기록다음 대화에 남길 건 결정한 이유였다
같은 설명을 계속하는 문제도 일기에서 여러 번 다뤘습니다. 어떤 화면을 만들었는지뿐 아니라 왜 그렇게 만들었는지까지 남겨야 한다는 내용이었어요. 기능 이름만 써 두면 나중에 그 결정을 바꿔도 되는지 판단하기 어렵습니다.
그래서 작업 메모에 남기고 싶은 내용도 달라졌습니다. 지금 무엇이 되는지, 아직 어디가 비어 있는지, 이번에는 무엇을 건드리지 않을지. 길게 쓰기보다 다음 작업을 시작할 때 알아야 할 것을 남기는 쪽입니다. 도구가 이전 맥락을 얼마나 가져오든, 제가 확인할 기준은 있어야 하니까요.
반복 설명과 작업 메모에 관해 쓴 일기다음 작업에서는 먼저 한 문장으로
여전히 만들고 싶은 게 생기면 바로 화면부터 보고 싶습니다. 다만 이번에 일기를 묶으면서, 시작 전에 적어둘 문장이 하나 생겼어요. 누가 들어와서 무엇을 하고 나가는 곳인지.
그 문장부터 적고, 오늘 만들 부분만 골라서 부탁하려고 합니다. 하다가 생각이 바뀌면 바뀐 이유도 남기고요. AI에게 설명하려고 시작한 메모가 결국 제가 만들 것을 정하는 데도 도움이 됩니다.
참고한 자료
조금 헤매도 끝내 만든다.
떠돌이방랑자