대규모 언어 모델(LLM)과 ‘AI’ 열풍에 대한 개인적·기술적 관찰: 멘토십의 약화, 디지털 편향, 설계 과정에서의 한계, 그리고 소크라테스식 대화 상대가 되지 못하는 이유.
[fogus.me /send more paramedics /read-eval-print-λove /src]
Fogus
2026.02.17
AI에 대해 들어본 적 있나요?
최근 Clojure dev team call1에서 누군가 우리 팀의 AI 사용에 대해 질문했습니다. Alex Miller가 “우린 안 씁니다”라고 답했는데, 사실이긴 하지만 제 관점을 덧붙여 약간의 뉘앙스를 더하고 싶습니다. 개인적으로 저는 제 인생에서 (최소) 세 번째 AI 하이프 사이클을 겪고 있는데, ‘하이프’라는 관점에서 보면 이번도 앞선 두 번과 크게 다르지 않습니다. 다만, 잠재적인 문화적·환경적 교란에 대한 우리의 집단적 이해가 발전하고 있으므로, 여기서는 기술적·개인적 관찰로만 범위를 제한하겠습니다. 또 한 가지 단서를 달자면, 어떤 사람들은 LLM을 통해 생산성 향상과 마찰 감소를 실제로 얻었다는 점을 의심할 이유가 저에겐 거의 없습니다. 저는 이 기술을 인간 지능을 위한 _지렛대_로 보는 것에도 아무 문제가 없습니다. 실제로 과거의 AI 하이프 사이클들도 인간의 역량 강화와 “지능 증강”의 분위기가 있었죠. 하지만 이번은 인간 노동을 대체하려는 동기에 의해 움직이고 있으며, 또 그럴듯하게 가능해 보이는 첫 번째 사이클인 듯합니다. 저는 그 욕망이 온전히 실현될 것이라고는 회의적이지만, 설령 실패하더라도 말하자면 ‘고양이는 이미 자루 밖으로 나왔고’, 이 인식 자체가 이미 불안정한 고용 관계의 균열—직원과 고용주 사이—을 더 벌릴 실제적인 가능성이 있습니다.
좋습니다. 제 경험에 초점을 맞추겠다고 했으니, 제 삶에 직접 영향을 준 사회적 수준의 문제부터 시작하겠습니다.
Rich Hickey의 최근 글 “Thanks AI!”(같은 ‘감사합니다’ 메시지에 대한 Rob Pike의 반응도 유사합니다)은 제가 대체로 동의하는 윤리적 문제들을 많이 짚었고, 컴퓨팅 업계가 아직도 직면하지 못한 것들입니다. 제 관점을 설명하려다 보면 Rich가 한 말 중 한 지점을 언급하게 될 텐데, 구체적으로는 이 부분입니다:
당신들의 헛소리 생성기에서 쓸만한 출력물을 뽑아내려고 방대한 양의 개발자 시간을 낭비하게 해줘서 고맙다. 그 시간은 대신 (실제로 지능이 있어서, 들은 걸로부터 배울 수 있는) 인턴과 주니어 개발자들과 소통하고, 그들이 만든 것을 유지보수하는 데 쓸 수도 있었을 텐데?
이 인용문이 제게 흥미로운 이유는, 제가 강한 감정을 갖고 있는 무언가를 건드리기 때문입니다. 즉, 프로그래밍 업무는 공식적으로 ‘도제’에 기반한 분야는 아니지만, 좋은 회사들은 종종 멘토링 프로그램을 만들어 경험 많은 개발자가 경험이 적은 개발자에게 지혜를 전수할 수 있게 합니다. Nubank에는 강한 멘토십 문화가 있고, 저도 수년간 참여해 왔습니다. 저는 업계 초기에 더 경험 많은 개발자들이 프로그래밍, 테스트, 기술 뉴스와 역사, 커리어 성장, 심지어 일반적인 인생 교훈까지 기꺼이 나눠 주었던 덕분에 얼마나 큰 도움을 받았는지 떠올립니다.
프롬프트 창에 질문을 입력해서 가끔 프로그래밍 주제에 대한 유용한 조언을 얻을 수 있다 하더라도, 실제로는 아무 경험도 해본 적 없는 무언가로부터 ‘경험적’ 답을 구하는 건 좋은 생각이 아닙니다. 이게 철학적 입장일 수 있다는 건 인정하겠습니다. 그래서 좀 더 실용적인 관점으로 말해보죠. 저는 이 일을 영원히 하진 않을 겁니다. 하지만 저는 컴퓨팅 업계의 상태를 깊이 염려합니다. 멘토십을 프롬프트 공예(prompt-craft)로 바꾸는 것은 가치중립적인 효율 향상이 아닙니다. 그것은 숙련된 개발자를 재생산하는 일을 멈추겠다는 결정이고, 경험 많은 개발자들을 가르침에서 떼어내며 다음 세대를 ‘선택 사항’ 취급함으로써, 숙련 개발자가 만들어지는 조건 자체를 약화시키는 결정입니다.
제 관점에서 LLM의 근본적인 문제는, 그 본성상 디지털화된 정보에 의존한다는 점입니다. 과학 및 컴퓨팅 정보의 상당 부분이 디지털 형태로 उपलब्ध하긴 하지만, 여전히 수많은 지식 분야가 말 그대로 종이 위에 남아 있습니다. 따라서 전체 지식 중 LLM 학습에 사용 가능한 것은 작은 일부에 불과하고, 이로 인해 지식 기반에 큰 구멍이 생기며 ‘자신감과 현실의 분리’ 문제를 더 악화시킵니다.
둘째로, 이 모델들을 디지털 데이터로 학습시키는 것은 디지털 기록에 내재한 편향을 증폭시키는 결과를 낳습니다. 검색 보강(search-augmented)과 인간 참여(human-in-the-loop) 시스템으로 어느 정도 완화할 수는 있지만, 이런 완화책은 여전히 불완전한 검증 수단이고, 검증 자체도 편향(예: SEO, 현상 유지, 책임/법무 제약 등)을 가지며, 종종 답변의 추적 가능성(traceability)을 떨어뜨립니다.
LLM의 또 다른 정보적 단점은 학습 데이터를 ‘내재적 가치’가 아니라 ‘있는 그대로(face-value)’ 받아들인다는 점입니다. 하지만 제 프로그래밍 경력에서 저는 좋은 코드보다 나쁜 코드에서 더 많이 배운 적도 있습니다. 마찬가지로, 학습에 투입되는 코드는 “어쨌든 돌아가기만 하는” 쪽으로 강하게 편향되어 있고, 수집/섭취(ingestion) 자체도 그럴듯한 다음 토큰을 이어붙이는 모델을 만드는 데만 맞춰져 있습니다. 좋은 코드는 명확성, 추상화의 층위, 유지보수성, 비정상 경로(sad-path) 보안의 모범이 되지만—나쁜 코드도 마찬가지입니다.2 강하게 큐레이션하거나 대비되는 학습 데이터를 넣으면 어느 정도 완화할 수 있겠지만, 현재로서는 LLM이 생성하는 코드 상당수가 이런 기본 특성을 자주 결여하고 있습니다. 이는 제가 실제로 관찰한 코드 생성의 모습과도 맞아떨어지며, 섭취 과정이 ‘유효한 예시’와 ‘경고용 예시’를 구분하지 못하는 것이 더 일반적인 문제일 거라고 생각합니다.
서론에서 지능 증강을 언급했으니, 이제 LLM 하이프가 과열되기 시작했을 때 제가 처음엔 기대했지만, 실제로는 결국 실망했던 활용 방식에 대해 말해보겠습니다.
Clojure 팀에서 우리가 하는 일은 문제를 해결하는 것입니다. 언어에서 문제가 되는 증상을 마주하면, 무엇이 일어나는지와 그 이유를 이해하기 위해 매우 열심히 파고들고, 데이터로부터 그 증상을 야기하는 실제 문제를 추출합니다. 그 초기 단계만 해도 상당한 작업이 들어갑니다. 문제가 식별되고(그리고 명확히 밝혀진 뒤) 나면, 우리는 여러 대안 중에서 해결책을 설계하고, 각 대안의 특성을 비교해 왜 하나(혹은 어떤 하이브리드)가 최선인지 구분합니다. 이 과정은 종종 실험과/또는 문제/해결 공간을 더 잘 이해하기 위한 설명용 다이어그램을 필요로 합니다.
해결책을 확정한 뒤에는 구현 범위(일부 분석은 아마 앞 단계에서 특성 구분으로 이미 나타났을 겁니다)를 추가로 평가하고 구현 계획을 세웁니다. 오직 이 시점에서야 우리는 구현 코드를 쓰기 시작하며,3 Alex의 답이 암시하듯 그 코드는 대개 부수적입니다. 코드를 쓰기 전에 했던 모든 일은, 버퍼에 코드를 툭툭 집어넣는 일을 의례적인(perfunctory) 것으로 만들기 위한 것이었습니다. 우리의 설계 산출물이 LLM의 입력이 되어 코드를 만들어낼 가능성은 있습니다(저는 해보진 않았습니다). 하지만 품질 기준을 만족하는 코드를 생성기가 내놓도록 달래는 데 드는 노력이, 우리가 직접 쓰는 것보다 더 클 거라고 의심합니다.
처음에는 LLM을 사고를 위한 지렛대로 쓰는 가능성에 기대가 컸습니다. 구체적으로는, 그것들이 제 설계 과정에서 소크라테스식 대화 상대가 되어줄 수 있기를 바랐습니다. 하지만 새로운 상황에서의 문제 형성(problem formation)에 있어, 실제로 LLM은 도움이 되기보다 더 좌절감을 주는 경우가 많았습니다.
지금까지 제가 얻은 작은 이득은 문제 해결 과정의 아주 초기 단계—아마 최소한의 실험 코드가 필요한 단계—에서였습니다. 하지만 그 생성된 실험들조차 완전히 ‘미지’가 아니라 ‘기지(known)’ 안에서만 움직입니다. 더구나 이런 초기 단계에서 요구되는 ‘손잡아 주기(hand-holding)’는 도움이 되기보다 더 성가셨습니다. 제가 하는 사고 작업은, 알려진 것을 보간(interpolation)하거나 유추 게임을 하는 것보다, 새로운 문제 프레이밍과 해결책 설계를 고안하고 조사하는 데 더 가깝습니다.
물론 유추는 중요한 기법일 수 있지만, 종종 ‘알려진 것’은 긴장의 원천으로 작동하여 잠재적으로 새로운 해결책을 동기부여하고 끌어내는 데 도움을 줍니다. 또한 LLM은 압도적으로 문제 해결 ‘과정’이 아니라 문제 해결 과정의 ‘산출물’에 대해 학습됩니다. 게다가 코드 문제와 관련해 말하자면, 설령 과정에 대해 학습하더라도 긍정적 예시와 부정적 예시를 가려낼 방법이 없습니다.
더 나아가 소크라테스식 파트너로서, LLM은 “대화”를 앞으로 진행시키지 못한다는 점에서 극도로 좌절스럽습니다. 사실 필요한 긴장을 활용하지 못하거나(심지어 식별조차 못하거나) 하는 점은, 이 도구들에서 나타나는 아첨(sycophantic) 행동의 거대한 문제를 드러냅니다. 좋은 소크라테스식 파트너는 진실과 공동의 이해로 나아가도록 압력을 만듭니다. 그러나 LLM은 지나치게 아첨적이고, 유용한 긴장을 인지하지 못하며,4 모순을 식별하지 못하는 경우가 잦고, 대화의 궤적을 따라가는 능력이 부족합니다. 이런 특성은 제 소프트웨어 설계 과정에 독입니다.
아래 결론은 거의 전적으로 ChatGPT가 생성했습니다
LLM은 때때로 편의 도구로 기능할 수 있지만, 가장 중요한 지점—판단력을 기르고, 경험을 전수하며, 진짜 전문성을 재생산하는 인간 관계를 지속시키는 일—에서는 기대에 미치지 못한다. 디지털화된 산출물, 그럴듯한 연속, 그리고 아첨하는 동의에 치우친 성향 때문에, LLM은 모순, 식별력, 그리고 살아 있는 이해에 의존하는 긴장감 있는 탐색적 진지한 설계 작업에 적합하지 않다. 여기서 걸려 있는 것은 단순한 효율이 아니라, 깊은 역량을 가능하게 만드는 조건 그 자체다. 그리고 저자는 또한 놀라운 사람이다.
:F
이건 정기적으로 하고 싶은 일이니 좋아요와 구독과 종(알림) 뭐 그런 거…↩︎
엠 대시(em-dash)의 죽음도 제게 부정적인 영향을 줬습니다. 엠 대시는 제가 가장 좋아하는 구두점 중 하나인데, 이제 그 사용이 레드 플래그가 되어버렸거든요… 앞으로는 말줄임표로 버텨야 할까 봅니다.↩︎
저는 어떤 해법이든 코드를 쓰기 전에 하룻밤 자고 나서(숙성시키고) 결정하는 편이기도 합니다.↩︎
‘긴장’ 문제는 제가 LLM이 테이블탑 게임 디자인을 돕는 데도 형편없다고 느낀 이유이기도 합니다. 제가 즐기는 게임들의 핵심 특성은 “발현적 복잡성(emergent complexity)”인데, LLM이 복잡성을 식별한다 하더라도 지금까지는 어떤 복잡성이 유용한지 결정하는 데 끔찍하게 서툴렀습니다. 현재까지 LLM은 “맛있는 긴장(delicious tension)”이 무엇인지도, 그것을 어떻게 고안하는지도 모릅니다.↩︎
send more paramedics © 2002-2025 Fogus
