AI가 15년 묵은 프린터를 살려냈을 때, 개발자는 무엇을 해야 하나

서랍 속 프린터가 말을 걸어왔습니다

저도 창고에 그런 물건이 하나 있습니다. 10년도 더 전에 큰맘 먹고 장만한 전문가용 필름 스캐너입니다. 최신 운영체제를 설치한 어느 날부터 먹통이 됐습니다. 제조사 홈페이지에 들어가 보니 ‘지원 종료’라는 네 글자만 덩그러니 떠 있었습니다. 멀쩡한 기계가 소프트웨어 지원이 끊겼다는 이유만으로 값비싼 고철이 되는 순간이었습니다. 아마 많은 분들이 비슷한 경험을 해보셨을 겁니다. 구형 프린터, 웹캠, 혹은 아버지가 아끼시던 오디오 인터페이스 같은 것들 말입니다.

그런데 최근 이 고질적인 문제를 인공지능(AI)이 해결하는 놀라운 사건이 벌어졌습니다. 한 개발자가 더는 쓸 수 없게 된 구형 HP 레이저 프린터(LaserJet 1008a)를 새 컴퓨터(macOS)에서 쓰고 싶다고 AI에게 하소연한 것이 시작이었습니다. 그냥 푸념만 한 게 아닙니다. 그는 AI 모델 ‘클로드(Claude)’에게 프린터의 기술 설명서와, macOS의 인쇄 시스템(CUPS) 작동 방식에 대한 문서를 함께 던져줬습니다.

결과는 놀라웠습니다. 몇 시간 뒤, 클로드는 실제로 작동하는 프린터 드라이버 코드를 완성해 냈습니다. 드라이버란 하드웨어와 운영체제라는, 서로 다른 언어를 쓰는 두 세계를 연결해주는 통역사 같은 프로그램입니다. 보통은 하드웨어 제조사 소속의 전문 엔지니어들만 만들 수 있는 복잡한 소프트웨어입니다. 그런데 AI가, 그것도 단종된 지 오래된 제품의 드라이버를 ‘창조’해낸 것입니다. 서랍 속 고철이던 프린터가 다시 인쇄를 시작했습니다. AI가 죽은 기계에 새 생명을 불어넣은 셈입니다.

이 사건은 단순히 ‘AI 코딩 실력이 늘었네’ 하고 넘어갈 일이 아닙니다. 웹사이트 꾸미는 코드나 데이터 정리하는 파이썬 스크립트 수준이 아닙니다. 하드웨어의 속살과 운영체제의 뼈대를 직접 만지는 시스템 프로그래밍의 영역에 AI가 성공적으로 발을 들였다는 신호탄이기 때문입니다. 이는 소프트웨어 개발이라는 일의 본질, 그리고 개발자의 가치가 어디에서 비롯되는지에 대한 근본적인 질문을 우리에게 던지고 있습니다.

AI는 어떻게 '드라이버'라는 벽을 넘었나

대체 AI는 어떻게 이런 복잡한 일을 해낼 수 있었을까요? 마법처럼 보이지만, 작동 원리를 찬찬히 뜯어보면 의외로 간단한 그림이 그려집니다.

먼저 ‘드라이버’가 뭔지부터 비유를 들어보겠습니다. 여러분이 프랑스 식당에 갔는데 주방장은 프랑스어만 할 줄 알고, 여러분은 한국어만 할 줄 안다고 상상해 보십시오. 아무리 “스테이크 미디엄 레어로 주세요”라고 외쳐봐야 주방장은 어깨만 으쓱할 뿐입니다. 이때 양쪽 언어를 모두 할 줄 아는 통역사가 나타나 “Le chef, un steak, cuisson à point, s'il vous plaît”라고 대신 전달해준다면 어떨까요? 그제야 맛있는 스테이크를 먹을 수 있을 겁니다. 여기서 통역사가 바로 ‘드라이버’입니다. 프린터라는 하드웨어(주방장)와 컴퓨터 운영체제(손님) 사이에서 양쪽이 알아들을 수 있는 언어로 명령을 번역하고 전달하는 역할입니다. 당연히 양쪽의 ‘문법’과 ‘어휘’를 모두 완벽하게 알아야 하니, 아무나 만들 수 없었습니다.

