AI가 저를 세 번 무대에 세웠습니다. 그래도 대중 연설은 여전히 좋아하지 않습니다

AI 요약

글쓴이는 2025년 7월 AI를 활용해 직접 만들어 보던 경험이 법원 업무 실험과 발표로 이어졌다고 설명합니다. 캘리포니아 커뮤니티 칼리지 AI 여름 캠프에서는 1,300명가량의 지원자 가운데 100명만 뽑혔고, 글쓴이는 캠프 첫날 PDF 추출기를 만들어 팀 프로젝트에 보탰습니다. 팀은 14개 팀 가운데 2위를 차지했습니다. 이후 뉴멕시코주 앨버커키와 로스앤젤레스, 리버사이드의 법원 행사에서 현장 직원이 AI 실험을 주도하는 방법을 발표했습니다. 발표를 세 번 마친 뒤에도 대중 연설 자체는 좋아하지 않지만, 메시지가 불편함보다 중요해 다시 초대받으면 나서겠다고 말합니다.

법원 AI 실험의 조건

글쓴이는 법원 업무의 AI 파일럿을 시작하기 전에 서면 승인을 받았습니다. 공개 데이터, 비식별 처리한 데이터, 가상 데이터만 썼고 결과는 사람이 검토했습니다. 시작 전에 중단 기준도 정했습니다. 발표의 요지는 현장 직원이 문제를 발견하고 승인을 요청한 뒤 직접 만들고, 결과물을 내고, 다시 보고하는 다섯 단계로 작은 실험을 주도할 수 있다는 것입니다. 이를 위해서는 직원의 호기심뿐 아니라 제안서를 검토하고 작은 시험을 허용하는 관리자의 협조가 필요하다고 설명합니다.

첫 번째 실험인 Write of Access는 기록 열람 신청서의 손글씨를 읽는 스크립트를 시험했습니다. 글쓴이는 정확도 기준을 90%로 정했지만 결과는 약 80%에 머물렀습니다. 오류는 체크박스와 서명, 날짜처럼 손글씨가 인쇄된 양식과 겹치는 곳에 모였습니다. 글쓴이는 모델을 더 개선하는 대신 손으로 작성할 부분이 적은 양식을 만드는 편이 해결책이라고 판단해 실험을 멈췄습니다.

두 번째 실험인 Hung Jury는 사법위원회에 제출하는 연례 배심원 데이터 보고서의 일부를 자동화하려 했습니다. 금요일 오후에 시작해 월요일 아침에 중단했습니다. PDF에서 값을 추출하고 JSON 매핑을 만드는 등 세 가지 접근이 원천 시스템의 데이터 오류에 막혔습니다. 기존 Excel 통합 문서가 여전히 더 적합한 도구였고, 필요한 조치는 코딩보다 데이터 문제를 논의하는 일이었습니다. 글쓴이는 막다른 길을 석 달이 아니라 주말 동안 확인하는 편이 낫다고 말합니다.

프로젝트마다 달랐던 AI의 역할

리버사이드 발표에서 청중은 AI가 법원 데이터를 처리했는지 물었습니다. 글쓴이는 그 질문에 답하는 설명을 발표에 넣지 않은 점을 아쉬워하며 프로젝트별 역할을 정리합니다. Your Honor, I Object는 캠프 전에 만든 배심원 안내 챗봇 시제품으로, 공개된 캘리포니아 법률을 바탕으로 답을 생성하는 데모입니다. 법원 파일럿으로 사용하지 않았습니다. Write of Access에서는 ChatGPT가 Python 스크립트 작성을 도왔고, 스크립트가 비식별 처리한 양식을 Amazon Textract에 보냈습니다. Textract는 문서의 인쇄 문자와 손글씨를 읽는 AWS 머신러닝 서비스입니다. Hung Jury에서도 ChatGPT가 Python 코드 작성을 도왔지만, 파일럿 데이터에 AI 모델을 적용하지 않았습니다.

글쓴이는 생성형 AI가 답변하는 경우와 AI가 코드 작성을 돕는 경우, 머신러닝 서비스가 문서를 판독하는 경우를 구분해야 한다고 봅니다. 특히 문서가 외부 서비스로 전달됐는지와 누가 사용을 승인했는지를 청중이 알아듣기 쉽게 설명할 필요가 있다고 말합니다. 다음 발표에서는 이 구분을 슬라이드에 넣을 계획입니다.

dev.to 반응

