AI가 업무를 알고, 코드가 알며, 나는 휴대폰만 가져간다
요약
본 글은 AI 에이전트가 단순한 개인 비서 역할을 넘어 팀 단위의 협업을 통해 실질적인 결과물을 만들어내는 미래 컴퓨팅 환경을 제시합니다. 특히, 영상이나 스크린샷 같은 일상적인 입력 데이터를 다른 사람이 즉시 사용할 수 있는 인터랙티브 데모나 작동하는 미리보기로 변환하는 워크플로우에 초점을 맞춥니다.
핵심 포인트
- AI 에이전트의 역할은 개인 비서에서 팀 단위 협업으로 확장된다.
- 단순한 '번역'을 넘어, 일상적 데이터를 실용적인 결과물로 만드는 것이 핵심이다.
- 영상이나 스크린샷 같은 입력도 다른 사람이 상호작용할 수 있는 데모로 변환 가능하다.
- AI 에이전트가 도구(Tool)를 사용하는 것을 넘어, 동료 역할을 수행하는 '역할 부여'가 중요하다.
파트 2: 다리가 팀을 연결한다. 팀은 무엇으로 유용한 무언가를 만들 수 있을까?
이전 글에서 나는 개인 비서인 Instinct를 Mac의 OpenCode에 연결했다. Instinct는 PM(Product Manager) 역할을 하고, OpenCode가 개발자 역할을 한다. 내가 비서에게 문자를 보내면, 그가 작업을 인계하고 결과물이 내 휴대폰으로 돌아온다.
이렇게 하면 작업 인계(handoff) 문제는 해결된다. 이제 흥미로운 질문이 남는다. 팀에게 무엇을 인계할 수 있을까?
북마크한 동영상. "이거 이상해 보여요"라고 캡션이 달린 스크린샷. 같은 간단한 계산을 다시 해달라는 이메일.
보통 이런 것들을 매번 스스로 코딩 작업으로 번역해야 한다. 요청 내용을 복사하고, 컨텍스트를 붙여넣고, 답변을 설명하는 과정을 반복한다. 미래의 컴퓨팅이 마치 사무실 업무처럼 보이게 될 때까지 계속해서 말이다.
내가 원하는 다음 단계는 팀에게 그 '번역' 자체를 맡기는 것이다. 일상적인 것이 들어가서, 다른 사람이 사용할 수 있는 무언가가 나오는 것이다.
"MCP로 이것을 할 수 없나요?"
MCP(혹은 플러그인)를 통해 코딩 에이전트에게 브라우저 도구를 제공할 수 있다. 페이지를 보고, 코드를 수정하며, 결과를 확인할 수 있는 코딩 에이전트는 유용하다.
하지만 내가 말하는 차이는 그것이 아니다.
내가 구분하려는 것은 누가 대화의 주도권을 가지느냐이다.
코딩 에이전트에 도구가 붙어 있어도, 여전히 개발자에게 직접 이야기하고 있는 것이다. 이 설정에서는 내가 개인 비서와 이야기하고, 그 비서가 별도의 코딩 에이전트와 협업한다. Instinct는 요청과 그에 관련된 외부 정보를 처리한다. OpenCode는 저장소(repository) 내에서 작업하며 코딩 세션을 유지한다.
MCP는 양쪽 중 어느 쪽에나 포함될 수 있다. 그것이 팀이라는 아이디어를 무의미하게 만들지는 않는다. 도구는 에이전트에게 '능력'을 부여하지만, 인계(handoff)는 그 능력에 '다른 역할'을 부여하는 것이다.
개발자에게 브라우저를 주는 것은 유용하다. 하지만 개발자에게 동료를 주는 것이 내가 흥미롭다고 느끼는 부분이다.
비디오가 들어가고, 도구가 나온다.
어떤 아이디어를 설명하는 영상을 시청한다. 보통의 결과물은 북마크와 '내가 생산적인 일을 했다'는 느낌뿐이다.
만약 결과물이 다른 사람이 사용할 수 있는 것이라면 어떨까요?
아래 예시는 팀이 적절한 도구와 접근 권한을 갖추었을 때 할 수 있는 일의 예시일 뿐입니다. 이 워크플로우들이 모두 오늘 브릿지에서 출시된다는 기록이나 주장은 아닙니다.
예를 들어, 영상이 옵션을 비교하는 방법을 가르친다고 가정해 봅시다. 당신은 그것을 Instinct로 보냅니다:
이 방법을 조사해 주세요. OpenCode와 협력하여 유용한 부분을 작은 인터랙티브 데모로 만드세요. 공유하기 전에 검토를 위해 다시 가져옵니다.
Instinct는 접근 가능한 자료와 지원 출처를 확인합니다. 방법론을 판매용 발표에서 분리하고, 가정을 식별하며, 구축할 가치가 있는 버전을 선택하는 것을 돕습니다. OpenCode는 간략한 설명을 조정 가능한 입력값, 실제 예시, 결과 검증이 포함된 데모로 만듭니다.
이제 당신의 친구가 자신만의 옵션을 입력하여 그 방법을 시도해 볼 수 있습니다. 그들은 영상을 보거나, 유용한 부분을 찾거나, 스프레드시트로 번역할 필요가 없습니다.
흥미로운 변화는 비디오를 요약으로 만드는 것이 아닙니다. 그것은 비디오를 다른 사람의 손에 쥐여줄 수 있는 무언가로 만드는 것입니다.
스크린샷이 들어가면, 작동하는 미리보기가 나옵니다.
누군가가 개발자가 가장 좋아하는 메시지인 다음과 같은 모바일 페이지 스크린샷을 당신에게 보냅니다:
이거 이상해 보여요.
아름답고 정확한 사양입니다. 우리가 프레임을 잡아야 합니다.
그 메시지와 당신의 코딩 에이전트 사이에서 통역가 역할을 하는 대신, 팀에게 스크린샷과 검사할 페이지를 줄 수 있습니다:
뭐가 잘못되었는지 파악하고, 명확한 문제를 수정하며, 제가 검토하기 위해 보낼 수 있는 작동하는 미리보기를 주세요. 디자인 자체를 변경하기 전에 저에게 물어봐 주세요.
Instinct는 '이상하다'라는 것을 관찰 가능한 무언가로 바꿉니다: 내비게이션이 주요 액션을 가리거나, 레이아웃이 좁은 폭에서 잘리는 것 같은 경우입니다. OpenCode는 범위가 지정된 변경을 수행합니다. 시각적 접근을 통해 Instinct는 결과를 확인하고, 남아있는 문제가 있으면 코딩 세션으로 다시 보냅니다.
유용한 결과물은 상대방이 자신의 휴대폰에서 열어볼 수 있는 작동하는 미리보기입니다. 단순히 스크린샷을 승인하고 나중에 버튼이 장식용이라는 것을 발견하는 대신, 실제로 상호작용해 볼 수 있습니다.
막연한 불만이 사용하고 검토할 수 있는 수정된 경험으로 바뀝니다. 팀이 번역을 수행했고, 당신은 그것이 할 수 없는 결정을 내립니다.
반복되는 이메일이 들어옵니다. 작은 유틸리티가 나옵니다.
그리고 모두가 같은 사소한 계산을 손으로 처리하기 때문에 계속 돌아오는 이메일이 있습니다.
'이러한 요구사항에 어떤 옵션이 적합할까요?'라는 질문과 제약 조건 목록이 뒤따릅니다. 누군가가 시트를 열고, 입력을 복사하고, 규칙을 확인하며 답을 작성합니다. 다음 주가 되면 다른 입력값으로 의식이 돌아옵니다. 축하합니다. 당신의 받은 편지함에는 수동 API가 생겼습니다.
당신은 팀에게 이렇게 요청할 수 있습니다:
이 반복되는 요청을 보세요. 합의된 규칙들을 사람들이 직접 사용할 수 있는 작은 도구로 만드는 것을 도와주세요. 이때 이메일을 노출하거나 새로운 규칙을 만들 필요는 없습니다.
Instinct는 어떤 입력값이 중요한지 파악하고, 당신과 함께 규칙을 확인하며, 간략한 설명에서 개인적인 맥락을 제거합니다. OpenCode는 승인된 로직을 기반으로 예시와 검사를 포함하는 유틸리티를 구축합니다.
결과물은 간단한 적격성 검사기가 될 수 있습니다. 누군가가 자신의 요구사항을 입력하고 어떤 옵션이 적합한지, 그리고 그 이유가 무엇인지 확인할 수 있습니다. 해결되지 않은 경우는 자신 있게 꾸며낸 답변을 받는 대신 그대로 해결되지 않은 상태로 유지됩니다.
이제 다음 사람은 복사할 설명서가 아닌, 시도해 볼 도구를 얻게 됩니다. 이메일이 게시되는 것이 아니라, 승인된 프로세스가 재사용 가능한 무언가로 변환되고 있는 것입니다.
이는 다른 형태의 동일한 팀 역학입니다. Instinct는 코드 주변의 작업을 이해합니다. OpenCode가 그 사물을 만듭니다. 당신은 규칙과 공유 여부를 승인합니다.
이 예시들 중 어느 것도 두 에이전트 없이는 불가능하지 않습니다. 매력적인 점은 더 이상 사람이 모든 출처, 불만 사항 및 반복 요청을 수동으로 기술 명세서로 만들고, 그 모든 답변을 다시 전달할 필요가 없다는 것입니다.
두 에이전트, 인간의 잡무 감소
목표는 올바른 이유로 방해받는 것입니다.
"이 디자인들 중 어떤 것이 더 마음에 드세요?"라는 질문은 유용한 방해입니다.
"제 마지막 메시지를 다른 앱에 복사해주세요"라는 요청은 대화인 척하는 케이블과 같습니다.
코딩 응답은 요청의 일부가 완료되었다고 말할 수 있지만, 또 다른 부분은 결정이 필요합니다. 그로 인해 당신이 휴대폰에서 터미널 기록을 해독해야 하는 상황이 생겨서는 안 됩니다. PM(Product Manager)은 명확한 언어로 결정을 전달하고, 그 답변을 코딩 세션으로 다시 가져와야 합니다.
수정 사항이 코드 검사를 통과하더라도 브라우저에서 여전히 잘못 보일 수 있습니다. PM은 마지막 문장이 자신감 있게 들렸다고 승리를 선언하기보다는, 그 증거를 개발자에게 돌려줄 수 있어야 합니다.
"제 컴퓨터에서는 되는데요"는 오래된 고전입니다. 이것을 "제 요약본에서는 되는데요"로 대체할 필요는 없습니다.
역할은 맥락을 유지해야 합니다. 어시스턴트는 요청과 함께 머물러야 하고, 개발자는 코드와 함께 머물러야 합니다. 후속 작업은 메시지를 보낼 때마다 프로젝트를 기억하지 못하는 낯선 사람에게 소개하는 대신, 동일한 코딩 세션으로 돌아갈 수 있어야 합니다.
제가 이 팀에게 바라는 것은 이것입니다. 제가 무언가를 붙여넣을 때만 움직이는 작업이 아니라, 제 결정 사이를 계속해서 움직이는 작업 말입니다.
다리(The bridge)는 복도와 같다
다리는 작업을 OpenCode 기계로 전달하고 출력, 브랜치 및 세션 정보를 반환합니다. 이는 두 팀원을 감독하기 위해 고용된 세 번째 천재가 아니라, 팀원들 사이의 연결고리입니다.
또한 다리가 마법처럼 브라우저나 항상 켜져 있는 컴퓨터, 또는 품질 보증 시스템이 되는 것도 아닙니다. 시각적 검토에는 시각적 도구가 필요합니다. 기계는 사용 가능해야 합니다. 결과물은 여전히 확인이 필요합니다.
첫 번째 버전은 대화형 코딩 핸드오프를 제공합니다. 제가 구축하고 싶은 것은, 명확한 브리프(briefs), 유용한 증거, 그리고 적절한 순간에 돌아오는 질문들로 둘러싸인 더 풍부한 팀 워크플로우입니다.
제가 이것이 나아가길 바라는 방향
개인 비서(Personal assistants)와 코딩 에이전트(coding agents)는 각기 다른 영역에서 계속 개선될 것입니다. 저는 어느 하나의 제품이 모든 면에서 최고가 되기를 기다리기보다는, 이 두 가지 모두로부터 이점을 얻고 싶습니다.
더 나은 개인 비서는 요청과 그 주변의 맥락을 더 명확하게 이해할 수 있을 것이며, 더 나은 코딩 에이전트는 그러한 간략한 설명을 더 나은 구현으로 바꿀 수 있을 것입니다. 이 둘의 '인계(handoff)'가 이러한 개선점들을 만나게 하는 핵심입니다.
그렇기 때문에 저는 이 조합 자체가 휴대 가능해지기를 바랍니다. 팀을 유지하되, 좋은 이유가 생길 때마다 팀원 중 한 명을 교체하는 방식입니다. 제가 오늘 사용하는 조합은 Instinct와 OpenCode입니다. 다른 비서나 코딩 에이전트들은 자체적인 통합(integration)이 필요할 것이며, 이것들을 교체하는 것이 방향성이지, 모든 조합에서 이미 지원되는 기능은 아닙니다.
저는 어느 하나의 플랫폼이 승리할 것이라고 베팅하지 않습니다. 저는 두 가지 개선 곡선 모두를 타고 싶습니다.
소스 코드는 여기입니다: [https://github.com/sharkwani/instinct_openCode_bridge]
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기