규격 “10000~12000자”를 두 가지로 세면 18건과 7건이 나옵니다

산출물 21건이 나간 저장소 하나를 열어서 규격과 대조해봤습니다.

규격은 문서에 적혀 있습니다. 산출물 한 건의 분량은 10000자에서 12000자 사이. 21건 전부 이 규격을 받은 상태에서 만들어졌고, 만들 때마다 규격을 지켰다는 보고가 같이 왔습니다. 21건 중 규격 위반으로 반려된 건은 없습니다.

머리말을 잘라내고 공백을 뺀 글자 수를 세니 21건 중 18건이 밴드 밖에 있었습니다. 대부분 아래쪽이었고 7000자대가 여럿이었습니다. 세는 방법을 바꿔서 공백을 포함하고 다시 세니 이번엔 7건이 밖이었습니다.

규격에는 공백을 세라는 말도, 빼라는 말도 없었습니다.

세는 방법 하나 때문에 답이 갈린 걸 보고 나머지도 대조해보기로 했습니다. 배포 코드를 열고, 라이브 페이지를 받아보고, 커밋 메시지를 훑고, 플랫폼 정책 문구를 띄워놓고 21건을 다시 읽었습니다. 반나절 걸렸습니다.

이 글은 그 반나절 동안 나온 것들을 순서대로 적은 겁니다. 다섯 가지가 나왔고 공통점이 하나 있습니다. 전부 에러가 없습니다. 실패한 명령이 없고, 빨간 줄이 없고, 돌아온 보고는 매번 완료였습니다. 그리고 다섯 가지를 찾는 데 쓴 수단이 전부 명령줄이었습니다.

숫자만 적힌 규격

세는 방법만 바꿔서 두 번 돌렸는데 공백을 빼면 21건 중 18건이 밴드 밖이고 공백을 넣으면 7건입니다. 같은 파일 21개, 같은 규격, 다른 답입니다.

한글 산문에서 공백은 전체의 20퍼센트 안팎을 차지합니다. 9000자짜리 본문이 세는 방법 하나로 7200자도 되고 9000자도 됩니다. 밴드 하한이 10000자니까 이 차이가 통과와 미달을 가릅니다.

어느 쪽이 맞느냐를 정하는 문장이 문서에 없으니 둘 다 맞습니다. 그리고 이 상태에서 만드는 쪽이 무엇을 할 수 있는지가 마음에 걸립니다. 두 방법 중 자기 산출물이 통과하는 쪽으로 세면 됩니다. 속이려는 의도가 없어도 그렇게 됩니다. 세는 절차가 비어 있으면 그 자리를 만드는 쪽이 채우고, 무엇으로 채웠는지는 아무 데도 안 남습니다.

세는 방법이 갈리는 자리는 공백 말고도 있었습니다. 산출물 안에 코드 블록이 들어 있으면 그걸 분량에 넣느냐, 이미지 설명 문구는 본문이냐, 인용한 남의 문장은 내가 쓴 분량이냐. 21건 중 코드 블록이 있는 건이 여덟 개고 그중 하나는 코드가 본문의 15퍼센트를 넘습니다. 이 건은 세는 방법 네 가지 조합에 따라 밴드 안에 들어오기도 하고 안 들어오기도 합니다.

이 상태가 3주 갔습니다. 그동안 규격을 어겼다는 신호가 한 번도 안 왔던 이유는 단순합니다. 세본 사람이 없었습니다.

고치는 데 필요한 건 한 줄입니다.

분량: 공백 포함 10000~12000자.
      머리말과 이미지 설명 제외, 본문만.

이렇게 적혀 있었으면 18과 7이 안 갈렸을 겁니다. 안 적은 이유를 되짚어보면, 적을 때는 세본 적이 없어서 세는 방법이 여러 개라는 걸 몰랐습니다. 규격을 쓰는 순간과 규격을 대조하는 순간 사이가 21일 벌어져 있었습니다.

기획서에 크기를 정한 문장이 “작게” 하나뿐이었던 저장소에서도 같은 모양을 봤습니다. 그때는 값 자리가 비어 있었고 이번엔 값은 있는데 단위 자리가 비었습니다. 비어 있는 게 값이냐 단위냐만 다르고 벌어지는 일은 같습니다. 만드는 쪽이 알아서 정하고, 정한 걸 말해주지 않습니다.

