당신이 생각할 수 있다는 것을 무엇이 증명하는가?

AI는 단순히 결과물(output)을 저렴하게 만든 것이 아닙니다. 그것은 노력, 역량(competence), 그리고 신뢰 사이의 오래된 계약을 깨뜨렸습니다.

개발자들에게 이것은 추상적인 이야기가 아닙니다. 누구나 몇 초 만에 깔끔한 PR(Pull Request), 그럴듯한 코드 리뷰(code review), 작동하는 API 엔드포인트(endpoint), 또는 역량 있어 보이는 아키텍처 다이어그램(architecture diagram)을 생성할 수 있게 되면서, 결과물(artefact)은 과거에 증명하던 것들을 더 이상 증명하지 못하게 되었습니다. 좋은 솔루션이 더 이상 누군가가 그 문제와 씨름했다는 것을 의미하지 않게 된 것입니다.

생산성 논쟁의 이면에 깔린 질문은 더 어렵습니다. 만약 작업물이 더 이상 내가 생각할 수 있다는 것을 증명하지 못한다면, 무엇이 그것을 증명할 수 있을까요?

오래된 증명 계약 (The old proof contract)

모든 기관은 증명 계약(proof contracts)을 기반으로 운영됩니다. 학교는 에세이와 시험을 요구합니다. 기업은 이력서(CV), 인터뷰, 그리고 작업 샘플을 요구합니다. 시장은 트랙션(traction)과 리텐션(retention)을 요구합니다.

이러한 신호 중 그 어느 것도 순수한 적은 없었습니다. 이력서는 언제나 마케팅 문서였습니다. 인터뷰는 언제나 긴장감과 매력에 의해 왜곡되었습니다. 포트폴리오는 그 사람이 얼마나 많은 도움을 받았는지 숨길 수 있었습니다. 하지만 그것들은 충분히 잘 작동했습니다. 왜냐하면 다듬어진 결과물을 만드는 데는 비용이 많이 들었기 때문입니다. 비용이 마찰(friction)을 만들었고, 그 마찰이 신호(signal)를 만들어냈습니다.

AI는 이 "충분히 비싼" 부분을 공격합니다. AI는 역량 있어 보이는 데 드는 비용을 압축합니다. 그것만으로도 비용을 대리 지표(proxy)로 삼았던 시스템들을 무너뜨리기에 충분합니다.

변화 (The move)

결과물이 저렴해지면, 결과물의 품질은 최종적인 증명이 아니라 시작을 위한 입찰가가 됩니다. 중요한 질문은 상위 단계로 이동합니다:

이 결과물은 그 뒤에 있는 개인, 팀, 또는 시스템에 대해 무엇을 증명하는가?

때때로 그 대답은 "별로 증명하는 것이 없다"일 수도 있습니다. 깔끔한 PR은 누군가가 좋은 모델에 접근할 수 있었고, 첫 번째 결과를 그대로 붙여넣지 않을 정도의 안목(taste)을 가지고 있음을 증명할 뿐일 수도 있습니다. 강력한 이력서는 지원자가 채용 필터가 어떻게 작동하는지 알고 있음을 증명할 수도 있습니다.

유용한 대응책은 AI를 금지하는 것이 아닙니다. AI로 다듬어진 결과물을 증명 대상(proof object)으로 취급하는 것을 멈추는 것입니다. 차세대 증명 시스템은 결과물이 나오기 전, 도중, 그리고 그 이후에 무엇이 일어났는지를 묻습니다.

판단과 결과물을 구분하는 다섯 가지 질문

이 질문들은 코드, PR, 아키텍처 결정, 인터뷰 답변, 그리고 당신 자신의 작업 모두에 적용됩니다.

1. 어떤 문제가 선택되었으며, 어떤 더 쉬운 문제는 거부되었는가?

사고(thought)의 첫 번째 증거입니다. 잘못된 작업은 종종 처음 접한 유창한 프레임(fluent frame)을 그대로 수용하는 것에서 시작됩니다. 훌륭한 작업에는 대개 숨겨진 거절이 포함되어 있습니다. 즉, 누군가가 유혹적인 버전을 보았지만 그것을 택하지 않은 것입니다. 코드베이스(codebase)에서는 6개월 뒤에 깨질 한 줄짜리 코드(one-liner) 대신, 더 어렵더라도 유지보수가 용이한 추상화(abstraction)를 선택하는 모습으로 나타납니다.

