- 큰 덩어리를 통째로 시키면 결과는 그럴듯한데, 어디가 틀렸는지 짚을 수가 없어요.
- 필요한 건 더 좋은 프롬프트가 아니라 검증 가능한 단위로 쪼개는 것이었어요.
- 첫 화면 리디자인을 뼈대·색·시세·모바일 네 조각으로 나누고, 단계마다 스크린샷으로 확인했어요.
주말에 블로그 첫 화면을 손보고 싶었어요. AI 코딩 도구를 켜고 한 문장을 적었습니다. 첫 화면을 요즘 느낌으로 리디자인하고, 실시간 시세도 붙이고, 모바일에서도 잘 보이게 해달라고요. 십 분쯤 뒤에 파일 여러 개가 바뀌었고 화면에는 제법 그럴듯한 게 떠 있었어요. 그런데 시세 숫자는 비어 있었고, 휴대폰으로 열어보니 글자가 화면 밖으로 삐져나가 있었습니다.
왜 통째로 시킨 일은 늘 절반만 끝나 있을까요?
저는 비전공자라서 그다음이 진짜 문제였어요. 결과물이 완전히 틀렸으면 차라리 나았을 텐데, 절반은 멀쩡하고 절반만 어긋나 있으니까 어디를 봐야 할지 감이 안 잡히더라고요. 바뀐 파일이 대여섯 개인데, 그중 어느 부분이 시세를 담당하고 어느 부분이 모바일을 담당하는지 저는 모르는 상태였습니다.
그래서 그냥 다시 시켰어요. 시세가 안 나온다고 말하니 시세는 나왔는데, 이번엔 위쪽 메뉴가 겹쳐 보였습니다. 메뉴를 고쳐달라고 하니 이번엔 글자 크기가 전부 커졌어요. 세 번쯤 반복하고 나니 처음보다 더 엉망이 됐고, 결국 전날 백업으로 통째로 되돌렸습니다. 반나절이 그렇게 날아갔어요.
나중에 돌아보니 원인은 단순했어요. 저는 한 번에 네 가지 일을 시켰거든요. 구조를 바꾸고, 디자인을 바꾸고, 새 데이터를 붙이고, 화면 크기까지 대응하라고요. 넷 중 셋이 잘돼도 제 눈에 보이는 건 그냥 안 되는 화면 하나였습니다. 절반만 끝나 있는 것처럼 느껴진 이유가 여기 있었어요.
사실 AI 가 일을 못 한 건 아니었어요. 각각을 따로 시켰다면 대부분 잘 처리했을 일들이에요. 다만 넷을 한 번에 받아 든 탓에 결과도 한 덩어리로 나왔고, 저는 그 덩어리를 통째로 받아들이거나 통째로 버리는 선택밖에 못 했습니다.
문제가 프롬프트 실력이 아니었던 이유는 뭘까요?
처음엔 제가 설명을 못 해서라고 생각했어요. 그래서 다음번엔 요구사항을 열 줄쯤 적었습니다. 색상 코드도 적고, 글꼴도 적고, 모바일 기준 폭까지 적었어요. 결과는 조금 나아졌지만 본질은 똑같았습니다. 여전히 한 번에 결과가 통째로 나왔고, 문제가 생기면 어디서부터 어긋났는지 알 수 없었어요.
긴 요청은 요구를 정확하게 만들어 줄 뿐이지, 중간에 확인할 지점을 만들어 주지는 않더라고요. 열 줄짜리 요청도 결국 답은 한 번에 나오니까요. 제게 필요했던 건 문장을 더 정교하게 다듬는 일이 아니라, 중간에 멈춰서 확인할 자리를 만드는 일이었어요.
코드를 안 읽고도 됐는지 판정되는 크기로 잘라야 했어요.필요한 건 더 좋은 프롬프트가 아니라 중간에 멈춰 확인할 자리였어요.
이건 실력 문제라기보다 구조 문제라고 생각해요. 코드를 읽을 줄 알면 어디가 틀렸는지 찾아 들어가면 되지만, 저는 그게 어려워요. 그러니 코드를 읽지 않고도 됐다와 안 됐다를 판정할 수 있는 크기로 일을 잘라야 했던 겁니다. 도구를 바꾸는 것보다 이게 먼저였어요.
생각해 보면 이건 AI 만의 이야기도 아니에요. 사람한테 일을 맡길 때도 한 번에 네 가지를 던져 놓고 결과만 받으면 어디서 어긋났는지 서로 모르잖아요. 다만 AI 는 워낙 빨리, 그럴듯한 모양으로 결과를 내주니까 제가 확인 없이 다음으로 넘어가기가 훨씬 쉬웠던 것 같아요.
어디서 잘라야 잘 쪼갠 걸까요?
그래서 기준 세 가지를 만들었어요. 거창한 방법론은 아니고, 몇 번 말아먹고 나서 남은 최소한의 규칙입니다.
- 한 번에 하나만 바뀌게: 이번 단계에서 화면의 무엇이 바뀌는지 한 문장으로 말할 수 있어야 해요. 문장이 두 개가 되면 그건 이미 두 가지 일입니다.
- 끝났는지 눈으로 확인할 수 있게: 코드를 안 보고 화면만 보고도 됐다, 안 됐다를 말할 수 있어야 해요. 판정이 안 되는 단계는 잘못 잘린 겁니다.
- 틀렸을 때 되돌리기 쉽게: 한 단계에서 건드리는 범위가 작아야 되돌리기도 쉬워요. 저는 단계마다 저장 지점을 남기고 스크린샷을 한 장씩 찍어 둡니다.
세 번째가 특히 중요했어요. 되돌릴 자신이 없으면 겁이 나서 자꾸 고쳐 달라는 말만 반복하게 되는데, 그게 제일 위험한 길이더라고요. 언제든 되돌릴 수 있다는 확신이 있으면 과감하게 시도해 보고 아니면 버리면 되니까, 오히려 시도 횟수가 늘었습니다.
세 기준을 다 만족하는 크기는 생각보다 작아요. 처음엔 이렇게까지 잘게 나눠야 하나 싶어서 민망했는데, 몇 번 해 보니 이 정도가 딱 제가 감당할 수 있는 크기더라고요. 잘 쪼갠 단계는 요청도 짧고, 확인도 삼십 초면 끝납니다.
첫 화면 리디자인을 넷으로 쪼개면 어떻게 될까요?
같은 작업을 처음부터 다시 했어요. 이번엔 한 문장이 아니라 네 번의 요청으로 나눴습니다.
- 1단계 뼈대: 색이나 데이터는 신경 쓰지 말고 구역만 잡아 달라고 했어요. 상단 소개, 최신 글, 시세 자리, 하단 이렇게요. 밋밋한 흑백 화면이 나왔고, 구역이 제자리에 있는지만 눈으로 봤습니다.
- 2단계 색과 간격: 뼈대는 건드리지 말고 색과 여백만 바꿔 달라고 했어요. 여기서 뭔가 어긋나면 원인은 둘 중 하나라 찾기가 쉬웠습니다.
- 3단계 실시간 시세: 이미 자리를 잡아 둔 시세 칸에 숫자를 채우는 일만 맡겼어요. 데이터가 안 들어와도 나머지 화면은 멀쩡했습니다.
- 4단계 모바일 확인: 마지막으로 좁은 화면에서만 점검했어요. 삐져나간 건 시세 칸 하나뿐이었고, 고칠 곳도 분명했습니다.
네 단계 모두 끝에 스크린샷을 한 장씩 찍었어요. 별것 아닌 습관 같은데 효과가 컸습니다. 3단계에서 화면이 이상해졌을 때 2단계 스크린샷과 나란히 놓고 보니 달라진 건 시세 칸 높이 하나였거든요. 코드를 읽지 않고도 범인을 한 칸으로 좁힐 수 있었어요.
걸린 시간은 처음 시도보다 짧지 않았어요. 요청을 네 번 나눠 하느라 오히려 비슷했습니다. 다만 날려버린 반나절이 없었어요. 저한테는 그 차이가 전부였습니다. 중간에 멈춰 확인한 세 번이 결국 시간을 벌어 준 셈이에요.
쪼개는 감각은 어떻게 몸에 붙을까요?
두 방식을 겪고 나서 제 나름대로 정리해 본 차이는 이렇습니다.
요령이 조금 붙은 뒤로는 요청을 적기 전에 스스로에게 한 가지를 물어봐요. 이게 끝났는지 나는 무엇을 보고 판단하지, 하고요. 여기에 답이 안 나오면 아직 덩어리가 큰 겁니다. 반대로 상단에 시세 두 줄이 뜨면 끝이라는 식으로 답이 나오면, 그 정도는 맡겨도 됐어요.
물론 무조건 잘게 나누는 게 답은 아니더라고요. 서로 얽혀 있어서 억지로 나누면 중간 화면이 아예 안 뜨는 작업도 있어요. 그럴 땐 나누는 대신 되돌릴 지점만 확실히 만들어 두고 한 번에 갑니다. 기준은 결국 하나예요. 실패했을 때 내가 감당할 수 있는가.
비전공자가 AI 와 일할 때 늘려야 할 건 지식보다 이 감각이라고 생각해요. 코드를 못 읽어도 어디까지 시키고 어디서 멈춰 확인할지는 제가 정할 수 있으니까요. 그 판단만큼은 도구가 대신해 주지 않더라고요.
- 요청 전에 이게 끝났는지 무엇을 보고 판단할지부터 답해 봐요.
- 한 단계에서 바뀌는 건 하나, 확인은 화면만 보고 삼십 초면 끝나요.
- 억지로 나누기 어려운 작업은 되돌릴 지점만 잡고 한 번에 가요.
같이 보면 좋은 글
다음 편에서는 이렇게 쪼갠 단계를 어떻게 기록으로 남기는지 써 보려고 해요. 스크린샷과 두세 줄 메모를 어디에 어떻게 쌓아 두면 같은 실수를 덜 반복하게 되는지, 제가 NAS 안에서 굴리고 있는 방식 그대로 정리해 보겠습니다.