DEVOCEAN

터미널에서 프롬프트 몇 줄로 코드를 만들어내던 에이전트 도구가 실제 업무 화면을 만나는 순간 개발팀은 멈칫하게 됩니다. 에이전트가 생성한 UI 코드는 사내 디자인 시스템 컴포넌트 이름을 전혀 알지 못한 채 raw HTML과 인라인 스타일로 덮여 있고, 스마트폰 앱 제어 시나리오를 테스트하려 해도 폰마다 ADB(Android Debug Bridge)를 연결하거나 루팅 권한을 뚫어야 하는 번거로운 제약에 가로막히기 때문입니다. 개발자 개인의 로컬 터미널 안에서 맴돌던 생성형 AI 도구가 팀 단위 협업 시스템 및 모바일 모듈, 실제 UI 브라우저 런타임과 부딪힐 때 생기는 이 끊어짐 현상은 2026년 현재 많은 개발 조직이 공통으로 겪는 병목입니다.

오늘 소개하는 소식 중 세 가지는 바로 이 경계면을 다루고 있습니다. PC를 벗어나 모바일 단말기 화면을 직접 조작하는 에이전트, 팀 단위 협업 백로그 및 지식 베이스를 에이전트에 연결하는 협업 플랫폼 전략, 그리고 AI가 뱉어낸 산출물을 사내 디자인 시스템으로 매핑해 실제 프로덕션 코드로 전환하는 구조입니다. 이 세 기록은 AI가 더 이상 '혼자 쓰는 코드 생성기'에 머물지 않고 팀 협업과 프론트엔드/모바일 런타임의 구성 요소로 정착하기 위해 어떤 인터페이스 접점이 필요한지 보여줍니다.

모바일 접근성 트리를 통한 단독 화면 제어의 실무적 수용성

기존의 모바일 자동화 도구나 에이전트 실험은 주로 PC와 스마트폰을 USB로 연결한 뒤 ADB 명령어로 터치 좌표를 송출하거나 루팅, Shizuku 같은 별도 권한 획득 도구에 의존했습니다. 이 때문에 운영 환경과 동일한 샌드박스 단말에서 실행하기 어렵고 모바일 환경 고유의 앱 간 전환을 에이전트가 단독 수행하기가 까다로웠습니다.

OpenPhoneUse 프로젝트는 Android 11 이상 환경에서 ADB, PC 연결, 루팅, Shizuku 없이 모바일 단말 단독으로 동작하는 화면 조작 에이전트를 제시했습니다. 이 시스템은 안드로이드 OS의 접근성 서비스(Accessibility Service)를 활용해 화면의 접근성 트리(Accessibility Tree) 정보와 스크린샷 렌더링 결과를 동시에 인식합니다. 사용자 입력을 받아 탭, 텍스트 입력, 스크롤 이벤트를 생성하며 여러 앱을 직접 오가는 구조입니다.

그림 1. OpenPhoneUse가 화면을 인식하고 조작 이벤트를 만드는 흐름

여기서 DEVOTEE의 해석을 덧붙이자면, 접근성 트리를 텍스트 기반 뼈대로 삼고 캔버스나 지도 화면 같은 비텍스트 요소를 스크린샷 멀티모달 렌더링으로 보완한 점이 핵심입니다. 모바일 앱 UI는 DOM(Document Object Model, 웹 문서를 객체로 표현한 구조) 구조가 명확한 웹 화면과 달리 버튼이 캔버스 객체에 그려지거나 텍스트 레이블이 빠진 아이콘으로 처리되는 경우가 많습니다. 접근성 노드 뷰만으로는 클릭 위치의 정확한 좌표를 계산하기 어렵고, 스크린샷만으로는 화면 스크롤 시 위치 오차가 발생합니다.

개발 실무에서는 이를 QA 자동화나 사내 모바일 작업 시나리오 샌드박스로 수용할 수 있습니다. 예를 들어 앤드로이드 11 이상 단말에서 접근성 서비스 권한을 획득하고 ADB 연결 없이 에이전트를 가동하여 특정 UI 흐름을 테스트하는 방식입니다.

// OpenPhoneUse가 활용하는 Android 접근성 서비스 기반 노드 탐색 및 탭 이벤트 처리 구조 예시
package com.example.agent.accessibility

import android.accessibilityservice.AccessibilityService
import android.accessibilityservice.GestureDescription
import android.graphics.Path
import android.view.accessibility.AccessibilityNodeInfo

class AgentControlService : AccessibilityService() {

    override fun onAccessibilityEvent(event: android.view.accessibility.AccessibilityEvent?) {
        // 화면 상태 변경 이벤트를 수신하여 에이전트에 현재 뷰 트리 전달
    }

    override fun onInterrupt() {
        // 서비스 중단 시 처리
    }

