Vibe Coding 시대, 에이전트와 '애플리케이션 위'에서 대화하고 싶다

서론

'바이브 코딩(Vibecoding)' 시대의 UI 프레임워크는 어떠해야 할까요? 결론부터 말씀드리자면, 사람과 에이전트가 실행 중인 애플리케이션을 공유하며 개발할 수 있어야 한다고 생각합니다. 애플리케이션에 직접 프롬프트를 작성하거나, 화면을 직접 편집하고, 에이전트가 애플리케이션을 조작하여 디버깅하는 것 같은 공동 개발 경험입니다.

저는 Python 데스크톱 UI 프레임워크인 Nuiitivet을 만들면서 이 생각에 도달했습니다. 본 글에서는 그 배경과 Nuiitivet에서 구현한 방법을 설명하겠습니다.

에이전트에게 애플리케이션을 만들게 하면 무슨 일이 벌어지는가

에이전트에게 맡기면 일단 작동하는 것은 만들어 줍니다. 좋은 시대가 되었습니다.

하지만 그것만으로는 완성된 경우가 거의 없습니다. 상상했던 것과 조금 다릅니다. 직접 만져봐야 개선점을 찾을 수 있습니다. 실행해 보면 버그가 있습니다. 그 후에도 에이전트와의 대화는 계속됩니다.

대화는 크게 두 가지로 나눌 수 있다고 생각합니다.

• Refine: 작동하는 것을 원하는 것에 가깝게 다듬어 가는 과정의 대화 -
• Debug: 이상한 동작을 고치는 과정의 대화

물론 둘 다 채팅으로 지시할 수는 있지만, 지시를 언어화하는 것이 번거로울 때가 있습니다.

Refine에서 말로 표현하기 어려운 것은 '어디'입니다. 부품이 많은 화면에서 수정하고 싶은 위치를 글로 특정하는 것은 수고롭습니다. '위에서 세 번째 카드, 오른쪽 버튼 아래의 여백'이라고 머릿속으로 생각하면서 글을 써야 합니다.

Debug에서 말로 표현하기 어려운 것은 '재현 절차'입니다. 버그가 발생한 후 자신이 했던 행동을 순서대로 적어 내려갑니다. 이것 역시 번거롭고, 기억 착오로 빠뜨리는 부분이 있으면 재현할 수 없습니다.

애플리케이션 위에서 대화한다는 아이디어

인간도 에이전트도 하고 싶은 것은 애플리케이션을 만드는 것입니다. 하지만 인간과 에이전트의 커뮤니케이션은 채팅 상에서만 이루어집니다. 저는 여기에 있어야 할 모습과의 격차가 있다고 느꼈습니다.

원래 마땅히 그래야 하는 모습은 무엇일까 생각하다 보니, 화이트보드에 쓰면서 토론하는 상황이 떠올랐습니다.

즉, 인간과 에이전트 모두 애플리케이션을 보고/조작하고/지시를 직접 작성하며 커뮤니케이션하는 형태가 이상적이지 않을까? 라고 생각했습니다.

애플리케이션 자체가 화이트보드가 되어 커뮤니케이션의 주역이 되는 것입니다.

아래에서는 구체적으로 Nuiitivet에서 어떻게 구현했는지, Refine과 Debug 순서로 살펴보겠습니다.

Refine: 화면 위에서 지시하기

애플리케이션 위에 프롬프트 쓰기

'어디'를 설명하는 것이 번거로울 때는 주석 모드(comment mode)로 직접 애플리케이션에 프롬프트를 작성합니다.

Ctrl+Shift+C<br>

(macOS는 Cmd+Shift+C)로 주석 모드에 진입하여, 수정하고 싶은 부품이 명확하다면 그 부품을 클릭하고 주석을 작성할 수 있습니다. 범위가 불명확한 영역을 지정하고 싶다면 드래그로 범위를 지정하는 것도 가능합니다.

작성을 마치면 채팅에서 /nuiitivet-see-comments라고 입력합니다. 이것은 Nuiitivet이 제공하는 스킬(skill)이며, 에이전트가 주석을 읽고 작성된 대로 애플리케이션을 수정해 줍니다.

아래 예시에서는 애플리케이션에 두 개의 주석을 달았습니다.

1: too much space, match the top (간격이 너무 넓다. 상단과 같은 간격으로 맞춰줘.)

2: outlined (디자인을 아웃라인으로 변경해 줘.)

애플리케이션에 직접 프롬프트를 쓸 수 있기 때문에, '어디'를 언어화하는 고민이 필요 없습니다.

