AI

레이아웃 테스트 중에 가장 까다로운 부분 중 하나는 코드 로직 상의 부분도 물론 중요하지만, 레이아웃을 클릭하고 원하는 결과 값을 잡아내는 일입니다. 특정 해상도에서는 버튼이 잘리거나, 목록이 겹쳐보이고, 핵심 정보가 노출되지 않는 등의 일반적인 단위 테스트만으로는 발견하기 어려운 경우가 있습니다. 특히 사내에서는 기능 개발 전 SRS(소프트웨어 요구사항 명세서)로 정리되는 요구사항이 많으면 많을수록, 놓치는 구현사항들이 생기기마련인데 이를 Jira DC(Data Center) MCP와 Brower Skill을 함께 사용하여 요구사항 분석부터 실제브라우저에서의 레이아웃 검증까지 연결하여 이를 해결하고자 했습니다. 테스트 하기 전 제약사항으로는 사내의 업무망은 일반적인 회사와 다르게 폐쇄망으로 구성이 되어있어 내부 프록시에서 허용한 URL만 접근이 가능하고, 인터넷이 차단되어 서비스기업처럼 자유롭게 무언가를 이용하지 못한다는 제한점을 가지고 있었습니다. 요구사항이 매번 흐려진다. SRS를 작성하고, 소프트웨어 요구사항들을 개발자가 파악할 때 텍스트가 길어지면 길어질수록 놓치는 요구사항들이 분명히 생깁니다. 예를 들어 아래와 같은 요구사항들이 명시되어있다고 가정해봅시다. 관리자 화면의 검색 영역을 개편한다. 좁은 화면에서도 필터와 검색 버튼이 깨지지 않아야한다. 목록의 주요 컬럼은 가로 스크롤 없이 확인할 수 있어야한다. 저장 버튼은 화면 크기와 관계없이 접근 가능하다. A 데이터 조건이 왔을 때 B 데이터가 노출되어야하고, C 데이터 조건이 왔을 때는 D 데이터가 노출되는 것과 같이 조건부 렌더링이 성립해야한다. … 그 외 N개가 넘는 요구사항들이 존재합니다. 위 요구사항들이 모두 충족되었다고 해도, 수정 이후 기존 기능에 사이드 이펙트가 발생했는지 기존 화면에 대해서도 회귀 검증을 진행해야합니다. TF에서 공식적인 팀으로 변화되기까지 정식적인 QA 절차가 없다보니 점점 늘어나는 메뉴에 핫픽스 빈도는 점점 늘고있기 때문에 이를 해결하고자 했습니다. Browser Skill의 채택 이유

AI 리터러시가 과연 무엇일까요? 요즘은 검색, 글쓰기, 번역, 이미지 제작, 업무 정리까지 AI를 활용하는 일이 점점 자연스러워지고 있습니다. 하지만 AI를 사용한다는 것과 AI를 잘 활용한다는 것은 조금 다른 이야기입니다. 이 차이를 만드는 능력을 AI 리터러시라고 합니다. AI리터러시란 인공지능의 특성과 한계를 이해하고, 필요한 상황에서 적절하게 활용하며 결과를 비판적으로 판단하는 능력을 마합니다. 쉽게 말해 AI에게 좋은 질문을 하고, 나온 답변을 검토한 뒤 책임있게 사용하는 역량을 뜻합니다. AI는 빠르게 정보를 정리하고, 글의 초안을 만들고, 아이디어를 제안하는데 매우 유용한 도구라고 생각합니다. 하지만 항상 정확한 답을 주는 것이 아니기도 합니다. 실제로 존재하지 않는 정보나 출처를 마치 그럴 듯하게 만들어 내기도 하고, 오래된 정보를 바탕으로 답변할 수도 있습니다. (이를 AI 할루시네이션이라고도 합니다) 그래서 AI를사용할 때는 “AI가 말했으니 맞겠지” 라고 바로 신뢰하기 보다는 중요한 정보는 한번 더 확인하는 태도가 필요합니다. AI 리터러시는 크게 4가지 정도로 생각할 수 있습니다. AI가 잘하는 일과 부족한 일을 이해해야합니다. AI는 요약, 번역, 초안 작성, 아이디어 발상 같은 작업을 빠르게 처리하는데 강합니다. 반면 최신 정보를 확인한다거나, 정확한 사실 판단, 개인 상황에 대한 최종 의사결정에는 한계가 있습니다. 목적에 맞게 질문하는 능력입니다. AI의 답변 품질은 질문의 구체성에 크게 영향을 받습니다. 예를 들어 “영어 공부 계획을 짜줘” 라기보다는 “영어 초보자를 위한 하루 40분, 4주짜리 토익 공부 계획을 표로 만들어줘” 라고 구체적인 질문으로 요청하는 편이 훨씬 빠르고 실용적인 결과를 얻을 수 있습니다. (요 근래에는 에이전트가 똑똑해져서 뭉뚱그려한 질문에 대해서는 재질문을 하는 경우도 많아졌습니다, 이 과정이 에이전트가 질문을 구체적으로 만들어가는 과정이라고 생각할 수 있습니다) 결과를 검증하는 능력입니다. 특히 의료, 법률, 금융, 뉴스처럼 잘못된 정보가 큰 영향을 줄 수 있는 분야는 반드시 공식 자료나 전문가를 통해 확인해야합니다. AI는 유용한 출발점이 될 수 있겠지만, 최종 판단을 대신해주는 존재는 아닙니다.

