[① 어떤 상황에서 AI를 활용했나요?]
기획하고 결정하는 일을 십수년 해 왔다. 늘 느낀 것은 이 일의 병목이 판단에 있다는 점이었다.
문서를 읽고, 사양이 서로 어긋나지 않는지 대조하고, 회의에서 나온 말을 결정으로 바꾸고,
그 결정이 앞의 결정과 충돌하지 않는지 확인한다. 만드는 시간보다 확인하는 시간이 길다.

처음에는 AI를 "글을 대신 써 주는 도구"로 썼는데 오래가지 못했다.
초안은 빨라졌지만 확인할 것이 오히려 늘었기 때문이다.

방향을 바꾼 계기는 단순했다. AI에게 "AI를 어떻게 쓰면 되느냐"고 물어본 것이다.
"이런 일을 하려는데 너를 어떻게 쓰면 잘 쓰는 거냐"고 물었다.
그때부터 도구 사용법을 스스로 궁리하는 대신 모르는 것을 전부 AI에게 묻기 시작했다.

그렇게 쓰다 보니 양이 빠르게 늘어, 한 주에 700억 토큰을 넘긴 적도 있다.
많이 쓰는 것 자체는 성과가 아니다. 많이 시키면 많이 틀리고,
많이 틀리면 되돌릴 장치가 필요해진다. 아래는 그 장치를 만들며 쌓인 노하우다.

[② 어떤 AI를 어떻게 활용했나요?]
하나. 모르는 것을 전부 묻는다

하고 싶은 것만 분명하면 된다. "○○할 건데 너를 어떻게 쓰면 잘 쓰는 거냐"로 시작하면,
도구 사용법을 먼저 익히느라 늦어질 일이 없다.
지금까지 바꾼 습관 중 가장 크게 효과를 본 것이고, 남에게 권할 수 있는 첫 단계다.

둘. 규칙을 계층으로 나누고, 한 장을 500자 안에 맞춘다

규칙을 한 곳에 몰아 두면, 어떤 일을 하든 그 전부를 지고 시작하게 된다.
그것만으로 실제 일에 쓸 여력이 사라진다. 그래서 세 층으로 나눴다.

· 맨 위: 사람과 환경에 관한 사실, 모든 일에 공통인 규칙만
· 가운데: 그 일(프로젝트)의 규칙 색인
· 아래: 규칙 본문을 주제별로 쪼갠 파일들

내리는 기준은 하나다. "다른 일에서도 이게 참인가?" 아니면 아래층으로 내리고,
같은 규칙이 두 층에 겹치면 아래층에서 지운다.

여기에 하나를 더 걸었다. 한 규칙 파일이 500자를 넘지 않게 하고, 넘으면 쪼갠다.
길어진 규칙은 끝까지 읽히지 않고, 끝까지 읽히지 않는 규칙은 없는 규칙과 같다.
글자 수 제한을 둔 뒤로 규칙이 지켜지는 비율이 눈에 띄게 올라갔다.

셋. 자주 어기는 규칙은 자동 검사로 강제한다

몇 번을 적어 놔도 반복해서 어기는 규칙이 있다. 그런 것은 글로 두지 않고 검사로 바꾼다.
정해 둔 순간(파일을 고칠 때, 명령을 내릴 때)에 자동으로 끼어들어 확인하고,
어겼으면 그 자리에서 막는 장치를 붙일 수 있다.

다만 이걸 전부에 걸면 안 된다. 이 검사는 늘 켜져 있어서, 넓게 걸수록 모든 작업이 느려진다.
그래서 지금은 집중할 작업 한 가지에만, 조건을 좁혀서 건다.
지킬 것이 많다고 검사를 늘리면 오히려 일 전체가 느려져 결국 아무도 안 쓰게 된다.

넷. 모델을 하나로 고르지 않고 서로 부르게 해 둔다

모델마다 잘하는 것이 다르다. 그래서 하나로 다 하지 않는다.
· 전체 지휘, 파일 읽고 쓰기, 3D·화면 만들기 : Claude Code
· 이미지 생성, 컴퓨터 화면을 직접 보고 조작하기 : Codex
· 5회를 시도해도 안 풀리는 문제 : 고추론 모델 (배제한 방법 목록을 함께 준다)
· 사실 대조 : 공개 API로 받은 원문

편리한 점은 이 판단을 사람이 매번 하지 않아도 된다는 것이다.
프롬프트 한 번이면 지휘하는 모델이 스스로 "이건 저쪽이 낫다"고 판단해 불러서 쓰고,
받아 온 결과를 이어서 처리한다. 지시하는 쪽은 무엇을 원하는지만 말하면 된다.

