파이어베이스 스튜디오에서 에이전트 AI 활용하기 : zum 뉴스

지금 AI의 화두는 에이전트다. 소프트웨어 엔지니어링에 에이전트 AI를 활용하는 방법은 다양하다. 일부 에이전트는 개발자 환경과 독립적으로, 사실상 원격 개발자처럼 작동한다. 예를 들어 코그니션 AI(Cognition AI)의 데빈(Devin)에는 셸, 코드 편집기, 웹 브라우저를 모두 갖춘 자체적인 작업 공간이 있다. 이와 달리 개발자의 환경 내에서 작동하면서 셸, 편집기, 디버거, 기타 툴을 공유하는 에이전트도 있다. 구글의 파이어베이스 스튜디오(Firebase Studio, 구 프로젝트 IDX)가 이 유형에 해당하며, 구글 제미나이 대규모 언어 모델을 활용해 개발자가 공유 환경에서 애플리케이션을 프로토타이핑하고 빌드하는 과정을 지원한다.

AI 어시스턴트는 자동차의 파워 스티어링과 같다. 즉, 통제권은 운전자인 프로그래머에게 그대로 있고 툴은 그 힘을 증폭하는 역할을 한다. 개발자가 코드를 입력하면 어시스턴트는 함수를 완성해 코딩 프로세스 속도를 높여준다. 자연스럽게 떠오르는 그 다음 단계는 테스트를 실행하고 코드를 디버깅하고 UI 모형을 만들거나 기타 작업을 스스로 수행할 수 있는 역량을 어시스턴트에 부여하는 것이다.

파이어베이스 스튜디오는 에이전트가 적절한 동작을 수행하도록 지시하는 프롬프트를 입력할 수 있는 호스팅되는 환경을 제공한다. 이런저런 일을 하도록 지시하면 제미나이는 사용자의 의도를 실행에 옮겨 파일을 변경하거나 명령을 실행한다. 이것이 프롬프트에 대한 응답을 제공하는 데 국한되는 어시스턴트와 에이전트의 본질적인 차이점이다.

상점 만들기

파이어베이스의 제미나이에는 프롬프트를 통해 앱 아이디어를 탐색할 수 있는 앱 프로토타입 제작 에이전트가 포함돼 있다. 프롬프트 창에 “아웃도어 장비를 판매하는 상점을 만들자”고 입력한다.

Matthew Tyson

제미나이가 응답으로 앱 프로토타입 제작을 위한 계획을 제공한다. 여기서 볼 수 있듯이 제미나이의 계획에는 제품 카탈로그, 제품 필터링 툴, 장바구니가 포함돼 있다. 또한 몇 가지 스타일 가이드라인도 제시한다.

Matthew Tyson

이제 “이 앱 프로토타입 만들기(Prototype this App)” 버튼을 클릭한다.

Matthew Tyson

괜찮아 보인다. 이것으로 이미 UI가 만들어졌다. 가격 범위 슬라이더에 조절 노브 하나가 빠져 있지만 어쨌든 동작은 한다. 조작하면 오른쪽에 보이는 제품이 실제로 필터링된다. 카테고리 선택기도 작동한다. UI의 반응성도 좋고, 창 크기 조절에 따라 레이아웃도 잘 처리된다. 제품 설명과 이미지 모두 AI가 생성했다. 이미지는 무의미하지만 어쨌든 테스트 데이터일 뿐이다.

이건 시작에 불과하다. 사용할 기술 스택을 아직 지정하지 않았다. 앱이 구현되는 방법에 대해서는 알 수 없지만 AI 에이전트는 대략적인 수준의 프롬프트를 받은 다음 환경 내에서 스스로 움직여 필요한 작업이 수행되도록 했다.

파이어베이스 개발 환경

이 환경은 흥미롭다. 파이어베이스 스튜디오는 지금 보이는 미리보기 창과 관리형 클라우드 VM 인프라를 제공하며, 여기에는 코드를 실행하고 내부를 조작할 수 있게 해주는 컴퓨팅 및 기타 리소스가 포함돼 있다. 제미나이 AI 모델이 생성한 내부 구조를 살펴보자.

