도메인 전문 지식은 언제나 진정한 해자(Moat)였다

소프트웨어를 작성하는 데 있어 어려운 점은 결코 작성 그 자체가 아니었습니다. 그것은 먼저 머릿속에 도메인(Domain)의 작동 모델을 구축하는 것이었습니다. 급여 시스템(Payroll system)을 출시하기 전에는 압류(Garnishments)와 세전 공제(Pre-tax deductions)가 무엇인지, 그리고 누군가의 급여 기간이 세율 변경 시점과 겹칠 때 어떤 일이 발생하는지를 이해해야 했습니다. 교통 앱(Transit app)을 출시하기 전에는 GTFS 피드(GTFS feed)가 무엇인지, 왜 여정(Trip)과 경로(Route)가 서로 다른 것인지, 그리고 "정시"에 도착하는 버스가 어떻게 여전히 잘못될 수 있는지를 배워야 했습니다. 코드는 그러한 이해를 옮겨 적은 것에 불과했습니다. 이해를 습득하는 것이 바로 업무였습니다.

에이전트형 AI(Agentic AI)는 이 둘 사이의 연결 고리를 끊어버렸습니다. 이제 모델을 구축하지 않고도 소프트웨어를 제작할 수 있으며, 이는 전체 직업군이 조직되었던 근간이 되는 가정을 깨뜨립니다.

작년의 제 의견을 포함하여 일반적인 견해는, 이러한 도구들이 시니어 개발자(Senior developers)를 증폭시킨다는 것입니다. 시니어 개발자들은 판단력(Judgment)을 가지고 있기 때문입니다. 맞는 말이지만 불완전합니다. 그 이후 제가 목격한 현상은 더 구체적이고 더 흥미롭습니다. 제약 조건(Binding constraint)이 *'당신이 그것을 만들 수 있는가'*에서 *'그것이 맞는지 판단할 수 있는가'*로 이동했습니다.

이러한 도구 중 하나를 실제로 잘 사용할 수 있는 사람이 누구인지 생각해 보십시오. 두 사람을 상상해 보십시오.

첫 번째 사람은 실제 소프트웨어 배경 지식이 없는 도메인 전문가(Domain expert)입니다. 물류 배차원(Logistics dispatcher), 임상 코더(Clinical coder), 보험계리사(Actuary) 같은 사람들입니다. 그들은 스택 트레이스(Stack trace)를 읽을 수 없고, 해시 맵(Hash map)과 리스트(List)의 차이점도 말하지 못할 것입니다. 하지만 그들은 에이전트가 생성한 일정을 보고 어떤 운전사도 법적으로 해당 교대 근무를 할 수 없다는 점이나, 해당 코드가 포함된 청구가 절대 지급되지 않을 것이라는 점을 즉각적으로 알 수 있습니다. 그들은 주어진 입력값(Inputs)과 출력값(Outputs)의 집합에 대해 올바른 출력값을 알고 있습니다. 왜냐하면 그들은 10년 동안 그 입력과 출력 속에서 살아왔기 때문입니다. 그들에게 에이전트를 쥐여주면 놀라울 정도로 효과적입니다. 왜냐하면 그들에게 부족한 것, 즉 코드를 생성하는 능력이 바로 에이전트가 제공하는 것이기 때문입니다. 그들이 가져오는 것은 에이전트가 할 수 없는 것, 즉 실측값(Ground truth)입니다.