다섯. 위임하되 한도를 준다

한 번에 하나씩 묻지 않고 여러 갈래로 나눠 동시에 굴린다. 나누는 것 자체가 이득이지만,
한도가 없으면 안 된다.

한 번은 조사 ai를 6갈래로 나눴는데 그 여섯이 각자 또 갈래를 쳐서 스무 개가 됐다.
사용량 한도를 다 태우고 결과는 하나도 건지지 못했다.
그래서 지금은 굴릴 때마다 이렇게 건다.

1. 동시에 굴릴 수 있는 개수의 상한 (예: 다섯)
2. 각 갈래가 쓸 수 있는 자원의 상한 (예: 웹 검색 100회 / 40회)
3. 중간 결과를 그때그때 파일에 쓸 것. 다 끝내고 한 번에 쓰지 못하게 한다

3번이 특히 중요하다. 위 사고에서 아팠던 것은 한도를 태운 것보다
아무것도 남지 않았다는 것이었기 때문이다.

여섯. "맞느냐"고 되묻지 않고 원본을 직접 연다

검토를 시키면 대체로 "맞다"고 하는데, 확인이라기보다 동의에 가깝다.
그래서 1차 자료를 직접 연다. 아래 ③의 오류 5건은 법제처 「국가법령정보 공동활용」
공개 API로 받은 법령 원문으로, 치명적 4건은 그 제품의 공식 상점 페이지·공식 위키와
국립국어원 표준국어대사전 원문으로 잡았다.
출처는 달라도 방법은 하나다. AI에게 되묻지 않고 원본을 직접 열었다.

일곱. 판단이 바뀌면 그 자리에서 문서를 고친다

나중에 몰아서 고치면 그 사이에 틀린 문서를 근거로 다음 결정을 내리게 된다.

[③ 활용 결과 어떤 변화가 있었나요?]

첫째, 필요한 도구를 사서 쓰지 않고 만들어 쓰게 됐다.
회사에서 필요한 도구 대부분을 직접 만들어 쓴다. 프로그래머에게 기획서를 전달하고, 구현을 기다리고, 사용법을 가이드받기 까지 며칠이 걸리던 일을 그 자리에서 완성시킬 수 있게 되었다.
회사 보안상 세부 사항은 말할 수 없지만 생활에서도 마찬가지여서, 식물 물주기 관리 앱은 오후에 시작해 그날 저녁부터 썼다.
폴더를 만든 시각과 첫 배포본 시각이 2시간 35분 차이다.
AI 사용량 확인 앱은 이틀 만에 첫 판이 나왔고, 단어 공부 앱은 지금도 매일 손보며 쓴다.
쓰다가 불편하면 그날 고친다. "내 손에 맞는 도구"의 기준이 달라졌다.

둘째, AI가 쓴 문장에서 틀린 것을 잡아내게 됐다. 세 가지가 기억에 남는다.
- 법에 걸리는 줄 몰랐던 설계.
어떤 제안서에서 통신사가 이용자의 문자를 대신 받아 처리하는 흐름을 짰다. 읽기에는 그럴듯했다. 그런데 법령 원문을 직접 열어 보니 그 흐름 자체가 통신비밀보호법에 걸렸다. 설계를 통째로 뒤집었다.
앞서 AI에게 "법에 문제 없느냐"고 물었을 때는 문제없다는 답을 받았다.
같은 제안서에서 인용 26건을 법령 원문과 하나씩 맞춰 보니 5건이 틀려 있었다.
- "없다"고 단정한 기능이 이미 있었다.
다른 글에는 "지도 앱은 이 질문에 답해 주지 않는다"고 썼는데,
확인해 보니 계단을 피해 가는 길찾기가 이미 몇 해 전에 들어와 있었다.
검색 한 번이면 드러날 것을 그럴듯하다는 이유로 넘어갈 뻔했다.
- 결과는 맞는데 과정 설명이 틀렸다.
자료를 거르는 프로그램이 그 자료보다 다섯 시간 먼저 만들어져 있었다. 곧 그 프로그램은 그 자료를 읽은 적이 없다.
글에는 프로그램이 걸러 냈다고 적혀 있었다. 파일이 만들어진 시각을 나란히 놓고서야 보였다.
글 한 편을 통째로 검증했을 때는 사실 주장 33건 가운데 10건을 고쳤고, 그중 4건은 그대로 냈으면 안 될 것이었다.
흥미로운 것은 학술 인용이 서지사항도 수치도 전부 원문과 맞았다는 점이다.
틀린 쪽은 반대였다. AI가 가장 자신 있게 쓴 "누구나 아는 사실"에서 틀렸다.