“코드 편집(Edit the Code)” 버튼을 클릭하거나 입력 상자를 사용해서 변경하려는 내용을 설명할 수 있다.

우선 입력 상자에 다음과 같은 프롬프트를 입력했다.

가격 범위 슬라이더에 오른쪽 조절 노브가 없는데 고칠 수 있어? (The price range slider is missing a knob on the right hand side of the slider, can you fix that?)

몇 분 후 슬라이더가 수정된 미리보기가 다시 로드됐다. 또한 제미나이는 변경된 파일로 .vscode/settings.json 파일과 src/components/ui/slider.tsx도 출력했다. 두 번째 파일은 당연한데 첫 번째 파일은 제미나이가 왜 수정했는지 알 수 없어서 클릭해봤다. 다음과 같은 내용이 포함된 .vscode/settings.json 파일이 가운데 창에 열렸다.

{
    "IDX.aI.enableInlineCompletion": true,
    "IDX.aI.enableCodebaseIndexing": true
}

이걸 보니 실제로 코드를 살펴보고 싶었다. “코드 편집”을 클릭하면 다음과 같은 비주얼 스튜디오 코드가 웹으로 구현된 IDE로 이동된다.

Matthew Tyson

웹용 마이크로소프트 VS 코드의 레이아웃과 비슷하다. 다만 그 경우에는 IDE를 VM에 연결하는 반면 파이어베이스 스튜디오에는 관리되는 내부 환경이 있다.

파일 탐색기에서 파이어베이스 스튜디오가 Next.js 앱을 제공한 것을 볼 수 있다. 기본값으로 합당한 선택이다. 프론트엔드와 백엔드를 모두 처리할 수 있는 자바스크립트/타입스크립트 스택이 제공된다. 이 말은 이와 같은 호스팅 환경(예를 들어 Next.js를 만든 버셀(Vercel))에서 잘 작동하는 간단하고 정해진 배포 경로가 있다는 의미이기도 하다.

파이어베이스 환경은 깃허브와 잘 통합되므로 이 부분에서 필요한 모든 작업을 수행할 수 있다는 점도 주목할 만한 부분이다. 예를 들어 기존 깃허브 리포지토리에서 이 앱을 실행할 수도 있다.

Next.js 앱에 포함되는 일반적인 구성요소 외에 /.idx/dev.nix라는 파일도 있다. 이는 환경 파일로, Nix 패키지 관리자를 사용해서 VM에 어떤 툴과 패키지가 설치되는지를 설명한다.

파이어베이스에서 제미나이와 채팅하기

파이어베이스 스튜디오의 오른쪽 창에는 미리보기와 제미나이, 두 개의 탭이 있으며 제미나이를 열면 AI 챗봇에 액세스할 수 있다. 테스트를 위해 다음과 같은 일반적인 질문을 해봤다.

이 앱이 어떻게 작동하는지 설명할 수 있어? 데이터는 어디서 가져와? (Can you describe how this app works? Where is the data coming from?)

제미나이는 전체적인 구조와 사용되는 기술에 대해 잘 설명했지만 필자의 관심을 끈 부분은 다음과 같다.

- 외부 API 없음: 파일 목록에 외부 API 호출을 명확히 보여주는 항목이 없습니다. 만약 있다면 데이터를 불러오는 라이브러리(예: axios 또는 fetch)나 API 관련 코드가 포함된 파일을 볼 수 있을 것입니다.
- 데이터베이스 파일 없음: 마찬가지로, 클라이언트 측 코드 내에 데이터베이스에 직접 연결된 것으로 보이는 파일이 없습니다.

실제 상황이라면 처리해야 할 중요한 아키텍처 부분이다. 그렇다면 이것을 추가할 계획에 대한 제미나이의 생각을 물어보자. 다음과 같이 질문한다.

이 데이터를 라이브로 사용 가능하도록 만들고 싶은 경우 CRUD가 가능한 실제 데이터를 사용하는 가장 간단한 경로는 뭐야? (If we wanted to make this data live, what steps would you suggest for the simplest path to using real data that can be CRUDed?)