이번 사건에서 개발자는 AI에게 바로 이 ‘문법책’ 두 권을 던져준 셈입니다. 하나는 ‘프린터 사용 설명서(HP 1008a 기술 문서)’이고, 다른 하나는 ‘손님의 요구사항 전달법(macOS 인쇄 시스템 아키텍처)’입니다. 그리고 AI에게 “이 두 문법책을 보고 둘 사이를 통역하는 프로그램을 만들어줘”라고 요청한 것입니다.

여기서 클로드 같은 ‘대규모 언어 모델(LLM, Large Language Model)’의 진가가 드러납니다. LLM은 쉽게 말해, 수십억 개의 문장을 읽고 그 안의 패턴을 학습해 사람처럼 말을 만들어내는 AI입니다. 여기서 중요한 것은 AI에게 프로그래밍 코드 역시 하나의 ‘언어’로 보인다는 점입니다. 영어, 한국어와 마찬가지로 C언어, 자바(Java) 같은 프로그래밍 언어도 저마다의 문법과 맥락을 가진 텍스트 덩어리일 뿐입니다. 클로드는 개발자가 준 두 개의 기술 문서를 읽고, 그 문서에 담긴 논리적 관계와 패턴을 파악했습니다. 그리고 그 관계를 코드로 번역해 ‘통역 프로그램’, 즉 드라이버를 써낸 것입니다.

이 과정은 AI가 단순히 외운 것을 뱉어내는 게 아님을 보여줍니다. 주어진 기술 명세를 이해하고, 그것을 목표 시스템의 요구사항에 맞춰 새로운 코드로 ‘조합’하고 ‘생성’하는 능력을 갖췄다는 의미입니다. 마치 두 개의 서로 다른 레시피를 보고 완전히 새로운 퓨전 요리를 만들어내는 것과 같습니다.

데자뷔: 4세대 언어와 CASE 도구의 추억

사실 ‘코딩 없는 개발’이나 ‘자동 코드 생성’이라는 구호는 이번이 처음이 아닙니다. IT 업계에 오래 몸담은 분들이라면 지금의 상황이 어딘가 익숙하게 느껴질 겁니다. 저 역시 20여 년 전 비슷한 구호들을 들으며 이 업계에 발을 들였습니다.

1980년대에는 ‘4세대 언어(4GL)’라는 것이 유행했습니다. 사람이 쓰는 말과 비슷한 명령어로 데이터베이스를 관리하고 보고서를 만드는 도구였습니다. “모든 직원의 목록을 이름순으로 보여줘” 같은 식으로 말입니다. 당시 사람들은 이제 복잡한 코볼(COBOL)이나 포트란(FORTRAN) 같은 프로그래밍 언어는 사라지고, 경영진이 직접 필요한 프로그램을 만들 수 있을 거라 기대했습니다. 결과는 어땠을까요? 4세대 언어는 정해진 용도, 특히 데이터베이스 조회 같은 특정 작업에서는 빛을 발했지만, 조금만 복잡한 비즈니스 논리가 들어가면 금세 한계에 부딪혔습니다. 결국 프로그래머를 대체하지 못하고, 그들의 생산성을 높여주는 여러 도구 중 하나로 남았습니다.

1990년대에는 ‘CASE(Computer-Aided Software Engineering) 도구’가 그 자리를 이어받았습니다. 화면에 네모, 동그라미 같은 도형으로 시스템 설계도를 그리면, 컴퓨터가 알아서 코드를 ‘짠!’ 하고 만들어준다는 개념이었습니다. 마치 조감도를 넣으면 실제 아파트가 지어져 나오는 마법 같았습니다. 하지만 CASE 도구가 생성한 코드는 종종 비효율적이었고, 사람이 직접 수정하기가 거의 불가능한 ‘블랙박스’에 가까웠습니다. 결국 이 역시 프로그래머를 대체하기는커녕, 비싸고 다루기 힘든 애물단지로 전락한 경우가 많았습니다.

