CoT와 ToT로 정리한 Skill과 Agent 설계

2026년 3월 23일

#AI

AI는 점점 질문에 답해주는 도구를 넘어서, 직군 상관없이 업무 흐름 안으로 들어오고 있어요.

프론트엔드 개발에서도 코드 생성, 문서 요약, 에러 분석, 테스트 작성, 리뷰 보조 등… 많은 업무들이 AI로 자동화되고 처리되고 있어요.

저 또한 기술 성장에 맞춰, 현업에서 하고 있는 모든 워크플로우를 자율적으로 수행해주는 Agentic Workflow 를 만드는 것을 목표로 하고 있어요.

이제는 Q&A 로 AI가 코드 몇 줄을 생성해주는 것이 아니라, 저 대신 일을 해주는 것처럼요 🫣

Claude 를 활용하다보니, “Skill 과 Agent 을 어떤 기준으로 나누면 좋을까?” 라는 고민으로 이어졌어요.

이 고민을 정리하는 것에 도움이 되었던 개념은

CoT(Chain-of-Thought)

ToT(Tree-of-Thought)

였습니다!


✨ CoT vs ToT

AI에게 일을 맡기려면 먼저 이 작업이 **‘선형적’**인지, ‘탐색형’ 인지 스스로 판단해야 했어요. 이때 CoT와 ToT 개념이 도움이 큰 도움이 되었어요!

1. CoT, Chain-of-Thought

ABC

CoT는 하나의 생각 흐름을 따라가면서 단계적으로 결론에 도달하는 방식이에요! 즉, 정답 경로가 선형적인 작업에 잘 맞아요.

예를 들면 이런 아이디어들이 떠올랐어요.

  • PR 리뷰 Skill
    • PR 리뷰 → 변경 요약 → 위험 포인트 → 테스트 체크 → 코멘트 작성
    • 성능 이슈 검토 / 보안 관점에서 검토 / 접근성 관접에서 검토 … 스킬 등으로 쪼갤 수 있음
  • 에러 로그 해석 Skill
    • 로그 분석 → 원인 추정 → 재현 조건 정리 → 해결책 제안
  • 작업 분해 Skill
    • 기획서 분석 → 요구사항 추출 → 작업 단위 분해 → 의존성 정리
  • TC 생성 Skill
    • 주요 동작 파악 → 정상 케이스 → 예외 케이스 → 엣지 케이스 → Testing Library 기반의 테스트 코드 생성
    • 실패 케이스만 생성 / 회귀 테스트 후보 추출 / E2E 테스트 초안 생성 등의 스킬로도 발전시킬 수 있음

이런 작업들은 순서가 비교적 명확하고, 항상 같은 절차로 진행되는 업무에요. 그래서 팀의 업무 순서, 컨벤션에 맞게 잘 정의해두면, 반복해서 재사용하기 좋았어요.

실제로도 몇 개의 스킬을 세팅하고 사용하니까 일의 효율이 훨~~씬 더 높아졌어요.

2. ToT, Tree-of-Thought

     A
   /   \
  B     C

반대로 ToT는 순차적으로 문제 해결에 접근하는 방식은 아니에요.

여러 후보를 만들고, 각각 비교하고, 필요하면 다시 다른 방향을 탐색하는 방식이에요. 여러 선택지를 두고 더 효율적인 작업을 선택해야하는 경우가 적합해요. 대신 비교적, 높은 추론 능력을 요구하는 모델을 사용합니다.

예를 들면 이런 경우예요.

  • 프론트엔드 아키텍트 Agent
    • 입력이 ‘CRM 만들어줘!’ 인 경우 다양한 설계 후보를 탐색하고, 비교
    • 디렉터리 구조, 상태 관리, 서버/클라이언트 상태 관리, 컴포넌트 후보, 캐싱 전략 등… 하나의 구조가 정답이 아니라 각각의 장단점과 적용 조건을 비교
  • 코드 리팩토링 Agent
    • 가독성, 성능, 유지보수, 타입 안정성, 테스트 용이성 등 리팩토링 방향 후보를 만들고, 기준을 선택해요. 여러 개선 결로를 비교하게 만드는 구조가 필요
  • 로그 분석 Agent
    • 에러 로그 해석 Skill보다 상위 개념
    • 최근 발생 로그 패턴 수집, 공통 원인 후보 찾기, UX 연결, 영향도 높은 큰 문제 비교 및 제안
    • 다양한 조건, 이벤트 들의 탐색과 비교가 필요한 업무
  • 릴리즈 전략 비교 Agent
    • hotfix / feature flag / staged rollout

이런 작업들은 정답이 하나로 정해져 있지 않아요. 작업의 후보를 잘 만들고, 비교하고, 선택하는 과정이 더 중요해요.


✨ 정리

이번에 정리하면서 느낀 건, 결국 중요한 건 모델 자체보다 업무를 어떻게 나누는가였어요.

  • 선형적이고 반복 가능한 작업은 Skill로 만들고
  • 분기와 비교와 판단이 필요한 작업은 Agent로 만든다

이렇게 방향을 잡았더니, 접근 방식을 헤맸던 “AI를 활용한 자동화”가 설계의 문제라는 것을 깨달았어요.

이제는 생각하는 관점도 달라졌어요.

“AI가 어떤 작업을 해줄까?” 보다 “우리 팀 업무 중 어떤 걸 자동화 가능한 단위로 쪼갤 수 있을까?”

이 질문이 FE AI Agent를 만드는 데 더 중요하다고 느꼈어요.


✨ 마무리

이제는 Claude를 단순한 Q&A 도구로 활용하는 것을 넘어,

업무 단위를 Skill로 쌓고, 그 Skill들을 조합해 목표 중심으로 움직이는 Agent를 만들고 있어요.

더 나아가 Skill / Agent / Hook을 연결해 하나의 업무 파이프라인으로 확장해보려고 합니다. 🪄

이 과정에서 CoT와 ToT는 단순한 이론이 아니라,

업무를 어떻게 나누고 어떤 역할로 설계할지 판단하는 데 꽤 유용한 기준이 되었어요. (그렇다고 1:1로 대응된다는 것은 아니에요!)

정리하면 이렇습니다.

  • CoT는 선형적인 워크플로우에 잘 맞았어요
  • ToT는 탐색과 비교가 필요한 의사결정에 잘 맞았어요
  • Skill은 CoT형으로 설계할 때 더 안정적이었어요
  • Agent는 ToT형으로 설계할 때 더 유연했어요

결국 핵심은 하나였어요.

작업을 선형과 탐색형으로 나누고, 그에 맞게 Skill과 Agent를 설계하는 것이었어요.

이 방향성을 바탕으로 앞으로는 FE 팀의 업무 파이프라인을 더 구체적으로 설계하고,

Claude 안에서 함께 일하는 FE 팀원 Agent를 하나씩 늘려가보려고 합니다. 🔎


Profile picture

주희(Joy)
가치를 고민하는 과정을 함께해요