제미나이는 몽고DB, 포스트그레SQL을 비롯한 몇 가지 합리적인 방법을 제안했다. 눈에 띄는 부분은 다음과 같다.

파이어베이스 : 파이어베이스 파이어스토어를 데이터베이스로 사용하고 파이어베이스 SDK를 Next.js 앱에서 활용하면 별도 백엔드 서버의 필요성이 최소화되고 내장된 인증과 보안 규칙이 제공되므로 매우 간편한 접근 방식이 될 수 있습니다.

파이어베이스 파이어스토어는 구글의 호스팅되는 데이터 API이며, 나쁘지 않은 선택이다. 이미 구글 클라우드 서비스를 사용 중인 데다 파이어스토어는 필요한 모든 규모를 처리할 수 있는 API 기반 데이터 저장소를 제공할 수 있기 때문이다. 여기서 구글이 파이어베이스 스튜디오 액세스를 무료로 제공하는 이유 중 하나를 볼 수 있다. 바로 다른 구글 클라우드 서비스와의 통합이다. 구글은 자체 클라우드와 개발자 간에 공생 관계를 원하며, 개발자들도 이 공생 관계의 혜택을 누릴 수 있다.

파이어베이스 파이어스토어 활용하기

이제 제미나이가 무엇을 할 수 있는지 확인하기 위해 다음과 같이 입력한다.

파이어스토어와 통합을 구현해. 필요한 Next.js 서비스를 생성하고 새 데이터 저장소와 연결하고 몇 가지 테스트 데이터를 채워 넣고 새로운 백엔드를 사용해 UI가 정상적으로 작동하도록 해. (OK, go ahead and implement integration with Firestore, create whatever Next.js services are necessary, wire them together with the new data store, populate it with some test data, and make the UI work using that new backend.)

제미나이의 응답은 다음과 같다.

이 요청은 백엔드 서비스, 데이터베이스 통합, 프론트엔드 UI 등 애플리케이션의 다양한 부분에 걸쳐 여러 단계가 필요한 매우 복잡한 요청입니다. 구현하기 위해서는…죄송하지만, 제가 도와드릴 수 없는 일입니다. (This is a significant request that involves multiple steps across different parts of the application (backend services, database integration, and frontend UI). To ensure I can implement this… I’m sorry, but I can’t help you with this.)

다시 이렇게 입력한다.

그럴 줄 알았어! 그럼 프로세스를 시작할 수 있도록 도와줄 수 있나? 먼저 파이어스토어를 프로비저닝하고 커넥터를 추가하는 작업은 어때? (I knew it! OK, can you help me start the process? Maybe, start by provisioning Firestore and adding a connector to it?)

이 질문에 대해서는 제미나이가 도울 수 있다고 응답했지만 이를 위해서는 다음과 같은 몇 가지 정보가 필요하다고 했다.

- 파이어베이스 프로젝트 : 이 애플리케이션에 대한 파이어베이스 프로젝트가 이미 설정돼 있나요? 그렇다면 프로젝트 ID가 필요합니다. 그렇지 않은 경우 파이어베이스 콘솔에서 프로젝트를 만들어야 합니다.

- 파이어베이스 초기화 : Next.js 앱에서 파이어베이스는 어떻게 초기화되나요? 파이어베이스 구성을 위한 전용 파일이 있나요?
- 인증 : 파이어베이스 인증을 사용하나요? 이 부분은 파이어베이스에 대한 보안 액세스를 설정하는 데 중요합니다.

필자가 AI에 맡기면 좋겠다고 생각했던 실제 소프트웨어 개발 작업이 바로 이런 종류의 작업이다. 특히 개인적으로 싫어하는 인증 부분이 그렇다. 필자는 다른 창으로 옮겨서 계정을 설정하고 사용자와 프로젝트에 대한 ID를 받고 키와 인증서를 관리하는 일, 뭔가를 복사해서 앱에 붙여넣거나 어딘가의 키 저장소에 저장하거나 그 밖에 책임감 있게 관리해야 하는 모든 작업을 싫어한다.

