동료가 된 AI에게는 작업장이 필요하다
논문 『From Chatbot to Digital Colleague: The Paradigm Shift Toward Persistent Autonomous AI』를 읽고
AI가 챗봇에서 디지털 동료로 넘어가려면 기억, 작업공간, 검증 루프, 권한 위임이 함께 필요하다. 인간-AI 협업을 업무설계 관점에서 읽는다.
제일 먼저 든 생각
요즘 “AI를 동료처럼 쓴다”는 말은 흔하다. 그런데 이 논문을 읽으며 걸린 지점은 조금 다르다. 동료처럼 쓰려면, AI에게도 작업장이 있어야 한다는 것이다. 채팅창 하나에 질문을 던지고 답을 받는 방식으로는 동료가 아니라 호출형 도구에 가깝다. 동료는 맥락을 이어가고, 지난번에 합의한 절차를 기억하고, 중간 산출물을 남기고, 실패했을 때 어디서 막혔는지 설명할 수 있어야 한다.
AI를 동료처럼 쓴다는 말은 모델을 더 자주 호출한다는 뜻이 아니다. 동료에게 자리가 필요하듯, AI에게도 기억할 것, 작업할 곳, 검증받을 루프, 넘겨받을 권한의 경계가 필요하다.
논문은 LLM의 변화를 “챗봇(Chatbot) → 사고형 LLM(Thinking LLM) → 에이전트(Agent) → 오픈클로(OpenClaw)식 작업 시스템 → 디지털 동료(Digital Colleague)”라는 흐름으로 정리한다. 핵심은 모델 성능 자체보다 **지속되는 작업공간(workspace)**과 **재사용 가능한 스킬(skill)**이다. AI가 한 번 답하고 사라지는 것이 아니라, 상태를 저장하고, 절차를 반복 가능하게 만들고, 검증 루프를 통해 일을 닫는 방향으로 움직인다는 주장이다.
논문이 말하는 전환을 Deciflow 관점에서 읽으면, 모델 선택보다 먼저 작업공간·스킬·검증 루프를 설계해야 한다는 메시지로 보인다.
“답변”에서 “작업”으로 넘어가는 순간
논문 초록의 가장 중요한 문장은 이 대목이다.
“LLM은 대화형 답변에서 지속되는 작업으로 이동하고 있다.”
“from conversational answers to persistent work.”
이 표현이 좋은 이유는 AI 도입의 단위를 바꿔주기 때문이다. 많은 조직은 여전히 “어떤 프롬프트를 쓰면 좋은가”, “어떤 모델이 더 정확한가”에 머무른다. 하지만 실제 업무에서는 좋은 답변보다 더 귀찮은 문제가 많다. 입력 파일은 어디에 두는가. 중간 산출물은 누가 확인하는가. 실패 로그는 어디에 남는가. 같은 일을 다음 주에도 반복할 수 있는가. 사람이 중간에 개입해야 할 권한 경계는 어디인가.
논문은 “작업공간 + 스킬(Workspace + Skill)” 패러다임을 통해 이 문제를 본다. 작업공간은 단순한 폴더가 아니다. 현재 상태, 자료, 로그, 산출물, 과거 시도, 검증 결과가 모이는 실행 기반이다. 스킬은 프롬프트 조각보다 넓다. 특정 업무를 닫기 위해 필요한 절차, 도구 호출, 판단 기준, 예외 처리의 묶음에 가깝다.
이렇게 보면 AI 업무설계의 질문도 달라진다. “AI가 할 수 있나?”보다 “AI가 이 일을 반복할 수 있는 작업장과 절차를 갖고 있나?”를 먼저 물어야 한다.
디지털 동료는 권한의 문제이기도 하다
논문은 에이전트가 외부 도구를 호출하고 작업을 수행하는 단계로 넘어갈수록 평가와 거버넌스가 중요해진다고 본다. 여기서 나는 “동료”라는 말의 부담을 다시 느꼈다. 동료에게 일을 맡긴다는 것은 단지 산출물을 받는 일이 아니다. 그 동료가 어떤 권한으로 어떤 파일을 열람하고, 어떤 시스템에 쓰기 권한을 갖고, 어떤 경우 사람에게 멈춰 물어야 하는지를 정하는 일이다.
특히 조직 업무에서는 이 경계가 성능보다 먼저 터진다. 회의록 요약은 쉽게 시작할 수 있지만, 회의록을 바탕으로 인사 평가 코멘트를 초안 작성하거나 교육 이수 데이터를 해석하는 순간 민감도가 올라간다. 이때 “똑똑한 AI”보다 중요한 것은 작업공간의 접근권, 로그의 남김 방식, 검증자의 위치, 최종 승인 절차다.
논문이 제안하는 디지털 동료의 모습은 낙관적이지만, 그대로 받아들이기보다 조건문을 붙여 읽어야 한다. AI가 동료가 되려면 사람처럼 자율적이어야 한다는 뜻이 아니라, 자율성을 부여해도 추적 가능한 구조가 있어야 한다는 뜻에 가깝다.
Deciflow에 붙여본 작은 실험
내 작업에 바로 붙이면, 거창한 에이전트 플랫폼보다 먼저 “반복 업무 하나를 작업공간화”하는 실험이 적당해 보인다.
예를 들어 논문 노트 발행 업무를 하나의 작업공간으로 본다면, 단순히 원문을 요약하는 모델 호출만으로는 부족하다. 후보 논문 목록, 중복 검사 결과, 원문 추출물, 이미지 검증 결과, 빌드 로그, 배포 확인, 최종 브리핑 문구가 한 흐름 안에 남아야 한다. 그리고 다음 실행에서는 이 기록을 다시 읽고 같은 논문을 고르지 않아야 한다. 여기서 AI의 기억은 “모든 것을 기억하는 능력”이 아니라 “다음 작업을 망치지 않기 위해 필요한 상태를 남기는 능력”이다.
업무 자동화 프로젝트에서도 같은 질문을 쓸 수 있다.
- 이 업무의 작업공간은 어디인가?
- 중간 산출물과 최종 산출물은 어떻게 구분되는가?
- AI가 재사용할 스킬은 문장인가, 절차인가, 코드인가?
- 실패했을 때 사람이 읽을 수 있는 흔적은 어디에 남는가?
- 권한 위임은 어느 단계까지 허용할 것인가?
논문이 보여주는 것은 “곧 AI가 진짜 동료가 된다”는 확정적 예언이라기보다, 동료처럼 보이는 AI를 만들려면 대화창 바깥의 업무 인프라를 함께 설계해야 한다는 점이다. 오늘의 작은 행동은 하나다. 반복되는 AI 업무 하나를 골라, 프롬프트가 아니라 작업공간·스킬·검증 루프 세 칸으로 다시 그려보는 것.
원문 첫 페이지. 논문은 챗봇에서 지속형 자율 작업 시스템으로 넘어가는 흐름을 큰 지도로 정리한다.