앞으로 강한 사람은 코딩을 잘하는 사람이 아니라, 자기 일을 도구로 바꾸는 사람이다

얼마 전 쓴 글에서 나는 이런 질문을 던졌다.

개발자는 사라지는가? 아니면 모든 직무가 조금씩 개발자가 되는가?

생각보다 이 질문에 반응이 좋았다. 아마 많은 사람이 비슷한 감각을 갖고 있기 때문일 것이다. AI 코딩 도구가 좋아질수록 개발자의 일만 바뀌는 것이 아니다. 기획자, 연구자, 컨설턴트, 교육 담당자, 재무 담당자, 마케터, 운영 담당자의 일도 조금씩 바뀐다.

그런데 여기서 오해하면 안 되는 지점이 있다.

모든 직무가 조금씩 개발자가 된다는 말은 모두가 개발자로 이직한다는 뜻이 아니다.

더 정확히 말하면 이렇다.

자기 일을 잘 아는 사람이, 자기 일의 일부를 작은 도구로 바꿀 수 있게 된다.

이 변화가 훨씬 중요하다.

코딩을 배운다는 말의 의미가 바뀐다

예전에는 “코딩을 배운다”는 말이 꽤 분명했다. 문법을 배우고, 자료구조를 배우고, 프레임워크를 배우고, 개발자로 취업하거나 개발 업무를 하는 것을 떠올렸다.

물론 이 의미는 여전히 중요하다. 깊은 시스템을 만들고, 안정적인 서비스를 운영하고, 보안과 성능을 책임지는 개발자의 역할은 쉽게 사라지지 않는다.

하지만 AI 코딩 에이전트가 들어오면 “코딩을 배운다”는 말 옆에 다른 의미가 생긴다.

• 내 업무에서 반복되는 일을 발견하는 능력
• 업무 규칙을 명확한 조건으로 설명하는 능력
• 예외 케이스를 테스트로 바꾸는 능력
• 산출물을 검증하는 기준을 세우는 능력
• 작은 자동화 도구를 만들고 고쳐 쓰는 능력

이건 전통적인 개발자 교육과 조금 다르다. 문법 중심이 아니라 업무 구조 중심이다.

앞으로 많은 사람에게 필요한 것은 “개발자가 되는 교육”이 아니라 “자기 일을 도구화하는 교육”에 가까울 수 있다.

강한 사람은 문제를 도구로 번역한다

AI 코딩 에이전트는 구현 장벽을 낮춘다. 예전에는 작은 스크립트 하나를 만들기 위해서도 개발자에게 요청하거나, 스스로 꽤 많은 문법을 배워야 했다. 이제는 자연어로 설명하고, AI가 초안을 만들고, 사용자가 결과를 검토하는 방식이 가능해졌다.

그런데 여기서 차이가 난다.

누군가는 이렇게 말한다.

엑셀 파일을 자동으로 정리해줘.

다른 누군가는 이렇게 말한다.

매주 들어오는 엑셀 파일에서 학과명 표기를 표준화하고, 중복 학생을 제거하고, 결측값이 있는 행은 예외 파일로 빼고, 전주 대비 신청자 수가 20% 이상 줄어든 학과를 표시해줘. 원본은 건드리지 말고, 예외 파일과 처리 로그도 남겨줘.

두 사람 모두 AI에게 일을 시켰다. 하지만 두 번째 사람은 자기 업무를 도구로 번역하고 있다. 무엇을 해야 하는지, 무엇을 건드리면 안 되는지, 어떤 예외를 따로 봐야 하는지, 결과를 어떻게 검증할지 알고 있다.

AI 시대에 강한 사람은 코드를 많이 외운 사람이 아닐 수 있다. 자기 일을 충분히 잘 알아서, 그 일을 AI가 실행 가능한 구조로 바꿀 수 있는 사람일 가능성이 크다.

도구화 가능한 업무에는 공통점이 있다

모든 일이 자동화되는 것은 아니다. 사람을 만나 설득하고, 복잡한 이해관계를 조정하고, 가치 판단을 내리는 일은 여전히 어렵다. 하지만 많은 업무에는 반복되는 구조가 있다.

도구화 가능한 업무는 대체로 이런 특징을 갖는다.

