AI 쓰는 법에 정답은 없지만, 오답은 있다

프롬프트 엔지니어링을 공부하라던 게 엊그제 같은데, 곧 RAG를 모르면 뒤처진다고 했고, 에이전트의 해가 왔고, 하네스를 이야기하다가, 루프가 답이라더니, 요즘은 다시 그래프 이야기를 합니다. 이름이 바뀔 때마다 다들 와다다 몰려가죠. 솔직히 저도 그 대열에 몇 번 섞여 있었습니다.

그런데 돌아보면 정작 제가 AI를 쓰는 방법은 프로젝트마다 전부 달랐습니다. '하이퍼커뮤니티'를 만들 때 AI는 제품 속의 부품이었어요. 실시간 번역 파이프라인 안에 조용히 들어가 있었고, 사용자는 자기가 AI를 쓰고 있다는 사실조차 몰랐죠. 지금 개인 프로젝트에서는 기획과 조사, 구현, 리뷰를 나눠 맡는 에이전트 팀을 굴리고 있고, 이 블로그에서 AI는 글쓰기를 거들고 실험을 대신 돌려주는 동료에 가깝습니다.

같은 사람이 써도 자리마다 이렇게 다른데, 유행은 모두에게 같은 답을 팝니다. 이 간극이 이 글의 출발점입니다.

몰려갔다가, 조용히 돌아온다

Hacker News를 시간순으로 읽으면 재밌는 왕복이 하나 보입니다.

2023년, LangChain이 LLM 개발의 표준처럼 번지던 바로 그해에 반동도 같이 시작됐습니다. 'Langchain Is Pointless', 'The Problem with LangChain' 같은 스레드가 연달아 올라왔고, 2024년에는 'Why we no longer use LangChain for building our AI agents' 같은 걷어낸 쪽의 기록이 나오죠. 그해 말에는 Anthropic도 'Building Effective Agents'에서 같은 관찰을 내놓습니다. 성과를 내는 구현은 복잡한 프레임워크가 아니라 단순하고 조합 가능한 패턴 위에 있더라고요.

2025년에는 아예 원점 회귀가 유행이 됩니다. 에이전트는 결국 도구를 부르는 루프일 뿐이라는 글이 호응을 얻었고, '12-Factor Agents'는 제어 흐름을 프레임워크나 모델에 외주 주지 말라는 원칙을 세웠죠. 연말부터는 오래 도는 에이전트를 위한 하네스 같은 글과 함께 하네스가 화두에 오릅니다.

그리고 올해는 그 왕복이 한 해 안에 다 들어옵니다. 하네스 엔지니어링 글이 쏟아지다 몇 주 만에 '하네스 엔지니어링만으로는 부족하다'는 반동이 호응을 얻었고, 그래프 오케스트레이션을 팔던 LangChain은 'The Art of Loop Engineering'을 냈고, 그 직후엔 다시 그래프 엔지니어링이 화두가 됐습니다. 유행이 돈다는 걸 유행을 파는 쪽이 스스로 보여준 셈이죠.

이 왕복에서 두 가지가 눈에 밟혔습니다. 하나는 돌아오는 물결이 잘 안 보인다는 것. 도입한 프레임워크에 대해서는 다들 글을 쓰지만 걷어낸 프레임워크에 대해서는 잘 쓰지 않으니까, 몰려가는 소리는 크고 돌아오는 발걸음은 조용합니다. 다른 하나는 왕복이 빨라지고 있다는 것. LangChain이 표준에서 '아직도 쓰는 사람 있나요'가 되기까지 2년이 걸렸는데, 이번 그래프 유행에는 몇 주 만에 팩트체크와 겹쳐 쓰는 것이라는 정리가 따라붙었거든요.

그러니까 이 왕복이 가르쳐 준 건 "다음 유행이 정답"이 아닙니다. "통째 도입이 오답"이라는 쪽에 가깝습니다.

오답은 수렴한다