    fun findAndClickNodeByText(targetText: String): Boolean {
        val rootNode: AccessibilityNodeInfo = rootInActiveWindow ?: return false
        val matchedNodes = rootNode.findAccessibilityNodeInfosByText(targetText)
        
        if (!matchedNodes.isNullOrEmpty()) {
            val nodeToClick = matchedNodes[0]
            if (nodeToClick.isClickable) {
                return nodeToClick.performAction(AccessibilityNodeInfo.ACTION_CLICK)
            }
        }
        return false
    }

    fun dispatchTapGesture(x: Float, y: Float) {
        val stroke = GestureDescription.StrokeDescription(
            Path().apply { moveTo(x, y) },
            0,
            100
        )
        val gesture = GestureDescription.Builder().addStroke(stroke).build()
        dispatchGesture(gesture, null, null)
    }
}

이 접근법에는 명확한 조건이 붙습니다. 이 도구는 조건부로 유효하다는 판단입니다. PC 없이 폰 내부에서 독립 가동된다는 장점이 뚜렷하지만, 접근성 서비스는 OS 보안 정책상 금융 앱이나 개인정보 입력 창에서 차단되거나 이벤트 전달에 지연이 발생할 수 있습니다. 따라서 실제 고객 단말 제어 서비스보다는 사내 모바일 앱 E2E 테스트 검증이나 내부 단말 작업 자동화 샌드박스 용도로 제한하여 도입해야 합니다.

단일 도구를 넘어 팀 백로그와 지식 그래프로 확장되는 AI 에이전트

개인 개발자의 터미널이나 폰 내부를 넘어설 때 부딪히는 두 번째 장애물은 '팀 문맥의 부재'입니다. 코드 자동 완성이 아무리 빨라져도, 그 코드가 어떤 Jira 이슈 티켓의 요구사항을 해결하는지, Confluence 기술 문서에 정의된 표준 데이터 구조를 따르는지 알지 못하면 리뷰 단계에서 반려됩니다.

암스테르담에서 열린 컨퍼런스 발표 내용을 다룬 Atlassian의 AI 에이전트 전략 보고서는 'The End of Single-Player AI'라는 명제를 제시합니다. 질문에 답변하거나 단일 파일 코드를 요약하는 개인 생산성 도구 단계를 넘어, 조직의 업무 흐름과 시스템 정보(Teamwork Graph)에 직접 연결되는 에이전트 오케스트레이션을 다룹니다.

이 발표에서 제시된 3가지 핵심 축은 Context(업무 이력 및 문맥 연동), Collaboration(팀원과 에이전트 간 역할 분담), Confidence(실행 결과의 검증 통제)입니다. 특히 MCP(Model Context Protocol, 외부 시스템과 AI 모델 간 문맥 전달을 위한 오픈 프로토콜)와 Rovo 엔진을 결합하여, Jira 백로그 상태 변경이 Confluence 문서 업데이트 및 Git 커밋 커맨드로 이어지도록 구성했습니다.

• 주요 입력 — 개인형 AI (Single-Player AI): 사용자가 직접 입력한 로컬 프롬프트 및 파일 단건 / 팀 통합형 AI (Multi-Player Agent): Jira 이슈 티켓, Confluence 기술 명세, MCP 인터페이스
• 실행 범위 — 개인형 AI (Single-Player AI): 로컬 IDE / 터미널 내 코드 샌드박스 / 팀 통합형 AI (Multi-Player Agent): 조직 지식 그래프(Teamwork Graph) 및 시스템 상태 연동
• 결과물 처리 — 개인형 AI (Single-Player AI): 개발자 개인이 수동으로 복사하여 PR 생성 / 팀 통합형 AI (Multi-Player Agent): 팀 백로그에 상태 등록 및 리뷰어 자동 할당

여기부터는 DEVOTEE의 해석입니다. Atlassian의 이 전략은 개발자들이 IDE에 갇혀 있던 AI 활용 범위를 기업 업무 프로세스로 끌어올렸다는 의미가 있습니다. 개발자가 CLI에서 코드를 수정할 때 에이전트가 Jira 티켓의 Acceptance Criteria(수용 조건)를 MCP 프로토콜로 직접 읽어온 뒤 테스트 케이스를 생성하고, 작업이 끝나면 티켓 상태를 'In Review'로 자동 전환하는 구조입니다.

이 방식은 지금 써볼 만하다는 판단입니다. 개발팀이 이미 Jira나 Confluence를 백로그 관리 도구로 사용 중이고 MCP 표준 인터페이스를 수용할 수 있다면, 개발자가 PR을 작성할 때 겪는 수동 입력 병목을 줄일 수 있습니다. 다만 MCP 커넥터가 가져오는 조직 데이터의 접근 권한 제어(Role-Based Access Control)가 선행되어야 안전하게 작동합니다.

Figma 스펙 수용을 통한 AI 생성 UI의 프로덕션 코드 전환

모바일 제어와 백로그 연결을 해결하더라도 프론트엔드 영역에는 여전히 커다란 구멍이 남아 있습니다. 바로 AI가 그려낸 UI 산출물이 실제 서비스 프로덕션 코드로 이어지지 못하고 버려지는 문제입니다.