그렇다면 지금의 AI 코딩 도우미는 과거의 실패를 반복할까요? 저는 다르다고 봅니다. 결정적인 차이가 있습니다.

과거의 도구들은 ‘규칙 기반’이었습니다. 정해진 틀 안에서만 작동했고, 그 틀을 벗어나는 창의적인 문제 해결은 불가능했습니다. 반면 지금의 LLM은 ‘생성 기반’입니다. 방대한 데이터를 학습한 뒤, 그럴듯한 패턴을 확률적으로 만들어냅니다. 그래서 프린터 드라이버처럼 한 번도 본 적 없는 새로운 문제에 대해서도 나름의 해결책을 시도해볼 수 있는 것입니다. 또한 AI가 만든 코드는 개발자가 읽고, 이해하고, 고칠 수 있는 일반적인 코드입니다. 이 점이 결정적으로 다릅니다.

AI 코딩, 무엇을 할 수 있고 무엇은 못 하나

저도 요즘 코딩할 때 AI를 옆에 끼고 삽니다. 깃헙 코파일럿(GitHub Copilot)이라는 서비스인데, 월 10달러 정도를 내면 똑똑한 신입 개발자 한 명을 옆에 둔 것처럼 일할 수 있습니다. 며칠간 집중적으로 써보니 AI가 무엇을 잘하고, 무엇은 끝내 못 하는지가 명확하게 보였습니다.

AI가 정말 잘하는 일은 다음과 같습니다.

• 상용구 코드(Boilerplate) 작성: 프로젝트 초기 설정, 파일 읽고 쓰기, 네트워크 연결 등 어떤 프로그램을 만들든 거의 항상 들어가는 반복적인 코드들이 있습니다. 예전에는 이런 코드를 짜느라 한두 시간을 썼다면, 이제는 AI에게 “기본적인 웹서버 코드 만들어줘”라고 한마디 하면 10초 만에 뼈대가 완성됩니다. 단순 노동에서 해방되는 것입니다.
• 낯선 기술 사용법 학습: 새로운 프로그래밍 언어나 라이브러리(미리 만들어진 코드 부품 모음)를 쓸 때, 예전엔 두꺼운 책이나 수십 개의 웹페이지를 뒤져야 했습니다. 이제는 AI에게 “이 라이브러리로 차트 그리는 예제 코드 보여줘”라고 물어보면 됩니다. 프린터 드라이버 사례는 이 능력이 극단적으로 발휘된 경우입니다. AI가 나 대신 ‘메뉴얼’을 읽고 요약해주는 셈입니다.
• 막혔을 때 실마리 제공: 아무리 해도 풀리지 않는 버그나 복잡한 알고리즘 앞에서 머리를 쥐어뜯을 때가 있습니다. 이때 AI에게 문제 상황을 설명하면 완벽한 정답은 아닐지라도 제가 미처 생각지 못한 해결 방향 서너 개를 던져줍니다. 24시간 대기하는 지치지 않는 사수(선배 개발자)가 생긴 것과 같습니다.

반면, AI가 아직, 그리고 아마도 꽤 오랫동안 못 할 일은 더 중요합니다.

