AI 에이전트로 혼자 만들며 속도와 퀄리티, 의도를 지키는 법

NeuroTerm은 AI 에이전트와 함께 일하는 임베디드 개발자를 위한 터미널이다. 보드의 시리얼 콘솔과 SSH를 탭으로 열어 두면, Claude Code나 Codex 같은 에이전트가 그 탭의 출력을 직접 읽고, 내가 허락하면 직접 입력한다. 사람이 콘솔과 에이전트 사이에서 로그를 나르지 않아도 되게 하려고 만들기 시작했다. 그 이야기는 첫 글에 적었다.

에이전트 쪽 기술은 몇 달마다 할 수 있는 일이 달라진다. 그 변화를 따라가지 못하는 터미널이라면 만들 이유가 없다. 그런데 NeuroTerm은 혼자 만들고, 직접 손을 대는 날은 주말로 정했다. 넉넉한 구조는 아니다.

이 조건에서 놓치고 싶지 않은 것이 세 가지 있다. 개발 속도, 퀄리티, 그리고 제품의 철학이다. 하나만 붙잡기는 어렵지 않다. 빠르게 가면 퀄리티가 흔들리고, 에이전트에게 많이 맡길수록 제품이 무엇을 위해 있는지가 흐려진다. 셋을 같이 붙잡으려고 두 가지를 짰다.

하나는 의도 주도 개발이다. 내가 의도를 적어 두면, 에이전트들이 그 의도에 맞춰 아이디어를 고르고 기능을 만든다. 다른 하나는 릴리즈 트레인이다. 2주마다 출발하고, 준비되지 않은 일은 기다려 주지 않으며, 도착하면 다음 트레인이 곧바로 출발한다. 의도는 트레인에 무엇을 실을지 정하고, 트레인은 2주마다 그 의도를 한 바퀴씩 돌린다. 첫 트레인은 오늘, 11월 1일에 출발했다.

10월에는 NeuroTerm 1.11, 1.12, 1.13을 열흘 간격으로 냈다. 속도는 났다. 하지만 그 열흘은 정해 둔 간격이 아니었다. 되는 대로 만들고 되는 대로 냈다. 그렇게 지내 보니 걸리는 것이 두 가지 있었다.

하나는 그 속도가 오래갈 수 없다는 점이었다. 따라갈 변화를 내가 직접 찾아다니고 있었다. 에이전트 도구가 무엇을 바꿨는지, 비슷한 도구가 무엇을 냈는지, 사용자가 어디서 막혔는지를 나한테 가져다주는 것이 없었다.

더 큰 문제는 의도였다. 이 기능이 무엇을 위해 있는지, 무엇은 절대 하면 안 되는지를 나는 그때그때 에이전트에게 말했고, 에이전트는 그 대화 안에서만 기억했다. 내 판단은 내 컴퓨터 한 대의 Claude 메모리에 흩어져 있었다. 구현을 에이전트에게 맡길수록 이건 더 위험해진다. 코드는 잘 나오는데, 제품은 내가 원하던 모습에서 조금씩 멀어질 수 있다.

그게 유독 마음에 걸렸던 건, 지금까지의 NeuroTerm이 내 취향과 의도를 한껏 담아 만든 제품이기 때문이다. 하나하나 맞추느라 시간이 많이 들었고, 그만큼 정도 많이 들었다. 에이전트가 맡는 일이 늘어나도, 그렇게 맞춰 온 것이 흐려지지 않았으면 했다.

그래서 의도를 문장으로 적기 시작했다. 적어 둔 의도는 여러 개인데, 두 개만 소개하면 이렇다.

하나는 에이전트의 손을 믿을 수 있어야 한다는 것이다. 보드를 보고 만지는 일을 에이전트에게 맡겨도 불안하지 않아야 한다. 보드에 무언가를 쓸 때는 그 탭에서 먼저 묻고, 자동으로 도는 일은 사람이 정해 준 경계 안에서만 돈다. 편해도 믿을 수 없는 기능은 보드 앞에서 결국 쓰지 않게 된다.

다른 하나는 처음 받은 사람이 그날 자기 보드를 붙일 수 있어야 한다는 것이다. NeuroTerm을 막 내려받은 임베디드 개발자가 그날 바로 자기 보드를 연결하고, 옆에 에이전트를 두고, 쓸 만하다고 느껴야 한다. 내 컴퓨터에서만 돌아가는 도구로 끝내고 싶지 않아서 적은 의도다.