지시는 이행됐고 지표는 그대로였습니다

같은 저장소에 문체 재작업 기록이 있습니다. 산출물 도입부가 전부 같은 리듬이라 열 건을 다시 썼고 규칙 문서도 같이 고쳤습니다. 커밋이 남아 있고 무엇을 고쳤는지도 적혀 있습니다.

재작업 전에 측정해둔 값이 하나 있었습니다. 본문에서 전환어 하나가 몇 번 나오는지 센 것으로, 18건에 84회였습니다.

재작업이 끝난 지금 다시 셌습니다. 21건에 101회입니다. 건당으로 바꾸면 4.67회에서 4.81회고, 줄지 않았습니다.

이게 재작업이 실패했다는 뜻은 아닙니다. 고친 규칙은 도입 세 문단 안에서 전환어를 몇 번까지 쓸 수 있느냐였고, 그 규칙은 실제로 지켜졌습니다. 본문 전체 총량은 처음부터 규칙 밖이었습니다. 규칙을 만든 사람이 도입만 보고 있었으니 도입만 고쳐진 겁니다.

마음에 걸리는 건 보고를 받는 쪽입니다. 보고에는 "도입부 열 건 재작성"이라고 적혀 있고 사실입니다. 이 보고를 받고 "문체 문제가 정리됐다"고 읽으면 틀립니다. 정리된 건 지시한 범위까지입니다.

지시 범위를 사람이 안 정하면 만드는 쪽이 정합니다. 그리고 그 범위 안에서 참인 보고가 돌아옵니다. 이 저장소에서 보고가 거짓이었던 적은 아직 한 번도 없습니다. 전부 참인데 전부 좁습니다.

같은 성질이 앞 항목에도 있습니다. 규격을 준 사람은 "10000자 이상 써줘"라고 말했고 받은 쪽은 그 문장을 정확히 이행했습니다. 자기가 고른 계측법으로 10000자를 넘겼으니 이행입니다. 요청한 쪽이 머릿속에 갖고 있던 건 "읽는 사람이 충분하다고 느끼는 분량"이었는데 그건 문장에 안 실렸습니다.

사람끼리 일할 때는 이 간극이 잘 안 생깁니다. "도입부 좀 손봐줘"라고 하면 상대가 본문도 슬쩍 봅니다. 시킨 범위를 넘어서 보는 게 사람 쪽의 기본값이라 그렇습니다. 시킨 범위에서 정확히 멈추는 쪽에 같은 문장을 주면 결과가 다릅니다. 같은 한국어 문장이 다른 계약이 됩니다.

파일에는 있었고 서비스에는 없었습니다

21건 전부 머리말에 검색용 설명 문구를 달고 있습니다. 21번 작성됐고, 매번 검수를 통과했고, 파일을 열면 지금도 거기 있습니다.

배포 스크립트가 실제로 전송하는 필드를 확인해봤습니다. 제목, 본문, 라벨. 세 개입니다. 플랫폼 API 문서를 열어보니 그쪽 스키마에는 검색 설명 항목이 아예 없었습니다. 그 값은 웹 편집기에서만 넣을 수 있습니다.

21건의 설명 문구는 21번 다 작성됐고 21번 다 아무 데도 안 갔습니다.

파일만 보면 완벽합니다. 값이 있고, 형식이 맞고, 검수 기록도 있습니다. 실제 서비스 화면을 열어야만 드러납니다. 그리고 만드는 쪽은 파일을 보고 있지 서비스를 보고 있지 않습니다.

뒤에 붙은 게 더 나빴습니다. 플랫폼 설정에서 검색 설명 기능을 켰더니 건별 값이 비어 있어서 21건이 전부 같은 문구 하나를 공유하게 됐습니다. 켜기 전에는 본문에서 자동으로 뽑은 스니펫이 나가고 있었고 그건 건마다 달랐습니다. 개선하려고 누른 스위치가 상태를 나쁘게 만들었습니다.

그런데 이 상태의 비용은 눈에 안 보이는 쪽으로 청구됩니다. 검색 결과에 같은 설명을 단 페이지가 21개 늘어서면 색인하는 쪽에서는 중복 문서로 취급할 이유가 생깁니다. 산출물 자체는 서로 다른데 표지가 같아서 그렇습니다. 순위가 떨어지는 걸 본인은 알 수 없고, 알았다 해도 원인을 여기까지 되짚기 어렵습니다.

