AI 시대의 우리는

AI 시대에 접어들면서 우리가 일하는 방식은 많이 달라졌습니다. 반복적이고 지루한 일은 사람보다 AI에게 맡기는 편이 더 효율적이기 때문입니다. 그래서 요즘은 AI가 일자리를 대체한다는 이야기도 자주 나오는데요. 이런 AI 시대를 어떻게 바라봐야 하고, 에이전트는 어떻게 만들어야 하는지 정리해 보겠습니다.

1. 일하는 방식의 변화

AI 덕분에 일의 효율은 점점 높아지고 있습니다. 그리고 우리는 AI를 쓰는 사람에서 AI에게 일을 시키는 사람으로 바뀌어 가고 있습니다. 이를 위해 많은 곳에서 Agent를 만들고 있습니다.

그런데 Agent는 개발자가 더 잘 만드는 것이 아닙니다. Agent를 만든다는 건 AI 모델 자체를 만드는 것이 아니라, AI를 활용해 문제를 해결하는 것에 가깝기 때문입니다. 그래서 오히려 도메인 전문가가 유리할 수 있습니다. 문제를 잘 분석하고 도메인에 맞게 설계하는 것이 핵심이기 때문입니다.

  • AI: 일정하고 반복적인 업무
  • 사람: 정의, 판단, 조율 업무 → 업무를 잘 아는 사람

그렇기에 사람은 일하는 방식과 생각을 바꿔야 합니다. 핵심은 무엇을 AI에게 맡길지 아는 것입니다. 단순 반복 업무는 AI에게 맡기고, 사람은 문제를 정의하는 일, 결과를 판단하고 검증하는 일, 이해관계자를 조율하는 일에 집중해야 합니다.

2. Agent?

그렇다면 AI에게 일을 시키려면 무엇을 해야 할까요? 보통 Agent를 만든다고 합니다. 그런데 Agent는 일반 대화형 AI와 무엇이 다를까요?

  • 대화형 AI: 질문하고 답하는 방식 → 사람이 매번 질문을 작성하고 다음 단계를 이어감
  • Agent: 일을 맡기는 방식 → 목표를 주면 Agent가 알아서 일을 진행

즉 Agent는 목표를 받아 스스로 계획을 세우고, 필요한 도구(검색, 파일, 외부 API 등)를 사용해 실행하고, 결과를 확인하며 작업을 끝까지 수행하는 AI라고 볼 수 있습니다.

쉽게 비유하면 신입 사원에게 업무를 지시하는 것과 비슷합니다. 하나하나 손으로 시키는 것이 아니라, 목표와 가이드를 주고 맡기는 것이죠.

3. AI 사고법

AI가 어떻게 동작하는지 이해하면 일을 더 잘 시킬 수 있지 않을까요? LLM은 정답을 알고 있는 것이 아니라, 앞의 문맥을 보고 다음에 올 단어(토큰)를 확률적으로 예측하는 방식으로 답을 만들어 냅니다. 그럴듯한 문장을 만드는 데 최적화되어 있다 보니, 사실이 아닌 내용을 사실처럼 말하는 할루시네이션이 발생할 수 있습니다.

특히 숫자, 고유 명칭, 출처 같은 부분에 약합니다. 그렇기 때문에 사람이 신뢰할 수 있는 자료로 더블 체크하는 과정이 꼭 필요합니다.

그럼 할루시네이션을 줄이고 좋은 결과물을 얻으려면 어떻게 해야 할까요? 바로 프롬프트를 잘 작성해야 합니다. 지시가 명확해야 AI도 잘 수행할 수 있습니다. 앞에서 말한 신입 사원에 대입해 봐도, 명확하게 지시해야 일을 잘할 수 있다는 걸 알 수 있습니다.

그럼 명확한 지시는 어떻게 내려야 할까요?

  1. 역할 부여: 어떤 전문가로서 답해야 하는지 (예: "너는 10년 차 마케터야")
  2. 맥락 설명: 왜 이 일을 하는지, 배경과 대상은 누구인지
  3. 형식 지정: 결과물을 어떤 형태로 받을지 (표, 목록, 분량 등)
  4. 제약 설정: 하지 말아야 할 것, 지켜야 할 조건

이 네 가지를 바탕으로 프롬프트를 구체적으로 작성하면 원하는 결과물을 얻을 가능성이 훨씬 높아집니다. 또 참고 자료를 함께 제공하고, 모르는 내용은 모른다고 답하게 하는 것도 할루시네이션을 줄이는 데 도움이 됩니다.

