우린 '원래부터' 의사결정 에이전트였다

· 13min

우린 ‘원래부터’ 의사결정 에이전트였다

개발자로 채용될 때 이런 평가를 받은 적이 있다.

“창업과 투자 경험에서 나온, 의사결정자로서의 트레이드오프 인사이트가 있다.”

솔직히 말하면 그 말이 꽤 좋았다. 그리고 그 이후로 나는 계속 스스로를 의사결정자라고 생각해왔다. 코드를 짜면서도. 물론 결정의 범위는 점점 넓어지고 있다.

그러니까 코딩 에이전트로 정적 사이트 만들고 “이게 프로그래밍인가요?”라는 질문을 보면, 가끔 이런 생각이 든다.

그게 신기한 거였나?

Unopinionated한 것들은 재현하기 쉬워졌다

Express 서버 띄우고, Next.js 부트스트랩하고, 기본 CRUD 갖춘 게시판 만드는 일—지금은 Claude Code나 Cursor한테 맡기면 어지간하면 돌아간다. 복잡도에 따라 난도는 다르지만, “어떻게 만드느냐”가 이미 정해진 작업들은 재현 비용이 급격히 낮아졌다.

이 작업들을 나는 unopinionated한 작업이라고 부른다. 정답이 있거나, 정답에 수렴하는 패턴이 이미 커뮤니티에 쌓인 것들. RESTful endpoint 설계, 컴포넌트 폴더 구조, ORM 쿼리 작성—에이전트가 인터넷의 집단지성을 학습했으니, 집단지성이 합의한 답은 잘 낸다.

문제는 그 다음이다.

Opinionated한 결정 하나가 진짜 비싸졌다

최근에 복잡한 워크플로우 빌더를 만들었다. 정확히는 “빌더를 돕는 빌더”, 메타 빌딩에 가까운 작업이었다.

그 레벨에서 개발하다 보면 재미있는 일이 생긴다. 코드를 작성하는 시간보다, 결정을 하는 시간이 더 소진된다. 수직·수평으로 쪼개진 모듈과 정책과 패턴과 마케팅적 요소들 사이에서, 매 순간 이 질문이 따라온다:

이 결정은 의견이 있어야 하는가, 없어야 하는가?

노드 간 데이터 흐름을 어떻게 추상화할 것인가. 사용자가 커스텀 로직을 넣을 수 있게 열어줄 것인가, 아니면 프리셋만 제공할 것인가. 에러 처리를 워크플로우 레벨에서 할 것인가 노드 레벨에서 할 것인가. 이 컴포넌트는 제품 마케팅 관점에서 “기능”인가 “동작”인가.

이런 결정을 에이전트에게 맡기기 어려운 이유는 하나가 아니다. 적어도 넷으로 나뉜다.

  • 맥락. 코드베이스의 역사, 제품의 방향, 팀의 문화, 사용자의 멘탈모델. 이게 프롬프트에 다 들어가지 않는다. 에이전트가 못 하는 게 아니라, 내가 다 넘겨주지 못한다.
  • 권한. 안을 잘 내더라도, 그 안을 채택할 권한은 조직이 사람에게 준다.
  • 책임. 결정이 틀렸을 때 되돌리고 설명하는 건 사람 몫이다.
  • 평가. 그 결정이 맞았는지는 몇 주나 몇 달 뒤에야 드러난다. 돌려 보고 바로 채점할 수 없다.

그러니까 모델이 판단안을 만드는 능력과, 조직이 결정에 책임지는 일은 별개다. 모델은 꽤 괜찮은 안을 낸다. 나도 그 안을 받아서 고친다. 그 장면은 글 끝에 붙여 뒀다.

역설적으로, 에이전트가 구현을 가져가면 갈수록 opinionated한 판단의 가치는 올라간다. 재현할 수 없는 것이기 때문에.

코드 작성은 차라리 즐겁다

좀 더 솔직하게 말하자면—나는 코드를 작성하는 시간이 즐겁다. 생각을 정리하고 발전시킬 수 있는 귀중한 시간이기도 하다. 타이핑하면서 설계가 잘못됐다는 걸 깨닫고, 변수명을 짓다가 추상화가 틀렸다는 걸 알아챈다.

에이전트는 이 피드백 루프를 더 빠르게 해줬다. 내가 방향을 잡으면 구현은 빠르게 나오고, 나는 그걸 보면서 더 빠르게 판단을 수정한다.

피곤한 건 코딩이 아니다. 결정이 피곤하다. 특히 opinionated와 unopinionated 사이 경계가 흐릿한 구간—거기서 잘못 결정하면 나중에 기술 부채가 아니라 구조 부채가 된다. 되돌리기 어려운 것들.

”프롬프팅이 프로그래밍이냐”는 질문이 왜 틀렸나

