커서를 지우는 일과 예산을 자르는 일은 왜 같은 문제인가

어떤 사람은 더 이상 커서를 쓰지 않겠다고 선언한다. 어떤 조직은 한 번에 301억 원의 예산을 잘라낸다. 겉으로 보면 전자는 생산성 도구의 교체이고, 후자는 지방자치단체의 정치적 충돌이다. 그러나 두 사건에는 놀라울 만큼 같은 질문이 숨어 있다.

누가 무엇을 결정하고, 그 결정이 실제 세계에 도달하기까지 어떤 인터페이스를 거치는가?

커서가 사라지는 순간 개발자는 코드 편집기를 바꾸는 것이 아니다. 자신의 의도를 소프트웨어에 전달하는 방식을 바꾼다. 지방정부의 예산이 삭감되는 순간 의회는 숫자 몇 개를 지우는 것이 아니다. 주민의 필요가 행정의 실행으로 번역되는 통로를 바꾼다.

이 둘을 함께 보면 기술 혁신과 공공 갈등을 관통하는 하나의 원리를 발견할 수 있다. 현대 사회에서 권력은 자원을 소유하는 데서만 나오지 않는다. 권력은 의도를 실행으로 변환하는 인터페이스를 통제하는 데서 나온다.

인터페이스가 바뀌면 결정의 의미도 바뀐다

개발자에게 편집기는 단순한 화면이 아니다. 그것은 생각과 결과물 사이에 놓인 작업 환경이다. 예전에는 개발자가 파일을 찾고, 코드를 읽고, 문법을 기억하고, 오류를 수정하며 조금씩 결과를 만들어야 했다. 그러나 인공지능 기반 도구가 발전하면 개발자는 점점 더 자연어로 목표를 설명하고, 도구가 생성한 결과를 검증하는 역할로 이동한다.

이 변화는 속도의 변화가 아니다. 행동의 단위가 바뀌는 변화다. 과거의 단위가 한 줄의 코드였다면, 새로운 단위는 하나의 요구사항이나 기능 묶음이 된다. 손으로 벽돌을 쌓던 사람이 설계 지시와 품질 검사를 담당하는 사람으로 이동하는 것과 비슷하다.

그래서 어떤 도구를 삭제하고 다른 도구로 옮겼다는 말은 취향의 문제가 아닐 수 있다. 그 말은 다음과 같은 선언일 수 있다.

나는 더 이상 결과를 만드는 과정 자체를 통제하는 사람으로 남지 않겠다. 대신 목표를 정의하고, 결과를 평가하며, 시스템의 방향을 조정하는 사람이 되겠다.

이때 중요한 것은 새 도구의 이름이 아니다. 중요한 것은 누가 번역을 담당하는가다. 사용자의 의도를 코드로 번역하는 인공지능이 강력해질수록 사용자는 구현 과정에서 멀어진다. 그만큼 생산성은 높아질 수 있지만, 동시에 이해와 검증의 부담은 커진다.

행정에서도 구조는 같다. 주민에게 필요한 것은 고령자 복지주택, 시장 재개발, 의료 시설, 관광 기반 시설처럼 구체적인 사업의 형태로 표현된다. 그러나 주민의 요구가 실제 건설과 서비스로 바뀌려면 집행부의 계획, 의회의 심의, 예산 편성, 절차적 검토, 계약과 집행이라는 여러 인터페이스를 통과해야 한다.

하동에서 301억 원, 일반회계의 약 5퍼센트에 해당하는 예산이 133개 사업에서 삭감된 일은 바로 이 번역 과정이 멈춘 사례로 볼 수 있다. 집행부는 생활과 지역경제에 직결된 사업이 차단되었다고 말하고, 의회는 시급성과 실효성이 부족하거나 절차와 소통이 미흡한 사업을 조정했다고 말한다. 양쪽 모두 자신이 주민의 이익을 보호한다고 주장할 수 있다.