여기서 재밌는 역설이 하나 있습니다. AI를 쓰는 정답은 3년째 못 정하고 있는데, 오답 목록은 점점 수렴하고 있거든요. Anthropic의 공인 아키텍트 자격시험(CCA-F)이 생겼고, 그 시험 대비 자료의 한가운데에 안티패턴 목록이 있습니다. 좋은 코드가 뭔지는 끝없이 논쟁해도 안티패턴 목록에는 다들 고개를 끄덕이는 것과 같은 구도죠.

목록을 추리면 이렇습니다.

• 에이전트 하나가 전부 처리하게 만드는 것
• 규칙을 프롬프트 지시로만 강제하는 것
• 에이전트가 스스로 보고하는 확신을 믿는 것
• 같은 답에 두 번 지불하는 것
• 에이전트가 맥락을 알고 있으리라 가정하는 것
• 실패를 조용히 삼키게 두는 것

그런데 저는 이 목록을 시험으로 배우지 않았습니다. 전부 실전에서 경험했어요.

시험이 아니라 실전에서 배운 목록

만능 에이전트, 그리고 반전

에이전트 팀을 기획, 조사, 구현, 리뷰로 나눈 건 거창한 설계 철학이 있어서가 아니었습니다. 하나가 다 하면 검증이 사라지기 때문이었어요. 만든 사람이 검토까지 하면 같은 눈으로 두 번 보는 것뿐이니까요. 리뷰어의 가치는 성실함이 아니라 위치에서 나온다는 걸, 저는 리뷰어가 뚫리는 걸 여러 번 보고서야 알았습니다. 역할이 나뉘니 모델도 나눌 수 있었습니다. 조율하고 검증하는 자리에는 비싼 모델을, 나머지에는 싼 모델을 배정해도 품질이 버티더군요.

다만 여기엔 반전이 하나 있습니다. 그렇게 팀을 갖춰 놓고 한 줄짜리 수정까지 팀 프로세스로 돌려 봤더니, 이번엔 조율에 드는 비용이 일 자체보다 커지더군요. 그래서 지금도 작은 일은 에이전트 하나에게 통째로 맡깁니다. 그러니까 원인은 "하나가 다 한다"가 아닙니다. 경계를 일의 모양에 안 맞춘 것이 원인이에요. 쪼개기는 목적이 아니라 결과입니다.

규칙은 어겨지고, 구조는 못 어긴다

시험에서 이 항목은 "JSON으로 답하라는 지시를 프롬프트로만 강제하지 말라"는, 층위가 작은 이야기로 나옵니다. 제가 겪은 버전은 층위가 컸습니다. 여러 에이전트가 같은 작업 폴더를 건드리다 사고가 났고, 규칙을 문서에 적었는데 또 났고, 더 자세히 적었는데 또 났습니다. 같은 사고가 다섯 번이요. 멈춘 건 규칙을 더 쓰는 걸 포기하고 작업 공간 자체를 격리했을 때였습니다. 읽고 지켜주길 바라는 것과 어길 수 없게 만드는 것의 차이인데, 시험이 JSON을 두고 하는 말과 결국 같은 원리죠.

확신은 근거가 아니다

저는 팀원 에이전트의 '확정'이라는 보고를 그대로 믿고 위로 올렸다가 배웠습니다. 실제 데이터와 대조해 보니 모순이었거든요. 시험 대비 자료도 같은 걸 가르칩니다. 판정은 에이전트의 자기보고가 아니라 금액이나 등급 같은 객관 기준으로 하라고요. 그 뒤로 제 팀의 규칙은 하나입니다. 모두가 동의해도 검증한 건 아니고, 확신이 강해도 근거가 되진 않아요. 판정은 실제로 재 본 값과 맞는지로만 합니다.

같은 답에 두 번 지불하지 않기