셋째, 안내 문서의 문장이 바뀌었다.
예전에는 복잡한 소프트웨어를 쓰려면 설치·실행 방법을 단계별로 적어 줘야 했다.
지금은 그 문서에 이렇게 쓴다. "AI에게 '○○ 설치하고 실행해 줘'라고 입력하세요."
설명서가 줄어든 게 아니다. 설명서가 필요한 자리가 옮겨 갔다.

[④ 나만의 방식 / 개선 포인트]
하나. 도구를 고르는 일보다 쓰려는 의지가 훨씬 크게 갈랐다.
"이건 내가 하던 일이니 내가 하는 게 확실하다." 이 말은 대개 맞다.
오늘 하루만 놓고 보면 사람이 하는 편이 빠르고 정확하다.
문제는 그 판단이 내일도, 반년 뒤에도 같은 결론을 낸다는 데 있다.

그 일을 AI가 확실하게 해내도록 다듬는 데는 수개월이 걸린다.
다듬는 동안은 손해처럼 보이고, 실제로 손해다. 다만 한 번 되고 나면
그 일에 쓰던 시간이 통째로 다른 일로 넘어간다. 사람이 더 중요한 것을 보게 된다.
이 계산을 받아들인 사람과 그렇지 않은 사람 사이에서 반년 뒤의 차이가 벌어진다.
도구를 잘 고르는 것보다 이쪽이 훨씬 크게 갈랐다.

둘. 700억은 자랑할 수치가 못 된다. 조건에 가깝다. 위의 일곱 가지는 전부
많이 틀리는 것을 되돌리려고 생긴 장치다. 많이 쓸수록 틀린 것이 섞여 들어오고,
섞여 들어온 것을 걸러 내지 못하면 규모는 그대로 손해가 된다.

셋. 성능을 올리려 하지 말고, 한계를 인정하고 그 둘레를 짠다.
AI가 길게 이어지는 일에서 앞에 정한 것을 잊는다는 것은 지금 시점에 풀리지 않은 문제다.
모델을 바꿔서 풀 문제가 아니므로 구조로 메운다. 위의 둘·셋·다섯이 그것이다.

넷. 가장 크게 배운 것은 마지막에 나왔다.
검증이 한 번 잡아 고쳐 놓은 문장이, 고친 뒤에도 여전히 틀려 있었다.
그 분야를 오래 해 온 사람(그것을 수천 시간 넘게 해 본 사람)의 눈에는 단번에 보였다.
처음 쓴 AI도 틀렸고, 검증한 AI도 틀렸고, 고친 AI도 틀렸고, 잡은 것은 사람이었다.
그만큼 쓰고 얻은 결론이 "사람이 마지막에 봐야 한다"는 것이라면 허무해 보이지만,
크게 굴려 봤기 때문에 그 자리가 정확히 어디인지 알게 됐다.

[⑤ 다른 사람도 따라 할 수 있나요?]
700억 토큰을 쓰지 않아도 그대로 된다. 위의 일곱 가지는 사용량과 무관하고,
오히려 적게 쓰는 사람일수록 효과가 크다.
한 번의 대화로 끝내는 사람이야말로 틀린 문장 하나를 그대로 들고 갈 위험이 가장 크다.

오늘부터 할 수 있는 순서는 이렇다.

1. "○○할 건데 AI 어떻게 쓰면 좋아?"를 AI에게 물어본다. 여기서 시작한다.
2. 규칙을 두 층으로만 나눠 본다. 어디서나 참인 것과 이 일에서만 참인 것.
그리고 한 장을 500자 안에 맞춘다. 넘으면 쪼갠다.
3. AI가 인용한 것 딱 하나를 원문으로 확인해 본다. 한 건만 해 보면 값어치가 바로 보인다.
4. 일을 두 갈래로 나눠 동시에 굴려 보고, 각 갈래에 한도를 걸어 본다.
그리고 중간 결과를 파일에 쓰게 한다. 대화창은 사라지지만 파일은 남는다.
5. 세 번 넘게 어긴 규칙이 있으면 그것만 자동 검사로 바꾼다. 한 가지부터, 좁게.

그리고 하나 더. "이건 내가 해야 확실하다"고 생각한 일을 딱 하나 골라 AI에게 맡겨 본다.
처음에는 분명히 더 오래 걸리고 결과도 못하다. 그 구간을 지날 생각이 있느냐가
도구를 무엇으로 고르느냐보다 결과를 크게 바꾼다.

장치를 먼저 만들면 훨씬 적게 쓰고도 같은 곳에 닿는다.
나는 그 장치를 만드느라 700억 토큰까지 썼지만, 그 길을 다시 갈 필요는 없다.