의도에는 무엇을 위해 있는지와 함께 절대 하면 안 되는 것도 적는다. 화면에 이모지를 쓰지 않는다, 새 버튼을 넣기 전에 겹치는 버튼부터 뺀다 같은 감각도 같은 자리에 둔다. 에이전트가 무엇을 만들든 이 문장들 안에서 만든다. 그렇게 적어 둔 의도는 쌓이고 다듬어지면서 NeuroTerm이라는 제품의 철학이 된다.

트레인은 이 의도를 들고 2주를 돈다.

첫날 새벽, 에이전트가 지난 2주 동안 바뀐 것을 읽는다. 에이전트 도구와 비슷한 도구들의 변화, 임베디드 쪽 소식, 사용자가 남긴 이슈와 메일을 읽고, NeuroTerm 자신도 들여다본다. 적어 둔 의도를 지금 기능이 어디서 못 지키고 있는지 찾는 것이다. 그중 의도에 닿는 것만 카드가 되어 나에게 온다. 카드에는 그 기능이 완성되면 화면이 어떻게 바뀌는지, 누가 어떤 순간에 그걸 쓰는지가 그려져 있다.

카드가 바깥에서만 오는 건 아니다. 2주 동안 빌드를 쓰며 든 생각, 고민, 새로 생긴 의도와 취향은 내가 직접 카드로 적는다. 바깥의 변화와 나의 2주가 같은 길을 탄다.

아침에 나는 카드마다 채택할지 말지를 고르고, 이유를 한 줄 적는다. 거절한 이유도 버려지지 않는다. 어느 카드에는 너무 자동화하는 것도 좋지 않다, 자동화는 경계를 지켜야 한다고 적었다. 그 한 줄은 에이전트의 손에 대한 의도에 하면 안 되는 일로 들어갔고, 다음 트레인의 에이전트는 그 경계 안에서 카드를 가져온다. 고르는 일이 곧 의도를 적는 일이 된다.

채택한 카드는 에이전트들이 기능으로 만든다. 무엇을 만들지 적고, 그 문장에서 테스트를 먼저 쓰고, 코드를 쓰고, 리뷰를 거친다. 그동안 나에게 묻지 않는다. 카드를 채택한 것을 무엇을 왜 만드는지에 대한 승인으로 보기 때문이다. 되돌리기 어려운 결정이 새로 생길 때만 멈추고 나에게 넘긴다. 다 만들어지면 짧은 결과를 보고, 내가 예라고 답해야 들어간다.

오늘 들어간 탭 통합 Timeline이 그렇게 만들어졌다. 한 작업에 여러 탭을 같이 띄워 두면, 그 탭들에 찍힌 줄을 받은 시각 순서대로 한 시간축에 놓는다. 에이전트도 그 시간축을 읽고, 나도 같은 화면을 본다. 내가 한 일은 카드를 채택하며 메모 몇 줄을 단 것뿐이다. 사용자가 쉽게 설정하고, 사용자도 보고, 에이전트도 쓸 수 있게.

그다음 일주일은 개발 빌드를 직접 쓴다. 8일째 밤에 출시 후보인 RC를 만들고 나면 고치기만 하고, 새 기능은 다음 트레인을 탄다. 둘째 주에는 나와 원하는 사용자가 RC를 쓰고, 14일째 토요일 밤에 낸다. 날짜는 내가 기억하지 않는다. 오늘이 트레인의 며칠째인지, 지금 기능을 넣어도 되는지는 코드가 판단한다. 바쁜 주에도 트레인은 제때 출발하고 제때 도착한다.

속도는 이 구조에서 나온다. 변화를 찾아다니는 일도, 구현도 에이전트가 맡고, 나는 고르고 답한다. 그래서 주말 하루로도 기능이 들어간다. 다만 트레인은 기능의 리듬이지 버그의 리듬이 아니다. 사용자가 버그를 알리면 에이전트가 재현하고, 실패하는 테스트부터 쓰고, 고쳐서 그 트레인에 싣는다. 앱이 죽거나, 탭이나 로그를 잃거나, 보드에 허락하지 않은 것이 쓰이거나, 보안에 닿는 버그는 트레인을 기다리지 않고 고치는 대로 패치로 나간다. 에이전트 쪽 도구가 바뀌어 연동이 깨지면, 고칠 곳이 든 플러그인만 먼저 업데이트된다.