두 번째는 해당 도메인에서 일해본 적이 없는 강력한 제너럴리스트 엔지니어(Generalist engineer)입니다. 그들은 무엇이든 설계(Architect)할 수 있고, 신뢰성(Reliability)과 테스트(Testing), 그리고 새벽 2시에 시스템이 무너지는 것을 방지하는 방법을 알고 있습니다. 하지만 그들을 임상 코딩(Clinical coding) 분야에 투입한다면, 그들은 그럴듯해 보이는 틀린 답과 정답을 구분해내지 못할 것입니다. 에이전트(Agent)는 컴파일이 되고, 엔지니어가 작성할 생각을 했던 테스트를 통과하며, 미묘하고도 값비싼 오류를 포함한 청구 규칙(Billing rule)을 기쁘게 생성해낼 것입니다. 엔지니어에게는 오라클(Oracle, 정답지)이 없습니다. 그들은 소프트웨어가 잘 만들어졌는지는 검증할 수 있습니다. 하지만 그것이 '정확한지'는 검증할 수 없습니다. 왜냐하면 여기서의 정확성(Correctness)은 그들이 머릿속에 담고 있지 않은 도메인에 의해 전적으로 정의되기 때문입니다.

이것이 어떤 방향으로 영향을 미치는지 주목하십시오. 에이전트 등장 이전에는 엔지니어에게 디스패처(Dispatcher)에게는 없는 경로가 있었습니다. 바로 도메인을 학습할 수 있는 경로였습니다. 전문가를 따라다니고, 사양서(Specs)를 읽고, 운영 환경(Production)에서 실수를 저지르며 느리고 고통스럽게, 그들은 정신적 모델(Mental model)을 구축할 수 있었고 그 후에 시스템을 구축할 수 있었습니다. 그 경로는 많은 분야에서 커리어 사다리 그 자체였습니다. 도메인 전문가에게는 그와 대등한 경로가 없었습니다. 왜냐하면 신뢰할 수 있는 소프트웨어를 만드는 법을 배우는 것은 그들이 결코 하지 않을 수년 간의 작업이었기 때문입니다.

에이전트 도구(Agentic tools)는 그 경로들 중 하나를 무너뜨렸지만, 다른 하나는 무너뜨리지 않았습니다. 도메인 모델을 작동하는 코드로 변환하는 능력인 엔지니어의 강점은 이제 저렴해졌습니다. 하지만 무엇이 옳은 모습인지 아는 도메인 전문가의 강점은 그렇지 않습니다. 프롬프트(Prompt)만으로는 그 단계에 도달할 수 없습니다. 수천 번의 급여 계산(Payrolls)을 조정해 온 사람의 암묵적 지식(Tacit knowledge)을 담고 있는 스킬 파일(Skill file) 같은 것은 존재하지 않습니다.

따라서 이 새로운 세상에서 가장 가치 있는 사람은 두 가지 기술을 모두 갖춘 사람입니다. 왜냐하면 그들은 두 계층 모두에서 검증할 수 있기 때문입니다. 그들은 생성된 코드가 견고하다는 것을 알면서도, 동시에 그 코드가 만들어내는 답이 참(True)이라는 것을 압니다. 그들은 "운전자는 11시간을 초과할 수 없다"라는 규칙을 알고 있기 때문에 이를 인코딩하는 테스트를 작성할 수 있으며, 무엇을 테스트하고 있는지 알기 때문에 그 테스트 자체가 의미가 있는지도 판단할 수 있습니다. 에이전트는 전사(Transcription)를 수행합니다. 그들은 두 번에 걸쳐 심판(Judging)을 수행합니다.

만약 당신이 향후 몇 년간 어디에 투자할지 결정하려는 숙련된 엔지니어라면, 이것이 바로 그 베팅입니다. 명확한 아이디어를 깔끔한 코드(Clean code)로 바꾸기 위해 당신이 땀 흘려 익힌 기계적인 기술(Mechanical skill)의 가치는 급격히 낮아졌습니다. 여전히 희소한 것은 실제 특정 도메인(Domain)에 대한 깊고 검증된 모델입니다. 지금 바로 그것을 확보하십시오. 하나의 산업, 도구, 규제 체계(Regulatory regime), 또는 물리적 프로세스(Physical process)를 선택하여, 과거에 프로그래밍 언어나 프레임워크를 배웠던 방식 그대로 학습하십시오. 그것이 바로 에이전트(Agent)가 당신을 대신해 해줄 수 없는 부분이며, 현재 가장 가치 있는 부분입니다.