세션 상태판: 백그라운드 에이전트 멈춤 지점 표시

2026년 5월 14일 | 바이브코딩 Tips

---

백그라운드 코딩 에이전트를 두세 개만 동시에 띄워도, 문제는 속도보다 멈춤 지점을 놓치는 데서 먼저 생긴다. 한 세션은 파일을 읽고 있고, 다른 세션은 테스트를 돌리고 있고, 또 다른 세션은 사람 결정을 기다리고 있다. 화면에는 모두 “작업 중”처럼 보이지만 실제로는 완전히 다른 상태다. 이 차이를 안 나누면 나는 결국 각 대화창을 다시 열어 “얘는 어디까지 했더라”를 확인하게 된다.

그래서 요즘 병렬 에이전트 작업을 굴릴 때는 프롬프트를 더 길게 쓰기보다 작은 세션 상태판을 먼저 만든다. 칸반 보드처럼 거창하게 운영하자는 뜻은 아니다. 각 세션이 지금 탐색 중인지, 수정 중인지, 검증을 기다리는지, 사람 판단이 필요한지, 아니면 보류해야 하는지만 한 줄로 고정하는 정도다. 이 한 줄이 있으면 에이전트가 여러 개로 늘어도 사람이 회수할 수 있는 형태로 남는다.

Figure 1: 여러 백그라운드 에이전트 세션을 탐색중, 수정중, 검증대기, 사람판단, 보류/폐기 칸으로 나누는 상태판

1. 병렬 실행은 곧 관찰 문제다

에이전트를 하나만 쓸 때는 대화창이 곧 상태판이다. 방금 지시했고, 방금 답을 봤고, 이어서 내가 다음 말을 하면 된다. 그런데 백그라운드 세션을 여러 개 띄우는 순간 대화창은 상태판 역할을 잘 못 한다. 각 세션이 마지막으로 본 파일, 실패한 테스트, 기다리는 결정이 서로 다른데, 목록 화면은 보통 “진행 중”이나 “완료” 정도로만 보이기 때문이다.

나는 이 지점에서 좋은 모델보다 좋은 관찰면이 먼저 필요하다고 느낀다. 모델이 똑똑해져도 사람이 어떤 세션을 먼저 열어야 하는지 모르면 병렬 실행은 금방 잡음이 된다. 특히 코드 수정, 문서 정리, 테스트 보강을 동시에 맡겨 놓으면 결과가 빨리 나오는 세션보다 멈춰 있는 세션이 더 중요해진다. 멈춤 지점을 놓치면 다음 지시가 늦어지고, 늦어진 지시는 이미 지나간 맥락을 다시 설명하는 비용으로 돌아온다.

2. 내가 쓰는 다섯 칸

상태판은 복잡해지면 안 쓴다. 나는 보통 다섯 칸만 둔다. 탐색중, 수정중, 검증대기, 사람판단, 보류/폐기다. 중요한 건 “열심히 하고 있음” 같은 감상 상태를 없애고, 다음 행동이 바로 보이는 칸으로 나누는 것이다.

상태	남기는 내용	사람의 다음 행동
탐색중	읽은 파일, 확인한 화면, 아직 안 본 범위	읽기 범위가 맞는지 확인
수정중	건드리는 파일, 금지 영역, 예상 diff 폭	범위 확대 여부 감시
검증대기	돌린 테스트, preview, 실패 로그, 미확인 영역	증거가 충분한지 판정
사람판단	요구사항 선택, UX 결정, 위험 수용 여부	선택지만 남기고 결정
보류/폐기	다시 열 조건, 버린 가설, 되돌릴 기준	지금 닫을지 다음 루프로 넘길지 결정

이 다섯 칸을 두면 세션 목록을 볼 때 질문이 바뀐다. “어느 에이전트가 제일 오래 돌고 있나”가 아니라 “어느 세션이 사람 입력 없이 더 진행하면 위험한가”를 보게 된다. 특히 사람판단 칸은 일부러 따로 둔다. 에이전트에게 계속 수정하라고 해도 해결되지 않는 문제가 있다. 요구사항을 골라야 하거나, UX 방향을 정해야 하거나, 위험을 받아들일지 말지를 사람이 선택해야 하는 경우다. 이걸 수정중 칸에 두면 에이전트는 추측으로 빈칸을 메운다.

3. 상태 이름보다 마지막 증거가 중요하다

상태판을 만들 때 내가 제일 자주 실수한 건 칸 이름만 예쁘게 붙이는 일이었다. “검증대기”라고 적어도 어떤 테스트를 돌렸는지, 어떤 화면을 못 봤는지, 실패가 재현되는지 없으면 다시 대화창을 열어야 한다. 결국 상태판이 또 다른 TODO 목록이 된다.

그래서 각 카드에는 상태 이름보다 마지막 증거를 더 중요하게 적는다. 예를 들면 “검색 필터 버그 수정중”보다 “SearchPanel과 query parser 확인, 라우터는 미확인, 현재 diff 2파일”이 낫다. “테스트 대기”보다 “unit은 통과, preview에서 빈 결과 케이스 미확인”이 낫다. 상태판은 일을 멋있게 분류하는 문서가 아니라, 다음에 열 사람이 바로 이어서 판단하게 만드는 얇은 인수인계다.

