요청자(Requester)는 수신자(Reader)가 아니다: 버그를 절대 보고하지 않을 사람을 위한 엔지니어링

요청은 하나의 긴 문장으로 나왔고, 그것은 좋은 문장이었다. 매일 아침 7시, 그녀와 관련된 세 가지에서 다섯 가지—날씨, 식료품 가격, 버스, 의사; 그녀가 이해하지 못할 단어는 없다; 한 항목에 대해 짧은 단락 하나; 소리 내어 읽을 수 있을 만큼 짧게. 그리고 마지막에는 거의 생각난 것처럼: 너무 길지 않게.

다음 날 아침 7시 20분에 전화가 울렸다. 그녀는 그것을 읽기 시작했고, 절반 정도까지 갔다가 채소를 사러 나갔다가 돌아와서 끝냈다. 판결은 단어 그대로 되돌아왔다: 그녀는 채소를 사러 나간 중간 지점에서 (읽기를) 중단했다. 더 짧게 만들어라.

이 교환에 대한 버전 중에는 어머니, 아들, 그리고 그가 6개월 전에 그녀에게 사준 태블릿에 관한 이야기가 있다. 이 태블릿은 이제 사진과 스크롤링이라는 두 가지 용도만 남아있다. 이것이 엔지니어링적인 관점이며, 가장 많은 예약 시스템들이 숨기려고 하는 것—작업을 요청하는 사람과 그 결과를 받는 사람이 다른 사람—에서 시작한다.

모든 결과물에는 세 사람이 있다

스스로를 위한 야간 작업을 구축할 때, 이 세 가지 역할은 한 몸으로 무너진다. 당신이 명세(spec)를 작성하고, 출력을 받고, 그것이 잘못되었을 때 알아차린다. 당신이 설계하는 모든 피드백 루프는 비밀리에 이것을 가정한다.

두 번째 사람을 루프에 넣으면 세 가지 역할은 분리된다. 아들이 요청을 제출한다. 어머니가 결과를 받는다. 그들 중 누구도 시스템이 중간에 무엇을 했는지 보지 못하고, 두 사람은 '좋다'는 것이 무엇을 의미하는지에 대해 동의하지 않는다—그는 그것이 정보성이 있다는 것을 의미한다고 생각하고, 그녀는 채소를 사기 전에 끝낼 만큼 짧다는 것을 의미한다고 생각한다.

모든 소비자 대상 반복 작업은 이런 형태를 띤다. 고객을 위한 주간 요약 보고서. 요청한 적 없는 팀을 위한 요약본. 흥미로운 엔지니어링은 생성 단계 자체에 있는 것이 아니다. 그것은 두 개의 간격, 즉 명세(spec)에서 현실로의 간격과 전달(delivery)에서 인지(acknowledgement)로의 간격에 있다.

명세는 전해 듣게 되며, 특정 방식으로 잘못되어 있다

그가 타이핑한 문장을 다시 읽어보세요. 모호하지 않습니다. 길이 제약 조건, 어휘 제약 조건, 형식 제약 조건, 주제 범위, 그리고 전달 시간이 포함되어 있습니다. 만약 PM이 이런 내용을 티켓으로 건네준다면 저는 그것을 비정상적으로 완벽하다고 생각할 것입니다.

또한 아무도 적지 않는 정확한 치수에서도 오류가 있었습니다.

주제는 맞았습니다. 그녀는 도로를 파헤치는 것, 찾아오는 추위, 다시 올라가는 달걀에 대해 알고 싶어 했습니다. 어조(register)는 맞았어요—평이하고, 콘크리트 같고, 수식어가 아무런 역할을 하지 않았습니다. 잘못된 것은 길이와 어휘였는데, 이 두 가지는 작성하는 사람에게는 보이지 않기 때문에 1차 사양서에는 거의 포함되지 않습니다. 그는 '지급준비율 삭감(reserve ratio cut)'이 무엇을 의미하는지 알고 있습니다. 그것이 아침 7시에 주방에 서 있는 사람이 잠시 멈춰서 해독해야 할 구절이라는 생각은 그에게 한 번도 떠오르지 않았습니다.

