코딩 에이전트 쓰는 법을 이미 아는데 코칭까지 받을 이유가 있을까요? 없다고 생각했습니다. 그냥 제품이 궁금해서 붙은 거였어요.
빈 폴더에서 시작해 세 시간쯤 뒤에 매일 아침 저절로 도는 웹 앱이 나왔습니다. 혼자 부딪히면서 만들어도 결국 나왔을 거예요. 다만 훨씬 많이 헤맸겠죠. 코칭이 한 일은 그 헤맬 자리를 앞으로 당겨서 미리 걷어낸 것이었습니다. 묻고, 고르게 하고, 목표를 문장으로 못 박고 나서야 손을 대더라고요.
가진 건 슬랙 스레드에 정리해 둔 출처 링크 목록이 전부였어요. 격주로 도는 AI 에이전트 스터디에서 발표를 맡게 돼서, 매일 아침 소식을 카드로 훑고 그중 몇 개를 골라 발표하는 걸 만들고 싶었습니다. 첫 요청은 이렇게 보냈습니다.
보통 여기서 바로 만들기가 시작되죠. 안 그랬습니다.
1. 만들기 전에 묻고, 고르게 합니다
코치가 네 가지를 나눠서 물었어요. 지금 어디까지 되어 있는지, 재료가 뭔지, 결과물을 어디서 볼 건지, 뭘 보면 다 됐다고 할 건지. 한 응답에 질문은 하나씩만 왔습니다.
시시해 보이는데 세 번째에서 걸렸어요. 매일 만들어진 카드를 어디서 보고 싶으냐고, 슬랙 DM이나 노션 데이터베이스, 로컬에서 여는 HTML 페이지 같은 선택지를 늘어놓고 묻길래 답하다 보니, 제가 원한 게 웹으로 배포된 앱이라는 게 그제야 말로 나왔습니다. 그 질문이 없었으면 그 말을 한참 뒤에야 꺼냈을 것 같아요.
그다음이 더 중요했는데, 방향 세 가지를 장점과 제약까지 적어서 늘어놓고 고르라고 했습니다.
코치 추천은 1번이었어요. 저는 3번을 골랐습니다.
어... 음... 근데 일단 방향 3로 하자. 일단 API를 쓸 여력이 안되서 말이야....
추천을 물릴 수 있게 만들어 둔 게 이 단계의 핵심 입니다. 코치는 바로 받아들이고, 나중에 여력이 생기면 같은 스크립트를 그대로 1번으로 옮길 수 있게 파일 구조를 호환되게 잡겠다고 덧붙였어요. 판단은 제 쪽에 두되, 그 판단의 대가는 미리 알려주는 식이었습니다.
대신 이건 제가 제약을 읽고 감수한 거예요. 아침에 맥이 꺼져 있으면 그날 카드는 안 쌓입니다.
2. 목표를 세 줄로 못 박고 일곱 조각으로 쪼갭니다
방향이 정해지자 완료 기준이 문장으로 나왔습니다. 이게 파일에 박혔어요.
9월 9일 스터디에서 실제 주소를 열어 진짜 수집된 카드로 만든 발표를 진행할 수 있다.
카드와 발표가 날짜·회차별로 남아 다시 열어볼 수 있다.
카드에 핵심 내용·실전 팁·원문 링크가 있고 수집이 빈 날에도 페이지가 깨지지 않는다.
그리고 이 세 줄에 닿기 위한 체크포인트 일곱 개가 나왔습니다. 각 체크포인트에는 할 일, 그걸 하는 이유, 쓸 실제 자료, 그리고 통과 조건이 미리 적혀 있어요.
마지막 항목이 제일 중요합니다. "카드 화면을 만든다"가 아니라 이렇게 적혀 있어요.
실제 카드가 화면에 보이고, 빈 날짜도 안내 문구로 깨지지 않으면 끝나요.
뭘 만들지가 아니라 뭘 확인하면 끝인지를 먼저 쓴 겁니다. 시작할 때는 형식적으로 보였는데, 끝에 가서 이 세 줄이 그대로 판정 기준이 됐어요. "된 것 같다"가 아니라 세 줄을 배포된 화면에 하나씩 대고 확인했습니다.
그런데 다 끝나고 보니 더 크게 작용한 건 "이유" 칸이었어요. 일곱 개 중 다섯 개가 "이걸 먼저 안 해 두면 나중에 되돌아온다"는 말이었거든요.
출처마다 형식이 달라서 먼저 갈라두지 않으면 수집기를 만들다 계속 되돌아와요.
요약 전에 원문이 제대로 잡히는지 봐야 카드 품질 문제가 수집 탓인지 요약 탓인지 구분돼요.
배포 전에 눈으로 봐야 간격·정렬·빈 날 처리 같은 문제를 싸게 고쳐요.
손으로 돌리면 며칠 안에 빠지기 시작해요.
혼자 만들었어도 저 자리에 결국 도착했을 겁니다. 다만 순서를 몸으로 배우고 나서 도착했겠죠. 수집기를 절반쯤 만들다 출처 형식이 제각각인 걸 알고 되돌아오고, 카드가 이상한데 수집 탓인지 요약 탓인지 몰라 한참 붙들고요. 코칭이 한 건 그 시행착오를 앞단으로 당겨 미리 없앤 겁니다. 없던 실력을 준 게 아니라요.
3. 통과 조건이 검증 항목을 미리 정해 줍니다
여기가 제일 놀랐던 부분이에요. 통과 조건이 미리 있으니까 검증이 끝나고 하는 요식이 아니라 단계 안에 들어와 있더라고요. 그때그때 시키지 않아도 승인해 둔 조건대로 이런 게 돌아갔습니다.
- 카드에 적힌 숫자 아흔여덟 개를 스크립트로 원문과 대조했어요. 원문에서 그대로 못 찾은 건 네 건인데 전부 한국어 단위로 바꿔 쓴 것이라 값은 같았습니다. 그날 카드 스물세 장 기준이고, 본문을 못 받은 여덟 장은 대조할 수치가 거의 없었어요.
- 출처마다 수집한 건수를 실제 피드·페이지와 나란히 놓 고 맞췄어요. 안 걸린 출처는 로그에 이유가 남고요.
- 카드가 0장인 날짜를 일부러 만들어 넣고 페이지가 깨지는지 봤어요.
- 예약 실행 환경을 실제와 똑같이 비워서 아침 스크립트를 통째로 돌려 봤습니다.
마지막 것에서 진짜가 나왔어요.
📎 launchd는 맥에 기본으로 들어 있는 예약 실행 도구예요. 정해진 시각에 스크립트를 돌려 줍니다. (설명서)
예약 실행은 환경변수를 거의 물려주지 않습니다. 그런데 코딩 에이전트는 USER 값이 있어야 로그인 정보를 읽어요. 그래서 예약으로 돌면 카드 만드는 단계에서 죽습니다. 손으로 돌릴 땐 절대 안 나오는 문제고, 다음 날 아침 여덟 시에야 조용히 드러났을 거예요.
이렇게 나온 버그를 제가 묻기 전에 그쪽이 먼저 들고 왔습니다. 제가 세어 본 기준으로 일곱 개 중 여섯 개고, 자잘한 것까지 넣으면 더 늘어나요. 그중 한 번은 이렇게 말하고 시작하더라고요.
이건 제가 테스트하다가 발견한 제 버그예요.
4. 멈추는 자리마다 되돌릴 기회가 생깁니다
단계가 끝나면 결과와 뭘 어떻게 확인했는지 를 보여주고 멈춥니다. 제가 답해야 다음으로 가요. 멈추는 지점이 일곱 개였고, 저는 네 번 되돌렸습니다.
첫 번째는 출처 조사였어요. 후보 열다섯 곳을 훑어 두 곳이 "못 가져온다"고 나왔는데 납득이 안 돼서 한 번 더 파 보라고 했습니다. 둘 다 살아났어요. 한 곳은 화면만 비어 있었지 데이터가 자바스크립트 파일 안에 그대로 들어 있었고, 다른 한 곳은 원인이 반대였습니다. 브라우저인 척 접근하면 거부당하고, 아무 표시 없이 그냥 요청하면 정상으로 열렸어요. 다만 이 한 곳도 블로그만 살았고 논문 목록은 끝내 못 가져왔습니다.
가장 크게 바꾼 건 그다음이었어요. 화면이 떴는데 카드가 너무 길었습니다. 말로 설명하는 대신 제가 원하는 모양을 직접 써서 보냈더니, 코치도 같은 생각이라면서 진단을 한 겹 더 들어갔어요.
생각이 같아요. 문제는 화면이 아니라 카드 데이터에 있어요.
지금 접힌 카드는 요약, 핵심 내용 첫 줄, 실전 팁 첫 줄을 다 보여줘요. 그런데 핵심 내용의 첫 줄은 "가장 중요한 것"이 아니라 그냥 첫 번째예요.
맞는 말이었어요. 제가 쓴 예시가 정확한 답이라고도 했고요. 그래서 카드에 "이 글에서 무엇이 달라졌는가"를 한 문장으로 쓰는 칸을 새로 만들고, 그날 카드 스물세 장을 전부 다시 만들었습니다. 화면 코드가 아니라 카드를 만 드는 규칙을 고치는 일이었어요.
한 번에 다 만들고 끝에 봤으면 저는 "카드가 좀 기네" 하고 넘어갔을 가능성이 큽니다. 되돌리는 비용이 커 보이니까요. 네 번째 자리에서 멈춰 서 있었기 때문에 고칠 수 있었습니다.
결과
두 화면이 돌아갑니다. 아침에 쌓인 카드를 훑어 발표할 것을 고르고, 고른 카드로 만든 발표를 스터디에서 같은 주소로 열어요.
제 첫 답변부터 마지막 체크포인트 결과를 받기까지 세 시간 사십육 분이 걸렸습니다. 중간에 제가 자리를 비운 시간이 포함된 값이라 순수 작업 시간은 이보다 짧아요. 앱 코드는 CSS를 빼면 천 줄이 안 되고, 커밋은 열 개입니다. (다음 날 아침 자동 실행이 만든 커밋까지 열한 개예요.)
따로 드는 API 비용은 없습니다. 대신 구독 사용량을 쓰는데, 실제로 작업 중간에 월 한도에 걸려 세션이 한 번 끊겼어요.
그리고 9월 4일 아침, 예약 시각에 실행 로그가 처음 남았습니다. 여덟 시 정각에 열세 곳을 훑어 열두 건을 새로 잡고 카드 열두 장을 만들었어요. 그중 다섯 건은 본문을 못 받아 요약만으로 카드가 됐고요. 수집이 13초, 카드 생성이 4분 48초 걸렸습니다.
남은 것
전제와 부딪히는 게 하나 있습니다. 수집이 제 맥에 묶여 있어요. 잠들어 있으면 깨어난 뒤 저절로 돌지만 완전히 꺼져 있던 날은 손으로 채워야 합니다. 스터디원과 나눠 쓰는 자동화는 아직 아니에요.
확인한 표본은 하루치 카드 스물세 장입니다. 며칠 쌓였을 때 화면이 어떻게 되는지는 아직 못 봤어요.
그리고 조용히 어긋나는 것들은 멈춰 서도 안 보였습니다. 첫 자동 실행은 다섯 단계 중 배포에서 멈췄는데, 스크립트가 로그에 이유를 남겨도 제가 열어 봐야 압니다. 날짜를 세계 표준시로 잡아 아침 실행이 늘 전날 파일에 쓰던 것도 그랬어요. 이건 발행 전에 다른 모델 둘에게 이 글을 반박해 보라고 시켰다가 나왔습니다. 둘 다 화면이 안 깨져서 눈에 안 띄던 것들이에요. 지금은 고쳐서 배포했습니다.
AI 활용 팁!
이 방식은 코칭 없이도 흉내 낼 수 있어요. 순서는 이렇습니다.
하나, 만들기 전에 완료 기준을 세 줄로 씁니다. "다 만들어줘"로 시작하면 끝에 가서 "이게 다 된 건가"를 감으로 판단하게 돼요. 세 줄만 미리 적어 두면 그게 판정 기준이 됩니다.
둘, 단계마다 "뭘 확인하면 끝인지"를 먼저 씁니다. 통과 조건이 있으면 검증 항목이 미리 정해져서 나중에 고르지 않아도 돼요. 이번에 예약 실행 환경에서 죽는 문제를 미리 잡은 게 이 항목 덕분입니다.
셋, 중간에 멈추게 합니다. 되돌리는 비용은 뒤로 갈수록 커져요. 저는 네 번 되돌렸는데, 몰아서 만들었으면 몇 개는 그냥 넘어갔을 것 같아요.
매일 도는 리포트, 반복되는 요약, 정기 점검처럼 결과물이 계속 쌓이는 일이면 적용해 볼 만합니다.
그런데 이 방식이 제일 도움이 될 사람은 따로 있는 것 같아요. AI를 이제 막 자기 업무에 붙여 보려는 분이요. 저는 코딩 에이전트를 쓸 줄 알아서 헤매도 결국 빠져나옵니다. 그런데 처음이면 헤매는 자리에서 그냥 멈추기 쉬워요. 뭘 만들지가 흐릿한 채로 "알아서 만들어줘"라고 하게 되고, 나온 걸 봐도 이게 맞는지 판단할 기준이 없으니까요.
코칭이 하는 건 그 세 가지를 먼저 세워 주는 겁니다. 만들 것을 문장으로 좁히고, 한 번에 다 하지 않게 끊고, 뭘 보면 됐다고 할지 정해 줘요. AI를 잘 쓰는 법을 가르친다기보다 헤맬 자리를 미리 치워 주는 쪽에 가깝습니다. 저한테는 시간이 줄어드는 일이었는데, 처음 하는 분한테는 시작하느냐 마느냐가 갈리는 일일 것 같아요.
솔직히 말하면 저 혼자 했어도 앱은 나왔을 거예요. 코칭이 없으면 못 할 일은 아니었습니다. 다만 훨씬 많이 헤맸을 거고, 같은 구조와 품질이 나왔을지도 모르겠어요. 달라진 건 결과물이 아니라 헤맬 자리를 앞단에서 얼마나 걷어냈느냐였습니다.
바로 쓸 수 있는 프롬프트
지금부터 [만들 것]을 함께 만들 건데, 바로 시작하지 말고 아래 순서로 가 주세요.
1. 제가 가진 재료와 지금 상태를 먼저 물어보세요. 한 번에 하나씩만요.
2. 방향을 2~3개 제안하고 각각 의 장점과 제약을 적어서, 제가 고르게 해주세요.
3. 방향이 정해지면 완료 기준 3줄과 단계별 통과 조건을 먼저 써 주세요.
4. 단계마다 결과와 무엇을 어떻게 확인했는지를 보여주고 멈추세요. 제가 답해야 다음으로 갑니다.
5. 확인은 실제 자료로 하세요. 잘 되는 경우 말고 비어 있는 경우, 실패하는 경우도 만들어 돌려 보세요.
6. 자동화를 붙인다면 실제와 같은 환경으로 미리 돌려 보세요.
[만들 것]은 본인 상황에 맞게 바꾸세요. 3번의 완료 기준은 AI가 써 준 걸 그대로 받지 말고 직접 고쳐서 확정하는 편이 좋습니다.
지난 글에서 가상 학습자에게 시켰던 과제가 "뉴스 대시보드 하나"였는데, 이번엔 그걸 제가 직접 만들게 됐네요. (코딩이 빨라진 만큼 QA도 빨라져 보자)
