10월 21일 오후, 요청 채널에 요청 봇이 새 글을 올렸다. 보안팀이 보낸 개인정보 처리방침 링크 변경 요청이었다. 봇은 내 쪽 팀을 불렀고, 요청함에는 티켓이 생겼고, 그 티켓의 담당자는 나였다. 팀 일정에 없던 일이 “해 주세요”로 바로 들어왔다.

아무도 묻지 않았지만, 자동화는 이미 말하고 있었다. 당신 일이죠?

일은 302 리다이렉트 하나였다. 다음 날 운영에 나갔고, 잘 동작한다. 그런데 다시 보면 이 일에는 조건 셋이 겹쳐 있었다. 간단했고, 같은 일의 티켓이 이미 옆 팀에 있었고, 코드도 옆 팀 범위였다. 옆 팀에 넘겼더니 “전달받은 내용이 없다”는 답이 돌아왔고, 결국 내가 에이전트 플로우로 끝까지 처리했다. 그 사이 이 일의 흐름 전체를 읽은 쪽은 없었다. 사람도, 자동화도.

자동화가 “당신 일이죠?” 했다

요청은 양식으로 들어온다. 양식이 티켓을 만들고, 봇이 팀을 부르고, 다른 봇들이 착수할 수 있는지와 크기를 판단해 붙인다. 요청한 사람도 받는 사람도 손으로 할 일이 거의 없다. 좋은 구조다.

다만 이 구조가 아는 건 “어느 양식으로 들어왔나”다. 이 요청은 내 쪽 양식으로 들어왔으니 내 쪽 일이 됐다. 바꿔야 할 코드가 누구 것인지, 같은 일을 다른 데서 이미 맡았는지는 양식에 칸이 없다.

간단한 작업이었다

요청은 짧았다. 통합 개인정보 처리방침을 보안팀이 관리하는 정적 페이지 하나로 모은다. 그러니 기존 처리방침 주소로 들어오면 새 페이지로 302를 보내 달라. 이전 버전을 보는 파라미터가 있으면 새 페이지 형식으로 바꿔 달라. 로컬 회원용 처리방침은 그대로 둔다. 그리고 앱·웹 하단, 회원가입 동의 화면 등에서 이 주소를 쓰는 링크가 같이 넘어가는지 확인해 달라.

간단해 보였고, 실제로 간단했다. 파라미터 형식은 그날 바로 맞췄고, 코드로는 미들웨어에서 경로 하나를 잡아 쿼리 하나를 바꾸는 몇 줄이었다.

간단한 일은 멈춰서 볼 이유를 주지 않는다. 크기도 작게 매겨졌고, 실제로 작았다. 다만 크기는 이 일이 누구 일인지에 대해서는 아무 말도 하지 않는다.

같은 일의 티켓이 이미 있었다

요청서 맨 아래에는 옆 팀 프로젝트의 티켓 하나가 붙어 있었다. 열어 보니 같은 일이었고, 내 쪽 티켓보다 먼저 만들어져 있었다. 요청자가 옆 팀에 먼저 올리고, 양식으로 한 번 더 넣은 것이다.

같은 일을 가리키는 티켓이 두 장이 됐다. 하나는 양식이 만든 내 쪽 티켓, 하나는 먼저 올라가 있던 옆 팀 티켓. 어느 쪽이 진짜 담당인지는 어디에도 적혀 있지 않았다.

범위 밖이라 넘겼더니, “전달받은 내용이 없습니다”

302 를 걸 페이지는 옆 팀이 소유한 앱에 있었다. 저장소의 코드 소유자 설정에도 그렇게 적혀 있다. 그래서 첫날 회신에서 이걸 짚었다. 대상 경로는 옆 팀 소관이고, 연결된 티켓도 옆 팀 것이라고. 옆 팀 티켓에는 코멘트로 담당자를 불러 302 를 부탁했고, 내 쪽은 앱 회원가입 동의 화면의 링크가 잘 넘어가는지 보겠다고 적었다.

다음 날 아침, 새 페이지가 열렸으니 배포해 달라는 연락이 왔다. 옆 팀 담당자에게 진행 중인지 물었다. 답은 “저는 전달받은 내용이 없습니다”였다.

책임이 둥둥 뜨면 버그가 된다에 “위임은 담당자 이름만 바꾸는 일이 아니다”라고 쓴 적이 있다. 이번엔 코멘트 하나로 넘겼다고 생각했고, 받는 쪽은 몰랐다. 누구의 잘못이라기보다, 넘긴 쪽도 받는 쪽도 확인하지 않은 채 일이 떠 있었다. 결국 내가 PR 을 올렸다. 자동화가 처음 말한 대로, 내 일이 됐다.

