내 손안에 작은 개발 조직이 생긴 듯했다

여러 에이전트가 작업하고 커밋이 쌓이는 모습을 보면서, 혼자 프로젝트를 진행한다는 감각이 달라졌다.

어디서 시작됐나

처음 영감을 얻은 것은 다른 사람들이 AI를 사용하는 방식이었다. 일부 스타트업과 회사들이 개별 업무에 AI를 쓰는 데서 더 나아가, 조직의 업무 흐름에 AI를 연결하고 있다는 이야기를 들었다. 주변에서도 지인이 AI 파이프라인으로 사이트 QA를 관리하고, 발견한 문제를 개발 작업으로 이어 가는 듯한 모습을 봤다. 내부 과정을 모두 확인한 것은 아니지만, 작업을 이어 붙이는 방식이 눈에 들어왔다.

그 모습을 보면서 나도 해 보고 싶어졌다. 아이디어를 정리하고, 문제를 찾고, 다음 작업을 나누는 과정까지 AI와 연결하면 어떨까. 그 사례들에서 출발해 내가 진행하는 프로젝트에 맞는 흐름을 직접 시험해 보고 싶었다.

생각보다 큰 감각

최근 며칠은 평소 상상하던 개발 방식을 직접 시험하는 데 시간을 많이 썼다. 프로젝트 하나를 정해 AI에게 작업을 맡기고, 부족한 기능과 문제를 계속 전달했다. 여러 작업으로 나누고 에이전트를 배정한 뒤 결과를 모으는 과정도 지켜봤다.

작업과 커밋이 빠르게 쌓이는 모습을 보고 순간적으로 이런 생각이 들었다. 내 손안에 작은 개발 조직이 생긴 것 같다고. 당시에는 ‘대기업 하나가 생긴 기분’이라는 말까지 나왔다. 실제 조직의 역량과 같다는 뜻은 아니다. 혼자 입력하고 기다리는 속도에 익숙해져 있다가, 여러 작업이 동시에 진행되는 모습을 눈앞에서 본 느낌이 그만큼 강했다.

재미있었다. 다음에 무엇을 해 볼지 계속 떠올랐고, 작업이 진행되는 동안 다른 요구를 정리하게 됐다. 막혀 있던 부분이 풀린 뒤에는 시간 가는 줄 모르고 몰입하기도 했다. 단순히 결과가 빨리 나오는 것뿐 아니라, 머릿속에 있던 구상을 실제로 시험할 수 있는 범위가 넓어진 점이 인상적이었다.

만들고 싶었던 흐름

내가 궁극적으로 시험하고 싶었던 것은 한 번의 코드 생성보다 길게 이어지는 개발 과정이었다. 떠오르는 기능과 개선 아이디어를 모으고, 작업 중 발견한 오류와 문제도 기록한다. 쌓인 항목을 검토해 관련된 것끼리 묶고, 실행할 수 있는 작업으로 나눈 뒤 적절한 에이전트에 배정하는 방식이다.

아이디어와 문제 기록
→ 검토·분류·우선순위 정리
→ 작업 분해와 에이전트 배정
→ 구현과 검증
→ 커밋과 통합
→ 필요한 리팩터링 검토
→ 다음 작업

계속 같은 지시를 입력하지 않아도 이 흐름이 이어지면 어떨까. 내가 다른 일을 하거나 잠든 동안에도 미리 정한 범위의 작업이 진행되고, 돌아왔을 때 결과와 판단이 필요한 지점을 확인할 수 있으면 좋겠다고 생각했다.

이 전체 흐름을 완성했다고 말하려는 것은 아니다. 일부를 시험하면서 다음에 연결하고 싶은 단계가 구체화됐다. 특히 문제를 모아 두는 것과 실제로 처리할 작업으로 바꾸는 과정 사이에는 아직 내가 검토하고 조정해야 할 부분이 많다.

브레인스토밍이 작업이 되기까지

이 구상의 일부를 구체적으로 볼 수 있었던 것이 PetV3의 브레인스토밍 기록이다. 나는 이 분야의 세부 기술 명세를 미리 작성해 둔 상태가 아니었다. 외부 사례를 조사하고, 현재 프로젝트와 비교하고, 다음 할 일을 정리하는 흐름을 원했다. 그 요청이 어떤 보고서와 작업 제안으로 이어지는지 보는 과정 자체가 흥미로웠다.

첫 보고서는 유사 제품과 사용자 불편을 조사하고, 프로젝트에서 만들 것·만들지 않을 것·미룰 것을 나눴다. 기능을 더 제안하는 데서 끝나지 않고, 이미 구현해 둔 소리를 실제 상태 변화에 연결하는 일을 먼저 하자는 결론으로 이어졌다. 새로운 아이디어보다 기존 작업을 사용자에게 닿게 만드는 것이 우선이라는 판단이었다.

두 번째 보고서는 앞서 정리한 작업 12개를 다시 살펴봤다. 구현된 화면 요소가 실제 실행 경로에 연결되지 않은 부분을 짚었고, 성능 개선의 대상도 기존 측정과 대조해 재검토했다. 그 결과 작업 큐는 새 기능 추가보다 기존 기능 연결과 남은 측정을 먼저 하는 순서로 정리됐다. 두 회차의 판단이 코드 변경과 별도의 커밋으로 남아 있다는 점도 확인했다.