• @build996 — AI 역할을 설명하는 표는 파일럿 결과보다 발표 앞부분에 두는 편이 좋겠습니다. 'AI가 스크립트 작성을 도왔다'와 '문서가 외부 서비스로 전달됐다'는 청중의 서로 다른 질문에 답하고, 표는 두 사실을 모두 드러냅니다. 청중이 문서의 이동 경로를 추측하지 않도록 파일럿마다 쉬운 데이터 흐름 화살표도 하나씩 넣겠습니다. 리버사이드에서는 그 차이를 설명한 뒤 질문이 달라졌나요, 아니면 우려가 계속됐나요?
  • @earlgreyhot1701d — 좋은 생각입니다. 청중이 기술 내용이 너무 많다고 느낄까 봐 더 기술적인 부분을 의도치 않게 뺀 것 같습니다. 우려는 남았습니다. 제가 명확히 설명하지 못했기 때문입니다. 질문을 받고 나서야 어떻게 설명하면 좋을지 생각했습니다. 법원 규모도 차이가 있습니다. 저희 법원은 훨씬 작아 실험할 여지가 더 많습니다. 상대 법원은 제약이 더 많아 그 점을 이해하기 어려워했습니다.
  • @build996 — 법원 규모 차이는 설명에 넣을 만한 조건 같습니다. 실험할 여지가 있다는 점은 프로젝트의 조건이고, 상대 법원의 제약은 도입 조건입니다. '더 큰 법원에서는 무엇을 승인받아야 하나요?'라는 슬라이드가 있으면 시제품과 당장 배포할 수 있는 시스템을 구분하는 데 도움이 되겠습니다. 기술 질문을 구현 세부 사항을 더 요구하는 말로만 보지 않고 실무적인 논의로 이어갈 수도 있습니다. 주로 데이터가 어디로 갔는지 물었나요, 아니면 누가 사용을 승인할 수 있는지 물었나요?
• @sinarezaei — 내용을 익숙하게 아는 것과 사람들 앞에서 발표하는 사람이 되는 데 익숙해지는 것은 다르다고 생각합니다. 주제를 속속들이 알아도 모두의 시선이 모이는 상황은 싫을 수 있습니다. AI를 써서 예측하기 어려운 기술 발표 질문을 연습하는 방법이 유용하겠습니다. 예를 들어 AI가 지원하는 작업 흐름을 엔지니어 팀에 발표하면서 모델이 잘못된 마이그레이션을 만들거나 데이터를 조용히 누락하면 어떻게 되는지 질문받는 상황을 연습할 수 있습니다. 완벽히 외운 대본에 기대지 않고 답한 뒤 회의적인 청중이나 시연이 계획대로 되지 않는 상황으로 연습을 이어갈 수도 있습니다. 가상 청중과 노출 기반 연습을 다룬 연구도 있습니다. 점점 어려운 상황에서 연습하는 방법은 단순한 생산성 요령만은 아닙니다. 이야기가 갑자기 대중 연설을 좋아하게 됐다는 결말로 끝나지 않는 점도 좋습니다. 즐기지 않아도 가치 있는 일을 해낼 수 있습니다.
  • @earlgreyhot1701d — 좋은 관찰입니다. 긴장을 극복하고 이 분야에서 사기꾼이라는 느낌을 받으면서도 발표를 해냈으니 성취라고 느낍니다. 다시 발표해 달라는 요청을 받을지는 지켜보겠습니다.
• @sizzlebop — 이 상황은 정말 무서울 것 같습니다. 몇 시간씩 무언가를 만들고 실험하며 무엇이 되는지 알아보는 건 즐겁지만, 사람들 앞에 서서 이야기하는 건 완전히 다른 도전입니다. 메시지가 편안함보다 중요하다는 말이 좋았습니다. 성공적으로 세 번 발표한 뒤에도 대중 연설을 좋아하지 않는다고 솔직히 말한 점도 시원합니다. 무대에서 내려온 뒤 성취감보다 안도감이 들었다는 부분도 인상적입니다. 기술이 맞는 해결책이 아니라고 판단한 파일럿 접근도 좋았습니다. 무엇을 자동화하지 않을지 알아내는 일도 무언가를 만드는 일만큼 가치가 있습니다.
  • @earlgreyhot1701d — 읽어 주셔서 감사합니다. 참고로 저도 정말 무서웠습니다. 파일럿이 작동하지 않으면 계속하지 않아도 된다는 점이 가장 큰 교훈이었습니다. 새로운 일을 시도할 재량을 받았기 때문에 멈추는 일도 두려웠습니다. 돌아보면 그럴 가치가 있었습니다. 실패 덕분에 생각하지 못했던 해결책을 찾기도 했습니다.
  • @sizzlebop — 그런 관점이 좋습니다. 아이디어를 작동시키는 데 몰두하다 보면 그만두는 일도 가치 있다는 사실을 잊기 쉽습니다. AI를 꼭 끼워 맞추려는 압박이 있는 상황에서는 특히 그렇습니다. 실패한 실험이 새로운 아이디어로 이어진 점도 좋습니다. 예상대로 되지 않아도 얻는 것이 있을 수 있습니다. 저도 대중 연설이 무섭기 때문에 본인도 두려웠다는 말이 위안이 됩니다.

원문: dev.to / 번역·요약: Trawling