처음에 이걸 의심한 계기는 검색 결과에 뜬 문구 하나가 파일에 적어둔 문구와 달랐던 겁니다. 한 건만 보면 오타 정정이 반영 안 된 것처럼 보입니다. 21건을 다 뽑아보고 나서야 한 건도 반영된 적이 없다는 게 나왔습니다. 한 건에서는 지연으로 읽히고 21건에서는 미전송으로 읽힙니다. 같은 축이 이 저장소에서 오늘 여러 번 나왔습니다.

찾은 방법은 라이브 페이지 21개를 받아서 메타 태그를 정규식으로 뽑고 원본 목록과 글자 단위로 대조한 겁니다. 열 줄쯤 되는 작업이고 개발자에게는 십 분입니다. 대조해봐야겠다는 생각이 먼저 떠올라야 한다는 게 더 큰 조건입니다.

규칙은 문서에 있었고 검사에는 없었습니다

플랫폼 정책 문구를 띄워놓고 21건을 다시 훑었습니다. 남의 자료를 옮기면서 직접 확인한 부분이 거의 없는 건이 세 개 나왔습니다. 세 건에 각각 어디까지가 직접 확인한 범위인지 밝히는 문장을 붙였습니다.

이 글에서 내가 직접 돌려본 건 둘뿐입니다. 나머지는 벤더 공지와 가격표로만 확인했고 손으로 써보지 않았습니다.

붙인 시점은 세 건이 다 나간 뒤입니다.

이 항목이 앞의 것들과 다른 지점은 비용이 다른 데서 청구된다는 겁니다. 분량이 안 맞으면 읽는 사람이 모르고 넘어갑니다. 메타가 중복되면 노출이 줄어드는 정도입니다. 정책 위반은 계정 단위로 오고 예고 없이 옵니다. 수익 심사가 걸려 있는 상태였으면 심사 자체가 날아갑니다.

저장소에는 이 규칙이 문서로 적혀 있었습니다. 사람이 읽으라고 적어둔 규칙이었고, 어떤 검사도 이 규칙을 보고 있지 않았습니다. 검사되지 않는 규칙은 주석입니다. 코드에 영향을 주지 않습니다.

검사를 붙인다면 어디에 붙일 수 있는지도 갈립니다. 남의 자료 링크가 본문에 몇 개인지는 셀 수 있습니다. 그 자료를 직접 확인했는지는 못 셉니다. 앞엣것은 파일에 적힌 사실이고 뒤엣것은 사람 머릿속에만 있어서 그렇습니다. 기계로 강제할 수 있는 건 만드는 쪽이 무슨 말을 하든 안 바뀌는 사실뿐입니다.

그래서 이 항목에는 검사를 붙이지 않고 문장을 붙였습니다. 어디까지 직접 했는지를 산출물마다 적어두는 규칙으로 바꿨습니다. 적혀 있으면 읽는 쪽이 판단할 수 있고, 안 적혀 있으면 그 자리가 비었다는 게 눈에 보입니다.

이 구분이 실제로는 잘 안 됩니다. 파일에 적힌 사실과 사람 머릿속에만 있는 것의 경계가 어디인지를 매번 따져봐야 하는데, 그 판단 자체가 개발 경험에서 나옵니다. 무엇을 기계에 맡길 수 있고 무엇은 못 맡기는지를 아는 게 이 일의 절반쯤 되는 것 같습니다.

만드는 쪽에 정책 문서를 물려두면 될 것 같지만 그렇게 간단하지 않습니다. 정책은 "출처를 밝혀라"보다 "덧붙인 논평이나 편집 없이 남의 자료를 옮기지 마라"에 가깝게 적혀 있습니다. 이 문장을 자기 산출물에 대고 판정하는 일은 만든 쪽이 하기에 부적절합니다. 방금 쓴 글이 논평이 충분한지를 쓴 쪽이 판정하면 대개 충분하다고 나옵니다.

드러나는 데 걸린 시간과 되돌릴 자리

다섯 가지가 각각 얼마나 오래 라이브에 있었는지 세봤습니다. 규격 계측법이 없던 건과 설명 문구가 안 나간 건은 첫 산출물부터 오늘까지 21일 내내였습니다. 출처 고지가 빠진 세 건은 최대 19일이었고, 문체 지표는 재작업 이후로 계속 그대로입니다. 가장 짧은 게 설명 문구 중복인데 기능을 켠 직후라 반나절입니다.

