도메인 전문성은 언제나 진짜 해자였다

• 소프트웨어의 어려움은 코드 입력보다 급여·교통 같은 현실 규칙을 이해해 도메인 모델을 만드는 데 있었고, 코드는 그 이해의 산물이었음
• 에이전트형 AI는 도메인 이해 없이도 소프트웨어 생산을 가능하게 하며 병목을 “만들 수 있는가”에서 “맞는지 판단할 수 있는가”로 옮김
• 물류 배차 담당자, 임상 코더, 보험계리사 같은 도메인 전문가는 코드를 몰라도 출력이 법·청구·운영 규칙에 맞는지 판별할 수 있음
• 범용 엔지니어는 아키텍처와 신뢰성을 검증할 수 있지만, 임상 코딩처럼 정답이 도메인 지식에 묶인 영역에서는 그럴듯한 오류를 놓칠 수 있음
• 가장 가치 있는 역량은 생성된 코드의 건전성과 출력의 참됨을 함께 검증하는 판단이며, 숙련 엔지니어에게 도메인 전문성 투자가 더 중요해짐

---

코드 작성이 아닌 도메인 이해가 본질

• 소프트웨어 개발에서 어려운 부분은 코드를 쓰는 것이 아니라, 먼저 도메인의 작동 모델을 머릿속에 세우는 일이었음
• 코드는 그 이해를 옮겨 적은 전사(transcription) 였으며, 이해를 획득하는 과정 자체가 진짜 업무였음

• 구체적 사례

  • 급여 시스템 출시 전에 압류 공제(garnishment), 세전 공제, 급여 기간이 임금률 변경 시점에 걸칠 때 발생하는 처리를 이해해야 했음
  • 대중교통 앱 출시 전에 GTFS 피드가 무엇인지, trip과 route가 왜 다른지, "정시" 버스가 어떻게 여전히 틀릴 수 있는지를 배워야 했음

Agentic AI가 끊어낸 연결고리

• Agentic AI는 모델 구축과 소프트웨어 생산 사이의 연결을 끊어, 모델 없이도 소프트웨어를 만들 수 있게 함
• 이는 직업 전체가 조직되어 있던 전제를 무너뜨림
• 작년의 관점은 이 도구가 판단력을 가진 시니어 개발자를 증폭시킨다는 것이었으나, 이는 참이지만 불완전함
• 실제로 관찰된 변화는 핵심 제약이 "만들 수 있는가"에서 "맞는지 판별할 수 있는가" 로 이동했다는 점

두 유형의 인물 비교

• 도메인 전문가 (소프트웨어 배경 없음)

  • 물류 배차 담당자, 임상 코더, 보험계리사 등으로, 스택 트레이스를 읽지 못하고 해시맵과 리스트의 차이도 설명하지 못함
  • 그러나 에이전트가 생성한 스케줄을 보고 어떤 기사도 그 근무를 합법적으로 할 수 없음을, 또는 해당 코드의 청구가 결코 지급되지 않음을 즉시 알아챔
  • 10년간 입력과 출력 속에서 살아왔기에 주어진 입력에 대한 올바른 출력을 알며, 부족했던 코드 생산 능력을 에이전트가 정확히 보완해 줌
  • 이들이 가져오는 것은 에이전트가 줄 수 없는 정답(ground truth)

• 도메인 경험 없는 강력한 제너럴리스트 엔지니어

  • 무엇이든 설계할 수 있고, 신뢰성·테스트·새벽 2시에도 시스템이 무너지지 않게 하는 법을 앎
  • 그러나 임상 코딩에 투입되면 그럴듯해 보이는 오답과 정답을 구분하지 못함
  • 에이전트는 컴파일되고 작성한 테스트를 통과하지만 미묘하고 비용이 큰 잘못된 청구 규칙(billing rule) 을 생성함
  • 엔지니어에게는 오라클(oracle) 이 없어, 소프트웨어가 잘 만들어졌는지는 검증해도 정확한지는 검증하지 못함 — 정확성이 그가 머릿속에 갖지 못한 도메인으로 정의되기 때문

한쪽 경로만 붕괴된 비대칭

• 에이전트 이전에는 엔지니어에게 배차 담당자에게 없던 경로가 있었음 — 전문가를 따라다니고 명세를 읽으며 운영 환경에서 실수를 겪으면서 도메인 모델을 천천히 습득할 수 있었음
• 이 경로는 많은 분야에서 경력 사다리(career ladder) 자체였으나, 도메인 전문가에게는 신뢰성 있는 소프트웨어를 배우는 수년의 작업이라는 동등한 경로가 없었음
• Agentic 도구는 이 두 경로 중 한쪽만 붕괴시킴
  • 도메인 모델을 코드로 옮기는 엔지니어의 강점은 이제 저렴(cheap) 해짐
  • 무엇이 맞는지 아는 도메인 전문가의 강점은 그렇지 않으며, 프롬프트로 도달할 수 없음
  • 수천 건의 급여를 정산해 본 사람의 암묵지(tacit knowledge) 를 담은 스킬 파일은 존재하지 않음