이것이 문제의 일반적인 형태입니다: 2차 사양서는 방향성은 맞지만 치수적으로는 틀립니다. 요청자는 주제를 알려줄 수 있습니다. 크기와 읽기 수준을 알려줄 수 있는 것은 오직 독자뿐인데, 그 독자는 기획 회의에 참석하지 않았습니다.

첫 주에는 그녀가 읽고 나서 전화를 했고, 거의 항상 같은 질문이었습니다: 이것은 무엇을 의미하나요? 그는 두 번 설명했고, 두 번째 설명에서는 그 자신도 모호해졌습니다. 그래서 그는 이 두 단어를 돌려보냈습니다—'이런 식으로 말하지 마세요. 그녀가 말하는 방식대로 말하세요.' 그리고 다음 날 문장은 이렇게 바뀌었습니다: 은행들이 빌려줄 수 있는 돈을 조금 더 가지고 있습니다.

시스템이 똑똑해진 것은 아니었습니다. 누군가가 하나의 제약 조건을 정확하게 번역했을 뿐입니다. '그녀가 말하는 방식대로 말하라'는 실제적이고 검증 가능한 요구사항이며, 이를 찾아내는 데 인간은 두 차례의 과정과 약간의 모호함을 필요로 했습니다.

unopened envelope is not an error

이것은 이 시스템을 거의 죽음 직전까지 몰고 갔던 실패 모드이며, 예외가 붙어 있지 않습니다.

그녀는 휴대폰에 메일 아이콘이 있었다. 하지만 한 번도 열어보지 않았다. 만약 전달된 내용(brief)이 잘못되었거나, 도착하지 않거나, 아니면 아홉 시에 도착하기 시작했더라도, 아무도 보고를 할 수 없었을 것이다. 그녀는 그저 봉투를 여는 것을 멈췄을 것이고, 시스템은 하루 종일 성공했다고 보고했을 것이다. 스택 트레이스(stack trace)도 없고, 재시도(retry)도 없고, 알림(alert)도 없다. 깨끗한 상태로 이탈하는 경우다.

이것이 엔지니어가 아닌 사람을 대상으로 하는 예약된 전달물(scheduled deliverable)의 정의적인 속성이다: 실패는 침묵이며, 당신이 소유한 모든 대시보드에서 성공 상태와 구별할 수 없다.

이것은 열람 횟수(opens)로 측정할 수 없다. 우리 경우에는 아예 측정할 수 없었다—전달 채널은 우리가 소유하지 않은 받은 편지함이기 때문에, 돌아오는 것은 불만 사항 아니면 아무것도 없다. 우리가 할 수 있었던 것은 가장 중요한 신호, 즉 그녀가 그에게 오늘 무엇이 새로운지 전화로 묻기 시작한 것과, 그리고 매일 오후 세 사람이 앉아 아침의 내용을 되풀이하고 '오늘 아침에 이거 읽었어'라는 말로 끝내는 장소인 파빌리온(pavilion)으로 휴대폰을 가져가는 것을 지켜보는 것이었다.

그것이 측정 기준이며, 우리가 보통 적용하는 모든 기준으로 볼 때 나쁜 측정 기준이다. 연속적이지 않다. 사용자당 단위도 아니다. 고객이 아닌 사람에게 걸려온 전화 통화로 도착한다. 집계할 수 없다. 하지만 이것이야말로 '전달됨(delivered)'과 '실제로 접수됨(landed)'을 구별하는 유일한 지표이며, 이 둘의 차이가 바로 전체 제품이다.

우리가 나중에 화이트보드에 적은 문구는 다음과 같다: 무언가가 실제로 접수되었는지 여부는 그것이 되풀이되는지 여부로 알 수 있다.