• ‘무엇을’ 만들지 결정하는 일: AI는 주어진 문제를 푸는 데 능하지만, ‘어떤 문제를 풀어야 하는지’는 알려주지 못합니다. 우리 회사에 지금 필요한 제품이 무엇인지, 사용자들이 정말로 원하는 기능이 무엇인지, 이 프로젝트가 사업적으로 어떤 가치가 있는지를 판단하는 것은 온전히 사람의 몫입니다.
• 시스템 전체의 큰 그림 설계: AI는 개별 부품(프린터 드라이버)을 만드는 데 도움을 줄 수 있지만, 그 부품들이 모여 이룰 ‘하나의 거대한 제품(운영체제)’ 전체를 설계하지는 못합니다. 각 부품들이 서로 어떻게 맞물려야 하는지, 10년 뒤에도 확장이 가능한 구조는 무엇인지 고민하는 ‘아키텍트’의 역할은 대체할 수 없습니다.
• 미묘한 맥락과 숨은 요구사항 파악: “사장님 지시인데, 이 버튼 좀 ‘있어 보이게’ 바꿔주세요.” 같은 요구사항을 AI는 이해하지 못합니다. 사용자가 말로는 표현하지 않지만 느끼는 불편함, 비즈니스의 복잡한 이해관계, 팀원들 간의 정치적 역학 같은 비정형적이고 감성적인 맥락을 읽어내는 능력은 여전히 인간 고유의 영역입니다.

여기서 흔한 오해 두 가지를 짚고 넘어가야 합니다. 첫째, ‘AI가 코드를 짜주니 개발자는 복사/붙여넣기만 하면 된다’는 생각입니다. 천만의 말씀입니다. AI가 뱉어낸 코드는 그럴듯해 보이지만 종종 미세한 오류나 심각한 보안 취약점을 포함하고 있습니다. 심지어 ‘환각(Hallucination)’ 현상으로 세상에 존재하지도 않는 함수를 만들어내기도 합니다. 그 코드를 검증하고, 테스트하고, 최종적으로 책임지는 것은 결국 사람 개발자입니다. AI가 써준 코드를 검토 없이 사용하는 것은, 인터넷에서 찾은 출처 불명의 글을 그대로 내 논문에 인용하는 것만큼이나 위험한 일입니다.

둘째, ‘이제 코딩 교육은 필요 없다’는 주장입니다. 오히려 정반대입니다. AI가 써준 코드가 좋은지 나쁜지, 효율적인지 아닌지, 안전한지 위험한지를 판단하려면 코드의 원리를 더 깊이 이해해야 합니다. 예전에는 자동차를 ‘운전할 줄 아는 능력’이 중요했다면, 이제는 차의 내부 구조와 메커니즘을 이해해 어떤 차가 좋은 차인지 ‘알아볼 줄 아는 안목’이 더 중요해진 것과 같습니다. 코드를 쓸 줄 아는 능력을 넘어, 좋은 코드를 감별하는 능력이 개발자의 새로운 핵심 역량이 될 것입니다.

개발자의 몸값, '판단의 가치'로 재편된다

결론은 이것입니다. 개발이라는 일의 무게중심이 ‘코드 작성(Writing)’에서 ‘코드 판단(Judging)’으로 옮겨가고 있습니다.

유명 레스토랑의 주방장을 생각해보면 쉽습니다. 과거에는 얼마나 빠르고 정교하게 칼질을 하느냐가 요리사의 중요한 실력이었습니다. 하지만 지금은 버튼만 누르면 어떤 재료든 순식간에 다져주는 푸드 프로세서가 있습니다. 그렇다고 주방장이란 직업이 사라졌나요? 아닙니다. 오히려 세계적인 셰프의 몸값은 더 올랐습니다. 그들의 가치는 이제 칼질 자체가 아니라, ‘어떤 제철 재료를 고를지’, ‘어떤 향신료와 조합할지’, ‘어떤 순서로 얼마만큼의 열을 가할지’를 결정하는 ‘판단력’에서 나옵니다.

프로그래머의 세계도 똑같이 재편될 겁니다. AI 덕분에 코드 한 줄을 ‘생산’하는 데 드는 비용과 시간은 거의 0에 가까워지고 있습니다. 그렇다면 가치는 어디에서 나올까요? 바로 코드가 작성되기 전과 후의 ‘판단’에서 나옵니다.