업무 특징	도구화 가능성
같은 형식의 파일이 반복해서 들어온다	높음
규칙은 있는데 사람이 매번 손으로 처리한다	높음
예외 케이스가 자주 생기지만 유형은 정해져 있다	높음
결과를 표, 리포트, 알림으로 정리해야 한다	높음
여러 시스템에서 데이터를 복사해 붙여넣는다	높음
판단 기준이 암묵적이고 매번 다르다	낮음, 먼저 기준화가 필요

여기서 중요한 것은 “자동화할 수 있는가”보다 “규칙을 설명할 수 있는가”다.

AI는 마법처럼 모든 일을 알아서 처리하지 않는다. 사용자가 업무의 구조를 설명해야 한다. 입력은 무엇인지, 출력은 무엇인지, 예외는 무엇인지, 실패하면 어떻게 알아차릴지 말해야 한다.

결국 자동화의 출발점은 기술이 아니라 업무 해석이다.

비개발 직무가 만들 수 있는 것들

이 변화는 추상적인 이야기가 아니다. 이미 많은 직무에서 작은 도구를 만들 수 있는 가능성이 생겼다.

직무	만들 수 있는 작은 도구
교육 담당자	학습 로그 분석, 과제 피드백 초안, 평가 루브릭 점검
컨설턴트	인터뷰 메모 분류, 보고서 목차 생성, 정책 키워드 매핑
재무 담당자	정산 오류 탐지, 예산 집행 현황 요약, 이상치 알림
HR 담당자	설문 응답 분류, 교육 수요 분석, 면담 기록 구조화
마케터	캠페인 성과 요약, 콘텐츠 반응 비교, 고객 피드백 클러스터링
연구자	데이터 전처리, 문헌 분류, 실험 로그 정리
운영 담당자	반복 체크리스트 자동화, 상태 알림, 문서 업데이트 점검

이 도구들은 처음부터 거창할 필요가 없다. 오히려 작을수록 좋다. 한 사람의 반복 업무를 30분 줄이는 스크립트, 매주 확인하던 표를 자동으로 정리하는 도구, 놓치기 쉬운 예외를 알려주는 체크 정도면 충분하다.

중요한 것은 그 작은 도구가 업무 담당자의 머릿속에 있던 규칙을 밖으로 꺼낸다는 점이다. 암묵지가 도구가 되는 순간, 개인의 요령은 팀의 자산이 된다.

개발자는 없어지는 것이 아니라 더 중요해질 수 있다

여기서 “그러면 개발자는 필요 없어지는가?”라는 질문이 다시 나온다.

나는 반대에 가깝다고 본다. 개발자는 사라지기보다 더 중요한 층위로 올라갈 가능성이 크다.

비개발 직무가 작은 도구를 많이 만들기 시작하면 조직에는 새로운 문제가 생긴다.

• 누가 이 도구들을 관리할 것인가?
• 보안과 개인정보는 어떻게 지킬 것인가?
• 업무용 데이터가 외부로 나가지 않게 하려면 어떻게 해야 하는가?
• 각자가 만든 자동화가 서로 충돌하면 어떻게 할 것인가?
• 임시 스크립트가 핵심 업무 인프라가 되었을 때 누가 책임질 것인가?

이 질문은 전형적인 개발자·엔지니어링 질문이다.

그래서 개발자의 역할은 단순 구현에서 끝나지 않는다. 오히려 조직 안에서 AI로 만들어지는 수많은 작은 도구의 품질, 보안, 유지보수, 공통 구조를 설계하는 쪽으로 중요해질 수 있다.

비개발 직무가 도구를 만들수록, 좋은 개발자는 더 필요하다. 단지 역할이 “요청받은 기능을 대신 만들어주는 사람”에서 “조직 전체의 도구화가 안전하게 굴러가도록 구조를 잡는 사람”으로 바뀔 뿐이다.

문제는 프롬프트가 아니라 검증이다

많은 AI 교육이 프롬프트 작성법으로 시작한다. 물론 프롬프트는 중요하다. 하지만 실무에서는 프롬프트보다 더 중요한 것이 있다.

바로 검증이다.

AI가 만든 도구가 정말 맞게 작동하는지 확인할 수 있어야 한다. 특히 업무 도구는 그럴듯하게 돌아가는 것만으로는 부족하다.

