AI 도구를 하나씩 써 보기 시작하면, 어느 순간 브라우저 탭과 앱 목록이 꽤 길어집니다.
Claude를 켜고, Codex로 코드를 만지고, Antigravity에서 다른 실험을 해 보고, Grok에서 흐름을 살펴보고, Google Spark 같은 새로운 작업 환경도 기웃거립니다. 예전 같으면 이건 그저 앱을 많이 쓰는 사람의 화면이었을 겁니다.
그런데 요즘은 질문이 조금 달라졌습니다.
“나는 어떤 AI 앱을 쓰고 있는가?”보다 “이 도구들이 내 업무 안에서 어떤 구조를 이루고 있는가?”가 더 중요해진 겁니다.
도구가 많아져서 아키텍처가 되는 것은 아닙니다. 사용자의 목표가 한 도구에서 끝나지 않고, 여러 작업 환경과 실행 주체, 외부 데이터, 검증 절차, 배포·운영 단계로 이어질 때 비로소 도구의 묶음은 디지털 아키텍처가 됩니다.
오늘은 제가 여러 AI 도구를 바라보는 기준을 제품 비교표가 아니라 업무 흐름의 계층으로 다시 정리해 보겠습니다.
1. 앱 목록과 아키텍처 사이에는 ‘연결 규칙’이 있다
앱 목록은 현재 무엇을 설치했는지를 보여 줍니다. 반면 아키텍처는 왜 그 도구가 필요한지, 언제 호출되는지, 어떤 결과를 다음 단계로 넘기는지를 보여 줍니다.
가령 “특허 관련 자료를 조사해 보고서 초안으로 정리한다”는 일을 생각해 보겠습니다.
앱 목록으로 보면 검색 도구, 문서 편집기, AI 챗봇, 파일 저장소, GitHub가 각각 따로 보입니다. 하지만 업무 흐름으로 보면 다음처럼 이어집니다.
사용자 목표
→ 작업 환경에서 요청
→ 에이전트가 과업 분해
→ 검색·파일·지식 도구 호출
→ 근거와 초안 생성
→ 사람의 검토·승인
→ 버전 저장·배포·운영
이 흐름에서 중요한 것은 “어떤 앱이 최고인가?”가 아닙니다. 각 단계의 책임이 어디에 놓이는가입니다.
검색 도구가 초안을 대신 책임지는 것도 아니고, 문서 편집기가 사실관계를 검증하는 것도 아닙니다. AI가 문장을 잘 만든다고 해서 사람의 승인 단계가 사라지는 것도 아닙니다. 도구의 성능보다 먼저 역할과 경계를 정해야 전체가 흔들리지 않습니다.
아키텍처 교훈 ①
앱은 기능의 이름이고, 아키텍처는 기능 사이의 책임과 이동 경로를 정한 설계다.
2. AI 업무 환경은 여섯 개의 층으로 읽을 수 있다
제가 지금까지의 작업을 정리하면서 가장 유용했던 구분은 다음 여섯 층입니다.
| 아키텍처 계층 | 하는 일 | 여기서 결정할 질문 |
|---|---|---|
| 사용자 접점·작업 환경 | 목표를 입력하고 결과를 확인한다 | 사용자는 어디에서 시작하고 끝내는가? |
| 에이전트 실행·오케스트레이션 | 요청을 쪼개고 순서를 정하며 도구를 부른다 | 무엇을 자동화하고 무엇을 사람에게 남기는가? |
| MCP·외부 도구 | 검색, 파일, 메일, API, 데이터베이스를 연결한다 | 어떤 시스템에 어떤 권한으로 접근하는가? |
| 지식·데이터·인프라 | 장기 자료와 현재 작업 데이터를 보관한다 | 무엇이 원본이고 무엇이 가공본인가? |
| 검증·승인·감사 | 근거, 변경, 승인, 보류를 기록한다 | 결과를 누가 다시 설명할 수 있는가? |
| GitHub·배포·운영 | 결과를 버전화하고 외부에 전달한다 | 어떻게 되돌리고 재현할 수 있는가? |
Claude, Codex, Antigravity, Grok, Google Spark 같은 이름은 이 표의 특정 한 칸에 영원히 고정되지 않습니다. 어떤 제품은 작업 환경이 될 수도 있고, 에이전트 실행 환경이 될 수도 있으며, 외부 도구를 연결하는 호스트가 될 수도 있습니다.
그래서 제품을 소개할 때 “이 도구는 무엇을 할 수 있다”라고만 쓰면 금방 낡습니다. 대신 “이 도구가 우리 업무의 어느 층에 들어와 어떤 책임을 맡는가”를 기록하는 편이 오래 갑니다.
예를 들어 같은 문서 생성 기능이라도, 한 번의 아이디어 메모를 만드는 데 쓰는 것과 고객에게 보낼 최종 의견서를 만드는 데 쓰는 것은 전혀 다른 배치입니다. 전자는 사용자 접점과 초안 계층에 가까울 수 있지만, 후자는 근거 검증·승인·감사 계층까지 반드시 연결되어야 합니다.
3. 도구의 진짜 가치는 ‘기능 수’가 아니라 ‘과업 완료율’에 있다
AI 도구의 소개 페이지를 읽다 보면 기능 목록이 화려합니다. 긴 문서를 읽고, 코드를 작성하고, 이미지를 만들고, 웹을 검색하고, 다른 서비스와 연결할 수 있다고 합니다.
그런데 실제 업무에서는 기능이 많다는 사실보다 마지막 단계까지 결과가 도착하는가가 더 중요합니다.
다음 두 환경을 비교해 보겠습니다.
도구 중심 환경
- AI에게 질문한다.
- 답변을 복사한다.
- 다른 앱을 연다.
- 다시 붙여 넣는다.
- 파일 이름을 정한다.
- 사람이 어디까지 확인했는지 기억에 의존한다.
이 방식도 당장은 작동합니다. 다만 작업이 길어질수록 정보가 끊기고, 같은 내용을 여러 번 옮기며, 중간 판단이 사라집니다.
아키텍처 중심 환경
- 사용자가 목표와 범위를 입력한다.
- 에이전트가 필요한 단계와 자료를 정리한다.
- 연결된 도구에서 원본을 조회한다.
- 결과에 근거와 상태를 붙여 초안을 만든다.
- 사람이 사실·위험·외부 전달 여부를 확인한다.
- 승인된 결과만 버전 저장 또는 배포 단계로 넘어간다.
두 번째 환경에도 복사와 붙여넣기는 남아 있을 수 있습니다. 차이는 그것이 개인의 기억에 의존하는 임시 행동인지, 규칙과 기록이 있는 작업 흐름인지입니다.
아키텍처 교훈 ②
좋은 AI 환경은 답변을 많이 생산하는 환경이 아니라, 목표가 검증 가능한 결과까지 끊기지 않고 이동하는 환경이다.
4. 여러 도구를 연결할수록 ‘중간 계층’이 중요해진다
도구를 두 개만 쓸 때는 사용자가 직접 연결해도 큰 문제가 없습니다. 하지만 검색 서버, 파일 시스템, 메일, 캘린더, 지식 저장소, GitHub가 동시에 붙으면 사람이 모든 연결을 기억하기 어려워집니다.
이때 필요한 것이 에이전트와 MCP 같은 중간 계층입니다.
중간 계층은 단순한 통로가 아닙니다. 다음을 정리하는 장소입니다.
- 사용자의 자연어 요청을 실제 작업 단위로 나누는 일
- 어떤 도구를 어떤 순서로 호출할지 정하는 일
- 도구가 반환한 자료를 원본·요약·추론으로 구분하는 일
- 특정 폴더나 계정에 접근할 수 있는 범위를 제한하는 일
- 실행 전에 사람이 확인해야 하는 지점을 표시하는 일
MCP를 예로 들면, AI 애플리케이션이 호스트가 되고, 각각의 서버가 외부 시스템의 기능이나 자료를 제공하는 구조로 이해할 수 있습니다. 이 구조는 “모든 데이터를 AI 안으로 복사한다”는 방식과 다릅니다. 필요한 순간에 필요한 통로를 열고, 어떤 서버가 어떤 기능을 제공하는지 분리해서 볼 수 있게 합니다.
물론 연결했다고 안전해지는 것은 아닙니다. 서버가 읽을 수 있는 범위, 원본을 바꿀 수 있는지, 외부로 데이터를 보낼 수 있는지, 실행 결과가 기록되는지를 별도로 확인해야 합니다.
연결이 늘어날수록 편의성 곡선만 그리면 안 됩니다. 권한·비용·감사 가능성 곡선도 함께 그려야 합니다.
5. 같은 도구라도 ‘입구’와 ‘출구’를 다르게 설계해야 한다
AI 도구를 업무에 도입할 때 제가 가장 먼저 보는 것은 기능표가 아니라 입구와 출구입니다.
입구: 어디에서 요청이 시작되는가
채팅창에서 시작할 수도 있고, IDE에서 시작할 수도 있고, 문서나 이슈 트래커에서 시작할 수도 있습니다. 입구가 달라지면 에이전트가 처음 읽는 컨텍스트와 사용 가능한 규칙도 달라집니다.
예를 들어 개발 프로젝트의 IDE에서 시작한 요청과, 외부 고객의 문의를 정리하는 문서에서 시작한 요청은 같은 모델을 사용하더라도 필요한 권한이 다릅니다. 전자는 코드와 테스트에 접근해야 할 수 있지만, 후자는 개인정보·계약정보·내부 메모의 경계를 먼저 확인해야 합니다.
출구: 결과가 어디까지 가는가
결과가 채팅창에 머무는지, 로컬 파일로 저장되는지, GitHub에 커밋되는지, 고객 메일로 발송되는지에 따라 위험도는 크게 달라집니다.
저는 출구를 대략 다음처럼 나눠 봅니다.
| 출구 | 예시 | 기본 원칙 |
|---|---|---|
| 개인 확인 | 채팅 답변, 임시 메모 | 사실과 추론을 구분한다 |
| 프로젝트 반영 | 문서 수정, 코드 변경 | diff와 테스트를 확인한다 |
| 팀 공유 | 이슈, PR, 내부 보고서 | 근거와 변경 이력을 남긴다 |
| 외부 실행 | 게시, 발송, 배포, 결제 | 사람의 명시적 승인을 거친다 |
입구와 출구를 그려 보면 “AI를 어디까지 자율적으로 움직이게 할 것인가”라는 질문도 구체적으로 바뀝니다. 모델을 무조건 믿거나 무조건 막는 대신, 출구의 위험도에 따라 승인 강도를 조절할 수 있기 때문입니다.
6. 특허 업무에 대입하면 ‘앱 선택’의 한계가 더 잘 보인다
특허·상표 업무는 도구 하나로 끝나는 일이 많지 않습니다. 검색, 분류, 원문 확인, 비교, 초안, 검토, 제출 준비가 순차적으로 이어집니다.
가상의 선행기술 조사 흐름을 아키텍처로 그리면 이렇습니다.
조사 목표·범위 입력
→ 검색 전략과 키워드 분해
→ 특허·판례·기술자료 조회
→ 원문·서지사항·검색 조건 저장
→ 관련성·차이점·불확실성 분석
→ 보고서 초안 작성
→ 변리사 또는 담당자의 검토·승인
→ 보고서 버전 저장·전달
여기서 AI 도구는 여러 역할을 맡을 수 있습니다. 검색식을 제안하고, 긴 문서를 요약하고, 비교표의 초안을 만들고, 반복적인 형식을 정리할 수 있습니다.
하지만 “관련성이 높다”는 판단과 “이 자료를 근거로 외부 의견을 확정한다”는 판단은 같은 일이 아닙니다. 전자는 분석 보조이고, 후자는 책임이 붙는 승인 행위입니다.
따라서 이 업무의 핵심은 특정 AI 제품을 고르는 데 있지 않습니다. 검색 원문과 분석 결과 사이에 어떤 표식을 남길지, 사람이 언제 개입할지, 최종본을 어떻게 재현할지를 먼저 정하는 데 있습니다.
이 원칙은 특허 업무에만 해당하지 않습니다. 회의록, 계약서 초안, 코드 리뷰, 마케팅 콘텐츠처럼 근거와 책임이 필요한 모든 업무에 적용됩니다.
7. 디지털 아키텍처는 도구를 줄이는 설계가 아니라 선택을 설명하는 설계다
아키텍처를 말하면 가끔 “그럼 도구를 하나로 통일해야 하나요?”라는 질문을 받습니다. 꼭 그렇지는 않습니다.
단일 도구는 연결 비용을 줄여 주지만, 특정 벤더에 대한 의존과 데이터 이동의 집중을 키울 수 있습니다. 여러 도구를 쓰면 선택권이 커지지만, 컨텍스트 단절과 운영 복잡성이 따라옵니다.
중요한 것은 하나를 고르는 것보다 왜 여러 개를 쓰는지 설명할 수 있는 상태입니다.
- 이 도구는 사용자 접점이 편해서 쓰는가?
- 이 도구는 특정 자료에 접근하는 역할인가?
- 이 도구는 초안 생성에 강하지만 외부 실행은 맡기지 않는가?
- 이 결과는 어느 저장소에 남고, 누가 다시 확인하는가?
- 도구를 교체해도 지식과 작업 기록이 남는가?
이 질문에 답할 수 있으면 도구가 바뀌어도 아키텍처의 중심은 유지됩니다. 반대로 질문에 답하지 못하면, 앱을 하나 더 설치할 때마다 시스템 전체가 조금씩 흐려집니다.
아키텍처 교훈 ③
벤더 이름은 바뀔 수 있지만, 입구·권한·근거·승인·출구의 설계는 업무의 뼈대로 남는다.
마치며
요즘 AI 도구의 변화는 너무 빨라서 기능 이름을 모두 따라가기도 어렵습니다. 새로운 앱이 나오고, 기존 제품에 에이전트 기능이 붙고, 서로 다른 서비스가 MCP나 API로 연결됩니다.
이럴 때마다 모든 제품을 외우려고 하면 금방 지칩니다. 대신 한 장의 그림을 그려 보는 편이 낫습니다.
사용자 접점
→ 에이전트 실행·오케스트레이션
→ MCP·외부 도구
→ 지식·데이터·인프라
→ 검증·승인·감사
→ GitHub·배포·운영
이 그림은 특정 제품의 광고 문구가 아니라, 제가 업무를 계속 이어 가기 위해 필요한 역할과 경계의 지도입니다.
AI 도구를 많이 쓰는 것 자체가 목표는 아닙니다. 내가 하려는 일이 어디에서 시작되고, 어떤 도구를 거쳐, 어떤 검증을 통과한 뒤, 어디에 남는지를 설명할 수 있다면 그때부터 도구의 묶음은 아키텍처가 됩니다.
다음 글에서는 이 구조 안에서 실제로 일을 수행하는 에이전트의 실행 루프를 더 가까이 들여다보겠습니다. 에이전트는 단순히 답변하는 존재가 아니라, 목표를 해석하고, 규칙을 읽고, 도구를 호출하고, 결과를 확인하며 다음 행동을 선택하는 실행 주체이기 때문입니다.