회사에서 발표를 해야해서 만든 AI를 통해 활용하고 있는 영역들 레이아웃 개발의 경우, 인공지능에게 맡기고 나는 중요 비즈니스 로직을 작업합니다. 레이아웃을 직접 개발해도 되지만, 일부 디자인 시스템 규격들이 구축되어있는 경우에는 에이전트에게 내부 디자인 컨텍스트를 제공하고 이를 통해 서비스 디자인 컨셉을 따라 디자인 시안으로 레이아웃 개발을 맡깁니다. 피그마 MCP를 활용해도 무방하며, 요새는 OCR.. 이라고해야하나 스크린샷을 뜨고 에이전트에게 제공을 해도 잘 읽고 잘 수행합니다. 그 외 단순 반복적인 작업인 경우에도 에이전트에게 명확한 요구사항 지시를 통해 시키곤 합니다. 중요 비즈니스 로직도 에이전트에게 맡기고 검증하면 되지라는 질문을 할 수 있는데, 어쩌면 에이전트 생각 구조 자체가 프로젝트의 전반적인 부분들을 읽고 파악하기 때문에 저보다 더 잘 구성할 수 있다고도 생각을 하는데요. 다만 주요 비즈니스 로직까지 에이전트에게 양도를 하게 되면 유지보수 측면이나, 누군가에게 코드를 설명할 때 어려움이 생깁니다. 그래서 주요 비즈니스 로직을 구성할 때는 되도록이면 코드 어시스턴트 느낌으로만 사용하고 있습니다. 그러다보니 실제로 신규 기능을 만드는 시간도 데이터 구조 파악과 레이아웃 구성에 4~5시간 애를 먹었다면 현재는 1~2시간 만에 빠르게 마치고 다음 작업을 이어할 수 있게 되었습니다. 만약 발표해야하는 시점이 있다면, PPT 초안 흐름을 에이전트가 작업합니다. 예전에는 PPT의 디자인부터 기승전결 흐름을 모두 기확하며 제작을 했다면, 현재는 내가 처한 상황과 발표 자료를 위한 내용들, 디자인 컨셉들을 컨텍스트로 제공을 해주면 에이전트가 알아서 발표 자료를 만들어주는 시대가 되었습니다. 실제로 최근에는 코드 작성을 하게 되면 에이전트가 코드를 작성하고, 유저 인터페이스를 보여주고, 디자인 원페이저를 만들어주고, 결과물에 따른 최종 보고서를 만들어주는 일련의 과정들을 경험해보면서 이전에는 경험해보지 못한 업무 상의 극 효율들을 체감해보고 있습니다. 실제로 사내 프론트엔드 아티클 공유 자리에서의 발표자료들도 에이전트가 1차로 만들어주고, 2차 수정은 제가했었습니다.