네이버의 AI 산출물이 프로덕션이 되기까지 세션 발표에서는 AI가 뱉어낸 산출물이 개발 현장에 적용되지 못하는 5가지 원인을 짚고, 이를 해결하기 위해 HTML이나 이미지 등 어떤 형식의 입력이든 Figma로 일치시키는 전략을 공유했습니다.

AI 도구가 렌더링한 HTML/CSS는 사내 디자인 시스템(Design System)의 시맨틱 토큰(Color, Typography, Spacing token)이나 재사용 React 컴포넌트를 사용하지 않고 스타일 속성을 하드코딩하는 경우가 많습니다. 결과적으로 개발자는 AI가 만든 코드를 버리고 디자인 스펙을 다시 손으로 구현하게 됩니다. 발표에서는 디자인 설계자와 AI가 공유할 수 있는 단일 창구(Single Source of Truth)로 Figma를 설정하고, Figma 캔버스 내 노드를 사내 디자인 시스템 코드 스펙으로 자동 변환하는 매핑 레이어를 도입했습니다.

// AI 생성 뷰 노드를 사내 디자인 시스템 토큰으로 매핑하는 스펙 변환 예시 (Figma Plugin / Engine 연동용)
{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "componentId": "DS_Button_Primary",
  "mappedProperties": {
    "label": "확인",
    "variant": "solid",
    "size": "medium",
    "colorToken": "var(--color-primary-600)",
    "spacingToken": "var(--spacing-16)"
  },
  "rawAiOutput": {
    "tag": "button",
    "style": "background-color: #0066ff; padding: 16px; border-radius: 4px;"
  }
}

이 매핑 시스템이 작동하면 LLM이 생성한 레이아웃 구조가 Figma의 Auto Layout 노드로 변환되고, 사내 디자인 시스템 파서(Parser)가 이를 읽어 <Button variant="solid" size="medium"> 형태의 프로덕션 반응형 코드로 파싱합니다.

그림 2. AI 산출물이 Figma를 거쳐 프로덕션 코드가 되는 경로

이 전환 전략은 지금 써볼 만하다는 판단입니다. AI 도구가 뱉어내는 파편화된 HTML 코드를 프론트엔드 개발자가 일일이 수동 수정하던 비용을 크게 낮춥니다. 단, 사내 디자인 시스템의 Figma 컴포넌트 라이브러리와 실제 React/Vue 컴포넌트 프로퍼티 명세가 1:1로 정교하게 매핑되어 있어야 한다는 전제 조건이 필요합니다.

그 밖의 소식

본문 주제로 고르지 않은 항목 중 기술 실무 및 인프라 운영 관점에서 살펴볼 소식을 정리했습니다.

• kt cloud 웨비나: 클라우드 운영 모니터링 및 Observability 체계 구축: 클라우드 인프라 운영 시 상태를 시각화하고 문제 분석 속도를 올리기 위한 Observability 모니터링 체계 사례입니다.
• KHISC 2026: 의료 AX 보안 및 SecureBridge 솔루션: 의료 현장의 AI 전환 시 환자 식별 정보를 마스킹하고 국내 서버 처리 규제를 맞추는 프라이버시 보안 안전판입니다.
• Fireworks AI 보안 침해 및 Notion 데이터 영향: LLM 호스팅 공급업체의 보안 침해로 인해 ZDR(데이터 무보관) 계약 환경에서도 고객 API 키 교체가 필요했던 실무 경고 사례입니다.
• Show HN: Yogurt - 비공개 로컬 AI 회의 노트: 회의 봇을 통화에 초대하지 않고 로컬 단말에서 프라이버시를 보호하며 통화를 녹음하고 요약하는 MIT 라이선스 오픈소스 앱입니다.

직접 해 볼 수 있는 한 가지

팀 내 AI 에이전트 도입 시 발생하는 프로덕션 이탈을 줄이기 위해, 오늘 당장 개발 파이프라인에서 실행해 볼 수 있는 조치가 있습니다.

1. 디자인 시스템 프로퍼티 매핑 검증: 팀에서 사용하는 UI 컴포넌트(예: Button, Modal, Input)의 이름과 프로퍼티 정의가 AI 에이전트의 프롬프트 컨텍스트에 포함되어 있는지 확인하세요.
2. 시스템 린트(Lint) 규칙 추가: LLM이 생성한 코드에 raw hex 색상(#0066ff)이나 하드코딩된 inline style 속성이 포함될 경우 빌드 단계에서 경고를 내보내고 디자인 시스템 토큰 사용을 강제하는 Stylelint 규칙을 적용하세요.
3. MCP 커넥터 단간 테스트: Jira나 Github Issues와 로컬 에이전트 도구를 연결하는 MCP 서포터 환경을 구축하여 에이전트가 티켓 요구사항 문맥을 직접 수집하도록 프라이버시 제한 범위를 지정해 보세요.