두 계층을 모두 검증하는 인재

• 새로운 세계에서 가장 가치 있는 사람은 두 기술을 모두 가져 양쪽 계층에서 검증할 수 있는 사람
• 생성된 코드가 견고함을 알고, 동시에 그 코드가 내놓는 답이 참임을 앎
• 규칙을 알기에 "기사는 11시간을 초과할 수 없다"를 인코딩한 테스트를 작성할 수 있고, 무엇을 테스트하는지 알기에 그 테스트가 의미 있음을 판별할 수 있음
• 에이전트는 전사를 담당하고, 사람은 두 번의 판단(judging, twice) 을 담당함

경험 많은 엔지니어를 위한 베팅

• 향후 몇 년을 어디에 투자할지 고민하는 숙련 엔지니어에게 이것이 베팅의 방향
• 명확한 아이디어를 깨끗한 코드로 바꾸는 기계적 기술(mechanical skill) 은 그 가치가 극적으로 하락함
• 여전히 희소한 것은 어떤 실제 도메인에 대한 깊고 검증된 모델이며, 이를 확보해야 함
  • 산업, 금융 상품, 규제 체계, 물리적 프로세스 중 하나를 골라, 과거 프로그래밍 언어나 프레임워크를 익히듯 그 도메인을 학습할 것
  • 이는 에이전트가 대신해 줄 수 없는 부분이자, 이제 가장 큰 가치를 지닌 부분

[xguru]

명확한 아이디어를 깨끗한 코드로 바꾸는 기계적 기술(mechanical skill) 은 그 가치가 극적으로 하락함

근데 이거 너무 코드에 대한 경시라고도 생각이 듭니다.
소프트웨어 개발 자체도 하나의 도메인이고 그걸 잘하는 것도 전문 기술인거죠
AI가 만드는 소프트웨어가 기능적으로는 해결해주지만, 완성시켜주지는 못하고 그걸 채우는 사람이 필요한 것처럼

[heycalmdown]

해커뉴스 의견들에 나온

이 글에서 묘사한 소프트웨어 제너럴리스트도 도메인 전문성이 있음. 그 도메인은 소프트웨어임

이 의견과 동일하네요.

[roxie]

저는 xguru 님 생각에 대해 약간의 반대 생각이 있습니다.

엑셀을 예로 들어볼게요. 일반적으로 회사 업무를 할 때 필요한 수준이 있고 그 이상을 넘으면 대부분 굳이 더 배우려 하지 않습니다. 엑셀을 미친듯이 잘 다루는 사람들도 있지만, 그건 정말 예외적인 경우죠.

코드의 경우에도 — 지금은 그렇지 않습니다만 — 어쩌면 그런 두 갈래로 쪼개질 수 있겠다 싶었습니다. 정말 복잡한 제품을 만드는 소수와, 자전거 타듯이 사용하는 대다수로요.

[xguru]

음? 엑셀을 잘 다루는 사람을 경시하진 않죠.
근데 코딩 하는 거 자체의 가치가 하락했다는 이야기는 경시하는 느낌 이란건데요.

자전거 타듯이 사용한다고 복잡한 제품 만드는 사람에게 당신 가치는 별로에요 라고는 말하지 않아야 한다고 생각합니다.

[roxie]

말씀주신 부분에 동의하고,

복잡한 소프트웨어라고 불릴만한 기술, 코드가 줄어들 것이라는 얘기였습니다. AI로 가볍게 짤 수 있는 것들이 늘어난다면요.

긱뉴스 요약본의 표현을 빌리자면: 에이전트가 대신해 줄 수 없는 코드는 나날이 줄어들 것 같습니다.

[devpain]

그 부분이 암묵지가 거의 사라진 상태고, 최상급 도메인 전문가가 에이전트를 설계해서 모델에 내장되다보니,,, 지금은 도메인지식의 중요성이 강조되지만 1년뒤에도 같은 주장을 할지 모르겠네요. 암묵지를 결국 프롬프트로 조금씩 넘어가는 상황이고 모델들은 사용자가 프롬프트에 추가된 암묵지를 선별하고, 다시 모델에 주입할테니까요. 암묵지 내장된 에이전트 모델은 가치가 있겠지만, 이것조차도 마켓에서 거래될거라고 봅니다. 그 분야에서 훨씬더 도메인 지식이 풍부한 에이전트.
1년뒤에는 오케스트레이션을 넘어 에이전트 경영(회사처럼)이 평가 기준이 되지 않을까 예상해봅니다.

[GN⁺]

Hacker News 의견들

• 개인 수준에서 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를 사용할 수 있었더라도 여기서는 너의 도메인 지식이 결정적이었다고 봄