‘AI가 모든 것을 혁신하고 있다’로 시작해서 alt 텍스트 작성을 위한 ChatGPT 프롬프트를 나열하는 버전의 기사를 본 적이 있을 겁니다. 그런 글을 읽으셨겠죠.

실제 웹 에이전시에서 일어나고 있는 일은 과장된 기대보다 더 복잡하고, 흥미로우며, 중요합니다. AI가 개발자를 대체하는 것이 아니라 — 개발자의 시간이 어디에 쓰이는지, 어떤 기술 스킬이 가치를 증폭시키는지, 그리고 에이전시가 납품 파이프라인을 어떻게 구성하는지를 근본적으로 재편하고 있습니다. 만약 여러분이 전문적으로 클라이언트 작업을 진행한다면, AI 도구를 의도적으로 채택했든 아니든 이미 변화의 영향을 받고 있을 겁니다.

AI 통합이 실제로 워크플로우 이점을 창출하는 지점, 새로운 기술 부채(technical debt) 카테고리를 만드는 지점, 그리고 이러한 것들을 프로덕션에 연결할 때 실제 코드가 어떻게 보이는지 제가 설명해 드리겠습니다.

에이전시 작업에서 AI가 진정으로 유용한 곳

콘텐츠 인텔리전스 파이프라인

제가 본 에이전시 워크플로우에서 가장 지속 가능한 AI 통합은 코드 생성이 아니라 콘텐츠 처리입니다. 구체적으로는, 구조화되지 않은 클라이언트 콘텐츠를 받아 대규모로 구조화되고 SEO에 최적화된 결과물로 변환하는 것입니다.

일반적인 패턴은 이렇습니다: 클라이언트가 Word 문서, 제품 사양서, 오래된 블로그 게시물 폴더를 덤프합니다. 이전에는 개발자가 이것을 수동으로 CMS(콘텐츠 관리 시스템) 준비 콘텐츠로 파싱해야 했습니다. 이제는 구조화된 추출 프롬프트와 함께 LLM(대규모 언어 모델)에 연결하여, 콘텐츠 모델에 직접 매핑되는 JSON을 얻을 수 있습니다.

// OpenAI를 통해 원시 클라이언트 문서를 처리하는 Laravel job
class ProcessClientContentJob implements ShouldQueue
{
...
}

response_format: json_object 제약 조건이 매우 중요합니다. 이것 없이는 자유 형식 텍스트를 파싱하게 되고, 이는 프로덕션에서 끊임없이 오류를 일으킵니다.

CI 단계로서의 자동 코드 검토

추세적으로 주목받는 또 다른 패턴은 PR(Pull Request) 파이프라인의 일부로 AI 코드 검토를 실행하는 것입니다. 이는 인간의 검토를 대체하기 위함이 아니라, 시니어 개발자의 주의가 닿기 전에 명백한 문제들을 잡아내는 첫 번째 필터 역할을 합니다.

.github/workflows/ai-review.yml

name: AI 코드 리뷰
on:
...

여기서 gpt-4o-mini를 선택한 것은 의도적입니다. 모든 PR(Pull Request)마다 실행되기 때문에 비용이 중요합니다. 고비용 모델은 중요한 작업에 아껴두어야 합니다.

아무도 말하지 않는 문제들

컨텍스트 윈도우 부채 (Context Window Debt)

거대 언어 모델(LLM)은 상태를 유지하지 못합니다(stateless). 모든 요청이 깨끗한 출발점입니다. 이는 당연하지만 그 함의는 은근하게 다가옵니다. 여러 사용자 상호작용에 걸쳐 AI 지원 기능을 구축할 때—AI 어드바이저가 있는 다단계 온보딩 마법사 같은 것을 생각해 보세요—당신은 매번 호출 시 컨텍스트를 재구성할 책임이 있습니다. 이는 대화 기록을 직렬화(serializing)하고, 한계를 초과할 때 지능적으로 잘라내며(truncating), 무엇을 버려도 안전한지 결정하는 것을 의미합니다.