문제는 어느 한쪽의 말이 자동으로 진실이 되는 데 있지 않다. 더 근본적인 문제는 주민의 필요가 어느 단계에서, 어떤 기준으로, 누구의 판단에 의해 사업으로 번역되는지 시민들이 충분히 볼 수 없다는 데 있다.

생산성 도구와 공공예산의 공통된 함정

인공지능 도구를 쓰면 개발 속도가 빨라진다. 하지만 생성된 코드가 많아질수록 코드의 출처와 작동 원리를 모르는 위험도 커진다. 짧은 시간에 기능을 만들었지만, 나중에 오류가 발생했을 때 누구도 전체 구조를 설명하지 못할 수 있다. 생산성의 증가는 때때로 이해의 감소를 대가로 한다.

예산도 마찬가지다. 사업을 빠르게 추진하려면 계획과 집행의 속도가 필요하다. 하지만 절차가 생략되고, 효과 검증이 부족하며, 반대 의견이 충분히 반영되지 않으면 예산은 속도만 빠른 약속이 된다. 반대로 심의와 견제가 지나치게 정치화되면 정당한 감시가 실행 차단으로 변한다.

여기서 중요한 구분이 필요하다. 통제와 지연은 다르고, 자율성과 독주는 다르다.

인공지능 코딩 도구를 사용한다고 해서 개발자가 통제를 포기해야 하는 것은 아니다. 오히려 생성 결과를 시험하고, 보안 취약점을 확인하고, 장기 유지보수 가능성을 검토하는 새로운 통제가 필요하다. 마찬가지로 의회가 예산을 삭감한다고 해서 무조건 발목을 잡는 것은 아니다. 재정 낭비를 막고, 사업의 우선순위를 다시 묻고, 집행부의 설명 책임을 강화하는 기능이 있을 수 있다.

그러나 통제가 정당하려면 통제의 기준이 공개되어야 한다. 개발자는 인공지능이 왜 특정 코드를 만들었는지 이해할 수 있어야 한다. 시민은 왜 특정 사업이 통과되거나 삭감되었는지 추적할 수 있어야 한다. 기준이 보이지 않는 통제는 품질 관리가 아니라 권력 행사로 느껴진다.

하동의 사례에서 고령자 복지주택 53억 원, 공설시장 재개발 30억 원, 건설과와 건축과의 대규모 삭감처럼 구체적인 숫자는 보이지만, 숫자만으로는 판단의 질을 알 수 없다. 삭감된 사업이 어떤 성과 지표를 충족하지 못했는지, 대체 사업은 무엇인지, 재추진 조건은 무엇인지, 삭감으로 발생할 사회적 비용은 얼마인지가 함께 공개되어야 한다.

그렇지 않으면 시민은 두 가지 불완전한 설명 사이에 놓인다. 한쪽은 생활이 멈춘다고 말하고, 다른 한쪽은 부실과 절차 위반을 막았다고 말한다. 하지만 시민에게 필요한 것은 구호가 아니라 사업별 판단의 장부다.

진짜 문제는 속도가 아니라 검증 가능한 속도다

기술 기업은 새로운 도구를 선택할 때 대개 세 가지를 본다. 얼마나 빨리 결과를 내는가, 얼마나 적은 비용으로 운영할 수 있는가, 그리고 문제가 생겼을 때 얼마나 쉽게 고칠 수 있는가. 공공예산도 똑같은 기준으로 평가할 수 있다.

첫째는 실행 속도다. 고령자 주거 문제나 시장의 쇠퇴는 기다려 달라고 말해 주지 않는다. 예산이 지연되면 주민의 생활과 지역경제에 실제 비용이 발생한다.

둘째는 목표 적합성이다. 돈을 쓰는 것 자체가 성과는 아니다. 시설을 지었는지보다 이용자가 실제로 늘었는지, 시장 매출이 회복되었는지, 주거 취약계층의 부담이 줄었는지를 확인해야 한다.