4. 프롬프트에 붙이는 짧은 양식

나는 병렬 세션을 시작할 때 아래 정도의 양식을 같이 붙인다. 에이전트에게 모든 보고를 장문으로 쓰게 만들려는 게 아니라, 사람이 상태판에 옮겨 적을 최소 필드만 고정하는 용도다.

세션명: 결제 내역 중복 요청 줄이기
목표: 사용자가 목록을 새로고침할 때 같은 요청이 겹치지 않게 한다.
상태 보고 형식:
- 현재 상태: 탐색중 / 수정중 / 검증대기 / 사람판단 / 보류 중 하나
- 마지막 증거: 방금 읽은 파일, 실행한 테스트, 확인한 화면
- 다음 행동: 계속 수정 / 검증 요청 / 사람 결정 요청 / 중단 중 하나
- 회수 조건: 파일 수가 4개를 넘거나 라우터를 건드려야 하면 멈춘다.

이 정도만 있어도 답변의 질감이 달라진다. “작업을 계속하겠습니다”보다 “라우터 수정이 필요해 보여 사람판단으로 넘깁니다”가 나온다. 나는 이 차이가 꽤 크다고 본다. 후자는 사람이 바로 판단할 수 있고, 전자는 다시 전체 맥락을 읽어야 한다. 바이브코딩에서 병렬성은 많이 돌리는 능력보다 빨리 회수하는 능력에 더 가깝다.

5. 충돌을 줄이는 작은 규칙

세션 상태판을 쓰면 파일 충돌도 조금 줄어든다. 같은 저장소에서 여러 에이전트가 움직일 때 가장 위험한 건 두 세션이 같은 파일을 다른 이유로 만지는 상황이다. 그래서 나는 상태판에 수정 파일 후보를 먼저 적게 한다. 한 세션이 `SearchPanel`을 수정중이면, 다른 세션은 같은 파일을 건드리기 전에 사람판단 칸으로 올라오게 만든다. 이것만으로도 나중에 diff를 보며 “둘 중 어느 쪽 의도가 살아야 하지”라고 고민하는 일이 줄어든다.

또 하나는 검증대기 칸을 오래 방치하지 않는 것이다. 에이전트가 테스트를 기다리거나 preview 확인을 기다리는 동안 다른 세션을 계속 늘리면, 나중에는 검증할 결과가 한꺼번에 쌓인다. 그러면 사람의 판단력이 오히려 떨어진다. 나는 보통 검증대기 카드가 두 개를 넘으면 새 세션을 띄우지 않고, 먼저 하나를 닫는다. 이건 생산성을 낮추는 규칙처럼 보이지만 실제로는 회수 비용을 줄인다.

6. 너무 많이 적지 않는 기준

상태판을 쓰다 보면 처음에는 온갖 항목을 넣고 싶어진다. 예상 완료 시각, 난이도, 담당 모델, 토큰 사용량, 브랜치 이름, 실패 횟수까지 다 적으면 멋있어 보인다. 그런데 실제로는 필드가 늘어날수록 갱신이 귀찮아지고, 갱신이 귀찮아지면 상태판은 금방 낡는다. 나는 그래서 한 카드에 네 줄을 넘기지 않으려고 한다. 세션명, 마지막 증거, 다음 행동, 회수 조건이면 대부분 충분했다.

특히 회수 조건은 꼭 남긴다. 백그라운드 에이전트는 화면 밖에서 오래 돌기 때문에, 사람의 주의가 돌아왔을 때 이미 너무 넓게 수정한 뒤일 수 있다. “테스트 2회 실패”, “금지 파일 접근”, “요구사항 선택 필요”, “preview 확인 불가”처럼 회수 조건을 작게 적어 두면 멈춤을 감정이 아니라 규칙으로 처리할 수 있다. 나는 이게 병렬 세션을 오래 굴릴 때 생각보다 마음을 편하게 만든다고 느낀다.

7. 상태판은 신뢰의 반대편이 아니다

가끔 이런 장치를 만들다 보면 에이전트를 못 믿어서 감시하는 것처럼 느껴질 때가 있다. 그런데 내가 보기에는 반대에 가깝다. 믿고 오래 맡기려면 어디서 멈추는지, 무엇을 봤는지, 어떤 결정을 사람에게 돌려주는지 보여야 한다. 상태가 보이지 않는 자동화는 잘 될 때는 빠르지만, 어긋날 때는 설명 없이 멀어진다.

세션 상태판은 그래서 아주 작은 운영 장치다. 프롬프트를 잘 쓰는 요령이라기보다, 여러 에이전트를 동시에 굴릴 때 사람이 놓치지 않을 좌표를 만드는 일이다. 백그라운드 실행을 늘리고 싶다면, 나는 먼저 실행 수보다 상태 칸을 늘리지 않는 쪽을 본다. 다섯 칸 안에서 멈춤 지점이 보이면 더 많이 띄워도 된다. 그게 안 보이면 하나만 돌려도 이미 복잡하다.