다시 처음으로 돌아가자. 코딩 에이전트로 사이트 만들고 “이게 프로그래밍인가요?”라는 질문.

나는 프로그래밍을 시작할 때부터—자아가 좀 비대했는지—이렇게 생각해왔다:

프로그래밍의 본질은 의사결정이고, 그 결정들을 사람이 아닌 시스템에 조금씩 더 위임하는 과정이다.

컴파일러가 등장했을 때, “어셈블리를 안 짜면 진짜 프로그래밍이 아니다”라고 했다. 프레임워크가 등장했을 때, “라이브러리 없이 짜야 진짜다”라고 했다. 지금은 에이전트한테 프롬프트 쓰면 “그건 프로그래밍이 아니다”라고 한다.

패턴이 보인다.

매번 추상화 레이어가 올라갈 때마다, 이전 레이어에 있던 사람들은 그게 “진짜”가 아니라고 말했다. 하지만 결국 살아남는 건 더 높은 레이어에서 더 좋은 결정을 내리는 사람이었다.

프롬프트도 결정이다. 무엇을 만들지, 어떤 제약을 걸지, 어디서 에이전트를 믿고 어디서 직접 개입할지—이 모든 것이 의사결정이다.

그래서

에이전트 시대에 살아남는 개발자가 어떤 사람인지에 대한 글은 이미 넘쳐난다. 나는 그런 식의 정리를 별로 좋아하지 않는다. 너무 쉽게 리스트가 되고, 리스트는 대부분 틀리기 때문에.

대신 이렇게 말하고 싶다.

에이전트가 잘하는 것과 못하는 것의 경계를 정확하게 아는 사람—그 경계에서 opinionated한 판단을 빠르게, 명확하게, 정당화할 수 있게 내리는 사람이 앞으로 더 비싸진다.

형태는 달라도 공통점은 하나다. 재현되지 않는다. 그리고 재현되지 않는 것에 가격이 붙는다. 적어도 내가 겪은 두 번은 그랬다. 채용 때 값을 쳐 준 것도 그 판단이었고, 빌더를 만들면서 시간이 가장 많이 든 것도 그 판단이었다.

우린 원래부터 의사결정 에이전트였다. 코딩 에이전트가 바꾼 게 아니라, 나머지를 다 가져가면서 그게 더 선명하게 보이게 됐을 뿐이다.

후기: 결정 하나를 꺼내 보면 (2026-10-14)

처음 쓸 때는 “에이전트는 이 결정을 못 한다”고 잘라 말했다. 반년 뒤 다른 제품에서 겪은 장면 하나가 그 문장을 못 버티게 했다.

2026년 9월, 공장의 자재 소요 계획을 일곱 단계로 돌리는 워크플로를 만들고 있었다. 저장된 그래프의 문제는 사람 검토 노드 일곱 개가 검사 결과와 상관없이 매 단계 멈춘다는 것이었다. 현업은 결과물을 보고 싶은 거지, 매번 승인 버튼을 누르고 싶은 게 아니다.

Claude 세션이 그래프 개편 제안서를 썼다. 사람이 멈춰서 확인하는 자리를 세 곳으로 줄이자는 안이었다. 시트 선별, 기초재고, 납품. 다른 모델 셋의 적대적 리뷰를 거친 2판에도 그 항목은 살아남았다. 틀린 안은 아니었다. 일곱 번 멈추던 걸 세 번으로 줄이니까.

그날 저녁 나는 자리를 고정하는 방식 자체를 버렸다. 멈추는 조건을 위치가 아니라 판정으로 바꿨다. 어느 단계든 연결된 검사가 reject하거나 에이전트가 검토를 요청할 때만 멈춘다. 통과하면 자동으로 간다. 이유는 하나였다. 현업이 보는 의미 단계가 일곱 개이고, 각 단계의 결과물은 다 보여야 하고, 검증에 걸리면 그 자리에서 엑셀을 보며 고쳐 이어갈 수 있어야 한다. 세 곳 고정은 이 요구를 약하게 표현한 것이었다.

같은 날 결정표에 올랐고, 제안서의 그 항목은 “대체됨”으로 표기됐다. 지금 그래프 정의는 검사 노드 뒤에 조건부 검토 분기 셋을 둔다.

이 장면을 넷으로 나눠 보면 이렇다. 에이전트는 안을 냈고, 안은 쓸 만했다. 다만 현업이 어디서 멈추고 싶어 하는지는 내가 회의실에서 들은 것이고(맥락), 그 그래프를 납품하는 건 우리 팀이고(권한, 책임), 자동 통과가 맞았는지는 공장이 몇 주 돌려 봐야 안다(평가). 에이전트가 결정을 못 한 게 아니다. 그 넷이 내 쪽에 있었을 뿐이다.