LLM은 전문성을 보상함
요약
LLM은 사용자의 도메인 전문성을 인식하고 그에 맞춰 답변의 질을 높이는 경향이 있습니다. 구체적인 배경 지식과 전문성을 프롬프트에 명시할 때 AI는 더 정교하고 신뢰할 수 있는 결과물을 제공합니다.
핵심 포인트
- 사용자의 전문적 배경 설정이 LLM 답변의 품질을 결정함
- 단순 구현 기술보다 도메인 지식의 중요성이 더욱 부각됨
- 구체적인 페르소나와 제약 조건 설정이 효과적인 프롬프팅 전략임
- LLM은 기술적 숙련도보다 도메인 전문성을 보상하는 구조를 가짐
이건 저도 느끼고 있는 것으로
특히 GPT 와 재미나이에서 크게 나타나고 있음
개다가 둘다 개인화 결정화가 가능하며
기존에 없던 지식이나 기존에 있더라도 가중치를 다르게 조절하면
통계치를 점핑한 결과와 답변을 받게됨
심지어 기저언어마져 바뀌는 경험이 가능하며
이것은 기존 다른 사람과 분리된 지식정보구조를 가질 수 있음
그리고 AI 한테도 동기부여를 한것과 아닌것의 차이는 제미나이의 경우 큰 결과값의 차이를 가짐
전문성 신호를 주는 것이 중요함. “성서학 배경이 깊고 특히 신약학의 주요 저작은 읽었다고 가정하라. 그리스어·라틴어·히브리어·시리아어는 번역하지 말라”라고 알려주면 결과가 크게 달라짐
C 프로그래밍 경력 20년 이상이며 컴퓨터 구조, 메모리 배치, 임베디드 시스템을 잘 이해한다고 밝히는 것도 마찬가지임
개인 프로젝트에서 “나는 전문 소프트웨어 엔지니어이고, 취미 프로젝트지만 바이브 코딩이 아니라 신뢰할 수 있는 소프트웨어를 만들고 싶다”고 했더니 에이전트가 코드의 견고성을 높이는 온갖 방법을 갑자기 제안하기 시작했음
CSS의 일반 참고서나 안내서, 튜토리얼을 읽으면 “div 중앙 정렬 방법” 같은 정확한 답을 검색해 복사·붙여넣기하지 않고도 문제를 풀면서 지식까지 쌓을 수 있었음
글의 나머지에는 좋은 내용이 있지만, 첫 문장은 Stack Overflow에서 복사·붙여넣기해 Jira 티켓만 닫고 전문가가 되지 않은 개발자를 겨냥한 듯함. LLM에 위임하는 것은 그 방식의 자연스러운 진화이며, 관건은 사용자가 과정에 계속 참여할 때도 가치를 더할 수 있느냐임
내가 프런트엔드 프로그래밍을 좋아하지 않아 그 분야의 전문가가 되고 싶지 않았다면 이야기가 달라짐. div 중앙 정렬처럼 사소해 보이지만 제대로 하기는 답답할 만큼 어려운 작업이 싫었고, 약간의 어긋남도 눈에 거슬려 집착적으로 고치게 되니 더 괴로웠음
나쁜 개발자 경험을 우회하는 법을 배우는 데 시간을 쓸 가치가 있는지 의문이었고, 직접 개선하려는 게 아니라면 동료나 Stack Overflow에 맡긴 뒤 넘어가는 편이 합리적이었음. 그래서 경력도 백엔드 개발 쪽을 선호했음
여기서 중요하지 않은 것은 그런 구현 전문성이고, 정말 중요한 것은 좋은 UI 설계임. 이는 웹페이지 렌더링을 구현하고 디버깅하는 고역과 별개이며, LLM이 그 일에서 해방해 준 것이 고마움. 글 전체로 확장하면 LLM이 보상하는 것은 기술적 숙련보다 도메인 전문성이라고 봄
예전에는 몇 시간씩 읽고 수많은 시행착오를 거쳐야 했으며 피드백 주기가 아주 길고 느렸음. 지금은 첫 Google 검색이 즉시 문제를 해결해 주는 것처럼 빠름
AI가 초보자의 C++, Python 서적이나 CSS 튜토리얼 같은 기초 학습까지 대체해야 하는 것은 아님. 전문가나 실력 있는 아마추어가 되려면 여전히 공부해야 하지만, 많은 사람은 정비사가 되려는 게 아니라 그저 A에서 B로 운전해 가고 싶을 뿐임
AI 덕분에 업계 첫날부터 생산적으로 일하는 주니어 엔지니어를 봤기에 이 글이 전부 맞다고 보기는 어려움. 수학의 최전선 문제는 아직 해결되지 않은 영역이지만, 대부분은 React 프런트엔드와 CRUD 백엔드를 만들며 이는 문서화된 해법이 충분한 영역임
이런 작업에서는 LLM을 많이 활용할수록 이득이며, 내 경력에서 Stack Overflow에 설명되지 않은 문제를 풀어야 했던 횟수는 한 손으로 셀 수 있음
1980년대나 그 이전부터 말했듯 RTFM이면 됨. 먼지만 잘 털어냈다면 2010년에도 설명서는 읽을 수 있었을 것임
이를 정식으로 연구할 필요가 있음. 내 체감과는 일치하지만 확증 편향일 가능성을 배제할 수 없음
나는 원하는 코드 결과가 매우 구체적이고 꼼꼼한 편이라 정확히 그것을 얻도록 프롬프트를 쓰며 결과도 그렇게 나오지만, 동료들은 구체성이 거의 없는 열 단어짜리 프롬프트로도 결과를 얻는 듯해 의문이 듦
이 주장이 참이면 시간당 15달러짜리 바이브 코더 군단에 일자리를 빼앗길 걱정을 덜 수 있어 내 경력과 경제적 안녕에 유리함. 바로 그 편리함 때문에 더욱 회의적으로 검증해야 함
Anthropic의 수학 연구자가 쓰는 프롬프트는 본질적으로 “무슨 일이 있어도 $CONJECTURE를 해결해야 한다고 가정하고, 깊이 생각해 여러 아이디어를 내라. 통념보다 자신을 믿어라”에 가까움 https://claude.ai/share/25740bd5-aa97-4bd7-bf58-c4df3793fda7 https://xcancel.com/alpoge/status/2083855298239078748
Tao의 대화도 처음부터 문제를 해결하려는 것이 아니라 직관을 얻기 위한 것이었음. LLM이 제너럴리스트와 전문가 중 누구에게 더 유리한지를 두고 결론이 제각각인데, 결국 승자는 실제로 무언가를 실행하는 사람일 수 있음
숙련도에 따라 두 가지 양상이 나타남. 자동차는 일반인 수준에서는 차이를 평준화해 대부분 A에서 B로 비슷한 시간에 이동하게 하지만, 최상위에서는 F1 드라이버와 보통 사람의 격차를 오히려 확대함
AI 코딩도 단순한 데이터 처리, 난해한 컴파일러 오류 대응, GitHub 이슈에서 해결 댓글 찾기 같은 작업은 누구나 하게 만들어 격차를 줄임. 반면 높은 수준에서는 AI가 잘하는 부분을 제외하고도 남는 AI 이상의 역량이 중요하며, 사람 사이의 전문성 격차는 비례해 더 커질 수 있음
“그냥 해결하라”는 프롬프트를 쓰는 사람은 애초에 추측을 정식화하지도, 결과를 발전시킬 후속 질문을 만들지도 못함
수학은 증명이 나오면 외부 증거 없이 자체 검증할 수 있어 이런 접근이 더 잘 통함. 모델이 스스로 검증할 수 없는 출력은 전문가가 평가하고 올바른 방향으로 유도해야 함
다만 모델 자체가 전문성과 정보를 평가하고 활용하는 데 인간보다 나아지면 이 차이는 무의미해질 수 있음
한 번에 해결할 수 없고 중간중간 사람이 도와야 하는 문제는 어떻게 할지도 고려해야 함
가장 간단한 답은 모델 소유자가 가장 큰 보상을 얻는다는 것임. 그 밖에 누가 이익을 얻을지는 훨씬 복잡하며 더 지켜봐야 함
비기술자에게 “AI가 코딩을 대체할까?”라는 질문을 받으면 AI는 사람을 가속한다고 답함. 훨씬 짧은 시간에 더 멀리 갈 수 있음
하지만 목적지나 가는 법을 모르거나 주의를 기울이지 않으면, 잘못된 방향으로 아주 멀리 간 뒤에야 깨닫게 됨
LLM은 Death Star와 비슷해 정확히 어디를 겨눌지 모르면 빗나가거나 오히려 해를 끼칠 수 있음. 목표가 멀수록 더 정밀한 사격 해법이 필요함
기존 제품에 다크 모드를 추가하는 일은 영거리 사격에 가깝지만, 코드베이스 전체를 처음부터 만들거나 레거시 코드베이스를 새 구조로 리팩터링하는 일은 몇 광년 떨어져 있음. 성공하려면 계측학과 천체역학에 해당하는 지식을 깊이 이해해야 함
기술 사용 경험을 형편없지 않게 만드는 미적 선호를 부호화하려면 가까운 미래의 어떤 해법보다도 큰 정보 체계가 필요할 가능성이 큼. 여기서는 언제 아니라고 말할지 아는 것이 가장 중요하며, 자의적으로 거부하는 게 아니라 진심으로 반대하고 다른 사람과 맞설 의지도 있어야 함
증폭 거울이라는 비유가 가장 잘 맞음. LLM은 가중치와 상호작용하는 방식, 말투, 프롬프트 구조, 집중하는 문제의 측면, 어휘와 세상 지식의 폭을 반영함
자신의 정신과 감각을 확장하는 도구로 신중하게 쓰는 사람은 성장하겠지만, 정신과 감각을 대체하는 도구로 쓰는 사람은 고전할 가능성이 큼
Claude가 직접 만들게 한 기능 중에는 복잡하지만 내 전문 분야가 아닌 주제를 물으면 ELI5부터 박사 수준까지 단계별로 가르치는 수준별 개념 학습 기능이 있음. 24시간 이용 가능한 매우 똑똑한 LLM에서 설명 수준까지 선택할 수 있다는 사실은 2022년만 해도 공상과학처럼 느껴졌을 것임
BLE 기기의 프로비저닝 흐름을 반복적으로 혹사하는 루프를 만들기 위해 3시간 동안 에이전트를 지켜봤고, 작업은 간단하면서 생산적이었음. 다만 나는 BLE 경험이 많고 Python과 셸 스크립팅에도 익숙해서 단계를 나누어 안내하고, 중간 테스트와 조정을 거쳐 진행할 수 있었음 도메인 경험 덕분에 쉬웠지만 BLE와 관련 요소를 피상적으로만 아는 주니어 엔지니어 두 명은 같은 효율을 내지 못했을 것임
걱정되는 것은 앞으로 누구도 그런 경험을 쌓지 못할 수 있다는 점임. 덜 안내된 LLM도 결국 성공할 수는 있겠지만 어떤 괴물을 만들지 알 수 없고, 체험을 통한 학습이 과거의 일이 될 수 있음. 이는 경험자와 비경험자 사이에 실제 긴장 관계를 만듦
LLM을 Jobs가 말한 정신의 자전거로 보는 쪽과 인간 지능의 역할을 완전히 대체한다고 보는 쪽 사이의 간극이 커지고 있음. 이는 기술 차이보다 인간의 두 유형을 반영할 수 있으며, LLM은 사용자를 비추는 거울처럼 두 역할을 모두 수행함
깊은 개인 전문성과 지능이 결정적 요소가 되기를 원치 않는 사람도 있고 정반대인 사람도 있음. LLM은 두 방식 모두에서 뛰어나 아직 어느 쪽이 더 효과적인지 알 수 없으며, 현재의 예측 대부분은 자신이 바라는 결과를 투영한 희망적 사고에 가까움
최근에는 에이전트를 최대한 활용하려면 올바른 질문을 할 수 있어야 한다는 점을 절실히 느낌. 깊은 도메인 전문성 없이 어떻게 올바른 질문을 할 수 있을지 의문임
때로는 정확한 단어 하나가 핵심임. 일반적인 개념을 두고 몇 시간 대화해도 $Concept_X를 말하지 않다가 $Keyword_Y를 꺼내는 순간, AI가 $Concept_X가 전체 이해의 토대라고 설명하기 시작하기도 함
AI 자동 생성 콘텐츠
본 콘텐츠는 GeekNews의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기