▲

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

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

소프트웨어의 병목은 구현에서 검증으로 이동함

  • 소프트웨어 작성의 어려운 부분은 코드 입력 자체가 아니라, 먼저 도메인 모델을 머릿속에 만드는 일이었음
    • 급여 시스템에는 압류, 세전 공제, 급여 기간이 임금 변경 시점을 걸칠 때의 처리가 들어감
    • 교통 앱에는 GTFS 피드, trip과 route의 차이, “정시”인 버스가 여전히 틀릴 수 있는 이유가 반영됨
    • 코드는 이런 이해를 옮긴 결과였고, 이해를 획득하는 일이 실제 업무였음
  • 에이전트형 AI는 도메인 이해와 소프트웨어 생산 사이의 연결을 약하게 만듦
    • 이제 도메인 모델을 직접 만들지 않고도 소프트웨어를 생산할 수 있음
    • 소프트웨어 직업 전체가 의존해 온 전제가 흔들림
  • 작년의 관점처럼 이런 도구가 판단력 있는 시니어 개발자를 증폭한다는 설명은 맞지만 충분하지 않음
    • 더 구체적인 변화는 병목이 “만들 수 있는가”에서 “맞는지 판단할 수 있는가”로 옮겨갔다는 데 있음

에이전트형 도구를 잘 쓰는 사람

  • 도메인 전문가는 코드를 몰라도 정답을 판별할 수 있음

    • 물류 배차 담당자, 임상 코더, 보험계리사 같은 사람은 스택 트레이스를 읽지 못하고 hash map과 list의 차이를 설명하지 못할 수 있음
    • 하지만 에이전트가 만든 스케줄을 보면 어떤 운전자가 법적으로 그 교대근무를 할 수 없는지 즉시 알 수 있음
    • 특정 코드 조합의 보험 청구가 결제되지 않을 것도 알아볼 수 있음
    • 이들은 입력과 출력 속에서 10년을 보냈기 때문에, 주어진 입력에 대한 올바른 출력을 알고 있음
    • 에이전트가 제공하는 것은 이들에게 부족한 코드 생산 능력이고, 이들이 가져오는 것은 에이전트에게 없는 정답 기준(ground truth) 임

  • 범용 엔지니어는 잘 만든 소프트웨어와 올바른 소프트웨어를 구분하지 못할 수 있음

    • 강한 범용 엔지니어는 아키텍처, 신뢰성, 테스트, 새벽 2시에 시스템이 무너지지 않게 하는 방법을 알고 있음
    • 하지만 임상 코딩 같은 도메인에서는 그럴듯하지만 틀린 답과 맞는 답을 구분하지 못할 수 있음
    • 에이전트는 컴파일되고, 엔지니어가 생각해낸 테스트를 통과하지만, 미묘하고 비싼 청구 규칙 오류를 만들 수 있음
    • 엔지니어는 소프트웨어가 잘 만들어졌는지는 검증할 수 있지만, 정답성이 전적으로 머릿속에 없는 도메인으로 정의될 때는 정확성을 검증하기 어려움

  • 에이전트 이전에는 엔지니어에게 유리한 학습 경로가 있었음

    • 엔지니어는 전문가를 따라다니고, 명세를 읽고, 운영 환경에서 실수하며 천천히 도메인을 배울 수 있었음
    • 많은 분야에서 이런 과정이 커리어 사다리의 핵심이었음
    • 도메인 전문가에게는 대칭되는 경로가 없었음
    • 신뢰할 수 있는 소프트웨어를 만드는 법을 배우는 데는 수년이 걸리며, 이들이 실제로 밟기 어려운 길이었음

  • 에이전트형 도구는 한쪽 경로만 무너뜨렸음

    • 엔지니어의 장점이던 도메인 모델을 동작하는 코드로 번역하는 능력은 저렴해짐
    • 도메인 전문가의 장점인 무엇이 맞는지 아는 능력은 저렴해지지 않았음
    • 프롬프트만으로 이 능력을 얻을 수 없고, 수천 번의 급여 정산을 맞춰 본 사람의 암묵지를 담은 skill file도 없음

  • 가장 가치 있는 사람은 두 층에서 모두 검증할 수 있는 사람임

    • 생성된 코드가 건전한지 알고, 그 코드가 내놓는 답이 참인지도 아는 사람이 가장 중요해짐
    • “운전자는 11시간을 초과할 수 없다”는 테스트를 쓸 수 있는 이유는 규칙을 알기 때문임
    • 그 테스트 자체가 의미 있는지도 판단할 수 있는 이유는 무엇을 테스트하는지 알고 있기 때문임
    • 에이전트는 옮겨 적는 일을 하고, 사람은 코드와 도메인 두 층에서 판단함
    • 숙련 엔지니어에게 중요한 투자는 실제 도메인의 깊고 검증된 모델을 얻는 것임
    • 명확한 아이디어를 깔끔한 코드로 바꾸는 기계적 능력의 가치는 크게 낮아졌음
    • 여전히 희소한 것은 실제 산업, 도구, 규제 체계, 물리적 과정에 대한 깊은 이해임
    • 프로그래밍 언어나 프레임워크를 배웠던 방식으로 하나의 도메인을 골라 배워야 함
    • 에이전트가 대신할 수 없는 부분이자 지금 가장 가치가 커진 부분은 도메인 전문성임

함께 보면 좋은 글 β

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