레이아웃은 직접 만지기

프롬프트로 지시할 정도는 아닌 변경 사항이 있습니다. 크기(size), 정렬(alignment), 순서 등 레이아웃과 관련된 것입니다.

Ctrl+Shift+E<br>

(macOS는 Cmd+Shift+E)로 레이아웃 에디트 모드(layout edit mode)에 진입하여, 애플리케이션 화면을 직접 드래그하며 변경합니다. 변경 사항은 직접 소스 코드에 작성됩니다.

에이전트를 거치지 않기 때문에 그 자리에서 순식간에 끝납니다.

다만, 수정할 수 있는 것은 소스 코드에 리터럴(literal)로 적혀있는 값뿐입니다. width=200은 변경할 수 있지만, width=self.card_w는 (생략)

마찬가지로 변수나 수식으로 되어 있는 크기, 상태 관리에서 동적으로 결정되는 순서는 바꿀 수 없습니다. 이 경우 배지(badge)에 이유가 표시되고 파일에는 아무것도 기록되지 않습니다. 주석 모드이거나 평소처럼 채팅으로 지시합니다.

소스 코드로 이동하기

에이전트가 코드를 작성하게 되더라도, 사람들은 코드 리뷰를 하고, 익숙한 엔지니어라면 지시하는 것보다 직접 쓰는 것이 더 빠르기도 합니다.

Ctrl+Shift+Click

(macOS는 Cmd+Shift+Click)

으로 클릭한 컴포넌트의 코드로 이동할 수 있습니다.

이동된 코드의 경우 직관적으로 읽고 쓰기 쉽도록 설계되어 있어, 코드 리뷰나 직접 편집을 하기 쉬울 것입니다.

디버깅(Debug): 에이전트가 앱을 보고 조작하기

에이전트가 앱 사용하기

최근의 에이전트는 지시받지 않아도 단위 테스트(unit test)까지 수행해 줍니다. 하지만 실제로 작동시켜 보면 버그가 남아 있는 경우가 있습니다. 에이전트가 앱을 직접 만질 수 없기 때문입니다. 그래서 Nuiitivet에서는 에이전트가 다음을 할 수 있도록 MCP 서버를 준비했습니다.

• 보기: UI 컴포넌트의 트리 구조, 상태 관리 값, 스크린샷 -
• 조작: 클릭, 입력, 스크롤, 키 전송

아래는 에이전트가 직접 앱을 조작하여 버그를 발견하는 예시입니다.

Test the Events list in the running app. By spec, it lists only events from today onward.

(실행 중인 앱에서 이벤트 목록을 테스트하세요. 명세에 따라 오늘 이후의 이벤트만 나열합니다.)

에이전트의 마지막 메시지는 다음과 같았습니다.

Cause: the filter at readme_calendar_app.py:132 keeps only

day > self.today.day

, so today's events are dropped. It should be>=

(원인: readme_calendar_app.py의 132행 필터가 day > self.today.day만 유지하기 때문에 오늘 이벤트가 누락됩니다. >=여야 합니다.)

에이전트는 사람이 한 것도 본다

어떤 버그가 발생했을 때, 그 재현 절차를 에이전트에게 설명하는 것은 번거롭습니다. 특히 절차가 길다면 더욱 그렇습니다.

Nuiitivet은 MCP 서버를 통해 에이전트가 사람의 앱에 대한 조작 로그를 가져올 수 있게 했습니다. 재현 절차는 에이전트가 자동으로 가져오기 때문에, 굳이 상세하게 설명할 필요가 없습니다. (입력한 텍스트 자체는 기록되지 않으므로 개인 정보 걱정은 할 필요가 없습니다.)

아래 예시는 '가끔 실패하는' 경우입니다. 모든 조작이 기록에 남아 있기 때문에, 에이전트는 그것들을 비교하여 왜 가끔 실패하는지 발견합니다.

다음 지시를 내리자,

I added an event a little while ago, but it works sometimes and not others. Please investigate the cause.

(아까 이벤트를 추가했는데, 성공할 때도 있고 안 될 때도 있어요. 원인을 조사해 주세요.)

마지막으로 에이전트가 다음과 같은 답변을 내놓았습니다.

The bug isn't intermittent in the framework. It depends on how you confirm the dialog.