• 이 문제를 푸는 것이 우리 사업에 정말 중요한가? (사업적 판단)
• 이 문제를 풀기 위해 AI가 제안한 5가지 기술적 접근법 중, 어떤 것이 가장 효율적이고 안정적인가? (기술적 판단)
• AI가 생성한 이 코드는 당장은 잘 돌아가지만, 5년 뒤 유지보수하기에 적합한 구조인가? (구조적 판단)
• 이 코드가 포함할지 모를 잠재적 보안 위협은 무엇이며, 어떻게 막을 것인가? (보안적 판단)

이런 질문에 답하는 능력, 즉 ‘판단의 값’이 앞으로 개발자의 몸값을 결정할 겁니다. 단순히 지시받은 내용을 코드로 옮기는 주니어 개발자나 코더의 입지는 점점 좁아질 수 있습니다. 반면, 복잡한 문제의 본질을 꿰뚫고, 최적의 기술적 방향을 결정하며, AI라는 강력한 도구를 능숙하게 활용해 팀 전체의 생산성을 끌어올리는 시니어 개발자나 아키텍트의 가치는 폭발적으로 증가할 것입니다.

우리가 추적해야 할 신호들

이 거대한 변화의 흐름 속에서, 우리는 어떤 신호들을 눈여겨봐야 할까요? 몇 가지 구체적인 지표를 제시합니다.

1. AI 모델의 ‘추론 비용’ 변화: ‘추론(Inference)’이란 AI에게 질문 한 번 하고 답을 얻을 때까지 드는 비용입니다. 쉽게 말해 AI 두뇌를 한 번 굴릴 때마다 내는 전기세와 서버 비용 같은 겁니다. 현재는 이 비용이 꽤 비싸서, 챗GPT 같은 서비스도 유료 모델을 운영합니다. 만약 이 추론 비용이 극적으로 하락해, 택시 기본요금이 버스 요금 수준으로 떨어진다면 어떻게 될까요? 코딩뿐만 아니라 모든 지식 노동의 영역에서 AI 도우미가 지금의 인터넷 검색처럼 보편화될 것이고, 그 파급력은 상상을 초월할 겁니다.

1. ‘자율 에이전트’의 실용성: 지금의 AI는 우리가 명령을 내려야 움직이는 ‘도구’에 가깝습니다. 프린터 드라이버 사례도 개발자가 명확한 지시와 자료를 줬기에 가능했습니다. 하지만 최근에는 ‘자율 에이전트(Autonomous Agent)’라는 개념이 주목받고 있습니다. “쇼핑몰 사이트 하나 만들어줘”처럼 높은 수준의 목표만 던져주면, AI가 스스로 계획을 세우고, 코딩하고, 테스트하고, 결과물을 내놓는 방식입니다. 최근 화제가 된 ‘데빈(Devin)’ 같은 프로젝트가 초기 형태입니다. 아직은 걸음마 단계지만, 이 에이전트들이 얼마나 안정적이고 실용적인 결과물을 내놓기 시작하는지를 지켜봐야 합니다. 인간의 ‘지시’ 없이도 ‘목표’를 달성하는 AI가 등장하는 순간, 게임의 규칙이 또 한 번 바뀔 겁니다.

1. 기업의 ‘기술 부채’ 처리 방식: ‘기술 부채(Technical Debt)’란 기업들이 오랫동안 운영해 온 낡고 복잡한 소프트웨어 시스템을 말합니다. 당장 바꾸기엔 너무 거대하고 위험해서 내버려 두지만, 이자처럼 계속해서 문제를 일으키고 발목을 잡는 골칫덩어리입니다. 만약 여러 기업들이 이번 프린터 드라이버 사례처럼 AI를 활용해 낡은 시스템을 성공적으로 현대화하기 시작했다는 소식이 들려온다면, 이는 AI가 연구실을 나와 산업 현장의 진짜 문제를 해결하는 핵심 동력으로 자리 잡았다는 가장 확실한 신호일 겁니다.

그래서, 제 밥그릇은 괜찮을까요?

이 글을 읽는 많은 개발자, 혹은 개발자를 꿈꾸는 분들이 결국 이 질문을 던질 겁니다. “그래서 제 밥그릇은 괜찮을까요?”