수정 사항(correction)은 diff가 되어야 한다

그가 보낸 두 가지 수정 사항 모두 스펙(specs)이 아니라 불만 사항이었다. '너무 길다'는 숫자가 아니다. '이런 단어는 쓰지 마라'는 단어 목록도 아니다. 만약 이것들을 프롬프트(prompts)로 취급한다면—더 엄격한 지침으로 마지막 출력을 다시 돌리는 것—오늘 밤은 고치겠지만, 다음 주에는 동일한 불만 사항을 재건축하게 되고, 그 추가 비용은 두 결과물이 이제 지침이 무엇인지에 대해 의견이 다르다는 것이다.

우리가 원했던 것은 모든 수정 사항이 지속 가능한 곳에 기록되는 것이었습니다. 즉, 간략한 변경을 생성하는 지침(instruction) 자체, 그 변경 사항이 요청한 사람에게 눈에 보이고, 다음 실행에서 그것이 계승되는 것입니다. 피드백은 결과물(artifact)에 대한 패치(patch)가 아니라, 원래의 요청(request)에 대한 차이점(diff)이 됩니다.

그것은 작은 리팩토링처럼 들립니다. 하지만 그렇지 않습니다. 왜냐하면 이 과정은 요청을 편집 사항이 누적되고 비전문가도 읽을 수 있는 '일급 객체(first-class object)'로 만들기 때문입니다. 그들은 그 안에 "더 짧게" 또는 "쉬운 단어들"이라는 내용을 보고, 그것이 자신이 설정한 말임을 인식할 수 있어야 합니다. 그렇지 않으면 다음 수정 사항은 그들이 알지 못했던 규칙과 모순될 것입니다. 프롬프트(prompt)의 버전 관리는 쉽습니다. 하지만 사람의 의도(intent)를 그들의 언어로 버전 관리하는 것은 완전히 다른 작업입니다.

며칠이 지나자 그녀는 스스로 고르기 시작했습니다. 자신과 관련 없는 것이라면 건너뛰었습니다. 이것이야말로 실제로 목표로 하는 상태이며, 그가 보낸 어떤 수정 사항도 그녀를 그 지점까지 이끌지 못했습니다. 누적된 차이점(accumulated diffs)들이 그렇게 했습니다.

이미 존재하는 곳에 전달하기

이것이 작동했던 이유는 이야기 속의 한 문장 덕분이었습니다. 즉, 설치할 것이 없다는 것입니다. 그녀의 휴대폰에는 이미 메일 아이콘이 있었습니다. 그가 한 번 보여주었을 뿐입니다. 봉투를 누르고, 맨 위의 것을요.

모든 전달 채널은 트레이드오프(trade-off)이며, 우리가 선택한 것에 대해 명확하게 밝힐 가치가 있습니다. 우리가 소유하지 않은 받은 편지함(inbox)은 열람 횟수를 셀 수 없고, 모든 클라이언트를 렌더링 테스트할 수 없으며, 레이아웃을 보장할 수 없고, 실패 시 페이지를 넘길 수도 없습니다. 대신, 그것은 독자에게 지난 20년 동안 해오던 제스처 이상의 것을 요구하지 않습니다.

설치 단계는 기술적인 비용이 아닙니다. 그것은 이탈 지점(churn point)이며, 우리가 도달하려는 사람들이 조용히 떠나는 곳입니다. 앱과 계정, 그리고 첫 번째 간략한 내용물(brief)을 보기 전에 로그인을 필요로 했던 버전의 제품이라면, 정확히 0건의 재전송률(retellings)을 기록했을 것이고, 우리는 건강한 전달을 보여주는 대시보드에서 그것을 배웠을 것입니다.

속일 수 없는 단어들

첫 주 동안 나눈 대화 중 한 가지가 제가 계속 돌아가 생각하는 부분입니다.

