목차06
수정
AI를 잘 쓰는 방법을 찾아보면 할 일이 계속 늘어난다.
프롬프트를 바꿔야 하고, 문서를 정리해야 하고, 에이전트를 나눠야 한다. 누군가는 작업을 잘게 쪼개라고 하고, 다른 사람은 크게 맡겨야 한다고 말한다.
둘 다 그럴듯하다.
그럼 나는 무엇을 따라야 할까?
처음에는 더 좋은 방법을 고르면 될 것이라 생각했다. 그런데 자료를 읽을수록 그 방법이 나온 조건을 알아야 한다는 생각이 들었다.
혼자 작은 기능을 만드는 사람과 여러 저장소를 운영하는 팀은 같은 문제를 겪고 있지 않았다. 자료를 수집하는 일과 서로 연결된 코드를 수정하는 일도 달랐다.
나는 이 차이를 놓치지 않기 위해 원문을 읽으려 한다.
1. 원문을 읽는다고 자동으로 더 잘 알게 되지는 않는다
요약은 쓸모가 있다. 어떤 자료를 읽어볼지 고르는 데도 도움이 되고, 긴 글의 구조를 먼저 이해할 수도 있다.
문제는 요약에서 얻은 결론을 그대로 내 작업의 기준으로 삼을 때다.
왜 그 방법을 선택했는지. 무엇을 해봤는데 잘되지 않았는지. 어떤 상황에서는 쓰지 말라고 했는지.
이런 조건이 빠지면, 나는 다른 사람의 답을 가지고 내 문제를 풀게 된다.
원문이라고 모두 옳은 것도 아니다. 제작자의 글은 자신의 경험이고, 공식 설명에는 제품을 소개하려는 목적도 있다. 논문을 공개한 저장소에 올라왔다고 모두 동료 검토를 마친 연구인 것도 아니다.
그렇기에 출처를 본 뒤에도 판단은 남는다.
2. 실제로 어떻게 일하는지 보여주는 글
Simon Willison의 글에서 참고한 것은 LLM을 만능 개발자로 취급하지 않고, 실제 코드와 확인 가능한 결과를 놓고 일하는 태도였다.[1]
내게 필요한 질문도 비슷했다.
AI가 할 수 있다는 설명을 들었는가, 아니면 내 작업에서 돌아가는 것을 봤는가?
이 둘을 구분해야 다음에 무엇을 맡길지도 정할 수 있다. 어떤 작업에서 잘됐다는 경험이 다른 작업의 보증이 되어서는 안 된다.
Harper Reed의 작업 방식에서는 스펙을 정리하고, 실행 계획을 나누고, 순서대로 구현하는 흐름을 참고했다.[2]
여기서 내가 중요하게 본 것은 파일 이름이 아니다. 구현을 시작하기 전에 무엇을 만들지 대화로 구체화하는 과정이다.
spec.md라는 파일이 있다고 기획이 끝난 것은 아니다. 문서 안에 내가 정하지 않은 선택이 그럴듯하게 채워져 있다면, 먼저 그 부분을 봐야 한다.
나는 AI가 정리한 문서를 읽으면서도 묻고 싶다.
이것은 내가 원한 것인가, 아니면 빈칸을 채우기 위해 만들어진 것인가?
3. 에이전트를 늘리면 무엇이 달라질까
Anthropic의 멀티 에이전트 연구 시스템 글에서는, 병렬로 자료를 찾는 작업과 서로 강하게 얽힌 작업을 구분해서 읽었다.[3]
자료를 각기 다른 방향에서 수집하는 일은 나눌 수 있다. 하지만 같은 파일을 동시에 고치거나, 서로의 중간 결과를 계속 기다려야 하는 작업은 조정이 필요하다.
그러니 내가 물어야 할 것은 ‘몇 명의 에이전트를 쓸까’ 이전에 있다.
이 일은 무엇을 기준으로 나눌 수 있는가? 결과는 어디에서 합칠 것인가? 서로 다른 결론이 나오면 무엇으로 판단할 것인가?
이 구분 없이 역할만 늘리면 사람이 읽어야 할 보고서가 많아질 수도 있다.
반대로 작업을 제대로 나눌 수 있다면 굳이 한 에이전트가 모든 일을 순서대로 하도록 묶을 이유도 없다. 나에게 필요한 것은 숫자에 대한 취향이 아니라, 실제 업무에 맞는 분리다.
- 어떤 문제를 다뤘나
- 자료를 서로 다른 방향에서 수집하는 일과, 강하게 얽힌 작업을 구분한다.
- 내 조건은 무엇이 다른가
- 이번 일은 자료 수집인가, 같은 파일을 고치는 일인가? 서로의 중간 결과를 기다려야 하는가?
- 무엇을 직접 확인할까
- 나눌 기준과 결과를 합칠 곳, 결론이 다를 때 판단할 방법부터 정해본다.
- 적용한 뒤 남길 것
- 무엇을 가져왔고 결과가 어떻게 달라졌는지 적는다. 잘되지 않은 이유도 남긴다.
4. 반복 실행에도 끝나는 조건이 필요하다
Geoffrey Huntley의 Ralph 글에서는, 한 번의 대화로 끝내려 하지 않고 작업을 반복해서 이어가는 접근을 살펴봤다.[4]
여기서 반복 자체에만 관심을 가지면 놓치는 것이 있다.
같은 요청을 여러 번 했다고 같은 판단이 나오거나, 결과가 반드시 좋아지는 것은 아니다. 잘못 정한 목표를 더 오래 수행할 수도 있다.
나는 이 방식을 볼 때 반복문보다 종료 조건을 먼저 생각한다.
무엇이 확인되면 끝낼 것인가. 무엇이 반복되면 멈출 것인가. 다음 시도에서 바꿀 것은 무엇인가.
이 질문이 없다면 계속 일하고 있다는 사실만 남을 수 있다.
5. 좋아졌다는 말은 무엇과 비교한 것일까
마지막으로 참고한 것은 METR의 개발 생산성 연구와 후속 측정 글이다.[5]
이 자료를 읽을 때는 AI에 유리한 결과인지 불리한 결과인지보다, 어떤 사람의 어떤 작업을 어떻게 측정했는지 먼저 봤다.
내가 회사에서 편리함을 느꼈다는 것은 내 경험이다. 하지만 그것만으로 모든 사람이 같은 정도의 도움을 받는다고 말할 수는 없다.
반대로 특정 실험의 결과만 가지고 내가 실제로 편해진 경험을 부정할 필요도 없다.
내가 가져와야 할 것은 확인하는 방법이다. 구현에 걸린 시간뿐 아니라 수정과 검토, 이후 유지에 드는 부담까지 함께 보는 것. 익숙한 일과 낯선 일을 나누는 것. 잘된 경우만 골라 남기지 않는 것.
내가 자료를 읽고 남기려는 것
이제 자료를 정리할 때는 세 가지를 남기려 한다.
먼저 그 사람이 해결한 문제를 적는다. 그다음 내가 가진 조건과 다른 점을 적는다. 마지막으로 내 작업에서 직접 확인할 수 있는 작은 행동을 고른다.
‘좋은 글이었다’로 끝내면 다음 작업에서는 다시 검색하게 된다.
반면 어떤 부분을 가져왔고, 적용했을 때 무엇이 달랐는지 남기면 그 자료는 내 작업의 일부가 된다. 잘되지 않았다면 그 이유도 같이 남겨야 한다.
좋은 방법을 많이 아는 사람이 되고 싶은 것은 아니다.
내가 왜 그 방법을 쓰는지 알고 싶다. 그리고 잘되지 않을 때 다른 방법으로 바꿀 수 있었으면 좋겠다.
아래 자료들은 그 답을 대신해주지는 않는다. 대신 내가 놓쳤던 질문을 만들어준다.
참고한 원문
출처와 주석
Simon Willison, Here’s how I use LLMs to help me write code, 2025-03-11. 개인 작업 경험을 정리한 글이다. ↩︎
Harper Reed, My LLM codegen workflow atm, 2025-02-16. 이 제목의 글을 Simon Willison의 글과 혼동하지 않도록 출처를 바로잡았다. ↩︎
Anthropic, How we built our multi-agent research system, 2025-06-13. 연구 과제의 결과를 모든 코딩 작업에 일반화하지 않는다. ↩︎
Geoffrey Huntley, Ralph. 반복 실행 방식에 관한 원저자의 설명이며, 결과의 정확성을 보장하는 자료는 아니다. ↩︎
METR의 2025년 초기 연구와 2026년 후속 업데이트. 이 글은 2026-09-06에 참고자료와 해석을 다시 정리했다. 각 원문의 주장과 내가 작업에 적용하며 만든 원칙은 구분한다. ↩︎