I Write Less Code Than I Used To. That May Be the Point.
Over the last year, my day-to-day job has changed in a way I am still trying to understand. I am...
개요 #
지난 1년 사이 자신의 일이 달라졌다고 말하는 엔지니어가 있다. 여전히 시스템을 설계하고 코드를 읽고 장애를 디버깅하지만, 직접 쓰는 코드의 양은 크게 줄었다. Dev.to에 글을 올린 marcosomma는 그 변화가 어색하면서도 무의미하지 않다고 봤다.
핵심은 단순한 도구 교체가 아니다. 구현은 저렴해졌고, 그 구현을 믿어도 되는지 판단하는 일은 비싸졌다. 그가 짚는 변화의 방향도 거기에 있다.
노력과 산출물의 직접적인 관계가 사라졌다 #
커리어 대부분의 기간 동안 소프트웨어를 만들어내는 일 자체가 일을 했다는 증거였다. 문제가 생기면 해법을 설계하고 코드를 썼고, 아침에 없던 것이 저녁에는 존재했다. 투입한 노력과 결과물 사이에 아주 직접적인 연결이 있었다.
지금은 그 연결이 흐려지고 있다. 주변의 구현 작업 상당 부분을 AI가 만들어낸다. 완벽하지도, 자율적이지도, 감독 없이 되는 것도 아니지만, 첫 구현이 더는 어려운 단계가 아닐 만큼 값이 싸졌다. API 엔드포인트든 마이그레이션이든 데이터 변환이든 테스트 스위트든, 문제를 설명하고 맥락을 충분히 주면 그럴듯한 구현이 놀랄 만큼 빨리 나온다.
Photo by Samer Daboul on Pexels
비싼 구간은 그다음부터 시작된다. 이게 실제로 동작하는가?
여기서 말하는 질문은 "코드가 실행되는가", "테스트가 통과하는가"가 아니다. 우리가 실제로 신경 쓰는 상황들의 범위 전체에서 그 기능이 올바르게 동작하는지를 묻는 것이다. 이 질문이 업무의 훨씬 큰 부분을 차지하게 됐고, 자신의 가치를 보는 관점까지 바꿔놓았다.
"어떻게 만들까"에서 "어디서 깨질까"로 #
1년 전에는 어떻게 구현할지를 훨씬 많이 고민했다. 지금은 어떻게 실패할 수 있는지를 훨씬 많이 생각한다. 그가 던지는 질문들은 이렇다.
- 모델이 예상하지 못한 입력을 받으면 어떻게 되는가
- 두 컴포넌트의 판단이 서로 어긋나면 어떻게 되는가
- 겉보기에 좋은 답변에 잘못된 근거가 들어 있으면 어떻게 되는가
- 평가기 자체가 편향되어 있으면 어떻게 되는가
- 모델이 95%는 성공하는데, 남은 5%가 정확히 비즈니스에 치명적인 실패들이라면
- 폴백이 조용히 프로바이더·리전·지연·비용·동작을 바꿔버리면
- 모든 응답이 HTTP 200인데 시스템은 여전히 틀렸다면
구현은 더 이상 가장 어려운 지적 문제가 아니다. 실패를 탐지하는 일, 실패를 예방하는 일, 그리고 "출시해도 될 만큼 좋다"가 정확히 무엇을 뜻하는지 정의하는 일이 어렵다.
여기서 이상한 역전이 일어난다. 수십 년간 소프트웨어 엔지니어링은 테스트와 검증을 구현 이후의 단계로 다뤘다. 먼저 만들고, 그다음 누군가 동작하는지 확인했다. AI 시스템에서는 점점 반대로 느껴진다. 구현을 생성하는 비용은 내려가는데, 그것을 믿어도 되는지 아는 비용은 올라간다.
평가기를 만드는 일이 QA로 보이는 문제 #
한 주 전, 휴가에서 돌아온 그에게 팀은 특정 기능의 새 평가기(evaluator)를 요청했다. 얼핏 보면 QA 업무처럼 들린다. 그는 그 생각에 거부감이 들었다고 솔직히 적었다. 소프트웨어를 만드는 법을 배우는 데 여러 해를 썼는데, 남들 작업을 확인해주는 사람이 되어가는 건가.
그런데 이 해석은 실제로 벌어지는 일을 놓친다.
평가기를 만드는 데서 어려운 부분은 평가기 코드를 쓰는 일이 거의 아니다. 그것도 AI가 크게 거들어준다. 진짜 어려운 건 평가기가 무엇을 측정해야 하는지 정하는 쪽이다. 무엇을 실패로 볼 것인가. 어떤 실패는 결정론적으로 확인할 수 있고 어떤 실패는 통계적 평가가 필요한가. 어떤 데이터셋이 현실을 충분히 대표하는가. 사각지대는 어디인가. 평가기 자체가 속을 수 있는가. 독립적이라고 믿었던 두 검증이 실은 같은 실수를 하고 있지 않은가. 프로덕션에 내보내도 되는 임계치는 어디인가.
이건 테스트 구현에 관한 질문이 아니다. 정확성의 운영적 정의에 관한 질문이다. AI와 함께 일하면서 정확성은 우리가 직접 설계해야 하는 대상이 됐다.
확률적인 것을 결정론으로 감싸는 일 #
전통적인 소프트웨어에는 비교적 편안한 계약이 있다. 입력과 상태가 같으면 결정론적 소프트웨어는 대체로 같은 출력을 낸다. LLM은 그 전제를 깬다. 거대한 입력 공간 전체에 걸쳐 그럴듯한 출력을 만들어내고, 구조적으로 올바르고 언어적으로 훌륭하고 내부적으로 일관되면서 완전히 틀린 결과를 낼 수 있다.
그래서 우리는 모델을 소프트웨어로 감싼다. 제약을 걸고, 출력을 검증하고, 신호를 비교하고, 폴백 경로를 만들고, 확률적 동작 주변에 결정론적 검사를 붙이고, 평가 데이터셋을 만들고, 회귀를 측정하고, 프로덕션 트레이스를 관찰한다. 그리고 결국 존재조차 몰랐던 실패 유형을 발견해 시스템을 또 손본다.
그의 업무 중 놀랄 만큼 큰 부분이 이 경계에 있다. 지능을 만드는 일이 아니라, 확률적인 지능을 실제 제품에 넣어도 될 만큼 신뢰할 수 있게 만드는 일이다.
자동화를 막는 건 지는 전략이다 #
여기서 그는 또 다른 불편함을 짚는다. AI가 구현을 만들 수 있다면, 다른 AI가 평가까지 만들지 못할 이유는 무엇인가. 자신의 원칙과 불신, 엣지 케이스를 찾는 방식을 설명해서 또 하나의 에이전트에 인코딩할 수 있지 않은가.
아마 할 수 있고, 해야 한다.
믿을 만한 실패 패턴을 발견하면 그 탐지를 자동화하고 싶다. 같은 리뷰를 반복하고 있다면 시스템이 대신 하게 만들고 싶다. 결정론적 게이트가 수동 판단을 대체할 수 있다면 그 게이트를 만드는 게 진보다. 자신의 가치가 작업을 자동화로부터 지켜내는 데 달려 있다면, 그건 지는 전략이다.
그래서 중요한 구분선은 인간이 할 수 있는 일과 AI가 할 수 있는 일 사이가 아닐지도 모른다. 아는 문제와 모르는 문제 사이다.
실패 유형이 한번 이해되면 그것은 싸진다. 테스트에 인코딩하고, 평가기를 만들고, 정책을 추가하고, 에이전트에게 찾아보라고 가르칠 수 있다. 그러면 어려운 부분은 다른 곳으로 옮겨간다. 최전선은 아직 측정할 방법을 모르는 다음 문제가 되고, 그의 일도 점점 그쪽으로 가고 있다.
스무 줄에 이틀이 들어 있을 때 #
그의 산출물은 점점 코드가 아니다. 정의이거나 제약이거나 아키텍처이거나 실패 분류 체계이거나 릴리스 기준이거나, 확률적인 무언가를 감싼 결정론적 가드다. 최종 산출물이 스무 줄짜리 코드일 때도 있지만, 그 스무 줄에는 정확히 무엇을 막아야 하는지 이틀 동안 고민한 결과가 담겨 있다.
이건 생산성에 대한 체감을 바꾼다. 한 주에 프로덕션 코드 1,000줄을 만들어냈다면 만든 것을 가리키기 쉽다. 같은 한 주를 미묘한 실패 유형 하나를 파헤치는 데 쓰고 결국 그것을 막는 작은 검사 하나를 추가했다면, 눈에 보이는 산출물은 훨씬 작다. 하지만 경제적 가치는 훨씬 클 수 있다.
시스템은 이미 생성하는 법을 안다. 더 어려운 질문은 그것이 생성한 결과에 의존할 수 있느냐다.
이름 붙이기 어려운 역할 #
이 역할을 정확히 무엇이라 불러야 할지 그는 아직 모른다. AI 엔지니어도 맞고, 신뢰성 엔지니어도 일부 맞고, 아키텍처도 일부 맞고, 평가 엔지니어링(evaluation engineering)이 중요해지는 것도 분명하다. 그중 어느 라벨도 그가 겪는 전환을 온전히 담지 못한다.
확실한 건 하나다. 구현을 만들어내는 사람에서, 그 구현이 신뢰받기 전에 무엇을 증명해야 하는지 묻는 사람으로 옮겨가고 있다는 것.
이게 낯설게 느껴지는 이유는 소프트웨어 엔지니어링이 우리를 만드는 일과 자신을 동일시하도록 훈련시켰기 때문이다. 코드는 장인정신이었고 산출물이었고 쓸모 있다는 증거였다. AI는 코드를 흔하게 만들고 있고, 무언가가 흔해지면 가치는 보통 다른 곳으로 옮겨간다.
소프트웨어 엔지니어링에서 다음으로 희소해질 자원은 구현이 아닐지도 모른다. 현실이 대신 알려주기 전에 구현이 틀렸다는 것을 알아내는 능력일지도 모른다.
싼 쪽은 점점 생성된다. 비싼 쪽은 어디서 깨질지 아는 것, 그리고 깨지지 않게 만드는 것이다.
이 글은 위 출처를 바탕으로 한국 독자를 위해 재작성한 기사입니다. 원문의 사실과 수치에 근거하며, 별도의 견해를 포함하지 않습니다.