'하이퍼커뮤니티'의 실시간 번역에서 비용을 잡은 건 더 싼 모델도, 더 짧은 프롬프트도 아니었습니다. 같은 입력에는 모델을 다시 부르지 않는 캐싱 정책이었어요. 채팅이라는 게 같은 말이 정말 많이 반복되거든요. AI를 잘 쓰는 것의 절반은 AI를 안 부르는 자리를 아는 것이라고, 저는 지금도 생각합니다. AI로 할 건 AI로 하고, 코드로 할 건 코드로 하는 거죠. 무작정 전부 해달라고 프롬프트부터 들이미는 건 비용 문제이기 전에 설계 문제입니다.

요약은 답이면서 독이다

시험은 두 가지를 동시에 말합니다. 에이전트가 맥락을 알고 있으리라 가정하지 말고 명시적으로 전달하라. 그리고 원시 대화 이력 대신 구조화된 요약을 넘겨라. 둘 다 맞는 말인데, 제 사고는 정확히 그 사이에서 발생했습니다. 검증을 맡긴 에이전트에게 원문 대신 요약을 넘겼더니, 검증자가 검증을 못 하고 제 결론을 복창만 하더라고요. 검증자를 늘린 게 아니라 복제한 거였죠. 받는 쪽이 실행자면 요약이 답이고, 검증자면 원문이 답입니다.

성공한 실패가 제일 위험하다

시험에서 최악으로 꼽는 건 빈 결과를 성공처럼 반환하는 에이전트입니다. 틀린 답보다 나쁩니다. 보고받는 쪽을 적극적으로 속이니까요. 저도 도구가 실패를 경고 한 줄로 뱉고 성공한 얼굴로 지나가는 걸 여러 번 겪고 나서야, 상태를 바꿨으면 반드시 되읽어 확인한다는 규칙을 세웠습니다. 에러를 내며 실패한 실패는 고치면 됩니다. 성공한 얼굴을 한 실패가 일정을 며칠씩 갉아먹죠.

녹여내기

돌아보면 유행의 왕복도, 오답의 수렴도 같은 방향을 가리키고 있습니다. 프레임워크도, 패턴도, 심지어 안티패턴 목록도 재료지 레시피가 아니라는 것. 저 목록을 뒤집어 보면 결국 한 문장이 됩니다. 일을 잘 쪼개고, 쪼갠 조각을 믿지 말고 확인하라. 지난 글에서 모노레포 논쟁의 결론이 도구가 아니라 쪼개는 능력에 있다고 썼는데, 이번 글은 그 능력의 목록인 셈입니다.

루프와 그래프도 저에겐 그렇습니다. 유행으로는 아직 지켜보는 중인데, 돌아보면 제가 쓰는 방식 안에 그 요소들이 이미 들어 있어요. 역할을 나눠 맡긴 에이전트 팀은 결국 작은 그래프고, 기획에서 구현, 리뷰로 돌다가 반려되면 되돌아가는 사이클은 결국 루프니까요. 그러니까 이건 진화의 사다리가 아닙니다. 일에 맞춰 쓰다 보면 이미 하고 있던 형태에, 이름이 나중에 도착하는 것에 가까워요. 사실 이름이 늦게 도착하는 건 이번이 처음도 아닙니다. 순차, 조건, 루프 세 가지면 어떤 계산이든 짤 수 있다는 건 1966년에 뵘과 야코피니가 증명해 둔 사실이거든요. 60년 전에 정리로 박제된 구조가, 에이전트의 세계에서 최신 유행이라는 이름으로 다시 상영되고 있는 셈이죠.

정답은 각자의 자리에서 찾는 수밖에 없습니다. 그러고 보면 HN에서도 How I Use "AI"나 How I program with LLMs 같은 '나는 이렇게 쓴다'는 개인의 기록이 웬만한 유행 글 못지않은 호응을 얻었죠. 그래서 저도 프로젝트마다 다르게 쓰고 있고요. 하지만 오답은 공유할 수 있습니다. 다음 유행이 어떤 이름으로 오든, 통째로 삼키지 말고 내 일의 모양에 맞는 부분만 녹여낼 것. 제가 3년치 유행에서 건진 건 이 한 줄입니다.