프롬프트는 보통 작업할 때마다 그때그때 내리는 지시(user prompt)를 말합니다. 반면 system prompt는 대화나 작업을 시작할 때 한 번 정해 두면 이후 모든 응답에 계속 적용되는 기본 지침입니다. Agent를 만들 때는 역할, 규칙, 말투 같은 공통 지침을 system prompt에 담아 두는 경우가 많습니다.

4. Agent 후보 찾는 방법

그렇다면 이제 진짜 Agent를 만든다고 할 때, 무엇을 자동화해야 할까요?

단순히 "무엇을 자동화할까?"라고 생각하면 범위가 너무 넓어서 쓸모 있는 에이전트를 만들기 어렵습니다. "업무 중 가장 비효율적이고 불편한 것은 무엇일까?" 즉 pain point에서 출발해야 합니다.

  • AI Slop: 목적 없이 만들어진 저품질 AI 산출물
  • AI Leverage: 문제를 정확히 겨냥해 가치를 만들어 내는 고품질 AI 산출물

AI Slop이 아닌 AI Leverage를 만들기 위한 업무 리디자인 방식은 다음과 같습니다.

  1. 나의 업무 펼치기: 업무를 작은 activity로 나누고, 다시 Task 단위로 분리합니다.
  2. pain point 찾기: 각 Task 안에서 비효율적이거나 불편한 지점을 찾습니다.
  3. 해결 방법 상상하기: AI가 그 pain point를 어떻게 해결할 수 있을지 상상합니다.
  4. Agent 정하기: 어떤 데이터를 입력받아, 어떤 과정으로 일하고, 어떤 결과물을 내놓을지 정의합니다.

Agent 후보에는 쉬운 후보와 어려운 후보가 있습니다. 그리고 쉬운 후보들이 하나둘 모여 어려운 후보를 해결하는 큰 Agent가 될 수 있습니다. 그러니 처음부터 거창한 것을 만들기보다 작은 것부터 시작하는 것이 좋습니다.

그래서 AX는?

AX(AI Transformation)는 아직 등장한 지 얼마 안 된 개념이라, 처음에는 단순히 AI를 잘 활용해서 생산성을 높이면 되는 것 아닌가 생각했습니다.

하지만 그렇게 단순하게 볼 문제는 아닌 것 같습니다. AI에게 정확히 무엇을 시킬 것인지에 대한 목적, 그로 인한 기대 효과, 그래서 결과적으로 무엇이 달라지는지까지 큰 틀의 파이프라인을 봐야 할 것 같습니다.

그렇기 때문에 AX 시대에는 개발자가 유리하다기보다는, 문제를 정확히 파악할 수 있는 도메인 지식이 많은 사람이 유리한 것 같습니다.

그렇다고 개발자가 찬밥 신세냐 하면, 그건 아닌 것 같습니다. 다만 문제를 푸는 방식이 달라졌을 뿐입니다.

원래 개발자도 문제를 해결하는 사람이었습니다. 그리고 그 문제를 풀기 위해 깊은 전공 지식을 바탕으로 직접 솔루션을 만들어 왔습니다. 어떤 기술과 구조를 사용해서, 어떻게 구현할지를 하나하나 고민하는 것이 개발자의 역량이었죠.

그런데 지금은 조금 다른 것 같습니다. 개발 지식을 아예 몰라서는 안 되지만, 모든 걸 깊이 알고 직접 구현하기보다는 AI에게 무엇을 어떻게 시킬지 아는 것이 더 중요해졌습니다.

  • 이전: 깊은 전공 지식으로 "무엇을 사용해서 어떻게 해결할 것인가"를 고민
  • 지금: 문제 정의부터 구체적으로 들어가서 "전체 큰 틀을 어떻게 잡을 것인가"를 고민 → 하위의 작은 Task들은 AI에게 맡김

결국 개발자에게도 문제 자체를 정의하고 큰 그림을 설계하는 눈이 필요해졌습니다. 나무가 아니라 숲을 보는 눈을요.

물론 최종 결정과 책임은 사람이 지기 때문에 AI가 모든 것을 대체할 수는 없습니다. 하지만 신입이 주로 맡던 단순한 업무들은 AI로 대체될 가능성이 큽니다.

그렇기에 신입이라도 스스로를 신입에 머무르게 두지 않고, AI를 활용해 빠르게 문제를 해결할 수 있는 사람이자 최종 결정과 책임을 질 수 있는 사람임을 입증해 나가야 할 것 같습니다.