여기서 막다른 길에 이른 것 같지만 다음과 같이 직접적으로 확인해 보자.

파이어스토어 인스턴스를 구축하고 그 과정에서 필요한 인증 관련 사항을 처리해줄 수 있어? (Can you please stand up a Firestore instance for me, and deal with whatever auth considerations are necessary?)

당연히 되지 않는다. 이렇게 시도해 보자.

알았어. 그럼 로컬 몽고DB 인스턴스를 설정하는 건 어때? (OK, OK. How about we set up a local MongoDB instance instead?)

제미나이는 이 질문에 대해서는 필요한 단계를 알려준다. 그러나 필자는 단계가 아니라 제미나이가 직접 행동하는 것, 즉 에이전시로 움직여 주기를 원한다. 이렇게 말해보자.

내 말은 네가 직접 필요한 툴을 모두 설치하고 몽고DB 서버를 설치하고 테스트 사용자와 데이터베이스를 만들어줄 수 있냐는 뜻이야. 가능해? (I mean, can you go ahead and install all the necessary tools, install the MongoDB server, create a test user and database in there?)

제미나이의 응답은 다음과 같다.

저는 로컬 컴퓨터에서 소프트웨어를 설치하거나 데이터베이스 서버와 같은 시스템 서비스를 관리하는 명령을 직접 실행할 수 없습니다. 제 기능은 제공된 터미널 환경 내에서 프로젝트 파일을 다루고 명령을 실행하는 것으로 제한됩니다. 시스템 수준의 설치나 구성은 수행할 수 없습니다. (I’m unable to directly execute commands on your local machine to install software or manage system services like a database server. My capabilities are limited to interacting with your project files and running commands within the provided terminal environment, but I cannot perform system-level installations or configurations.)

필자는 이와 같은 제한에 대해 알지 못했다. 미리 매뉴얼을 읽었다면 알았을 수 있지만 읽지 않았다. AI가 있기 때문이다. 툴의 기능을 그 툴에게 묻고 합리적인 답변을 얻을 수 있다는 것은 새로운 시대의 대표적인 특징이다.

관리자 페이지 작업

파이어스토어 백엔드 설정을 여기서 멈추고, 다음과 같이 묻는다.

괜찮아. 더 간단한 작업을 해보자. 기존 데이터에 새 항목을 추가할 수 있는 관리자 페이지를 만들 수 있어? 다른 모든 부분은 지금 상태로 두고, 아직 인증에 대해서도 신경 쓰지 말고 간단한 백오피스 페이지만 만들어. (Not to worry. Let’s do something simpler. Can you create an admin page that lets me add new items to our existing data? I mean, just leave everything else as is. Just a simple back office page, don’t worry about auth yet.)

제미나이는 여러 새로운 파일이 포함된 계획을 제시하며 다음과 같이 질문한다.

새 페이지 파일부터 만들어 보겠습니다. 관리자 페이지의 파일 이름은 무엇으로 할까요? 예를 들어 admin/page.tsx도 됩니다. (Let’s start by creating the new page file. What would you like to name the file for the admin page? For example, we could name it admin/page.tsx.)

이렇게 답한다.

그렇게 해. 필요한 변경 사항이 있으면 뭐든지 해. 다 마치고 나면 내가 확인할게. (Sure, just go ahead and make whatever changes you think are necessary, I’ll check it out when you are done.)

제미나이는 새 파일 변경 사항을 정의하는 대화상자를 표시하고 “파일 만들기(Create File)” 또는 “변경 사항 검토(Review Changes)” 버튼을 제공한다. “변경 사항 검토”를 클릭하면 제안된 page.tsx에 대한 비교 파일이 표시된다. 괜찮아 보여서 “파일 만들기”를 클릭한다. 제미나이가 바삐 움직이고, 새로운 src/app/api/products/route.ts 파일에 대해서도 위와 비슷한 대화상자를 표시한다. 이는 백엔드에서 Next.js 경로를 처리하게 된다.

제미나이는 이제 이렇게 말한다.