결론부터 말하자면, ‘AI가 당신의 일자리를 빼앗지는 않을 겁니다. 하지만 AI를 쓰는 다른 개발자가 당신의 일자리를 빼앗을 수는 있습니다.’ 단종된 프린터를 살려낸 AI의 이야기는 프로그래머 시대의 종말을 알리는 부고장이 아닙니다. 오히려 새로운 경주의 시작을 알리는 출발 신호탄에 가깝습니다.

그 경주는 누가 더 코드를 빨리, 많이 짜느냐의 경쟁이 아닙니다. 누가 더 나은 ‘판단’을 내리고, 더 깊이 있는 ‘질문’을 던지며, AI라는 강력한 신입사원을 더 잘 ‘부리는’ 관리자가 되느냐의 경쟁입니다. 지루하고 반복적인 잡일은 AI에게 맡기십시오. 그리고 남는 시간에 우리는 더 본질적인 일에 집중해야 합니다. 사용자의 진짜 문제를 해결하는 창의성, 더 나은 시스템 구조를 향한 고민, 그리고 기술로 세상을 어떻게 이롭게 할 것인가에 대한 철학 같은 것들 말입니다.

결국 AI는 질문에 답하는 기계입니다. 어떤 질문을 던질지 결정하는 것은 여전히, 그리고 앞으로도 훨씬 더 중요하게, 사람의 몫으로 남을 겁니다. 이제 우리에게 필요한 것은 코딩 실력 위에 ‘질문하는 능력’과 ‘판단하는 안목’을 쌓아 올리는 일입니다.

Q. AI가 만든 코드, 저작권은 누구에게 있나요? A. 아직 법적으로 매우 복잡한 회색 지대입니다. 현재로서는 AI 모델을 훈련시킨 데이터의 저작권, AI 서비스를 제공하는 회사의 약관, 그리고 AI를 사용해 결과물을 만든 사용자의 기여도를 모두 따져봐야 합니다. 예를 들어 깃헙 코파일럿의 경우, 생성된 코드의 저작권은 기본적으로 사용자에게 있다고 명시하지만, 만약 AI가 학습 데이터에 있던 특정 코드를 그대로 뱉어냈을 경우 원저작자의 권리를 침해할 소지가 있습니다. 당분간은 판례가 쌓이기를 기다려야 하는, 법조계에서도 가장 뜨거운 주제 중 하나입니다.

Q. 비전공자도 이제 AI로 쉽게 앱을 만들 수 있게 되나요? A. 간단한 개인 홈페이지나 데이터 처리 자동화 스크립트 정도는 확실히 이전보다 훨씬 쉬워질 겁니다. 하지만 우리가 매일 쓰는 ‘카카오톡’이나 ‘배달의민족’ 같은 복잡한 상용 서비스를 만드는 것은 완전히 다른 차원의 문제입니다. 집 짓기에 비유하자면, AI 덕분에 조립식 창고를 혼자 짓는 건 가능해져도, 여의도 IFC몰 같은 대형 복합 건물을 설계하고 시공하는 것은 여전히 수많은 전문가의 협업과 깊은 공학적 지식이 필요한 것과 같습니다. ‘아이디어’를 ‘제품’으로 만드는 과정의 간극은 여전히 큽니다.

Q. AI가 쓴 코드의 보안 문제는 어떻게 해결하나요? A. 단도직입적으로 말해, AI가 해결해주지 않습니다. 사람이 직접 검증하고 책임져야 합니다. AI는 보안 규칙을 학습해서 ‘안전한 것처럼 보이는’ 코드를 생성할 수는 있지만, 그 결과에 대해 책임지지는 않습니다. 오히려 최근에는 AI를 이용해 코드의 잠재적 취약점을 자동으로 찾아내는 또 다른 AI가 개발되는 등, 창과 방패의 싸움이 AI의 영역으로 확장되는 모양새입니다. 이 싸움의 최종 승패를 가르는 것 역시 인간 보안 전문가의 마지막 ‘판단’이 될 것입니다.