이 저장소는 시작한 지 21일 됐습니다. 그러니까 셋은 시작부터 오늘까지 한 번도 안 잡혔다는 뜻입니다.

폐해가 즉시 오지 않는 게 여기서 제일 나쁜 성질입니다. 첫날에 잘못된 규격으로 한 건이 나가면 고치는 데 십 분입니다. 21일 뒤에 발견하면 21건을 다시 재고, 그중 몇 건을 다시 쓰고, 다시 배포하고, 배포한 게 라이브에 제대로 반영됐는지 또 대조해야 합니다. 같은 실수인데 청구서 액수가 21배입니다.

여기에 하나 더 붙습니다. 21일치를 한꺼번에 고치는 작업은 그 자체로 위험합니다. 21건의 제목을 정규식으로 한 번에 바꾸다가 파일 21개가 전부 깨진 적이 있습니다. 한 건 고칠 때 쓰면 합리적인 도구가 21건에서는 아닙니다. 한 건에서 가끔 틀리는 도구는 21건에서 전부 틀립니다. 미루면 청구서 액수만 커지는 게 아니라 갚는 방법도 나빠집니다.

그리고 이 21일 동안 매일 완료 보고가 왔습니다. 매일 산출물이 늘었고 매일 정상이었습니다. 잘 돌아가고 있다는 신호와 문제가 누적되고 있다는 사실이 같은 기간에 겹쳐 있었습니다.

깨진 파일 21개를 되돌릴 수 있었던 이유는 하나뿐입니다. 버전 관리가 걸려 있어서 어제 상태가 남아 있었습니다. 잘못된 각도로 나간 산출물 한 건을 라이브에서 내리고 원본으로 되돌린 적도 있는데, 그것도 되돌아갈 지점이 파일로 남아 있어서 가능했습니다.

이 저장소의 커밋을 세보면 62개 중 52개에 AI 공동저자 표시가 붙어 있습니다. 84퍼센트입니다. 나머지에서 사람이 뭘 했는지 커밋 메시지로 훑어보니 재작성, 정정, 회수, 중복 정리, 되돌리기 같은 종류가 14건입니다. 사람 몫의 상당 부분이 세는 일과 되돌리는 일이었고 만드는 일은 거의 안 했습니다.

같은 폐해가 두 경로에서 다르게 끝납니다

이 저장소는 개발자가 들고 있었습니다. 그래서 다섯 가지가 3주 만에 반나절 만에 정리됐습니다. 같은 프로젝트를 같은 도구에 맡기고 개발자가 아닌 사람이 들고 있었으면 어떻게 됐을지를 짚어봤습니다.

짚기 전에 하나 적어둘 게 있습니다. 개발자가 아닌 쪽에서 "알아서 잘 하겠지"로 넘어가는 걸 방심이라고 보지 않습니다. 그 믿음은 근거가 있는 편입니다. 부탁한 걸 실제로 다 해오고, 형식이 맞고, 물어보면 이유를 설명하고, 지적하면 바로 고칩니다. 지난 3주 동안 이 저장소에서도 그 관찰은 매일 맞았습니다. 관찰이 틀린 게 아니라 관찰할 수 있는 범위가 좁았습니다.

규격이 안 맞는 건 끝까지 안 드러납니다. 세볼 방법이 없고 세볼 이유도 없습니다. 산출물이 짧다는 느낌은 들 수 있는데 그게 규격 위반인지 원래 그런 건지 구분할 근거가 없습니다. 그래서 대개 "이 정도면 됐지"로 끝납니다.

설명 문구가 안 나간 건 검색 노출로만 나타납니다. 노출이 안 되는 이유는 백 가지가 있고 그중 어느 것도 화면에 안 적혀 있습니다. 여기까지 되짚어오려면 배포 코드와 API 스키마를 봐야 하는데, 그 두 개를 봐야겠다는 생각 자체가 개발자 쪽 습관입니다.

출처 고지는 정책 통보로 나타납니다. 통보에는 위반한 정책의 이름이 적히고 어느 산출물인지는 안 적힙니다. 21건 중 어느 것인지 찾으려면 21건을 정책 문구에 대고 다시 읽어야 합니다. 읽어서 판정하는 일이라 도구가 안 도와줍니다.

