우리는 비즈니스를 루프로 운영합니다

Claude Code나 Codex와 개발하다 보면, 한창 코드를 짜다가 질문을 받는 순간이 있습니다. 기능 기획은 이미 정했는데도요.

이 정보를 기존 테이블에 넣을지, 별도 테이블로 뺄지. 이번 기능 안에서 해결할지, 다른 곳에서도 쓸 수 있는 공통 구조로 만들지. 당장 필요한 경우만 처리할지, 나중에 생길 경우까지 미리 열어둘지.

아래는 이런 선택을 설명하기 위한 예시입니다.

“고객별 처리 상태를 관리하자”는 기획이 있다고 해봅시다. 에이전트는 상태를 저장할 열을 만들다가, 상태가 바뀐 이유도 필요할 것 같고, 바뀐 시각과 이전 상태도 따로 있어야 할 것 같고, 나중에 예외를 처리하려면 설정도 몇 개 더 있어야 할 것 같다고 판단할 수 있습니다.

하나씩 보면 다 이유가 있습니다. 그런데 서비스에는 이미 변경 이력을 남기는 구조가 있을 수도 있습니다. 다른 기능이 같은 상태를 관리하고 있을 수도 있고요. 그 맥락을 놓치면 같은 정보를 두 군데 저장하게 되거나, 아직 쓰지도 않을 열과 설정이 잔뜩 생깁니다.

여기서 사람이 “그건 이미 이쪽에서 관리해”, “지금은 이 경우까지만 하면 돼”라고 골라주는 겁니다. 코드를 대신 짜주는 건 아니지만, 이 선택이 결과를 꽤 크게 바꿉니다.

이 질문에 답하는 사람까지 AI로 바꾸면 어떨까요. 구현하는 AI가 묻고, 다른 AI가 선택해주고, 다시 구현하고 검사하게 하는 겁니다. 사람을 기다리지 않으니 루프는 잘 돌아갈 수 있습니다. 다만 그 선택을 하는 쪽도 서비스 전체 맥락을 충분히 갖고 있지 않다면, 그럴듯한 선택을 연달아 하다가 결과가 산으로 갈 수 있습니다.

우리가 코딩 에이전트와 일하며 경계하는 오버 엔지니어링도 이런 데서 나옵니다. 기획을 바꾸지 않았는데도, 그 기획을 구현하는 과정에서 필요 이상으로 큰 구조를 만들 수 있는 거죠. 테스트가 통과한다고 이 설계가 우리 서비스에 가장 잘 맞는다는 뜻은 아닙니다.

중요한 설계 선택에는 서비스 전체의 맥락이 필요합니다.

그래서 코딩에서 루프를 완전히 닫는 일은 조심스럽습니다. 기획을 잘 써두는 것만으로 중요한 선택이 모두 사라지지는 않습니다. 구현 중에도 서비스가 지금 어떻게 돌아가고, 어디까지 바꿀 생각인지 아는 사람이 판단할 자리가 남습니다.

그런데 우리는 UpServe에서 비즈니스를 루프로 운영합니다. 코딩에서는 조심해야 한다고 해놓고, 사업에서는 계속 돌리자는 겁니다.

이 차이가 재미있습니다.

사업에서는 목표를 정해도 거기까지 가는 방법을 모를 때가 많습니다. 가령 “이번 달에 우리 서비스가 필요한 기업과 상담 10건을 잡자”고 정했다고 해봅시다. 설명을 위한 가상의 목표입니다.

관련 주제로 글을 쓸 수도 있고, 잠재 고객을 찾아 연락할 수도 있고, 파트너를 통해 소개받을 수도 있습니다. 어떤 방법이 통할지는 해봐야 압니다. 글을 쓰기로 정해도 어느 업종을 대상으로, 어떤 문제를 다룰지에 따라 또 길이 갈립니다.

여기서는 처음 짠 계획을 충실히 끝내는 것만으로 충분하지 않습니다. 글 열 편을 다 썼는데 상담은 한 건도 안 잡힐 수 있으니까요. 그때 필요한 건 “계획 완료”라는 보고보다, 결과를 보고 다음 방법을 고르는 일입니다.

저는 이 과정이 탐색에 가깝다고 생각합니다.

컴퓨터 쪽 말로 하면 BFS나 DFS가 떠오릅니다. BFS는 여러 갈래를 넓게 살피는 쪽이고, DFS는 한 갈래를 따라 깊게 들어가는 쪽입니다. 사업을 이 알고리즘대로 돌린다는 뜻은 아닙니다. 어디에 다음 시도를 쓸지 생각할 때 꽤 괜찮은 비유라는 얘기입니다.

처음에는 콘텐츠, 직접 연락, 파트너 소개를 작게 시도해볼 수 있습니다. 어느 쪽에 반응이 있는지 넓게 보는 겁니다. 그중 특정 업종의 기업들이 콘텐츠를 보고 문의한다면, 이번에는 그 업종의 문제를 더 깊게 파고들 수 있습니다. 어떤 글에서 문의했는지 보고, 비슷한 문제를 다룬 자료를 만들고, 상담으로 이어지는 과정을 다듬습니다.