• First event (

이것들을 가능하게 하는 것들

새롭게 프레임워크를 만들 의미가 있었는가?

여기까지 소개한 기능들은 하나하나 보면 신선하지 않은 것들이 있습니다. 사람의 조작 로그를 읽는 것이 조금 특이할 정도입니다. 그래서, 프레임워크를 새로 만들지 않아도 기존 프레임워크에 기능을 추가하는 도구로 충분하지 않았을까?라는 의문이 생길 수 있습니다.

솔직히 말하면, 그럴 수도 있습니다. Nuiitivet은 실험적인 프로젝트이기 때문에, 새롭게 만드는 것이 더 자유롭게 시도해 볼 수 있어서 좋았다는 것이 솔직한 심정입니다. 앞으로도 실험은 계속할 것입니다.

그렇다고 해도, 기존 프레임워크에 기능을 추가할 수 있느냐고 묻는다면, 답은 '프레임워크에 따라 가능하다'입니다. 대부분의 경우, 앞 절에서 언급된 핫 리로드와 Python 전용 두 가지가 장벽이 됩니다.

핫 리로드는 백엔드 라이브러리의 사정에 따라 재시작 없이 조합할 수 없는 경우가 있습니다. Python 전용은 화면과 코드의 대응 문제입니다. UI를 다른 언어나 파일로 작성하는 구성에서는, 화면상의 컴포넌트에서 코드 위치를 추적하기가 어려워집니다. Nuiitivet은 이 두 가지를 처음부터 전제로 설계했습니다.

이러한 제약이 없는 프레임워크라면, 같은 것들을 나중에 추가할 수 있을 것입니다. 이러한 생각이 다른 프레임워크에도 퍼지면 좋겠습니다.

이런 방향은 다른 곳에서도 시작되고 있다

'앱 위에서 대화하기'는 Nuiitivet만의 아이디어는 아닌 것 같습니다.

Claude Docs(2026년 9월 베타 공개)는 문서 위에서 Claude와 대화합니다. 문서의 텍스트를 선택하고 주석에 @Claude라고 쓰면, Claude가 스레드로 답장을 하고 문서를 그 자리에서 수정하며 무엇을 왜 바꿨는지 설명합니다. Claude가 작업하는 동안에도 문서는 잠기지 않아 사람이 동시에 편집할 수 있습니다.

Figma의 에이전트(2026년 5월 공개)는 디자인 파일 위에서 에이전트와 대화합니다. 캔버스에서 레이어를 선택하고 지시하면, 에이전트가 디자인 파일을 그 자리에서 수정합니다. 파일 내 주석을 요약하고 실행 가능한 계획으로 정리할 수도 있습니다.

각각 만들고 있는 것은 다르지만, 결과물 위에서 직접 소통한다는 방향성은 같습니다. 그래서 Nuiitivet의 생각은 그렇게 틀리지 않은 것 같습니다.

사용 방법

Python 3.11 이상, macOS / Windows / Linux에서 작동합니다.

Nuiitivet을 사용하려면 먼저 다음 명령어를 사용해야 합니다.

# uv의 경우
uv add nuiitivet
uv add --dev 'nuiitivet[dev]'
...

[dev]는 MCP 서버에 필요한 extra입니다. 마지막 줄은 에이전트용 스킬을 설치합니다. 기본적으로 Claude Code 프로젝트 스킬인 .claude/skills/에 들어가며, 다른 에이전트는 --dest로 위치를 지정합니다.

다음으로, MCP 서버를 에이전트에 등록합니다. Claude Code의 경우, .mcp.json에 다음을 추가합니다.

{

가장 작은 앱은 다음과 같습니다.

```python
import nuiitivet.material as nv
class CounterApp(nv.ComposableWidget):
def __init__(self):
...

다음 명령어로 실행합니다.

# uv의 경우
uv run python -m nuiitivet.dev run app.py
# pip의 경우
...

자세한 사용 방법은 가이드를 참조해 주세요.

맺음말

'Vibe Coding' 시대의 UI 프레임워크는 사람과 에이전트가 실행 중인 앱을 공유하며 개발하는 형태로 발전할 것이라고 생각합니다. 단순히 채팅으로 전달하는 것을 넘어, 앱 자체를 화이트보드처럼 활용하여 그 위에서 대화하는 것입니다. 이것이 저의 생각이며, Nuiitivet은 이를 구현하려는 시도입니다.

아직 개발 중인 단계이지만, 여러분의 의견이나 요청 사항을 주시면 감사하겠습니다. Issue 등록도 환영합니다. 기존 issue는 영어로 되어 있지만, 일본어로 작성하셔도 괜찮습니다.

다른 프레임워크와의 차이점, 읽기 쉬운 문법, 상태 관리 방법 등도 이야기하고 싶었지만, 이는 다른 글로 쓰기로 했습니다.

토론