AI를 잘 쓰고 있다는 착각, 그리고 그걸 확인하는 법

AI를 쓰면서 잘 되고 있다고 느낄 때, 그게 내 실력인지 모델이 좋아진 건지 구분하기 어렵습니다.
지난 1년간 제가 했던 두 가지 착각과, 그걸 실제로 재본 방법을 이야기합니다.

Transcript

1. AI를 잘 쓰고 있다는 착각, 그리고 그걸 확인하는 법 지금 잘 되는 게 내가 잘해서인가, 모델이 좋아져서인가 하동현 Android · 9 년차
2. 차례 오늘 이야기할 순서 01 02 03 04 05 우리는 AI를 잘 쓰고 있다고 착각한다 착각의 두 가지 형태 어떻게 재나 그래서 어떻게 하나 내일부터 뭘 하면 되나
3. 먼저 짧은 이야기 하나 사무실에 PC가 들어왔을 때 그때 스프레드시트는 프로그램이 아니라 세로줄 그어진 큰 종이였다 1980년 지금 이제 회계사는 없어지겠네 회계사는 그때보다 많다
4. 그런데 다같은 도구살아남은 건 아니다 앞에서 갈렸다 잃은 쪽 숫자 채워 넣고 계산식 쓰는 것만 할 줄 알았다 일자리가 없어진 게 아니라 일하는 방식이 바뀐 것이다. 우리도 지금 그 갈림길에 있다. 그러면 우리는 어느 쪽인가. 남은 쪽 그 도구로 사업 계획을 세울 줄 알았다
5. 01 우리는 AI를 잘 쓰고 있다고 착각한다
6. 착각이 만들어지는 경로 네그런데단계를 거쳐 결론에 도달했다 마지막 단계를 검증한 적이 없다 01 타임라인을 본다 "만들었습니다" · "자동화했습니다" 02 나도 만든다 스킬 · MCP · 에이전트 03 결과물이 눈에 보이게 늘어난다 세어볼 수 있는 것들 04 잘 쓰고 있다 — 라고 느낀다 여기서 멈췄다. 이 단계를 검증한 적이 없다
7. 이게 정말 내가 잘 써서 된 건가? 아니면 그냥 모델이 좋아진 건가? 한 번도 나눠서 확인해본 적이 없었다
8. 범위 차이는 실재한다 따져볼 건 그 차이가 얼마나 오래 가느냐다 차이 같은 도구를 줘도 사람마다 결과가 다르다 내년이면 사라질 것 ? 모델이 좋아지면 값이 없어진다 그때도 남을 것 모델이 따라잡기 어려운 자리 나는 어느 게 어느 건지 모른다. 나눠본 적이 없다. 오늘 하려는 게 그 구분이다.
9. 그 구분을 하려고 보니 먼저 걸리는 게 있었다. 내가 뭘 착각하고 있었는지부터 알아야 했다
10. 02 착각의 두 가지 형태
11. 착각 1 만들 때가 제일 재미있다 그래서 만든 것 중에 지금도 쓰는 게 몇 개인지는 세지 않았다 들인 공 지금 쓰는 정도 성능까지 재서 개선했다 성능이 아니라 그 일이 자주 안 생긴다 제일 많이 거의 안 쓴다 최대 품질과 사용 여부는 별개다. 성능은 쟀는데 "지난달에 이 일이 몇 번 있었지"는 세지 않았다. 거의 0
12. 착각 1 — 그럼 언제 만드나 만들지 말라는 얘기가 아니다 만들기 전에 묻는 건 이 둘뿐이다 1 2 이걸 몇 번 쓸 건가 만들면서 뭘 처음 해보나 둘 중 하나만 답할 수 있어도 만든다 둘 다 "글쎄"면 하나만 통과해도 만든다. 도구가 안 쓰여도 배운 건 남으니까. 둘 다 "글쎄"면 이미 아는 방식으로 하나 더 찍어낼 뿐이다. 그땐 정말 목록만 늘어난다. 안 만든다
13. 착각 2 손에 익은 곳부터 자동화한다 막히는 곳은 대개 남의 영역처럼 보인다 내가 자동화한 곳 실제로 늦어지던 곳 제일 손에 익은 자리 기획이 안 정해져서, 뭐가 되는지 몰라서 물어보고 기다리는 시간 코드 대기 여기서 새던 시간 이미 빠른 곳을 더 빠르게 만들고 있었다. 늦어지던 쪽은 내 영역이 아니라고 생각해서 안 건드렸다. 정작 여기
14. 느낌 말고 근거를 갖고 정하자. 그런데 근거를 대려면 먼저 정해야 했다 — 대체 뭘 보고 재나
15. 03 어떻게 재나
16. 판별 질문 다섯 답이 "글쎄"면, 그건 아직 도구가 아니다 1 2 3 4 5 이번 주에 몇 번 썼나 없을 때 대비 뭐가 줄었나 결과를 검증할 방법이 있나 이어서 봅니다 내가 붙어 있어야만 도나 이걸 빼면 뭐가 달라지나 이어서 봅니다 안 쓰면 없는 거다. 품질과 사용 여부는 별개다 "편해졌다"만 있고 줄어든 게 없으면 도구가 아니라 취미 AI 결과는 틀려도 그럴듯한 게 기본값이다 내가 봐줘야 돌아가면 도구가 아니라 내 습관 빼봐야 내 몫이 얼마인지 알 수 있다
17. 질문 3 결과를 검증할 방법이 있나 모르는 걸 모른다고 말하게 만드는 것 내가 옆에 없는 상태에서 답이 나간다 이 도구가 놓인 자리 기획자가 묻는다 — "이거 서버에서 되나요" 도구가 판정하고, 나는 그 자리에 없다 아는 척 잘하면 모른다고 말하면 그 자리에 틀렸다고 말해줄 사람이 없다 이걸 핵심 산출물로 뒀다 틀려도 그럴듯하다 "확인 필요" 모르는 걸 모른다고 말하게 만드는 것이, 아는 척 잘하게 만드는 것보다 중요했다.
18. 질문 5 이걸 빼면 뭐가 달라지나 기여를 네 축으로 나눠 본다 "결과가 같으면 기여 0"이라고 하면 너무 거칠다 — 결과는 넷 중 하나일 뿐이다 결과 신뢰 비용 재현 답 자체가 달라졌나 틀렸을 때 알 수 있게 됐나 훨씬 싸게 얻게 됐나 내일 해도 같은 답인가 틀리던 게 맞게 나온다 답이 같아도 이건 기여다 백분의 일이면 다른 일이다 운이 아니라 절차가 된다 넷 중 하나라도 달라졌으면 내 몫이다. 하나도 안 달라지면 — 그건 모델이 하고 있던 일이다.
19. 04 그래서 어떻게 하나
20. "이거 어때?"라고 물은 순간 좋고 나쁨의 기준을 넘긴 것이다. 고치는 건 내 손으로 하니까 내가 주도한다고 느낀다. 근데 방향은 내가 정한 게 아니다
21. 내가 자주 하던 질문 이렇게 물으면 기준이 딸려 간다 "이거 어때?" 답이 판정으로 온다 셋 다 빈손으로 물었다. "괜찮은지 봐줘" 기준이 딸려 간다 내가 아무것도 정하지 않은 채로 물으면, 좋고 나쁨의 기준까지 같이 넘어간다. "내 생각 맞아?" 대개 맞다고 한다
22. 원칙 0 덜나머지쓰는 게 아니다 — 판정만 빼고 더 많이 시킨다 원칙이 전부 여기서 나온다 선택지를 넓힌다 "다른 방식 3개를 내고, 각각 뭘 포기했는지 적어줘" 내 기준을 적용한다 "이 기준으로 전부 훑고 어긋난 데를 짚어줘" 셋 다 내가 먼저 뭔가를 정한 다음에 시킨다. 셋째가 특히 그렇다 — 내가 만든 걸 내가 재면, 반드시 유리하게 잰다. 내 판단을 반박한다 "나는 A로 정했다. 이게 틀렸다면 왜인지 찾아줘"
23. 원칙 1 프롬프트를 잘 쓰려고 하지 않는다 프롬프트는 대화가 끝난 뒤에 나오는 산출물이다 짧게 던진다 처음부터 공들이지 않는다 결과를 보고 "그게 아니라" 틀린 데를 그때 짚는다 그제서야 정리를 시킨다 "지금까지 맞춘 내용을, 다음에 그대로 쓸 수 있는 프롬프트로 정리해줘" 몇 번 반복 AI는 자기가 어디서 헷갈렸는지를 안다. 예측해서 미리 막는 게 아니라, 겪은 다음에 적는다.
24. 원칙 2 기술이 아니라 반복에서 출발한다 기술이 출발점일 때 "새 기능이 나왔네 — 이걸로 뭘 해볼까" 이렇게 시작한 건 거의 다 실패했다. 바꾸면 짜증이 출발점일 때 "문서가 쌓여서 못 찾겠다" · "규칙을 적었는데 안 지켜진다" 정책 문서랑 코드가 어느새 달라져 있다 — 이런 것들에서 시작한 건 남았다.
25. 원칙 2 — 세는 단위 한 단어를 바꾸니 목록이 달라졌다 내가 반복하는 일 내 앞에서 반복되는 일 내가 하는 일만 세면 내 손에 익은 것만 나온다. 앞에서 반복되는 걸 세니 남이 나한테 계속 물어보는 것이 목록에 들어왔다.
26. 원칙 3 기준을 안 주면 평균값이 나온다 디자인에서 가장 명확하게 보인다 "이런 앱 화면 만들어줘" → 어디서 본 것 같은 화면. 못 만든 게 아니라 가장 흔한 답을 넣은 것이다 먼저 이야기 누가 쓰나 · 어떤 느낌이어야 하나 그다음 여기서 나온다 디자인 시스템 색 · 여백이 왜 그런지가 정해진다 티가 나는 자리는 거의 둘이다 — 여백과 문구. 둘 다 "무엇이 한 덩어리인지 · 어떤 말투인지"를 안 정해준 결과다. AI 잘못이 아니다. 마지막 여기서 나온다 화면 같은 모델인데 결과가 완전히 달라졌다
27. 원칙 4 한양쪽 끝이번에 많이 시키지 않는다 다 함정이다 너무 크면 내가 다 못 읽는다 쪼갠 게 아니라 미룬 것이다 알맞으면 한 번에 판단할 수 있다 틀려도 그 덩어리만 버리면 된다 너무 잘면 맥락을 매번 다시 설명한다 그게 더 비싸다
28. 원칙 5 문서로 시작해서 문서로 끝낸다 대화는 사라지고 문서는 남는다 01 spec — 무엇을 만들 건가 02 plan — 어떤 순서로 만들 건가 03 구현 04 진척 — 어디까지 됐나 요구사항을 먼저 고정한다 PR 단위로 쪼갠다 한 덩어리씩 — 내가 다 읽을 수 있는 크기로 같은 문서에 다시 기록된다
29. 원칙 5 — 실제 P L A N 문서 이어받는 쪽이 읽을 수 있는 형태로 무엇이 무엇에 걸려 있고, 각각 어디까지 됐는지 새 대화를 열어도 이 문서만 주면 이어서 일한다. 기록이 아니라 인수인계다 — 다음에 읽는 게 내가 아니라 다음 세션의 AI다.
30. 원칙 6 한코드 위치는문서판단 재료가 안에서도 사람이 읽을 것만 남긴다 아니다 — 접어서 내린다 평소 — 접혀 있다 좌표를 본문에 펼쳐두면 판단 재료가 묻힌다. 지운 게 아니라 접은 것이다 — 검색은 그대로 된다. AI가 열면 — 파일 · 줄 · 심볼
31. 여기까지가 제 방식이다. 그대로 가져가시면 안 된다. 왜 그런지가 마지막 장이다
32. 05 내일부터 뭘 하면 되나
33. 먼저 함정 하나 남의 방식을 그대로 쓰면 하네스 엔지니어링 — 안다고 끝나는 게 아니다 01 잘 만든 구성이 공유된다 02 그대로 가져온다 03 안 맞아도 못 고친다 규칙 파일 · 스킬 · 훅 그 사람 일하는 방식에 맞춰 만들어진 것이다 내가 왜 그렇게 하는지 모르니까 이건 또 타임라인 보고 따라 만드는 것이다. 1장에서 시작한 그 자리로 돌아온다.
34. 추인과 판단 판단하려면 알아야 한다 "사람은 판단에 들어간다"는 말은 듣기엔 좋다 기준이 없으면 기준이 있으면 왜 괜찮은지 모르면서 도장만 찍는다. 그래서 "이거 어때?"라고 묻게 된다 이미 뭘 볼지 알고 있다. 그래서 물을 이유가 없다 추인 기준을 넘기는 건 대개 넘길 기준이 없어서 생긴다. 판단 그래서 시간을 쓰는 곳을 옮겼다 — 코드를 빨리 짜는 연습이 아니라 설계를 보는 눈 쪽으로.
35. 그럼 어디서 기르나 못하는 분야에서 연습한다 섞여 있는 걸 사후에 갈라내긴 어렵다 잘하는 분야 — 안드로이드 못하는 분야 — 디자인 · 영상 결과물은 괜찮게 나온다. 그런데 AI를 잘 쓴 건지 내가 고쳐서인지 구분이 안 된다 오로지 어떻게 다루느냐로만 결과가 갈린다. 유일하게 순수한 연습 환경 손으로 고쳐버린다 고칠 수가 없다 AI가 잘 못하는 분야일수록 좋다. 잘하는 분야는 한 번에 나와버려서 배울 게 없다. 열 번을 시켜야 나오는 쪽에서, 어떻게 말해야 원하는 게 나오는지를 배운다.
36. 빨라진 게 아니라 빨라진 것처럼 보이는 상태가 된다. 안 보고 넘어간 것들이 쌓이면 그렇게 된다
37. 남는 자리 모델이 따라잡기 어려운 세 자리 지금 잘한다고 생각하는 것 중에도 내년이면 값이 사라질 게 있다 01 무엇을 만들지 정한다 02 나온 결과가 맞는지 판별한다 03 무엇을 남길지 고른다 내 앞에서 반복되는 일에서 틀려도 그럴듯하니까 늘어난 만큼 다 보고 있나 오늘 말씀드린 건 제 방식이지 정답이 아닙니다. 저도 계속 바꾸고 있고요. 그러니 이걸 그대로 가져가시기보다는, 각자 자기 방식을 만들어보시길 권합니다.
38. 도구는 계속 바뀝니다. 바뀌지 않는 건 무엇을 받아들일지 정하는 자리입니다. 오늘 드리고 싶은 말은 그게 전부입니다