처음에는 넓게, 가능성이 보이는 길에서는 더 깊게.

한 길을 충분히 가봤는데 반응이 없다면 다른 갈래로 돌아옵니다. 반응이 보인다고 곧바로 정답이라고 할 수도 없습니다. 우연인지, 다시 해도 비슷한 결과가 나오는지 조금 더 봐야 합니다. 모든 방법을 똑같이 시험할 시간과 돈이 있는 것도 아니니, 가능성뿐 아니라 비용과 결과를 기다리는 시간도 보고 골라야 하고요.

이런 일에는 에이전트 루프가 잘 맞습니다. 목표를 보고 다음 시도를 고르고, 실제로 해보고, 결과를 확인하고, 다음 판단에 반영하는 과정이 반복되니까요.

여기서 결과는 에이전트가 쓴 “잘된 것 같습니다”라는 문장이면 안 됩니다. 글을 썼는지, 연락을 보냈는지는 실행 기록입니다. 상담이 잡혔는지는 사업의 결과입니다. 앞의 일을 많이 했다는 사실만으로 뒤의 목표에 가까워졌다고 볼 수는 없습니다.

아직 답장이 안 왔다고 바로 실패로 세는 것도 곤란합니다. 기다릴 시간이 필요한 일도 있고, 측정이 안 되고 있는 경우도 있습니다. 같은 화면을 계속 새로고침한다고 새로운 증거가 생기는 건 아닙니다.

그래서 루프를 돌리려면 기억해야 할 것이 있습니다. 무엇을 해봤는지, 왜 그 방법을 골랐는지, 무슨 결과가 있었는지, 그래서 다음에는 무엇을 바꿀지입니다. 이게 남지 않으면 에이전트는 지난번에 안 됐던 아이디어를 오늘 새 아이디어처럼 꺼낼 수 있습니다. 계속 일은 하는데 같은 자리를 도는 셈입니다.

해본 일과 그 결과가 다음 선택을 바꿔야 합니다.

UpServe에서 팀의 목표 루프를 설계할 때도 이 구분을 중심에 뒀습니다. 팀장은 목표를 향한 경로를 고르고, 일을 나눠 맡기고, 결과를 받아 다음 접근을 판단합니다. 목표 자체를 바꿔야 한다면 사람에게 돌아옵니다.

“상담 10건”이 안 된다고 에이전트가 “조회수 1만 회”로 목표를 바꿔버리면 안 되겠죠. 목표를 달성한 게 아니라 채점표를 바꾼 것이니까요. 어느 계정을 쓰고, 어디까지 연락하고, 얼마를 들일 수 있는지도 처음 맡긴 범위 안에서 판단해야 합니다. 새 권한이 필요하면 그 부분은 다시 정해야 합니다.

물론 개발에도 탐색은 있고, 사업에도 정해진 절차대로 끝내야 하는 일은 있습니다. 버그 원인을 찾는 일은 여러 가설을 시험하는 과정이고, 정해진 내용의 청구서를 발행하는 일은 사업 안에서도 완료 기준이 분명합니다.

비즈니스에서도 서비스의 맥락을 몰라도 된다는 뜻은 아닙니다. 다만 목표와 허용 범위를 정하고 작게 시험할 수 있는 전략이라면, 결과를 보면서 다음 선택을 고쳐갈 여지가 있습니다. 글의 주제나 접근할 고객군을 바꿔보는 일과, 서비스 전반에 영향을 주는 데이터 구조를 결정하는 일은 틀렸을 때 치르는 비용도, 다시 고치는 방법도 다릅니다. 그래서 어디까지 루프에 맡길지는 그 선택의 영향과 결과를 확인할 수 있는지를 함께 보고 정해야 합니다.

하나의 KPI를 정하는 것도 그 출발입니다. 다만 상담 건수만 늘리려고 맞지 않는 고객까지 약속을 잡으면 숫자만 좋아집니다. 어떤 상담을 셀지, 언제까지 볼지, 어떤 방식은 쓰지 않을지까지 정해야 우리가 원하는 목표가 됩니다. 충분히 시도해도 근거가 없거나 정한 범위를 넘어서야 한다면, 계속 돌리는 대신 사람에게 판단을 돌려줘야 합니다. 목표에 도달했을 때도 그 결과를 확인하고 다음 목표를 정하면 됩니다.

우리가 루프에 맡기고 싶은 건 이 사이의 일입니다. 목표는 그대로인데 첫 번째 방법이 안 통했을 때, 결과를 읽고 두 번째 방법을 찾아 실행하는 일. 그 방법이 통하면 조금 더 깊이 들어가보는 일.

매번 사람이 “그럼 다음에는 이걸 해봐”라고 말해야 이어지는 사업은, 아직 사람이 루프를 돌리고 있는 겁니다.

우리는 그다음 시도를 고르는 일까지 AI에게 맡기고 싶습니다. 그래서 비즈니스를 루프로 운영합니다.