요약
켄터키대학교 직원이 인본주의 신념을 근거로 업무에서 AI를 쓰지 않아도 된다는 허락을 받았습니다.
종교 전문 매체 RNS의 보도입니다. 켄터키대학교 연구 행정 담당자 데이비드 더먼(45)은 학교가 업무에 AI를 쓰라고 하자, 생각과 판단을 기계에 넘기는 일이 자기 신념에 어긋난다며 종교적 편의를 요청했습니다.
왜 중요한가
- 미국인본주의자협회는 인본주의자가 AI 사용을 면제받은 첫 사례로 봅니다.
- 연방 법원이 인본주의를 종교로 인정해 온 만큼, 인본주의자도 다른 종교인처럼 AI 거부를 요청할 수 있음을 보여 줍니다.
- 미국인 57%가 AI가 사회에 해롭다고 답할 만큼 AI에 대한 회의가 커지는 가운데, 그 흐름이 직장의 법적 권리로 이어졌습니다.
핵심 내용
- 학교는 부서에 과도한 부담이 없다고 보고 9월 25일 자 서한으로 요청을 받아들였습니다.
- 다만 AI를 쓰는 회의에 참석하거나 AI 기반 사이트로 자료를 내는 일은 계속 해야 합니다.
- 그는 Title VII(신앙에 맞게 근무 조건을 바꿔 달라고 요청할 수 있게 한 연방법)에 근거해 요청했습니다.
- 요청서에는 개인 신념과 함께 2003년판 인본주의 선언을 근거로 담았습니다.
- 법학자 더글러스 레이콕은 이런 요청은 신념이 진지한지에 달려 있고, 이는 고용주가 따질 문제라고 설명했습니다.
HN 반응
- AI를 거부하는 사람들이 아미시(현대 기술을 멀리하는 기독교 공동체)처럼 새로운 생활 방식을 이룰 수 있다는 관측이 먼저 나왔습니다.
- 토론은 개발자와 지식 노동자의 AI 활용 차이로 번졌고, 검증이 어려운 법률·의학 분야에선 AI 결과를 일일이 확인하느니 직접 하는 편이 낫다는 의견이 이어졌습니다.
정말 흥미롭습니다. 저는 AI가 대단한 도구라고 생각하는 사람이지만, AI 사용을 거부하는 사람들이 직장과 일상에서 어떻게 지내게 될지 꽤 궁금합니다.
아미시 같은 새로운 생활방식이 우리 눈앞에서 실시간으로 생겨나고 있는지도 모릅니다. (멀찍이서) 지켜보고 따라가 보기에 아주 흥미로운 일입니다.
AI를 보면서 느낀 점이 하나 있습니다. 소프트웨어 개발자가 쓰는 AI와 지식 노동자가 쓰는 AI가 빠르게 갈라지고 있다는 것입니다.
지식 노동자는 주로 일을 "보조"하는 데 씁니다. AI에게 질문하고, 문서를 만들게 하는 식이죠. 그래도 보통은 한 사람이 대화 스레드 한두 개를 상대하는 정도입니다.
반면 소프트웨어 개발에서는 에이전트 무리(fleet)를 돌립니다. 저희 회사는 에이전트 요청을 한 번 던지면 과정의 여러 단계에서 결국 AI 호출이 10~20번쯤 일어나도록 구성해 두었습니다.
이 차이를 짚는 이유는 두 집단이 AI를 바라보는 방식이 달라지기 때문입니다. 개발자에게는 그냥 "스택의 위쪽으로 올라가는 것"으로 느껴집니다. 더는 코드를 직접 쓰지 않아도 "소프트웨어 공장" 안에서 할 일도 풀 문제도 여전히 많습니다. 반대로 지식 노동자는 AI가 자기 대신 모든 결정을 내려 주는 것처럼 느낍니다.
저는 이걸 공장 노동자와 장인의 차이로 봅니다. 개발자는 "공장 노동자"입니다. 예전에는 현장에서 직접 일했지만 이제는 일을 넘겨받은 기계를 관리합니다. 그 단계에도 흥미로운 문제가 아직 많고, 스스로 가치가 있다고 느낄 수 있습니다. 이 비유에서 장인에 가까운 지식 노동자는 사정이 다릅니다. 공장을 운영하는 게 아니라, 자기가 하던 일을 로봇이 하는 걸 할 일 없이 앉아서 지켜보게 됩니다.
에이전트와 일반 채팅 인터페이스로 AI 쓰임새가 갈린다는 전반적인 논지는 맞다고 봅니다. 하지만 나머지는 동의하기 어렵습니다.
말씀하신 지식 노동자의 모습은 AI를 쓰다가 실패하는 사람들의 모습이고, 대개 티가 확 납니다.
자기 일을 아는 지식 노동자는 AI가 엉뚱한 길로 빠지기 일쑤고, 잘못된 출처를 대거나 없는 출처를 지어내고, 아무 페이스북 글이나 레딧 게시물을 어떤 주제의 권위 있는 자료처럼 가져다 쓴다는 것을 금방 알아챕니다. 법조계에서는 어느 관할(venue)이 적용되는지 AI가 제대로 이해하고 맞는 관할만 고수하게 하려면 씨름해야 합니다. 의학 연구에서는 엉뚱한 곳에서 나온 엉터리 논문을 끌어와 잘 정립된 연구와 뒤섞기도 합니다.
지식 분야 사람들은 AI를 반복해서 쓰면서 결과를 끊임없이 다시 확인하고 바로잡아야 한다는 걸 아주 빨리 깨우쳤습니다. 혼자 돌아가게 두면, 버몬트 법원에서 벌어지는 여러분의 사건과는 아무 상관도 없는 켄터키의 이상한 판례에 기댄 법리를 내놓을 겁니다.
프로그래밍도 그리 다르지 않습니다. 다만 알아채기까지 시간이 더 걸릴 뿐입니다.
AI를 쓰는 건 어댑티브 크루즈 컨트롤을 쓰는 것과 비슷합니다. 차가 결국 어디에 도착할지는 여전히 운전자 책임이고, 낮잠이라도 자면 병원에서 깨어나거나 영안실에 가게 됩니다.
다만 '개입과 개입 사이의 시간'이 꾸준히 길어지고 있는 것은 사실입니다.
가장 큰 차이는 프로그래밍 쪽이 AI가 스스로 틀렸는지 알아내기 훨씬 쉽다는 점입니다. 예를 들어 지식 노동자에게는 자동화된 테스트가 없습니다.
그 결과 지식 노동자는 과정에 더 깊이 관여해야 하고 실수에도 더 신경 써야 합니다. 그래서 사용자 경험은 더 나쁘고, 생산성도 대체로 프로그래머보다 낮습니다.
맞습니다. 그리고 프로덕션에만 나가지 않으면 실수를 바로잡는 데 돈도 시간도 거의 들지 않습니다. 다른 분야에서는 그렇지 않죠.
그보다는 지식 노동자들이 AI를 덜 능숙하게 쓰는 거라고 봅니다. 출처가 실제로 있는지 확인하는 건 AI든 다른 도구든 써서 하면 그리 어렵지 않습니다. 기능 테스트 같은 것이 프로그래밍이 아닌 작업에도 곧 들어올 겁니다.
직접 발품을 팔지 않으면 오류를 꾸준히 잡아내기가 훨씬 어렵습니다. 엉뚱한 파일을 보내거나, 복사해서 붙여넣기를 잘못하거나, 검증 단계 하나를 건너뛰는 정도면 대부분의 사람은 크게 일을 그르치기에 충분합니다.
대부분의 전문가에게는 업무 흐름에 AI 출력물을 넣지 않는 편이 더 안전합니다. AI는 계속 쓰되, AI가 낸 결과물을 복사해서 붙여넣는 짓은 그만두세요.
어렵진 않지만, 그렇게까지 꼼꼼히 결과물을 검토해야 한다면 어느 순간부터는 그냥 직접 하는 편이 낫습니다.
리서치용으로 더 나은 파이프라인이 왜 없는지 궁금합니다. 예를 들어 Opus에게 조사를 시키고, 그다음에 Haiku든 JEV든 더 적합한 걸로 훅을 하나 설정해서 출처가 실제로 있는지만 확인하게 하는 겁니다. 계속 덧붙여 나갈 수도 있습니다. 물론 너무 커질 수 있고, 물론 여전히 실패하겠지만, 지금 상태보다는 훨씬 나을 겁니다. 가치는 엄청난데 아무도 손대지 않은, 손 닿는 곳에 달린 열매 같아 보입니다.
가장 큰 차이는 소프트웨어 업계에서는 엉성하고 고장 난 제품을 내놓고도 나중에 패치하는 것 말고는 별다른 대가가 없는 경우가 흔하다는 겁니다. 법원 제출 서류로 똑같이 해 보세요. 바로 쫓겨납니다.
AI가 나오기 전에도 마찬가지였습니다.
현실에서 변호사가 자격을 박탈당하는 경우는 의뢰인에게 거짓말을 하거나 의뢰인 돈을 훔쳤을 때 말고는 사실상 없습니다.
네, 맞습니다. 논할 만한 직업 기준이 없는 업계가 ML로 가장 신나게 판을 벌이고 있다는 건 놀랍지도 않습니다. 제가 하려는 말은, 다른 여러 전문 분야에서는 소프트웨어 "엔지니어"처럼 일하는 것을 과실 행위(malpractice)라고 부른다는 겁니다.
AI는 아직 초기 단계입니다.
이 모든 건 결국 정리될 것이고, 언젠가 바이오도 법률도 소프트웨어도 다 그냥 잘 돌아갈 겁니다.
세상에 대한 어떤 가정도 붙들고 있지 마세요. 앞으로 이상한 일이 벌어질 겁니다.
잠깐만요, "그냥 잘 돌아간다"는 말은 옳고 그름을 가르는 객관적인 기준이 있다는 뜻이잖아요. 그런 기준은 없어요. 뭔가를 안정적으로 해내는 법률 AI가 나오겠죠. 그게 뭔지는 모르겠지만요. 그런데 법체계의 핵심은 사람이 자기 사건을 주장할 여지를 마련해 주는 것이잖아요. AI가 사람의 개입 없이 결정론적으로 "법을 한다"면, 그 AI를 쓰는 것 자체가 AI가 그토록 능숙하게 다루도록 학습한 제도의 목적을 무너뜨리는데, 그게 어떻게 "잘 돌아간다"고 할 수 있겠어요?
현실의 제약도, 그게 어떻게 돌아갈지 설명할 필요도 없는 유토피아식 사고네요. 저는 그런 데 관심 없습니다.
지금은 실리콘밸리식 영성의 새 버전을 이야기하는 게 아니에요. 사람들이 실제로 신경 쓰는 시스템을 이야기하고 있다고요.
변호사와 기사 작성자가 지식 분야에 속한다면, 그 논지에는 AI로 뭔가를 만들어 놓고 바로잡지 않는 사람들이라는 반례가 수두룩합니다.
"공장"에서 "에이전트 무리"를 쓰는 소프트웨어 엔지니어는 제가 직접 아는 사람 중에는 없습니다. 악몽 같은데요.
저는 보통 상위 수준 에이전트가 계획을 짜게 하고, 그 계획의 각 부분을 만들 하위 에이전트들을 띄우고, 그 에이전트들의 작업을 검토할 또 다른 하위 에이전트들을 둡니다. 그다음 PR에는 서로 다른 코드 리뷰 에이전트들이 코드를 보고, 거기에 더해 팀원들용 에이전트들도 제 코드를 리뷰합니다.
그리고 저는 아마 AI 개발에서 아마추어에 가까운 쪽일 겁니다. 이런 기법을 유튜브에서 배웠거든요.
앤트로픽 연구원들이 하는 일을 들어 보면, 문제를 푸는 데 에이전트를 수백, 수천 개씩 쓰는 것 같습니다.
그 사람들이 앤트로픽 연구원인 데는 이유가 있습니다. 자기가 쓴 토큰 비용을 실제로 내야 하면 가치 제안이 무너집니다.
서브에이전트 방식은 전체 성능을 높일 수 있지만, 대체로 토큰 사용량이 불균형할 만큼 많이 늘어납니다. 같은 일을 동시에 하면서 캐시를 공유하지 못하는 병렬 서브에이전트는 더 심합니다.
제가 하려던 말은, 저는 개발자 중에서 하위 25퍼센타일쯤인데도 작업 하나에 에이전트를 여러 개 쓰고 있고, 앤트로픽 연구원들은 상위 99퍼센타일이라 작업 하나에 에이전트를 수천 개씩 쓴다는 겁니다.
그러니 중간 정도 개발자는 작업 하나에 한 번에 에이전트 5~20개를 쓸 겁니다. 그게 "에이전트 무리"라고 부를 기준을 넘는지는 잘 모르겠습니다.
그 수치의 출처가 궁금하네요. 말씀하신 방식은 하위 25퍼센타일보다 상위 99퍼센타일에 가까워 보입니다. 중간 정도 개발자가 한 번에 에이전트를 5~20개 쓴다는 건 믿기 어렵습니다.
네... 저는 표본이 2~3명이지만, 저희 팀은 메인 에이전트 하나에 리뷰, 분석, 보안용으로 잘 다듬은 에이전트 몇 개를 더 두는 쪽을 선호합니다. 저는 보통 서로 다른 작업을 맡긴 채팅 2~3개를 돌리는데, 그 이상이면 맥락을 놓쳐요.
이 대목을 읽은 바로는, 작성자는 자기가 특별히 숙련됐거나 빠르게 일하는 사람은 아니라고 하면서도 실제로 이렇게 에이전트를 쓰고 있다는 겁니다. 그다음에, AI 최전선 업계 한복판에 있는 아주 앞선 연구원들은 훨씬 더 많은 에이전트를 훨씬 큰 규모의 작업에 쓴다는 얘기고요.
"중간 정도 개발자"는 특별히 숙련됐거나 빠르게 일하는 사람을 가리키는 것이지, 모든 실무자가 N개씩 에이전트를 연속적으로 쓴다는 뜻이 아닙니다.
앞으로 6개월만 지나면(그보다 빠를 수도 있고) 비용이 한 자릿수 배는 떨어질 겁니다.
"에이전트 무리" 접근법을 꽤 잘 요약한 말이라고 생각합니다.
단일 에이전트로는 하드웨어 한계에 부딪히니까 그렇게 하는 겁니다. 에이전트 하나가 올바른 결정을 내리고 탐색 공간을 효율적으로 훑는다면, 수십만 개의 에이전트가 필요하지 않을 겁니다. 결함이 있을 수 있는 샘플을 잔뜩 만들어 놓고 그중 결함 없는 것만 고를 수 있다니, 막대한 부가 있어야 누리는 사치입니다.
네, 저도 원 댓글이 소프트웨어 개발자들이 일하는 방식을 그렇게 규정한 데는 강하게 이의가 있습니다. 그렇게 일하는 사람도 있다는 건 압니다. 하지만 업계 다수라고는 생각하지 않습니다. 근처에도 못 갑니다.
그런 사람들이 어딘가에는 있다고들 하죠. 그렇다고 주장하는 사람 하나한테서 들은 적이 있어요. 쓸 만한 제품도 없는데 6개월 넘게 한 달 AI 지출이 수만 달러였대요. 직원 1명짜리 스타트업이었고요.
5성급 레스토랑도, 패스트푸드도, 길거리 고기 요리도 있지만 부엌은 여전히 있습니다. 슈퍼마켓에서 달걀과 채소를 살 수 있어도 텃밭에서 직접 먹거리를 기르는 사람들을 알고 있고, 달걀을 얻으려 닭을 키우는 사람도 아주 드물게 있습니다.
저는 사실 AI를 거의 쓰지 않습니다. 제 일은 업계 특화된 틈새 지식이 필요해서, AI는 독자 규격 기계를 어떻게 고치는지 알려 줄 수 없거든요. 몇 번 써 보긴 했는데, 엑셀 스크립트나 제가 배울 마음도 필요도 없는 소프트웨어를 만드는 시시한 일에 썼습니다.