이제 브라우저에서 /admin 경로로 이동해서 관리자 페이지에 접속하고 새 제품을 추가할 수 있습니다. (You can now navigate to the /admin route in your browser to access the admin page and add new products.)

필자는 관리자 페이지로 가는 링크가 필요하다는 점을 지적하고, 제미니도 동의한다. 또 다른 변경 사항을 확인하고(src/components/layout/header.tsx 파일) 페이지를 다시 로드하자 관리자 링크가 표시된다. 클릭하면 간단한 입력 양식이 열린다.

Matthew Tyson

테스트 데이터를 입력하고 “제품 추가(Add Product)”를 클릭한다. 제미나이가 이미지 URL이 필수라고 해서 “foo”를 입력하자 이제 제출이 수락된다.

빈틈 채우기

제품 유형이 없는 관계로, 어떻게 필터링해야 이 새로운 항목이 실제로 표시되는지 여부를 확인할 수 있는지 확실치 않다. 또한 새로운 관리자 페이지에는 홈페이지로 돌아가는 링크가 없어서 뒤로 가기 화살표를 사용해야 한다. 그래도 제미나이는 이 페이지를 설정하기 위한 단조로운 작업의 많은 부분을 성공적으로 수행했다.

주 페이지로 돌아와도 목록에는 워그 부츠가 표시되지 않는다. 이전과 동일한 제품 목록이다. 제미나이에 products.tsx 파일의 내용을 보여달라고 요청하면 제미나이는 다음과 같이 표시한다.

export const products = [
  {
    "name": "Warg Boots",
    "description": "Keeps the dire wolf's paws warm and clean.",
    "price": 1000,
    "imageUrl": "foo",
    "id": "1746565585872"
  }
];

문제가 있다. 제미나이가 이 파일의 내용에 접근할 수 있다는 사실은 좋은데 이 항목은 목록을 대체하는 것이 아니라 목록에 추가돼야 한다. 주 페이지로 돌아가서 페이지 다시 로드하기를 클릭한다.

Matthew Tyson

오류다. 앱이 정상적으로 작동하지 않는 것 같다. POST 핸들러가 제품 목록을 업데이트하는 것이 아니라 다시 쓰는 것으로 보이며, 그보다 더 기본적인 부분에서도 뭔가 잘못돼 페이지가 로드되지 않는 상황이다.

문제가 생겼지만 특별한 일은 아니다. 이것도 결국 소프트웨어 개발이다.

단순 작업 덜어내기

프로그래머가 아닌 사람이 파이어베이스 스튜디오 또는 그와 비슷한 AI 기반 개발 환경에서 복잡한 애플리케이션을 빌드하는 수준에 이르려면 확실히 아직 갈 길이 멀다. 구글 클라우드 플랫폼, 제미나이, 파이어베이스 스튜디오는 각 해당 분야에서 최고의 툴인 만큼 이러한 제한은 모든 에이전트 AI 개발 시스템에 해당될 것이다.

그럼에도 필자는 코딩할 때 제미나이 어시스턴트를 배제하고 싶지는 않다. 막대한 양의 번거로운 작업을 덜어주고 더 큰 그림에 집중할 수 있게 함으로써 훨씬 더 많은 가능성을 가져다 주기 때문이다.

앞으로 어떤 방향으로 발전할지, 파이어베이스 스튜디오 및 이와 비슷한 툴이 성숙 단계에 이르기까지 얼마나 걸릴지 궁금하다. AI가 툴 내에서 직접 행동을 수행할 수 있는 이 형태가 미래의 한 부분이 될 것이라는 점은 분명해 보인다. 그 기간은 AI 열성론자들의 예상보다 더 길 수 있고, 어쩌면 우리가 상상하는 완벽한 결과는 영영 실현되지 않을 수도 있다.

이렇게 생각해 보자. 정말 AI 에이전트가 클라우드 대시보드에 들어가서 관리형 데이터 저장소, 사용자, 인증을 프로비저닝하고 준비할 수 있게 되기를 원하는가? 그렇다면 걷잡을 수 없이 늘어나는 클라우드 비용에 대해 이야기할 차례다.

dl-itworldkorea@foundryco.com