Loading the catalog…
Loading the catalog…
검증자가 작업자와 같으면 같은 답이 나온다 도구도 틀리고, 도구를 돌린 쪽도 틀린다 앞선 글들에서 확인에도 층위가 있다고 썼다. 문서가 맞을 때도 있고, 검사 도구가 조용히 거짓말을 할 때도 있다는 이야기였다. 이번에는 한 칸 더 간다. 도구를 돌린 사람, 혹은 도구를 돌린 세션도 틀린다. 이틀 동안 "없다", "막혀 있다", "깨짐 0건" 같은 판정을 여러 번 내렸다. 그중에는 틀린 것도 있었고, 맞지만 내가 본 범위 안에서만 맞는 것도 있었다. 이 글은 그중 가장 일반화하기 쉬운 장면, 작업한 세션이 자기 작업을 검증했을 때 무슨 일이 있었는지를 다룬다. "깨짐 0건"이라는 보고 문서와 노트 도구에 대량 편집을 하는 작업이 있었다. 코딩 에이전트가 긴 한글 문장을 여러 군데 옮겨 쓰는 작업이었다. 작업을 마친 세션은 이렇게 보고했다. "한글 깨짐 0건." 같은 세션에 이어서 "한 번 더 확인해 줘"라고 시켰다면 같은 답이 나왔을 것이다. 그 세션은 자기가 한 작업의 맥락을 그대로 갖고 있고, 같은 방법으로 같은 곳을 볼 테니까. 그래서 작업을 본 적 없는 새 세션 을 열고, 읽기 전용으로 다시 확인하게 했다. 편집은 하지 말고 이상이 있어도 고치지 말고 보고만 하라는 조건이었다. 이 새 세션은 1건을 더 찾았다. 이 오류는 눈으로 안 보인다 이 편집 방식에서 생기는 오류는 한글이 비슷한 다른 글자로 바뀌어 저장되는 형태였다. 받침 하나가 다르거나, 초성이 끼어들어 음절이 늘어나는 식이다. 문장이 아예 깨지는 게 아니라 그럴듯한 다른 글자가 되기 때문에, 눈으로 통독해도 걸리지 않고 검색해도 걸리지 않는다. 눈에 같은 글자가 사실은 다른 글자였던 경우도 있었다. 한글 단어 안에 키릴 문자가 섞여 있었는데, 눈으로는 같은 글자로 보였고 검사 스크립트가 잡아냈다. 이런 오류 앞에서 "깨지지 말라"는 금지 문구는 방어선이 되지 못했다. 실질적인 방어선은 두 가지였다. 작업이 끝난 뒤에 편집한 곳을 코드 단위로 대조하는 사후 전수 확인 그 작업을 본 적 없는 세션이 한 번 더 읽어 보는 재확인 깨진 글자를 설명하다가 오염을 만들었다 이 과정에서 생긴 작은 사고가 하나 더 있다. 기존에 깨져 있던 곳을 설명하려고, 그 깨진 문자열을 글에 그대로 인용 했다. 그랬더니 그 설명 문장이 새 오염원이 되어, 기존 깨짐을 세어 둔 기준값이 늘어났다. 대조군이 오염된 것이다. 그다음부터는 깨진 글자를 그대로 쓰지 않고 정상 표기, 성격, 위치 로만 설명했다. "이 단어의 첫 음절 받침이 다르다, 어느 문단에 있다" 하는 식이다. 오염된 걸 설명하는 문장이 오염을 키운다는 건, 막상 겪기 전에는 생각하지 못한 일이었다. 같은 맥락의 작은 사고: 88과 86 같은 이틀에 숫자도 하나 어긋났다. 어떤 집계가 88건이라고 적혀 있었는데, 같은 조건으로 다시 세어 보니 86건이 나왔다. 집계가 같은 걸 가리키는 줄 알았는데, 그 숫자를 낸 정의를 함께 옮기지 않았다. 무엇을 한 건으로 세었는지가 달랐을 수 있다. 이 불일치는 지금도 원인을 찾지 못했다. 정의 없이 숫자만 옮기면 재현이 안 된다는 것까지만 확인했다. 그게 원인 규명이 아니라 교훈이라는 점은 구분해서 적는다. 아직 다 된 건 아니다 새 세션이 1건을 더 찾았다는 건 n=1 이다. 독립 검증이 항상 더 찾는다는 뜻은 아니다. 이번에는 그랬다는 관측이다. 한글 깨짐의 방어선은 완전하지 않다. 코드 단위로 비교할 수 있는 곳이 있었고, 그러지 못해서 눈으로 통독한 곳도 있었다. 후자는 한계로 남는다. 88과 86이 어긋난 원인은 모른다. 처음에 "깨짐 0건"이라고 판정한 건 작업한 세션이었고, 그 판정을 맡긴 건 나였다. 변명하자면 그 보고는 그 세션이 가진 눈으로는 사실이었다. 문제는 그 눈 하나로 검증을 끝낸 것이었다. 마무리: 판정 옆에 붙여야 할 것 이번 일을 정리하면서 판정 옆에 붙여야 할 것이 세 가지로 모였다. 어디까지 확인했는가 — "없다"는 "내가 본 범위에 없다"일 수 있다. 무엇으로 확인했는가 — 실측인지, 논증인지, 문서를 옮긴 것인지. 누가 확인했는가 — 만든 쪽의 자기 보고인지, 만든 적 없는 쪽의 재확인인지. 세 가지가 빠진 "0건"은 맞는 판정과 틀린 판정을 구분해 주지 못한다. 같은 눈으로 다시 보면 같은 답이 나오는 건 당연한 일이고, 틀린 곳은 다른 눈이 봤을 때 비로소 나왔다. 띵동(Ddingdong)은 청각장애인 1인 가구를 위한 현관 부착형 소리 분류 알림 시스템 졸업작품입니다. 초인종 · 노크 · 화재경보를 구분해서 사진과 자막까지 스마트폰으로 보내주는 걸 목표로 만들고 있습니다.
What RADAR observed and classified to build this opportunity. It is what the source published, not a verification that the offer is still active.
[ 졸업작품 기록 (73) ]. 검증자가 작업자와 같으면 같은 답이 나온다 도구도 틀리고, 도구를 돌린 쪽도 틀린다 앞선 글들에서 확인에도 층위가 있다고 썼다. 문서가 맞을 때도 있고, 검사 도구가 조용히 거짓말을 할 때도 있다는 이야기였다. 이번에는 한 칸 더 간다. 도구를 돌린 사람, 혹은 도구를 돌린 세션도 틀린다. 이틀 동안 "없다", "막혀 있다", "깨짐 0건" 같은 판정을 여러 번 내렸다. 그중에는 틀린 것도 있었고, 맞지만 내가 본 범위 안에서만 맞는 것도 있었다. 이 글은 그중 가장 일반화하기 쉬운 장면, 작업한 세션이 자기 작업을 검증했을 때 무슨 일이 있었는지를 다룬다. "깨짐 0건"이라는 보고 문서와 노트 도구에 대량 편집을 하는 작업이 있었다. 코딩 에이전트가 긴 한글 문장을 여러…
Open source