그래서 흐름을 다 읽지 못했다

나는 내 티켓을 에이전트 플로우에 넣었다. 플로우는 티켓 하나를 받아 브랜치를 따고, 검증하고, PR 을 올리고, 리뷰를 받고, QA 에 올리고, 배포 승인 티켓을 만든다.

플로우는 맡은 범위 안에서는 깊었다. 앱에서 모달로 열린 경우를 새 페이지의 “팝업 모드”로 넘기려던 첫 구현을, Android·iOS 앱 코드까지 읽고 되돌렸다. 그 모드의 닫기 버튼은 다른 앱의 브릿지를 부르게 되어 있어서, 이 앱에서 누르면 화면이 비어 버린다. 머지 전에 잡았다.

하지만 플로우에게 이 일의 티켓은 처음부터 끝까지 하나였다. PR 제목에는 옆 팀 티켓이 붙었는데, 배포 승인 티켓에는 내 쪽 티켓만 연결됐다. “두 티켓이 같이 처리되는 거지?” 하고 확인하고 나서야 나머지 하나가 걸렸다.

더 큰 건 확인 대상이었다. 플로우의 입력은 첫날 내 회신이었다. “내 쪽은 앱 회원가입 동의 화면을 확인한다.” 그 문장이 검증 대상이 됐고, PR 본문의 되돌림 기준과 배포 티켓의 확인 항목에 그대로 들어갔다.

배포 직전, 그 화면을 직접 보려고 폰에서 회원가입 버튼을 눌렀다. 뜬 건 다른 서비스가 운영하는 통합 계정 가입 화면이었다. 거기 있는 처리방침 링크는 이미 새 페이지를 열고 있었다. 확인하려던 가입 동의 화면은 운영에서 로그인 화면으로 돌려보내지는, 사용자가 닿을 수 없는 화면이었다.

이번 302 를 실제로 타는 곳은 마케팅 수신 동의 약관 본문의 링크, 웹 푸터, 그리고 밖에 퍼져 있는 이전 버전 링크 정도였다. 모바일에서 이 처리방침에 들어갈 길은 이미 거의 없었다. 요청이 걱정한 부분의 상당수는 이미 처리돼 있었다.

간단한 일이었고, 티켓은 이미 있었고, 남의 범위였다. 셋 다 한 번씩 멈출 이유였는데, 자동화가 “당신 일”이라고 한 순간부터 그 질문들은 다시 나오지 않았다. 나는 받은 일을 잘 끝내는 데 집중했고, 플로우는 받은 티켓을 깊게 팠다. 이 일이 왜 이런 모양으로 나에게 왔는지는 둘 다 읽지 않았다.

“당신 일”을 받은 다음 1분

다음에 요청 자동화가 일을 넘겨 오면, 착수하기 전에 이 셋부터 본다.

1. 같은 일을 가리키는 티켓이 이미 있는가, 누구 것인가
   → 요청 원문의 연결 티켓을 훑는다. 한 번에 처리하면 전부 같이 건다.

2. 바꿀 코드의 주인은 누구고, 그 사람이 받았다고 답했는가
   → 코멘트로 부른 것은 전달이 아니다. 답을 받아야 넘어간 것이다.

3. 확인하라는 화면이 지금 운영에서 사용자에게 열려 있는가
   → 그 주소를 운영에 한 번 요청하거나, 진입 코드를 읽는다.

셋 다 금방 확인된다. 8월에 취소선도 결과다를 쓰면서 “이전 변경에서 이미 해결했거나 의미가 달라진 부분은 없는가?”를 착수 전 질문으로 적어 두었다. 그 질문은 글에 있었고, 내 플로우에는 없었다. 이번 셋은 플로우 맨 앞에 넣어야겠다.

요청 자동화 쪽에도 칸 하나는 있었으면 한다. 양식이 팀을 정하기 전에, 바꿀 경로의 코드 소유자와 이미 연결된 티켓을 한 줄로 보여 주는 칸. 그것만 있어도 “당신 일이죠?”가 “누구 일일까요?”로 바뀐다.

마치며

302 는 다음 날 운영에 나갔다. 배포 뒤 운영에서 기본 주소와 이전 버전 주소, 로컬 회원 처리방침을 다시 요청해 봤다. 넘어갈 것은 넘어갔고, 남을 것은 남았다.

간단한 일은 간단하게 끝났다. 다만 그 일이 어떻게 내 일이 됐는지는, 끝나고 나서야 보였다.