그녀는 지급준비율에 관한 내용을 읽고, 일반적인 버전으로 이해한 다음, 또 다른 질문을 던졌다. '이것과 내 저축액과는 관련이 있나요?' 그는 대답할 수 없었다. 그래서 진실만을 말했다. 즉, 그것은 여기에 없다라고 말이다.

이것은 보이는 것보다 더 중요하다. 전지전능해 보여야 하는 시스템은 그 공백을 채우려 할 것이고, 생성된 문장은 그럴듯하지만 틀릴 것이며, 그녀는 아침 7시이고 확인할 방법이 없기 때문에 믿게 될 것이다. 유일하게 정직한 행동은 '범위에 포함되지 않음'을 말하는 방식이 버그처럼 보이지 않도록 하는 것이다.

이는 면책 조항(disclaimer)이 아니라 생성기(generator)에 대한 설계 제약 조건이다. 즉, 그것이 생성하는 것은 실제로 조립된 무언가와 추적 가능해야 하며, 답변이 그 범위를 벗어나는 경우 출력은 멈추도록 허용되어야 한다.

다음에 우리가 가장 먼저 확인할 것들

만약 내가 우리 자신이 아닌 누군가를 위해 다음으로 구축할 예정인 것을 위한 사전 점검 목록(pre-flight list)으로 이것을 압축해야 한다면:

• 누가 출력을 읽는가? 그리고 그 크기에 대해 언급한 적이 있는가? 만약 아니라면, 첫 번째 버전은 너무 길고 질문한 사람이 알아차리지 못할 것이다.
• 독자의 입장에서 실패란 어떤 모습인가? 만약 아무것도 아닌 것처럼 보인다면, 우리는 원격 측정(telemetry) 데이터가 없으므로 대신 인간의 신호—전화 통화, 답장, 구술 설명—가 필요하다.
• 수정 사항은 어디로 들어가는가? 만약 답변이 '다음 프롬프트에'라면, 우리는 같은 주를 계속 반복해서 만들고 있는 것이다.
• 독자가 휴대폰에서 이미 열어둔 것은 무엇인가? 그것이 전달 채널(delivery channel)이며, 나머지는 우리의 편의를 위해 그들이 다운로드하도록 요청하는 것들이다.
• 무엇에 대해 '범위에 포함되지 않음'이라고 말할 수 있는가?

이것들은 모델 관련 질문이 아니다. 이 모든 것은 작동했던 작업과 습관으로 자리 잡았던 차이점이었다.

위치(Where it sits)

CloudPal은 저희 기계에서 장시간 작업을 실행하고 완성된 문서를 전달합니다. 설치할 것도, 컴퓨터가 할 일도, 이미 가지고 있는 파일에서 읽어올 것도 없습니다. 원하는 것을 한 문장으로 설명하기만 하면 됩니다. 빠뜨렸다고 생각했던 부분까지 포함해서요. 그러면 그 작업이 읽고 쓰고, 결과는 사용자가 이미 보고 있는 곳에 도착합니다.

현재 제한적 미리보기(limited preview) 단계입니다: 새 계정에는 실제 작업을 실행할 수 있을 만큼의 1달러 크레딧이 제공되며, 일일 신규 계정 수는 제한됩니다.

엔지니어로서 평가한다면, 테스트할 가치가 있는 속성은 글쓰기 자체(prose)가 아닙니다. 첫째 주 버전의 수정 사항을 둘째 주 버전이 알고 있는지, 그리고 상대방이 앱을 열어보지 않고도 그것에 대해 이야기해 줄 수 있는지가 핵심입니다.

CloudPal.TuringCorp.net — 에이전트 패스(Agent Pass)를 생성하고 로그인한 후, 원하는 작업을 말해주세요.

이 시리즈의 이전 글: 첫 실행은 데모, 아홉 번째가 제품입니다, 가격이 아니라 측정 단위(meter)입니다, 요청은 한 문장이었습니다, 에이전트가 약속을 지켜야 할 때 무엇이 망가지는지, 그리고 설치 단계를 삭제했을 때.