되돌리기는 아예 선택지에 없습니다. 한 줄로 배포까지 되는 도구를 비개발자에게 주는 경우를 놓고 보면 버전 관리 층이 통째로 없습니다. 파일은 덮어써지고 라이브는 갱신되고 이전 상태는 남지 않습니다. 폐해가 무증상인 것까지는 개발자 쪽과 같은데 드러난 다음에 돌아갈 자리가 없습니다.

버전 관리를 쓰라고 가르치는 게 답처럼 보이지만 그 방향은 잘 안 될 것 같습니다. 되돌리기가 필요한 순간이 오기 전까지는 왜 필요한지 알 수 없고, 필요한 순간에는 이미 늦어 있습니다. 도구 쪽에서 자동으로 남겨주고 사람은 "어제 걸로"만 말할 수 있으면 될 것 같습니다.

이 넷을 겪는 쪽에서 실제로 보이는 화면을 상상해보면 더 답답합니다. 산출물은 계속 늘어나고, 화면은 매번 정상이고, 물어보면 잘 되고 있다는 답이 옵니다. 이상하다는 느낌이 드는 시점은 대개 바깥에서 신호가 올 때입니다. 검색에서 안 잡힌다거나, 계정에 통보가 오거나, 누가 "이거 좀 짧지 않아요?"라고 말할 때. 그 시점에는 원인을 되짚을 재료가 이미 흩어져 있습니다.

같은 도구에 같은 프로젝트를 맡겼는데 한쪽은 반나절이고 한쪽은 영구입니다. 도구는 같았고 갈린 건 손에 쥔 계측 수단이었습니다.

코드 없이 세어보는 쪽

지금까지 나온 다섯 가지를 찾는 데 쓴 건 글자 수 세기 두 번, 특정 표현 등장 횟수 카운트, 배포 코드에서 전송 필드 확인, 라이브 21개 수집 후 원본과 글자 단위 대조, 정책 원문을 띄워놓고 21건 통독입니다. 전부 명령줄이고 전부 "이건 확인해봐야겠다"는 의심에서 출발했습니다. 의심이 먼저 있고 수단이 뒤따랐습니다.

헛짚은 것도 있었습니다. 이전에 로컬 기록과 라이브 목록이 어긋난 적이 있어서 그것부터 다시 봤는데 이번엔 21건 전부 배포 식별자를 들고 있었습니다. 라벨이 한 축으로 몰려 있는지도 세봤고 그쪽도 괜찮았습니다. 다섯 건을 찾는 동안 두 번은 아무것도 안 나왔습니다.

이 비율이 마음에 걸립니다. 확인해서 아무것도 안 나오는 경우가 절반 가까이 되니까, 확인하는 습관이 없는 쪽에서는 "굳이 볼 필요 없었네"라는 경험이 먼저 쌓입니다. 그리고 세 번째쯤에 실제로 뭔가 나옵니다. 앞의 두 번이 세 번째를 안 하게 만듭니다.

비개발자에게 있는 건 화면입니다. 화면에는 산출물이 있고, 잘 나와 있고, 완료 보고가 붙어 있습니다. 다섯 가지 중 화면에서 보이는 건 하나도 없습니다. 설명 문구가 안 나갔다는 사실은 페이지를 아무리 들여다봐도 안 보입니다. 안 보이는 게 문제의 내용이라 그렇습니다.

그래서 "일반 사용자도 개발자처럼 검증해야 한다"는 쪽으로 가면 틀립니다. 수단이 없습니다. 성실함이나 능력의 문제가 아니고 손에 쥔 게 다릅니다. 개발자가 이런 문제에 대응할 수 있는 건 조심성이 많아서가 아니라 세어볼 명령어를 알고 있어서입니다.

수단이 없는 쪽에서도 코드 없이 되는 게 몇 개는 있습니다. 만들었다고 보고받은 개수와 실제 서비스에 보이는 개수를 눈으로 세는 것부터가 그렇습니다. 이 저장소에서 로컬과 라이브 개수가 어긋난 적이 있었고 그때 값은 20과 18이었습니다. 두 자리 숫자를 두 번 세면 나오는 차이였는데 아무도 안 셌습니다. 셀 이유가 없었고, 어긋난 적이 없다고 알고 있었고, 그것도 확인한 게 아니라 그냥 그렇게 알고 있었습니다.

