지난주 그는 버그 하나를 잡기 위해 에이전트 세션을 열네 번 돌렸습니다. 열세 번은 틀렸고, 열네 번째가 맞췄습니다. 그래도 그는 이걸 “내가 잡은 버그”라고 부릅니다.
GitHub의 스태프 엔지니어 Sean Goedecke가 1년 전과 지금의 LLM 활용 방식을 비교한 글을 발표했습니다. 2025년 초만 해도 에이전트는 “가끔, 의심하며” 쓰는 도구였는데, 지금은 하루에 수십 세션을 여는 일상이 됐다는 내용입니다. 무엇이 달라졌고, 무엇은 달라지지 않았는지를 솔직하게 정리한 글입니다.
출처: How I use LLMs as a staff engineer in 2026 – seangoedecke.com
1년 전과 지금, 무엇이 달라졌나
2025년 초, 그의 에이전트 활용은 제한적이었습니다. 단순한 파일 하나의 수정, 혹은 직접 짠 함수를 붙여 넣고 피드백 받기 정도. 코드 전체를 맡기는 건 상상하기 어려웠습니다.
지금은 모든 코드 변경을 에이전트에게 먼저 맡깁니다. PR 하나를 올리기 전에 에이전트가 초안을 만들고, 그는 한 번의 검토 패스만 거칩니다. 가끔은 그냥 올리기도 하지만, 그건 드문 일이고 주로 과도한 주석 같은 “LLM 특유의 흔적”을 걷어내는 작업이 필요합니다.
변화의 핵심은 감독 방식입니다. 예전 에이전트는 중간에 자주 틀렸고, 틀리면 회복하지 못했습니다. 그래서 실시간으로 개입하는 게 중요했죠. 지금 에이전트는 너무 빠르고 대부분 스스로 오류를 수정합니다. 감독보다는 평가가 더 중요한 역할이 됐습니다.
그가 에이전트 결과물을 검토하는 방식은 이렇습니다.
- 30초 안에 초기 평가 — “아, 내가 생각한 방향이 아닌데” 싶으면 바로 기각
- 괜찮아 보이면 제대로 읽으며 정확성 검토
- 어려운 작업은 다섯 번, 여섯 번 기각하고 다시 시도하거나, 결국 직접 손으로 작성
에이전트가 만든 결과를 무조건 쓰는 게 아니라, 빠르게 걸러내는 능력이 실제 생산성의 핵심이 된 셈입니다.
버그 잡기: 80%는 에이전트가, 나머지 20%는 사람이
버그 디버깅도 크게 바뀌었습니다. 2025년에는 “혹시나” 하는 마음으로 가끔 에이전트에게 던졌다면, 지금은 모든 버그를 일단 에이전트에게 넘깁니다. 버그 리포트를 붙여 넣고 세션을 열면, 80%는 에이전트가 스스로 원인을 찾아냅니다.
그 열네 번 사례가 흥미롭습니다. 에이전트가 열세 번 틀리는 동안 그는 놀고 있지 않았습니다.
- 로그와 Slack에서 추가 맥락을 발굴해 에이전트에게 전달
- 자체적으로 버그 재현 환경 구성
- “그 이론은 X 때문에 맞을 수 없어”라고 피드백하며 세션 재시작
열네 번째 에이전트가 풀어야 했던 문제는 첫 번째 에이전트가 풀어야 했던 문제보다 훨씬 쉬웠습니다. 사람이 검색 공간을 좁혀줬기 때문입니다. 에이전트가 답을 찾았지만, 그 과정을 가능하게 한 건 사람의 전문성이었습니다.
코드는 맡기고, 말은 직접 쓴다
에이전트가 쓴 코드로 PR을 올리면서도, 그 PR을 설명하는 글은 손으로 씁니다. 이유는 품질 문제만이 아닙니다.
PR 설명문을 직접 쓰는 건 리뷰어에게 “내가 이 변경사항을 이해하고 검토했다”는 신호입니다. 에이전트 생성 설명을 그대로 두면, 리뷰어가 이 코드를 처음 읽는 사람이 됩니다. 책임의 무게가 달라지죠.
Slack 메시지, ADR, 이슈도 직접 씁니다. “무엇이 중요한지 판단하는 감각”과 “그 판단을 한 사람이 있다는 신호”는 LLM으로 대체하기 어렵다고 봅니다. 블로그 글도 마찬가지입니다. 피드백 받는 용도로는 LLM을 활용하지만, 글은 직접 씁니다.
“균형점 찾기”가 지금의 핵심 스킬
그의 결론은 간결합니다. 지금 AI 시대의 핵심 스킬은 “에이전트에게 최대한 많은 걸 넘기되, 너무 멀리 가지 않는 것”입니다.
과소 활용하는 사람들은 에이전트가 버그를 잡거나 변경사항을 테스트할 수 있다는 걸 모른 채, 단순 작업조차 직접 합니다. 과잉 활용하는 사람들은 직접 써야 할 메시지를 에이전트에게 맡기거나, 꼼꼼히 검토해야 할 코드를 그냥 올립니다.
1년 전보다 균형점은 에이전트 쪽으로 많이 이동했습니다. 하지만 균형점을 찾는 일 자체는 여전히 어렵고, 그건 사람의 판단이 해야 할 일로 남아 있습니다.
답글 남기기