퀄리티는 날짜가 지킨다. 속도를 내면 퀄리티가 먼저 흔들린다. 에이전트에게 맡기면 코드는 금방 나오지만, 그대로 내보내면 그럴듯하기만 한 것이 쌓인다. 트레인은 그 사이에 날짜를 정해 둔 것이다. 정해진 날까지는 넣고, 그 뒤로는 고치기만 한다.

그래서 밖으로 나가는 것은 적어도 일주일은 내가 직접 써 본 것이다. 그 전에 계속 늘어나는 수천 개의 테스트를 통과하고, 여러 번의 코드 리뷰 라운드를 거친다. 한번 맞춘 동작은 그 테스트들이 지키기 때문에, 다음 기능을 빠르게 넣어도 예전 것이 슬쩍 무너지지 않는다. main은 매일 밤 전체 테스트를 다시 돌고, 릴리즈 빌드를 실제로 띄워 돌리는 e2e 테스트는 Windows와 Linux 양쪽에서 돈다.

에이전트가 만들고 에이전트가 검사한 것만으로 내보내지는 않는다. 화면이 어떻게 보이는지, 실제 PC를 껐다 켰을 때 어떻게 되는지처럼 기계가 판단할 수 없는 것은 내가 직접 보고 닫는다. 그 확인이 하나라도 열려 있으면 RC는 나오지 않는다. 내 컴퓨터에서만 괜찮은 것은 퀄리티가 아니다.

퀄리티에는 사용자가 겪는 경험도 들어간다. 트레인이 달릴 때마다 사용자까지 흔들려서는 안 된다. 그래서 기능은 되도록 플러그인으로 만든다. 필요한 사람만 필요할 때 내려받아 붙이면 되고, 필요 없는 사람의 화면은 그대로다. 트레인마다 헤드라인 하나는 실리지만 꼭 새 버튼일 필요는 없다. 기존 기능을 더 낫게 만든 것, 무언가를 뺀 것, 새 플러그인도 헤드라인이 된다. 기본 앱에 새 화면이 들어가는 건 플러그인으로 할 수 없을 때뿐이다.

철학은 트레인이 도착할 때 확인한다. 도착할 때마다 나는 의도마다 질문 하나에 답한다. 에이전트의 손에 대해서라면 이렇게 묻는다. 이번 트레인에서 에이전트에게 보드를 맡기며 불안했던 순간이 없었는가. 기억에만 기대지 않으려고, 그런 순간이 있으면 그때그때 한 줄씩 적어 두고, 그 트레인에 들어온 사용자 이슈와 함께 놓고 답한다. 지켜지지 않았다면 그 이유가 다음 트레인에서 먼저 고칠 것이 된다.

빠르게 많이 넣었는데 이 질문에 아니라고 답하게 된다면, 그 트레인은 실패한 것이다.

목표도 적어 두었다. 에이전트 쪽의 중요한 변화든, 사용자가 겪은 불편이든, NeuroTerm이 아직 못 지킨 의도든, 트레인 하나 안에 사용자에게 닿게 한다. 릴리즈 노트와 웹사이트 문구, 데모 영상도 그 트레인에 실린 기능에서 초안이 나온다. 그래서 내가 릴리즈 일에 쓰는 시간은 트레인 하나에 두 시간을 넘기지 않는다. 나는 의도만 쥐고 있으면 된다.

이 글에는 내가 그리는 트레인의 큰 모습만 적었다. 첫 트레인은 이제 막 출발했다. 몇 번 돌려 본 뒤, Claude를 비롯한 에이전트에게 무엇을 맡기고 무엇을 내 손에 남겼는지, 2주 트레인이 실제로 어디가 맞고 어디가 어긋났는지를 Methods에 더 자세히 적으려 한다.

이 구조에서 내가 하는 일은 많지 않다. 카드에 한 줄씩 답하고, 떠오르는 생각은 직접 카드로 적고, 빌드를 써 보고, 예라고 답하고, 트레인이 도착하면 의도마다 질문 하나에 답한다. 나머지는 에이전트들이 맡는다.

대신 그 몇 줄은 트레인을 타고 계속 돈다. 2주마다 바깥의 변화와 내 생각이 함께 들어오고, 나는 의도에 비춰 고르고, 고른 이유는 다시 의도가 된다. 트레인이 몇 번을 돌든 이 루프는 멈추지 않는다. 돌 때마다 NeuroTerm은 빠르게 바뀌면서도, 무엇을 위한 제품인지는 조금씩 더 분명해진다.

첫 트레인은 11월 14일 토요일 밤에 도착한다. 다음 날 새벽에는 두 번째 트레인이 출발한다.

댓글