A2UI (Agent-to(2)-User Interface)는 AI 에이전트가 사용자에게 풍부하고 인터렉티브한 UI를 생성하여 제공할 수 있도록 돕는 구글의 오픈소스 프로토콜이자, 표준입니다. 생성형 AI가 텍스트, 이미지, 코드를 생성하는 데는 탁월하지만, 복잡한 사용자 인터페이스를 구성하여 전달하는데는 여전히 어려움을 겪고 있습니다. A2UI는 에이전트가 단순히 텍스트로만 응답하는 것을 넘어서, 현재 대화 맥락에 가장 적합한 UI를 직접 생성하고 이를 프론트엔드 어플리케이션으로 전송할 수 있는 표준 형식을 제공합니다. (이전에 에이전트로부터 유저 인터페이스를 구축했던 조직들의 경우, 그 조직 별 규칙을 세우고 진행했을 확률이 높습니다) 오늘날 AI 에이전트는 점점 더 복잡한 작업을 수행하고 있습니다. 예를 들어 예약을 해야할 때, 에이전트로부터 텍스트로 날짜와 시간을 묻고 답하는 것은 어쩌면 비효율적일 것입니다. 에이전트가 Date Picker 컴포넌트나, 슬라이더와 같은 UI 요소를 노출시키며 사용자에게 선택지를 제공한다면 사용자 경험은 훨씬 향상될 것입니다. 하지만 보안 문제와, 플랫폼 호환성 문제로 인해 원격 에이전트가 로컬 어플리케이션의 화면을 직접 제어하거나 임의의 코드를 실행하게 하는 것은 위험합니다. A2UI는 이러한 문제를 해결하기 위해 "에이전트가 유저 인터페이스라는 언어를 말하게 하자 ㅡ Speak UI" 라는 철학 아래 개발되었습니다. 에이전트는 화면을 어떻게 그릴지 구체적으로 명령하는 코드가 아니라, 선언적인 데이터 형태(JSON)로 의도를 전달합니다. 클라이언트는 이 데이터를 받아 자신의 플랫폼(Web, Mobile, Desktop)에 맞는 네이티브 컴포넌트로 렌더링을 합니다. 이 방식은 보안을 유지하면서도 에이전트가 주도하는 동적인 인터페이스 구성이 가능해지는 보안성, 속도, 그리고 사용자 경험을 모두 만족시키는 새로운 접근법이 됩니다. 구글이 제안하는 A2UI를 기존 사용자와 에이전트 사이의 인터페이스들과 비교해보면 아래와 같습니다.

최근에 전직장 멘토님과 이야기를 하면서, 전 직장에 AI 플로우가 도입되고 있다는 것을 알게되었다. 이야기 중에 PRD(Product Requirements)와 WRD(Work Requirement Document)를 먼저 정의해놓고 개발을 진행하신다는 이야기를 듣게 되면서, PRD와 WRD가 대체 무엇인지 그리고 이 두가지 문서를 사용하게 되면 어떤 이점들이 있는지 알아보고자 한다. 처음엔 에이전트에게 "기능 만들어줘"라고 입력하는 것으로만 기능 구현을 할 수 있었지만, 프로젝트가 커질수록 담고있어야하는 컨텍스트 크기 뿐만 아니라 기능에 대한 정의가 이전 대화 기록으로 남아있어 사용자는 기억하기 쉽지 않았다. 만약 컨텍스트가 초기화되면 이전 요청한 기능들을 다시 기억하게 해줘야하는 순간들도 생각보다 많다 ^,^.. AI가 앞에서 했던 맥락을 잊어버리거나, 같은 기능을 요청했는데 매번 다른 구조로 짜주거나, 토큰이 터져서 대화 자체가 중단되는 순간들도 빈번하다. AI 기반 개발 방식이 자리를 잡으면서, 프롬프트 한 줄로 코드를 생성하는 것 이상의 체계가 필요해졌다. 그 중심에 PRD(Product Requirements Document)와 WRD(Work Requirement Document)를 먼저 작성하고, 이를 기반으로 AI가 구현하게 만드는 흐름, 일명 "플로우(Flow)" 방식이 있다. 왜 이 방식이 사용되고 있을까? AI 코딩 도구가 처음 나왔을 때, 대부분의 사용법은 단순했다. 프롬프트로 함수 하나를 만들고, 수정하고, 반복하는 식이었다. 그런데 GPT-4 급의 모델이 대화 컨텍스트를 길게 유지하면서 더 복잡한 작업을 하게 되자, 기존 방식의 한계가 드러났다. AI에게 프로젝트 전체를 설명하려면 대화 초반부터 엄청난 토큰을 소모하게 된다. 매 세션마다 같은 배경을 반복 설명해야 하고, 맥락이 흐릿한 상태에서 생성된 코드는 전체 구조와 맞지 않는 경우가 많다. 그 대안으로 나온 것이 문서를 먼저 작성하고, 그 문서를 AI의 참고 자료로 삼는 방식이다. 소프트웨어 개발에서 PM이 작성하던 PRD의 개념을 AI 개발 워크플로우에 끌어들인 것이다. WRD는 그보다 한 단계 더 내려가서, 실제로 어떤 기능들을 만들 것인지를 정리한 문서다.