class ConversationContextManager
{
    private const MAX_TOKENS = 6000; // gpt-4o-mini의 보수적인 한계
...

이것은 지루한 인프라 작업입니다. 하지만 이것이 작동하는 챗봇과 메시지 다섯 개 후에 제정신을 잃는 챗봇 사이의 차이를 만듭니다.

클라이언트 대상 콘텐츠에 대한 생성 의존성 과다 (Over-Reliance on Generation for Client-Facing Content)

이것은 에이전시 운영 측면에서 더 큰 문제입니다. 도메인 검토 없이 배포된 AI 생성 콘텐츠는 다운스트림(downstream)에서 SEO 문제를 야기합니다. 얇은 콘텐츠(thin content), 균질화된 문구, 기술적인 분야에서의 사실 오류가 흔한 실패 모드입니다. https://hanzweb.ae에서는 구조와 초안 스캐폴딩(scaffolding)을 위해 AI를 사용하고, 그 다음 출력을 인간 검토 단계로 거친 후에야 프로덕션 CMS에 적용하는 접근 방식이 가장 잘 유지되고 있습니다. 완전히 자동화된 파이프라인보다는 느리지만, 검색 성능에서의 품질 차이는 측정 가능합니다.

여기서 실제로 시너지를 내는 기술들 (What Skills Actually Compound Here)

학습 시간을 어디에 투자할지 고민하고 있다면, AI가 증강된 에이전시 워크플로우에서 가장 높은 레버리지를 가진 영역은 다음과 같습니다:

• 구조화된 출력을 위한 프롬프트 엔지니어링 (Prompt engineering for structured output) — JSON 모드, 함수 호출(function calling), 그리고 스키마 강제 적용이 자유 텍스트 파싱보다 더 신뢰성이 높습니다.
• 검색 증강 생성 (Retrieval-augmented generation, RAG) — 클라이언트별 지식을 청크화(chunk), 임베딩(embed)하고 검색하는 방법을 아는 것이 일반적인 LLM 출력을 클라이언트의 비즈니스 컨텍스트와 실제로 관련성 있게 만듭니다.
• AI 호출에 대한 관측 가능성 (Observability for AI calls) — 지연 시간, 토큰 사용량, 출력 품질 측정 항목을 로깅합니다. AI 기능이 조용히 저하될 때, 이를 진단하기 위한 데이터가 필요합니다.
• 비용 모델링 (Cost modeling) — 트리거당 $0.002가 드는 기능은 괜찮습니다. 트리거당 $0.40가 드는 기능은 배포되기 전에 예산 논의가 필요합니다.

결론

에이전시 워크플로우에서의 AI는 스위치를 켜고 끄는 것이 아니라, 신중하게 계측(instrument)해야 하는 표면입니다. 성공 사례는 실재합니다: 콘텐츠 처리, 코드 리뷰 보강, 고객 대면 대화형 인터페이스 등입니다. 하지만 실패 모드 역시 마찬가지로 실재합니다: 컨텍스트 관리 오류, 비용 초과 지출, 그리고 분석에서 몇 달 후에야 나타나는 콘텐츠 품질 퇴보 등이 있습니다.

이러한 도구들로부터 가장 많은 이익을 얻는 개발자들은 코드를 전부 AI에 맡겨 쓰는 사람들이 아닙니다. 그들은 결정론적 시스템(deterministic systems)이 어디서 끝나고 확률론적 시스템(probabilistic ones)이 시작되는지 이해하고 — 그에 맞춰 가드레일(guardrails)을 구축하는 사람들입니다.

AI 기능을 배포할 때도 어떤 인프라를 배포하듯이 해야 합니다: 로깅과, 폴백(fallbacks), 그리고 너무 쉬워 보이는 모든 것에 대한 건강한 회의론을 가지고 말입니다.