2. 제약 조건 하에서 어떤 트레이드오프(tradeoff)가 이루어졌는가?

지능은 경계선에서 드러납니다. 누구나 품질, 속도, 안전성, 그리고 유지보수성(maintainability)을 가치 있게 여긴다고 주장할 수 있습니다. 진정한 판단력은 이 모든 것을 동시에 극대화할 수 없을 때 나타납니다. 이 특정 엔드포인트(endpoint)를 위해 왜 지연 시간(latency)보다 정확성(correctness)을 선택했는지, 그리고 어떤 근거가 있다면 그 선택을 뒤집을 것인지를 설명할 수 있는 개발자는 결과물만으로는 보여줄 수 없는 무언가를 보여주고 있는 것입니다.

3. 결과물 자체가 증명할 수 없는 무엇을 확인했는가?

이것은 검증(verification)에 관한 질문입니다. 이는 AI를 생성기(generator)로 사용하는 사람과 AI를 판단 루프(judgement loop) 내부에서 사용하는 사람을 구분합니다. 생성된 코드는 컴파일(compile)될 수 있습니다. 그것은 검증이 아닙니다. 검증이란 그 주장에 답할 수 있게 만드는 외부적인 요소입니다. 즉, 엣지 케이스(edge case) 테스트, 프로덕션 데이터(production data) 확인, 그리고 실제 시스템에서 작동함을 증명하는 통합 테스트(integration test)가 바로 그것입니다.

4. 피드백을 받거나 현실과 접촉한 후 무엇이 변했는가?

수정(revision)은 창작(creation)보다 덜 화려하기 때문에 과소평가되곤 합니다. 하지만 AI의 세계에서 수정은 더 높은 수준의 신호(signal)가 됩니다. 첫 번째 결과물은 저렴합니다. 코드 리뷰(code review), 프로덕션 장애(production incident), 또는 동료가 결함을 지적한 이후에 변화된 결과물이야말로 더 많은 진실이 드러나는 지점입니다.

5. 이것이 틀렸을 경우 그 결과에 대한 책임은 누구에게 있는가?

책임감 (Accountability)은 기계가 실어 나를 수 없는 신호입니다. 모델은 결과물을 만들어낼 수 있습니다. 하지만 사람은 자신이 무엇을 뒷받침할 용의가 있는지 결정해야 합니다. "내가 이것을 출시했고, 이에 대한 페이저 듀티 (pager duty)를 책임지며, 문제가 생기면 깨어 있겠다"라고 말하는 개발자는, AI의 출력물이 스스로 말하게 내버려 두는 사람과는 다른 범주에서 움직이고 있는 것입니다.

이것이 실무에서 변화시키는 것

채용 (Hiring): 작업 샘플만을 요구하는 것을 멈추십시오. 후보자에게 그럴듯한 AI 생성 솔루션을 제공하고, 무엇이 잘못되었는지, 운영 환경 (production)에서 무엇이 망가질지, 그리고 배포하기 전에 무엇을 확인할 것인지 물으십시오.

코드 리뷰 (Code review): 깔끔한 디프 (diff)를 충분한 증거로 취급하는 것을 멈추십시오. 무엇이 생성되지 않았는지 물으십시오. 작성자가 어떤 트레이드오프 (tradeoff)를 옹호하고 있는지 물으십시오. 어떤 검증 (verification)이 해당 솔루션이 틀렸음을 증명할 수 있는지 물으십시오.

당신의 업무 (Your own work): 다듬어진 결과물만을 통해 가치를 증명하려 하지 마십시오. 결과물의 완성도는 유지하되, 그에 판단 (judgement)을 결합하십시오. 당신이 선택한 문제를 보여주십시오. 트레이드오프를 보여주십시오. 검증 과정을 보여주십시오. 수정 과정을 보여주십시오. 그리고 당신이 무엇을 책임질 것인지 보여주십시오.