셋째는 수정 가능성이다. 처음부터 완벽한 사업은 거의 없다. 좋은 정책은 실패하지 않는 정책이 아니라, 작은 실패를 조기에 발견하고 큰 손실 전에 수정할 수 있는 정책이다.

이 세 기준을 결합하면 기존의 찬반 구도가 달라진다. 사업을 전액 승인할 것인가, 전액 삭감할 것인가의 이분법에서 벗어나 가역적인 예산 설계를 생각할 수 있다.

예를 들어 고령자 복지주택 사업을 한 번에 53억 원 전액 집행하는 대신, 토지와 수요 조사를 위한 1단계 예산, 설계와 입주자 확보를 위한 2단계 예산, 공사 착수를 위한 3단계 예산으로 나눌 수 있다. 각 단계마다 공개된 조건을 설정하고, 조건을 달성하면 다음 예산을 자동으로 심의한다. 목표가 달성되지 않으면 사업을 중단하거나 설계를 변경한다.

공설시장 재개발도 마찬가지다. 건물부터 새로 짓는 대신 상인 수요, 공실률, 방문객 동선, 임대료 부담, 운영 주체의 재정 계획을 먼저 검증하는 소규모 실험을 할 수 있다. 시장 일부 구역을 임시로 개선하고 실제 이용 데이터를 모은 뒤 전체 재개발 여부를 결정하는 방식이다.

이것은 인공지능 도구를 사용하는 방식과 닮았다. 처음부터 거대한 프로그램 전체를 생성하게 하는 대신, 작은 기능을 만들고 테스트하며, 결과가 기대에 맞을 때 다음 단계로 넘어간다. 좋은 인터페이스는 결정을 크게 만드는 것이 아니라, 결정을 작게 쪼개서 틀렸을 때 덜 다치게 만든다.

민주주의는 거부권의 총합이 아니라 번역 품질의 문제다

의회와 집행부의 갈등을 단순한 정치적 대립으로만 보면 해법도 단순해진다. 한쪽을 설득하거나, 선거를 통해 세력을 바꾸거나, 더 강한 권한을 부여하면 된다고 생각하기 쉽다. 그러나 실제로 필요한 것은 권한의 이동보다 결정 과정의 해상도 향상이다.

133개 사업을 한꺼번에 삭감하는 방식은 행정적으로 강력해 보이지만, 사업별 가치와 위험을 구분하기 어렵게 만든다. 반대로 모든 사업을 원안대로 통과시키는 방식은 주민의 감시 기능을 약화시킨다. 두 방식 모두 시민이 무엇을 선택했는지 알기 어렵게 만든다.

예산 심의가 제대로 작동하려면 최소한 다음 질문에 사업별로 답해야 한다.

• 이 사업이 해결하려는 주민의 문제는 무엇인가?
• 사업이 없을 때 발생하는 비용은 얼마인가?
• 성공을 측정할 지표는 무엇인가?
• 언제 중간 평가를 하는가?
• 실패했을 때 누가 어떤 방식으로 수정하는가?
• 삭감할 경우 영향을 받는 사람은 누구이며, 보완책은 무엇인가?

이 질문들은 행정 문서를 더 길게 만들기 위한 장식이 아니다. 결정권자가 시민의 삶을 추상적인 숫자로 처리하지 않도록 만드는 최소한의 안전장치다.

특히 정치적 갈등이 깊을수록 절차의 투명성은 결과의 정당성만큼 중요하다. 같은 예산 삭감이라도 공개된 기준과 자료에 따라 사업별로 설명했다면 시민은 결과에 동의하지 않더라도 판단의 구조를 이해할 수 있다. 반대로 충분한 설명 없이 대규모로 삭감하면, 실제로 타당한 삭감까지도 정치적 보복처럼 보일 수 있다.