내가 놀란 것은 보고서가 길거나 전문 용어가 많아서가 아니었다. 내가 구상한 절차가 조사와 비교, 우선순위가 있는 작업 제안으로 이어졌다는 점이었다. 그 분야의 상세한 설계를 내가 모두 준비하지 않고도 이런 검토 과정을 구성해 볼 수 있었다. 물론 보고서의 모든 출처와 판단을 독립적으로 검증한 것은 아니다. 이 사례가 보여 주는 것은 완전 자동화의 완성이 아니라, 아이디어를 실행할 작업으로 바꾸는 과정까지 AI와 함께 시험할 수 있었다는 경험이다.

실제로 본 장면

병렬 작업을 맡기면 한쪽에서 구현이 진행되는 동안 다른 쪽에서는 별도의 작업이나 확인이 이어졌다. 결과와 커밋이 돌아오면 다음 작업으로 연결했다. 모든 내용을 내가 직접 입력하던 때와는 진행 속도가 다르게 느껴졌다.

하지만 커밋이 늘어난다는 사실만으로 프로젝트가 그만큼 완성되는 것은 아니었다. 변경이 합쳐졌는지, 내가 실행한 프로그램에 반영됐는지, 실제로 원하는 동작인지 확인해야 했다. 완료 보고를 받았는데 화면은 예전 그대로인 경우나, 기능은 추가됐지만 기존 사용성이 나빠진 경우도 있었다.

이 차이를 보면서 관심이 코드 생성량에서 작업 상태로 옮겨 갔다. 지금 무엇이 구현 중이고, 무엇은 검토를 기다리며, 어디에서 내 판단이 필요한지를 한눈에 보고 싶어졌다. 대시보드가 커진 과정은 이 필요에서 이어졌다. PetV3 기록에는 그 요구가 실제 프로젝트 진행에 어떻게 반영됐는지를 따로 정리했다.

내가 하게 된 일

내 역할은 모든 코드를 직접 작성하는 것보다 원하는 결과를 설명하고, 진행 중 발견한 차이를 지적하며, 다음 순서를 조정하는 쪽에 가까웠다. 기술 스택과 구현을 모두 내가 설계했다는 뜻은 아니다. AI가 제안하고 처리한 부분이 많고, 나는 그것이 내가 하려던 일에 맞는지 계속 판단했다.

요청도 점차 구체적으로 바뀌었다. 무엇을 추가할지뿐 아니라 기존 기능 중 무엇을 유지해야 하는지, 어떤 상태에서 멈추고 확인을 받아야 하는지까지 설명할 필요가 있었다. 리팩터링도 무조건 반복하는 작업보다는 변경을 살펴보고 필요한지 판단하는 단계로 두고 싶었다.

그래서 자동화가 늘어난다고 내 역할이 사라지는 느낌은 아니었다. 한 줄씩 구현하는 데 쓰던 관심이 작업의 경계, 우선순위, 결과 검토로 옮겨 갔다. 여러 결과가 한꺼번에 돌아올수록 내가 무엇을 확인할 수 있는지도 중요해졌다.

속도에는 비용이 따른다

이런 실험은 사용량도 함께 늘렸다. 처음에는 가능성을 확인하고 싶어 여러 모델과 추론 강도, 작업 배분 방식을 시도했다. 이제는 매번 가장 강한 모델을 쓰는 대신 작업에 맞는 선택을 해야겠다는 생각이 든다.

최근 Astra로 작은 작업과 대화를 시험하면서 응답과 처리 속도가 빠르다는 인상을 받았다. 그 변화가 전체 작업 비용에도 유리한지는 별도로 봐야 한다. 빠르게 끝나는 것, 토큰을 적게 쓰는 것, 내가 검토에 덜 시간을 쓰는 것은 서로 다른 기준이다.

앞으로는 작업을 시작해 받아들일 수 있는 결과가 나오기까지 얼마나 걸렸는지, 재작업은 얼마나 필요했는지, 사용량은 어땠는지를 함께 보고 싶다. 내가 원하는 것은 에이전트 수를 계속 늘리는 것이 아니라, 유지할 수 있는 비용 안에서 작업을 더 잘 이어 가는 방식이다.

계속 시험해 볼 이유

아직 완전 자동화라고 부를 단계는 아니다. 그래도 여러 작업이 실제로 진행되고 결과가 쌓이는 모습을 본 경험은 강하게 남았다. 상상만 하던 개발 흐름을 지금 손에 있는 도구로 일부라도 만들어 볼 수 있었다는 점이 좋았다.

‘내 손안의 작은 개발 조직’이라는 표현에는 그때의 흥분이 담겨 있다. 앞으로 확인할 것은 그 감각이 반복 가능한 작업 방식으로 이어지는지다. 요구가 잘 전달되고, 문제가 기록되며, 결과를 믿을 만한 근거가 남는다면 이 실험을 더 확장해 볼 이유가 충분하다.

이 글도 대화로 풀어낸 경험을 AI와 함께 정리하고 다시 읽으며 다듬었다. 빠르게 시도해 본 만큼, 무엇을 실제로 확인했고 무엇을 아직 기대하고 있는지 구분해서 남기려고 한다.