• 원본 데이터는 보존되는가?
• 누락된 행은 없는가?
• 예외 케이스가 별도로 표시되는가?
• 결과 수치가 기존 방식과 맞는가?
• 틀렸을 때 어디서 틀렸는지 알 수 있는가?
• 다른 사람이 같은 방식으로 다시 실행할 수 있는가?

이 질문 없이 만든 자동화는 위험하다. 업무를 빠르게 하는 것이 아니라, 틀린 결과를 더 빠르게 퍼뜨릴 수 있기 때문이다.

그래서 AI 시대의 실무 역량은 “AI에게 시키는 능력”과 “AI가 만든 것을 믿어도 되는지 확인하는 능력”이 함께 가야 한다.

조직은 시민개발자를 그냥 방치하면 안 된다

앞으로 많은 조직에서 시민개발자라는 말이 다시 중요해질 것이다. 현업 담당자가 직접 앱, 스크립트, 자동화, 리포트를 만드는 흐름이다.

하지만 시민개발은 그냥 “각자 알아서 만들어라”가 아니다. 그렇게 두면 그림자 IT가 늘어난다. 누가 만든지도 모르는 자동화가 핵심 업무를 처리하고, 담당자가 떠나면 아무도 고칠 수 없는 파일이 남는다.

조직이 준비해야 할 것은 세 가지다.

첫째, 작은 도구를 만들 수 있는 안전한 환경이다. 데이터 접근 권한, 샌드박스, 승인 절차, 로그, 백업이 필요하다.

둘째, 현업과 개발자의 협업 구조다. 현업은 문제와 규칙을 알고, 개발자는 안정성과 확장성을 안다. 둘이 분리되면 도구는 빨리 만들어져도 오래가지 못한다.

셋째, 검증 문화다. AI가 만들었다고 해서 바로 쓰는 것이 아니라, 테스트 데이터, 샘플 검토, 예외 케이스 확인, 롤백 경로를 갖춰야 한다.

이것이 없으면 AI 코딩은 생산성 혁신이 아니라 관리되지 않는 자동화의 폭증이 된다.

교육도 바뀌어야 한다

이 변화는 교육에도 꽤 큰 질문을 던진다.

코딩 교육을 계속 문법 중심으로만 할 것인가? 아니면 각자의 전공과 직무 문제를 도구로 바꾸는 교육으로 확장할 것인가?

앞으로 필요한 수업은 이런 형태에 가까울 수 있다.

• 내 업무에서 반복되는 데이터 흐름 찾기
• 업무 규칙을 조건문과 체크리스트로 바꾸기
• AI에게 작업을 맡길 수 있는 명세서 쓰기
• 결과를 검증하는 테스트 케이스 만들기
• 작은 도구를 만들고 동료에게 설명하기
• 실패했을 때 원인을 추적하고 수정 요청하기

이건 컴퓨터공학 전공자만의 교육이 아니다. 경영, 교육, 행정, 보건, 디자인, 연구, 컨설팅 모두에게 필요한 새로운 AI 리터러시에 가깝다.

내 결론

앞으로 강한 사람은 반드시 코딩을 가장 잘하는 사람이 아닐 수 있다.

물론 깊은 개발 역량은 계속 중요하다. 복잡한 시스템을 만들고 운영하려면 여전히 전문 개발자가 필요하다. 하지만 더 넓은 실무 세계에서는 다른 종류의 강자가 등장할 것이다.

자기 일을 잘 아는 사람.
반복되는 구조를 발견하는 사람.
업무 규칙을 명확히 설명하는 사람.
AI가 만든 결과를 검증할 수 있는 사람.
그리고 자기 일을 작은 도구로 바꿀 수 있는 사람.

이 사람이 AI 코딩 시대의 새로운 생산자가 된다.

그래서 나는 “모든 직무가 조금씩 개발자가 된다”는 말을 이렇게 바꿔 말하고 싶다.

모든 직무가 조금씩 자기 일을 소프트웨어로 표현하게 된다.

개발자는 사라지지 않는다. 다만 개발이라는 행위는 더 많은 직무로 퍼진다. 그리고 그 시대의 경쟁력은 코드를 외우는 능력보다, 자기 일을 도구로 바꾸는 능력에서 갈릴 가능성이 크다.