인공지능 시대의 개발도 같은 방향으로 변해야 한다. 개발자는 단순히 가장 빠른 생성 도구를 고르는 사람이 아니라, 생성 과정과 결과를 기록하고 검증 가능한 시스템을 설계하는 사람이 되어야 한다. 공공기관 역시 가장 큰 예산을 확보한 조직이 아니라, 가장 잘 설명하고 가장 쉽게 수정하는 조직이 되어야 한다.

바로 적용할 수 있는 결정의 네 가지 원칙

1. 결과보다 번역 과정을 먼저 기록하라

사업을 시작하거나 인공지능 도구를 도입할 때 최종 결과만 적지 말고, 어떤 문제를 해결하려 했는지, 어떤 선택지를 검토했는지, 왜 현재의 방식을 선택했는지를 남겨야 한다. 나중에 오류가 생겼을 때 기록이 없으면 책임은 사라지고 논쟁만 남는다.

2. 큰 결정을 단계별 결정으로 쪼개라

전액 승인과 전액 삭감 사이에는 수많은 선택지가 있다. 시범 사업, 단계별 집행, 조건부 승인, 중간 평가를 활용하면 속도와 통제를 동시에 확보할 수 있다.

3. 반대 의견을 거부가 아니라 데이터로 바꿔라

의회가 사업의 실효성을 문제 삼는다면 집행부는 반발부터 할 것이 아니라 측정 가능한 지표를 제시해야 한다. 개발자가 인공지능 생성 코드에 불안을 느낀다면 도구를 무조건 배제하기보다 테스트 범위와 검증 기준을 정해야 한다.

4. 실패 비용과 미실행 비용을 함께 계산하라

사업을 추진했을 때의 낭비만 계산해서는 안 된다. 사업을 중단했을 때 생기는 주거 불안, 지역 상권 침체, 행정 신뢰 하락도 비용이다. 반대로 추진의 편익만 강조해서도 안 된다. 두 경로의 비용을 같은 표 위에 올려놓아야 합리적인 판단이 가능하다.

결론: 좋은 사회는 결정을 빠르게 하는 사회가 아니다

커서를 지우는 개발자는 더 빠른 생산을 얻는 대신, 무엇을 만들고 있는지 끊임없이 확인해야 하는 책임을 떠안는다. 예산을 삭감하는 의회는 재정 통제의 권한을 행사하는 대신, 무엇을 왜 잘랐는지, 그 결과를 어떻게 보완할지 설명해야 하는 책임을 진다.

두 경우 모두 핵심은 도구나 권한 자체가 아니다. 의도와 결과 사이의 거리가 얼마나 멀어졌는가, 그리고 그 거리를 누가 책임지는가가 핵심이다.

오늘날 우리는 인공지능으로 코드를 만들고, 숫자로 도시를 설계하며, 회의와 문서로 시민의 삶을 결정한다. 이러한 시스템에서는 결정을 내리는 사람보다 결정을 번역하는 인터페이스가 더 큰 영향을 미칠 수 있다. 인터페이스가 불투명하면 최고의 도구도 불신을 낳고, 정당한 견제도 방해처럼 보인다.

진짜 혁신은 더 적은 클릭으로 더 많은 일을 하는 것이 아니다. 더 큰 결정을 더 작은 위험으로 시험하고, 그 과정을 누구나 이해할 수 있게 만드는 것이다.

따라서 우리가 물어야 할 질문은 “누가 이겼는가”가 아니다. 구글의 도구가 기존 편집기를 이겼는지, 집행부가 의회를 이겼는지에 매달리는 순간 우리는 본질을 놓친다. 더 중요한 질문은 이것이다.

이 결정은 주민과 사용자에게 어떤 결과로 번역되었으며, 틀렸을 때 되돌릴 수 있는가?

그 질문을 통과하는 도구와 예산만이 진정으로 삶을 앞으로 움직인다.