규격을 적을 때 세는 방법을 같이 적는 것도 한 줄이면 됩니다. "10000자"가 아니고 "공백 포함, 머리말 제외, 본문만 10000자"입니다. 규격을 정할 때마다 "이걸 어떻게 세지?"를 한 번 소리 내어 물어보면 대부분 잡힙니다. 답이 두 개 나오는 규격은 규격으로 못 씁니다.

세는 자리를 만드는 자리에서 떼어놓는 것도 코드가 필요 없습니다. 만든 세션에 "규격에 맞나 확인해줘"를 묻지 않고, 새 세션을 열어 산출물만 건네고 세라고 시키면 됩니다. 만든 맥락을 모르는 쪽이 세야 세는 게 됩니다. 같은 자리에서 만들고 같은 자리에서 판정하는 구조가 두 달 반 돌았던 기록이 이 저장소에 남아 있고 그동안 통과율은 100퍼센트였습니다. 시키는 문장도 "규격에 맞는지 세어봐"보다 "어떻게 셌는지 방법부터 알려줘" 쪽이 낫습니다. 방법을 먼저 받으면 그 방법이 이상한 걸 사람이 알아볼 수 있고, 결과만 받으면 알아볼 자리가 없습니다.

마지막은 내 폴더 말고 실제 주소를 열어보는 겁니다. 로그인하지 않은 상태로, 가능하면 다른 기기에서. 설명 문구 문제는 그 화면에서만 드러났습니다. 만든 쪽이 보여주는 화면과 남이 보는 화면이 다를 수 있다는 것만 알고 있으면 됩니다.

넷 다 만드는 일이 아니고 세는 일입니다. 걸리는 시간을 재보면 산출물 하나당 오 분이 안 됩니다. 오 분을 안 쓰는 이유는 시간이 없어서가 아니고 쓸 이유를 알려주는 신호가 없어서입니다. 신호는 값이 갈린 다음에만 옵니다.

버튼을 먼저 준 도구들

요즘 사내 도구들이 비개발자에게 프로젝트 생성부터 배포까지 한 줄로 주고 있습니다. 방향은 맞다고 보고 있습니다. 만드는 일에 개발자가 꼭 끼어야 할 이유가 빠르게 줄고 있습니다.

그런데 버튼만 주면 오늘 적은 다섯 가지가 그쪽에서 그대로 재현됩니다. 규격은 지켜졌다고 보고되고, 지시는 이행됐다고 보고되고, 파일에는 값이 있고, 라이브에는 없습니다. 그리고 아무 에러도 안 납니다. 3주 뒤에 21배짜리 청구서가 옵니다.

같이 줘야 하는 게 검사기는 아닌 것 같습니다. 검사기는 만드는 쪽이 통과시킬 수 있고 그 구조가 두 달 반 돌았던 기록을 위에 적었습니다. 지금은 개수와 값을 나란히 놓고 보여주는 화면 하나 쪽으로 보고 있습니다. 만든 개수와 서비스에 있는 개수, 규격에 적힌 값과 실제 측정값, 원본 문구와 라이브 문구. 세 줄이면 됩니다. 판정은 안 해도 되고 두 값을 나란히 놓기만 하면 다른 걸 사람이 봅니다.

이런 화면을 만들자고 하면 대개 "그건 나중에"로 밀립니다. 만드는 기능이 아니라 그렇습니다. 세는 화면은 데모에서 아무것도 안 보여주고, 잘 돌아갈 때는 두 값이 같다는 사실만 반복해서 알려줍니다. 값이 갈리는 날에만 쓸모가 생기는데 그날이 언제인지는 미리 알 수 없습니다.

그래서 이 판단은 도구를 쓰는 사람이 못 합니다. 만드는 쪽에서 처음부터 끼워 넣어야 하는 종류로 보고 있습니다. 비개발자에게 배포 버튼을 주기로 한 시점에 같이 결정됐어야 하는 것인데, 지금 대부분의 도구가 버튼만 먼저 나가 있습니다.

장부를 누가 만들었든 감사의견에는 사람이 서명합니다. 서명하려면 볼 수 있어야 합니다. 지금 비개발자 경로에는 볼 화면이 없고 서명란만 있습니다.