# 도메인 전문성은 언제나 진짜 해자였다 > Clean Markdown view of GeekNews topic #30039. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=30039](https://news.hada.io/topic?id=30039) - GeekNews Markdown: [https://news.hada.io/topic/30039.md](https://news.hada.io/topic/30039.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-05-31T14:40:18+09:00 - Updated: 2026-05-31T14:40:18+09:00 - Original source: [brethorsting.com](https://www.brethorsting.com/blog/2026/05/domain-expertise-has-always-been-the-real-moat/) - Points: 1 - Comments: 1 ## Topic Body - 소프트웨어의 어려움은 코드 입력보다 급여·교통 같은 현실 규칙을 이해해 **도메인 모델**을 만드는 데 있었고, 코드는 그 이해의 산물이었음 - **에이전트형 AI**는 도메인 이해 없이도 소프트웨어 생산을 가능하게 하며 병목을 “만들 수 있는가”에서 “맞는지 판단할 수 있는가”로 옮김 - 물류 배차 담당자, 임상 코더, 보험계리사 같은 **도메인 전문가**는 코드를 몰라도 출력이 법·청구·운영 규칙에 맞는지 판별할 수 있음 - 범용 엔지니어는 아키텍처와 신뢰성을 검증할 수 있지만, 임상 코딩처럼 정답이 도메인 지식에 묶인 영역에서는 그럴듯한 오류를 놓칠 수 있음 - 가장 가치 있는 역량은 생성된 코드의 건전성과 출력의 참됨을 함께 검증하는 **판단**이며, 숙련 엔지니어에게 도메인 전문성 투자가 더 중요해짐 --- ### 소프트웨어의 병목은 구현에서 검증으로 이동함 - 소프트웨어 작성의 어려운 부분은 코드 입력 자체가 아니라, 먼저 **도메인 모델**을 머릿속에 만드는 일이었음 - 급여 시스템에는 압류, 세전 공제, 급여 기간이 임금 변경 시점을 걸칠 때의 처리가 들어감 - 교통 앱에는 GTFS 피드, trip과 route의 차이, “정시”인 버스가 여전히 틀릴 수 있는 이유가 반영됨 - 코드는 이런 이해를 옮긴 결과였고, 이해를 획득하는 일이 실제 업무였음 - **에이전트형 AI**는 도메인 이해와 소프트웨어 생산 사이의 연결을 약하게 만듦 - 이제 도메인 모델을 직접 만들지 않고도 소프트웨어를 생산할 수 있음 - 소프트웨어 직업 전체가 의존해 온 전제가 흔들림 - [작년의 관점](https://www.brethorsting.com/blog/2025/07/agentic-coding-tools-not-skynet%2C-not-a-stochastic-parrot/)처럼 이런 도구가 판단력 있는 시니어 개발자를 증폭한다는 설명은 맞지만 충분하지 않음 - 더 구체적인 변화는 병목이 “만들 수 있는가”에서 “**맞는지 판단할 수 있는가**”로 옮겨갔다는 데 있음 ### 에이전트형 도구를 잘 쓰는 사람 - ## 도메인 전문가는 코드를 몰라도 정답을 판별할 수 있음 - 물류 배차 담당자, 임상 코더, 보험계리사 같은 사람은 스택 트레이스를 읽지 못하고 hash map과 list의 차이를 설명하지 못할 수 있음 - 하지만 에이전트가 만든 스케줄을 보면 어떤 운전자가 법적으로 그 교대근무를 할 수 없는지 즉시 알 수 있음 - 특정 코드 조합의 보험 청구가 결제되지 않을 것도 알아볼 수 있음 - 이들은 입력과 출력 속에서 10년을 보냈기 때문에, 주어진 입력에 대한 올바른 출력을 알고 있음 - 에이전트가 제공하는 것은 이들에게 부족한 코드 생산 능력이고, 이들이 가져오는 것은 에이전트에게 없는 **정답 기준(ground truth)** 임 - ## 범용 엔지니어는 잘 만든 소프트웨어와 올바른 소프트웨어를 구분하지 못할 수 있음 - 강한 범용 엔지니어는 아키텍처, 신뢰성, 테스트, 새벽 2시에 시스템이 무너지지 않게 하는 방법을 알고 있음 - 하지만 임상 코딩 같은 도메인에서는 그럴듯하지만 틀린 답과 맞는 답을 구분하지 못할 수 있음 - 에이전트는 컴파일되고, 엔지니어가 생각해낸 테스트를 통과하지만, 미묘하고 비싼 청구 규칙 오류를 만들 수 있음 - 엔지니어는 소프트웨어가 잘 만들어졌는지는 검증할 수 있지만, 정답성이 전적으로 머릿속에 없는 도메인으로 정의될 때는 **정확성**을 검증하기 어려움 - ## 에이전트 이전에는 엔지니어에게 유리한 학습 경로가 있었음 - 엔지니어는 전문가를 따라다니고, 명세를 읽고, 운영 환경에서 실수하며 천천히 도메인을 배울 수 있었음 - 많은 분야에서 이런 과정이 커리어 사다리의 핵심이었음 - 도메인 전문가에게는 대칭되는 경로가 없었음 - 신뢰할 수 있는 소프트웨어를 만드는 법을 배우는 데는 수년이 걸리며, 이들이 실제로 밟기 어려운 길이었음 - ## 에이전트형 도구는 한쪽 경로만 무너뜨렸음 - 엔지니어의 장점이던 도메인 모델을 동작하는 코드로 번역하는 능력은 저렴해짐 - 도메인 전문가의 장점인 무엇이 맞는지 아는 능력은 저렴해지지 않았음 - 프롬프트만으로 이 능력을 얻을 수 없고, 수천 번의 급여 정산을 맞춰 본 사람의 암묵지를 담은 skill file도 없음 - ## 가장 가치 있는 사람은 두 층에서 모두 검증할 수 있는 사람임 - 생성된 코드가 건전한지 알고, 그 코드가 내놓는 답이 참인지도 아는 사람이 가장 중요해짐 - “운전자는 11시간을 초과할 수 없다”는 테스트를 쓸 수 있는 이유는 규칙을 알기 때문임 - 그 테스트 자체가 의미 있는지도 판단할 수 있는 이유는 무엇을 테스트하는지 알고 있기 때문임 - 에이전트는 옮겨 적는 일을 하고, 사람은 코드와 도메인 두 층에서 **판단**함 - 숙련 엔지니어에게 중요한 투자는 실제 도메인의 깊고 검증된 모델을 얻는 것임 - 명확한 아이디어를 깔끔한 코드로 바꾸는 기계적 능력의 가치는 크게 낮아졌음 - 여전히 희소한 것은 실제 산업, 도구, 규제 체계, 물리적 과정에 대한 깊은 이해임 - 프로그래밍 언어나 프레임워크를 배웠던 방식으로 하나의 도메인을 골라 배워야 함 - 에이전트가 대신할 수 없는 부분이자 지금 가장 가치가 커진 부분은 **도메인 전문성**임 ## Comments ### Comment 58658 - Author: neo - Created: 2026-05-31T14:40:20+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48340411) - 개인 수준에서 **AI를 어떻게 써야 하는지** 아무도 모른다는 걸 인정하기까지 얼마나 더 장광설이 필요한지 모르겠음 처음엔 좋은 개발자이면서 AI 사용법을 배우면 충분하다고 했고, 다음엔 아키텍처 설계 능력이라 했고, 그다음엔 **취향**이 전부를 가른다더니 이제는 도메인 전문가만이 중요하다고 함 AI의 개선 또는 정체가 안정적이고 예측 가능한 상태가 되기 전까지 이런 해석은 계속 무의미하고 대체로 틀릴 가능성이 큼 - 점점 굳어지는 생각은 **AI 도구가 소프트웨어 개발을 더 어렵게 만든다**는 것임 가능한 일의 기준을 크게 끌어올리기 때문에 더 어려워짐. 개인 개발자가 훨씬 더 어려운 프로젝트를 맡을 수 있게 됐고, 결국 제약은 늘 시간이었으며 AI는 주어진 시간 안에 더 많은 일을 하게 도와줌 하지만 그 시간 안에 해낼 수 있는 일 자체가 훨씬 어려워졌음. 훨씬 더 많은 것을 이해해야 하고, AI 이전의 익숙한 안전지대 밖으로 크게 나가야 함 예전에는 익숙하지 않은 시스템 영역이거나 새 라이브러리를 배워야 해서 코드베이스 리팩터링이나 작은 기능 출시 준비에 며칠을 쓰는 게 받아들여졌음 코딩 에이전트 덕분에 그 학습 곡선을 훨씬 빨리 오를 수는 있지만, 여전히 직접 올라야 함. 그리고 들어오는 정보량은 훨씬 많아짐 비기술적인 바이브 코더에게 일자리를 빼앗길까 걱정된다면, 올바른 대응은 그들보다 소프트웨어를 훨씬 잘 만드는 것임. 그러려면 더 많은 실력, 더 큰 야망, 더 많은 경험이 필요하고, 쉽지 않음 - LLM은 무기고에 추가할 **도구**일 뿐임. 전능하지 않고 다른 도구처럼 주의해서 다뤄야 함 지금까지 가장 적절하다고 느낀 비유는 현대식 전동 드릴 드라이버와 드라이버/핸드 드릴 같은 구식 장비의 비교임 구식 장비에 비해 아주 짧은 시간에 놀라운 결과를 낼 수 있음 예를 들어 “하루 종일 걸릴 바닥 고정을 1시간 안에 끝냈고 중간에 담배도 여러 번 피웠다” 같은 놀라운 일화가 가능함. 못총을 썼으면 절반 시간에 끝났겠지만, 나중에 그 바닥을 쉽게 들어 올리긴 힘들고 비용도 두 배쯤 들었을 수 있음 온프레미스 LLM도 여러 개 쓰고 다른 모델들에도 접근할 수 있어서, 언젠가는 이 비유를 브랜드 차이까지 확장하게 될 것 같음 하지만 새 직장을 찾게 될 거라고는 생각하지 않음. 전동 드릴 드라이버는 목수나 현장 인부가 아니고, 사람이 없으면 쓸모가 없음 - 20년 전 **객체지향 과대광고**를 기억함? GoF 책을 대충 훑고 왜 쓰는지도 모른 채 모두가 패턴을 남발했던 코드를 아직도 우리 코드베이스에서 치우고 있음 20년 뒤에는 Claude와 공동 작성한 쓰레기를 치우고 있을 거라고 봄 [https://mastodon.gamedev.place/@JeremiahFieldhaven/116654345...]() - AI 이전에도 **도메인 전문가**인 편이 뛰어난 소프트웨어 개발자보다 더 가치 있는 경우가 있었음 2018년에 코딩 경험이 전혀 없던 사람이 특정 틈새시장을 알고 있었다는 이유만으로, 한 달 코딩해서 꽤 괜찮은 돈을 버는 도구를 만드는 걸 봤음 코드 일부를 보여줬는데 내 첫 프로그램만큼 엉망이었지만, 실제 문제를 해결하고 있었음 - 이건 관중이나 일반인이 **프로 스포츠**를 평가하는 방식과 비슷하게 느껴짐 예를 들면 “스포츠를 잘하려면 완벽한 대칭성이 필요하고, 이는 태아기 발달 안정성과 강하게 상관된다. 대칭성이 높을수록 완벽한 발달이다”라고 말함 그러다 몇 년 뒤 Bruce Lee는 한쪽 다리가 다른 쪽보다 꽤 짧고, Usain Bolt도 비슷한 비대칭 발달을 갖고 있다는 소식이 나옴 그러면 그들은 예외 사례라며 일반 규칙에는 영향이 없다고 처음 주장을 뒤집어 감쌈 그냥 흥미로운 걸 만들면 되고, 잘될 수도 있음 - 최근에 **바이브 코딩**으로 거의 만든 앱을 검토했음. 소유자는 거의 출시 준비가 끝났고 빠른 점검만 필요하다고 했음 살펴보니 데이터베이스 설계가 엉망이었음. 어떤 기능은 동작했고 어떤 기능은 동작하지 않았음. 빠진 부분과 왜 깨지는지를 설명했음. 원문 글처럼 그 사람은 도메인 전문가였음 지난달에만 수십억 토큰을 썼고, 도구는 빠르게 좋아지고 있음. 하지만 도메인 전문가에게 AI를 준다고 해서 소프트웨어 엔지니어가 필요 없어지는 건 아님 도메인 전문가는 AI로 소프트웨어를 만들 수 있고, 소프트웨어 엔지니어는 AI로 도메인을 배울 수 있음. 둘은 서로 다른 전문성을 가져옴 - 내가 향하는 방향은 결국 **플랫폼 엔지니어**에 가까운 것 같음 도메인 전문가들이 코딩 에이전트를 쓰기 시작할 때 안전하게 보호할 가드레일, 검증, 프롬프트 라이브러리, 에이전트 및 수동 리뷰를 만드는 일이 됨 내부용 T2/T3 고객 지원이나 지원 엔지니어와 조금 비슷함. 일상적인 문제를 100% 직접 해결하기보다 위험한 지점, 이상한 경계 사례를 잡고 모든 설정이 올바른지 확인하는 역할임 물론 횡단 관심사도 많이 다루게 됨 - 내 경험도 비슷함. LLM은 다른 도메인을 탐색하기 쉽게 해주지만, 그 도메인의 달인으로 만들어주지는 않음. 여전히 **전문 도메인 지식**이 필요함 다만 새 아이디어를 빠르게 시도하고 파고드는 도구로는 훌륭함. 호기심이 있다면 뛰어난 학습 가속기가 될 수도 있음 - “지난달에만 수십억 토큰을 썼다”는 부분이 이해가 잘 안 됨 하루 종일 Claude Code(Opus 4.6, 최대 노력 설정)를 쓰는데도 이게 어떻게 가능한지 모르겠음. 그 사용량이 실제로 보상을 해주고 있는지도 궁금함 내가 잘 몰라서일 가능성이 크지만, 정말 어떻게 그렇게 되는지 모르겠음 - **도메인 전문성**에 일관된 QA 마인드가 결합되면 소프트웨어 엔지니어를 대체할 수도 있겠지만, 일관된 QA 마인드는 드묾 - 최근에 겪은 아주 좋은 예가 있음 낚시 여행 중이었고, 내가 작업하는 무료 앱([https://oceanconnect.ca]())이 일에 도움이 될 수 있을지 선장에게 한번 봐보겠냐고 물었음 나는 바다에서 사람들이 **해양 데이터**를 어떻게 쓰는지 잘 모름. 무엇을 알고 싶어 하는지, 왜 그런지도 잘 모름. 사람들이 데이터를 어떻게 쓰는지, 우리가 데이터로 무엇을 할 수 있는지에 대한 질문과 정보가 쏟아져 나와서 전혀 준비가 안 되어 있었고, 그 관점을 얻는 게 정말 멋지고 흥미로웠음 모델은 그것이 추상화하는 시스템과 같지 않고, 모델을 개발하는 지식은 그것을 사용하는 지식과 거의 관련이 없다는 걸 다시 떠올리게 해줬음 이 사람은 물 위에서 **기상 데이터**를 어떻게 쓰는지에 대해 엄청난 지식을 갖고 있었음. 어떤 의미에서는 나보다 데이터를 더 잘 알고 있었고, 본인이 깨닫지 못하거나 디지털 표현을 이해하지 못하더라도, 프로그래밍만 할 수 있다면 자신 같은 사람들을 위한 유용한 앱을 훨씬 잘 만들 수 있을 것 같았음 이런 사람들이 LLM을 앞에 두고 아이디어를 화면에 옮긴다면 정말 대단한 걸 만들 수 있겠다고 생각했음. 언젠가 자금이 생기면 매일 바다에 나가는 사람들을 인터뷰해서 제품을 다듬고 싶음. 그 도메인 지식은 매우 특수하고, 복잡한 도메인에서 수십 년을 살아온 사람들은 절대 예상 못 할 것들을 알고 있음 - 이 글에서 묘사한 **소프트웨어 제너럴리스트**도 도메인 전문성이 있음. 그 도메인은 소프트웨어임 지금 뛰어난 제너럴리스트 소프트웨어 엔지니어라면 AI를 피하려고 아무 무작위 도메인으로 뛰어들지 않음. 소프트웨어가 자신의 도메인이고, 그 도메인이 확장되고 변형되는 동안 계속 그 안에 머무르게 됨 - 맞음. 게다가 이제 AI라는 새 초능력이 생겼고, 거의 어떤 도메인이든 파고들고 빠르게 전문성을 끌어올릴 수 있음. 글의 방향이 오히려 거꾸로라고 봄 - 어쩌면 좋은 소식은 서부 최고의 **스프레드시트 장인 회계사**라도 검증을 하려면 결국 어느 정도 프로그래밍 경험이 필요하다는 점임 LLM에게 “이 코드는 무엇을 하고, Y일 때 항상 X가 되느냐”고 물을 수는 있겠지만, 그건 검증 문제를 또 다른 검증 문제 안에 중첩하는 것뿐임 - 핵심은 애초에 코드가 아니었음 지난 5년 동안 벤처캐피털과 사모펀드용 소프트웨어를 만들면서 이 글이 정말 와닿았음. 코드 작성은 내 일에서 단연 가장 쉬운 부분이고, 회사 고객들이 실제로 필요로 하는 것을 이해하기 위한 **금융공학과 미묘한 맥락**이 어려운 부분임 우리는 가능하다면 시니어 펀드 회계사를 고용해서 프로그래밍을 가르치고 싶다고 농담하곤 함. 문제는 그런 사람이 거의 없다는 것임. 엔지니어에게 펀드 회계의 세부를 소프트웨어로 만들 수 있을 만큼 이해시키는 일도 어렵음 - 도메인 전문성만 있고 기술이 없으면 어느 지점부터는 기껏해야 엄청난 **기술 부채**로 이어짐 실제로 내 경력의 절반쯤은 “티켓이나 에픽을 닫을 만큼의 도메인 지식은 있지만 결국 기술 부채를 많이 남긴” 것들을 처리하는 일이었음 예를 들어 도메인 지식이 있어도 사람은 실수하고, 더 나은 방법을 모르고, 피드백을 반영하지 않거나, 더 나쁘게는 코딩 에이전트가 쓴 내용을 다시 확인하지 않기 때문에 PR을 매우 꼼꼼히 검토해야 했음 “기술적으로는 맞지만 너무 형편없이 작성돼 타임아웃이 나거나 매니저/DBA가 소리치는 것”을 리팩터링하는 일도 많았음 진짜 좋은 소프트웨어 엔지니어는 도메인을 배울 능력과 의지가 있지만, 배울 수 있는 방법이 있어야 함. 회사나 팀, 동료가 그걸 가능하게 해준 곳도 있었고, 입으로만 중요하다고 하면서 결국 JIRA와 회의 중 비IT 부서 사람들이 흘리는 말에서만 유추해야 하는 곳도 있었음 지난 5년 사이의 큰 패러다임 변화는 대부분의 회사가 사람을 한계까지 일하게 기대하면서, 오히려 중요한 대화를 나눌 여유를 막아 역효과를 낸다는 점이라고 봄 문화가 큰 변수임. 적어도 옆에서 짧게 대화하거나 회의를 쉽게 잡을 수 있는 곳도 있었고, 제대로 논의할 시간을 요청하려면 change.org 청원이라도 해야 할 것 같은 곳도 있었음 그래도 핵심은 맞음. 결국 **요구사항이 코드보다 중요**함. 모든 요구사항이 충족됐고 팀이 설계 결정을 승인했는데도, 구현 내내 자리를 비웠던 사람이 돌아와 작성 방식이 마음에 들지 않는다는 이유로 기능이 지연된 곳도 있었음 그러다 보면 어느새 “배치 프로세스”가 %numberOfRecord%*10개의 삽입을 수행하고, 잘못 설계된 데이터 모델 때문에 추가 조회까지 하며, 가장 잘못된 방식으로 SQL 업서트를 하고 있다는 걸 알게 됨. 즉 DB에서 먼저 가져온 뒤 없으면 삽입할 레코드를 추가하는 식임. 그러면서 데이터 계층의 쿼리 패턴을 다시 생각하기보다 “성능 개선”이라는 이름으로 점점 더 수상한 일을 계속함. 경력 중 한 번 이상 봤음 - AI 대응 조언처럼 보이는 아주 일반적인 글을 읽을 때마다, **소프트웨어 산업은 건설 산업과 비슷하다**고 떠올림 절대 정돈되지 않고, 완전히 최적화되지도 않으며, 항상 맞춤형일 수밖에 없음. 취향, 맥락, 지역성이 극단적으로 다른 현실에 맞춰야 하기 때문임 가끔 좋은 도구나 원자재가 등장할 수는 있음 - 소프트웨어의 진짜 해자는 시스템과 도메인 양쪽에 대해 광범위한 지식이나 경험을 사실상 요구하지 않는 데 있다고 봤음 **취향과 네트워크 효과**를 복제하는 건 훨씬 어려움. 실제로 바이브 코딩 이전에도 인재와 자원이 풍부한 벤처 투자 스타트업들이 시장에서 자리를 잡는 경우는 드물었음 그래서 20대도 여러 분야의 전문가들과 경쟁할 수 있었음. 지금의 반발은 다른 성숙 산업에서 흔히 보는 “업계 경력 X년” 사람들의 탄생 때문이라고 봄 - 분석가로 일하고 있고, 우리 그룹은 강한 기술 역량, 즉 **소프트웨어 엔지니어링 능력**을 가진 분석가가 약 20%이며 나머지는 전통적인 분석가나 도메인 전문가임 지난 1년 동안 비기술 분석가들이 개발 부분에 AI 모델을 활용하면서 내부 도구 개발 생산성이 높아지는 걸 봤음 이전에는 거의 모든 것이 Tableau로 개발됐음. 개발자가 아닌 사람이 동작하는 도구를 만들 수 있는 가장 접근성 높은 방법이었음 며칠 전에도 우리 그룹의 한 분석가가 작업하던 도구를 발표했는데, 기본적으로 Tableau 보고서를 더 유연한 앱으로 포팅한 것이었음 - 우리 그룹은 Tableau를 직접 만든 도구로 천천히 대체하고 있고, **성능 향상**이 엄청남 이런 BI 회사들은 큰 곤경에 빠질 것 같음. 특히 히스토그램처럼 단순한 것도 그리기 거의 불가능하게 만드는 Tableau 같은 회사는 더 그렇다고 봄 - 내 친구는 전기공학자이고 최근 **FIDE 체스 레이팅 2000**을 넘겼음. 30년 동안 체스를 뒀고, 고등학교 때 체스 클럽도 만들었음. 대학에서 마이크로컨트롤러를 다루며 조금 프로그래밍을 배운 정도임 나는 컴퓨터과학 학위가 있는 인프라/관리 잡역부에 가깝고, 30년 동안 취미로 프로그래밍을 해왔음. Lichess 레이팅은 좋은 날에도 1000임 우리는 체스 봇 대회를 해봤음. 오픈북이고, AI로 프로그래밍해도 되고, 오프닝북이나 엔드게임 테이블 등 무엇이든 가져다 써도 되는 자유 대결이었음. 나는 그를 완전히 압도했지만, 실제 보드 체스에서는 20년 동안 두 번밖에 이긴 적이 없음 그는 현실에서 무작위 플레이어 99%를 이길 것이고, 나는 아마 20% 정도만 이길 것임 내가 정확히 무슨 말을 하려는지는 모르겠지만, 이제는 도메인 지식이 전부가 아닐 수도 있다는 느낌이 듦. 아니면 도메인 자체가 바뀐 것일 수도 있음 - AI의 관점에서는 어떤 도메인은 **얕고**, 예를 들면 체스가 그렇고, 어떤 도메인은 깊다고 해석하는 게 온건한 이해일 것 같음 - 실제로 체스를 두는 능력이 몇 가지 단순한 원칙을 넘어서 **효율적인 게임 트리 탐색 알고리즘**을 작성하는 것과 무슨 관련이 있는지 모르겠음 그에게 프로그래밍 대결을 건 것이고, 훨씬 경험 많은 프로그래머인 네가 이긴 것임. AI를 사용할 수 있었더라도 여기서는 너의 도메인 지식이 결정적이었다고 봄