일자리를 뺏는 AI를 개발자는 싫어할까?
생존형 개발자의 생각 #141
개발자들이 최근 듣는 말 중에 “AI 때문에 힘들지 않아요? 일자리가 줄어들잖아요?”라는 것이 있다. 아마도 대부분의 경력직 개발자들은
“왜? ”라는 생각을 한다
AI 때문에 이전에는 혼자하기 힘들었던 것을 AI로 할 수 있는 시대가 왔기 때문이다. 그 만큼 일의 범위와 가치가 상승되었기 때문이다.
그리고 일자리가 줄어드는 것은 AI가 개발자를 대처하는 것이 아니라 시장이 줄어들기 때문이다. 유동성 없는 세상은 신규개발보다 유지보수조차 최소화하고 허리띠를 졸라매고 있기 때문이다.
참고로 대부분의 개발자들은 AI의 탄생에 환영하고 있다. 또다른 장난감이 세상에 나타난 것이고 그것을 통해 내가 뭘할 수 있을까?라는 기대감을 가지는 것이 개발자 본능이다.
1. 생성 AI로 개발자 위기 검증하기
생성 AI로 프롬프트를 만들 때는 유의해야 하는 것이 있다. 바로 생성 AI라는 점이다. 생성 AI는 대화를 하는 도구가 아니다. 생성을 하는 도구이다. 쉽게 말해, 서로 생각을 공유하며 정반합을 만들거나 감정을 향유하는 곳에 쓰는 도구가 아니라 “명령을 통해 결과”를 만들기 위한 도구이다(개인적으로 AI를 감정의 도구로 사용하는 것을 매우 위험한 행위로 여긴다. 마치 1980년대 몰지각한 청소년들이 공업용 돼지표 본드를 환각제로 사용한 것처럼 위험하다).
https://biz.chosun.com/topics/topics_social/2026/01/29/UHDHIIBESZAKLPYI66FH3O44YI/
그런 점에서 “내가 질문하는 프롬프트의 결과는 나의 의도에 맞추어 결과가 나온다”를 명심해야 한다. 즉, 어떤 현상에 대한 평가를 질의하면 질문자의 의도에 맞추어 결과를 만든다. 이런 현상을 누군가는 아부라고 표현하고 누군가는 할루시네이션이라고 하는데 무엇으로 부르던 간에 질문자의 “프롬프트”는 AI에게는 명령일 뿐이다.
결과적으로 내가 던진 프롬프트의 결과가 “올바른 지식”이라기 보다는 “내가 원하는 결과”를 만들 확률이 높아진다. 그래서 어떤 현상에 대한 다각화된 결과를 보고 싶다면 “장단점 또는 반론”에 대한 프롬프트가 들어가야 좀 더 객관적인 결과를 얻을 수 있다. 특히 레퍼런스 체크에 대한 프롬프트도 검증에 도움이 된다.
2. 개발자 위기에 대한 프롬프트 정리
프롬프트 1.
AI의 발전으로 개발자가 줄어든다는 이야기가 있다. 그런데 잘 보면 개발자가 줄어든 것이 아니라 신입이 줄어들었다. 그리고 개발자의 구인구직이 사라진 이유는 IT의 개발 프로젝트가 줄어들기 때문이라는 견해도 있다. 이에 대한 의견을 쉽게 표로 정리해줘
위의 내용을 요약한 것은 다음과 같다.
개발자가 줄어든다 X
├─ 신입이 줄었다 O (진입용 업무 소멸)
├─ 프로젝트가 줄었다 O (IT 투자 감소)
└─ 역할이 바뀌었다 O (코딩 → 설계·판단)
위에서도 언급했지만 “프롬프트 작성자의 의도”에 맞게 결과가 나오는 현상이 정상이다. 그러므로 작성자의 의도에 근거에 대한 레퍼런스 채크를 다음과 같이 해야 한다.
프롬프트 2.
이에 대한 근거를 검색해서 링크와 타이틀 내용을 표로 정리해줘
결과적으로 산업계나 학계에서 평가하는 것은 “신입의 종말”이다. 그리고 개발자 업무의 변화가 기인한 점도 있다. 결과적으로 중견에 속하는 현업은 더 많이 필요해지고 신입의 자리에 AI가 들어갔다고 생각해도 무방하다.
여기서 문제가 발생한다.
개인적으로 AI와 산업에 대해서 업계사람들과 이야기 할 때마다 목소리 높여 말하는 부분인데 “신입의 종말”은 업계의 종말과 같은 말이기 때문이다. 그래서 다음과 같은 프롬프트를 했다.
프롬프트 3.
이러한 추세는 몇 년안에 산업안전에 위험한 순간이 온다는 것일 수도 있다. 논리는 다음과 같다. 신입이 없는 기간이 장기화된다. 종사자의 숫자가 줄어든다. 경력자가 은퇴하는 시기에 종사자는 더 줄어든다. 그 시기에 업종 전반의 업무가 마비되는 현상이 발생할 수도 있다고 판단된다. 이러한 개인의견에 대한 검증을 표로 만들어줘
일단 의견이므로 검증표에 대한 프롬프트를 던지는 것이 현명하다. 그렇게 해야만 과도한 논리비약을 피할 수 있기 때문이다. 결과적으로 가장 핵심적인 포인트인 산업안전사고와 유지보수 공백은 확실시 문제가 되고 있다. “신입이 없는 산업”에서 유지보수가 가능하다고 믿는 사람은 “일을 해본 사람”이 아니다.
아무리 공장자동화가 수십년간 이루어졌다고 한 들, 사람이 유지보수하고 안전채크를 하지 않으면 반드시 오류가 발생하기 때문이다. 결국 사람에 해당하는 신입은 꾸준히 유입되어야 산업이 발전할 수 있다.
사람들은 기계가 영원하다고 믿는 습성이 있다.
그러나
기계도 노후가 된다.
그리고 위험한 순간이 온다.
그 때 사람이 필요하게 된다.
이런 말에 관심없는 사람들은 대부분 기획자나 마케터다. 누군가에게 자신의 생각을 동의시키거나 판매가 업의 목적인 사람들이기 때문이다. 유지보수와 보안 또는 안정성은 그들의 몫이 아니기 때문이기도 하다.
3. Opal로 정리하기
위의 내용은 개발자나 기술이해도가 높은 기획자에게 친숙한 포멧이다. 그렇다보니 이런 글들을 쓰다보면 내 자신조차도 만족스럽지 못할 때가 많다. 쉽게 쓰려고 해도 업의 특성상 분명 한계가 있다. 사고방식과 문장력의 한계는 어느업종이나 존재한다.
이럴 때! 구글신께서 민중을 위해 최근 배포하신 툴인 Opal을 사용하면 고민이 해결될 수 있다. Opal을 통해 전자파와 PC 먼지타는 냄새가득한 아스트랄한 문장들을 인간의 언어로 쉽게 재작성이 가능하다. 심지어 “비주얼한 랜딩페이지 형식”으로 만들 수도 있다.
Opal로 랜딩페이지를 만든 과정은 다음 링크를 참고하면 된다.
위의 내용을 gemini opal로 재가공한 홈페이지(랜딩페이지)는 다음과 같다.
깔끔하고 이해하기 쉬운 맥락으로 최소한의 전문용어를 써가며 문서를 작성해주었다.
개인적으로 Opal을 만난 순간, “드디어 때가 왔다”라는 생각을 했다. 구글님의 은총이 세상에 널리퍼지며 민중들이 구글님을 섬기는 속도가 빨라짐을 느끼게 되었다. Opal 말고도 NotebookLM도 강력하다. 기술적 맥락을 설명해야 하는 어려운 문제에 봉착 시, 나 대신 닝겐들에게 이해하기 쉽도록 핵심을 정리한 문서를 만들어주기 때문이다. 이런 이유로 개발자들은 AI에 대해 타 업종사람들보다 만족도가 심하게 높다.
4. 30년차 개발자 동료와 최근 만난 썰
최근 30년동안 개발자로 살고있는 지인을 만났다. 둘 다 50의 중반이 되었지만 게임에 대해서는 10대의 진심을 가졌기에 게임에 대한 열정을 잃지말라고 독려한다. 개인적으로 수년간 하는 일마다 내리막 길을 경험하다보니 게임에 대한 투자를 할 수 없었다. 고작 Steam 게임 200여개 정도만 구매했을 뿐이다. 그렇다보니 그 흔한 스위치도 보유하지 못했었다. 그런 모습을 보며 안스럽게 생각했는 지 자신의 스위치를 무상으로 증정했다.
젤다의 전설 “야생의 숨결”을 해보라는 이유에서였다.
게임을 받고 차를 마시면서 지난 30년간 이야기를 했다. 생각해보니 지인과 인연을 맺은지 벌써 30년이 된 것이다. 우리가 처음 개발자로 시작했던 시점의 환경과 지금의 환경을 이야기 하며 개발자의 업의 목적이 어떻게 변했는 지 이야기를 했다. 그리고 최근의 AI로 개발하는 방법들을 공유하며 향후 어떻게 변할 지에 대한 논의도 했다. 30년이 되가는 시점에서 개발자로 살아남은 사람은 “변화를 받아들인 사람(또는 2001년 오딧세이의 원숭이)”이라는 것에 공감했다. 그리고 수많은 세월동안 변하지 않았던 것이 무엇인지 논의도 했다. 그리고 변하지 않았던 것은 다음과 같았다.
개발자는 기계(PC, 핸드폰, …)가 움직이도록 명령을 만드는 사람이다.
이전에는 하드웨어를 이해하지 못하면 개발을 못하는 시대도 있었다(DOS 때가지는 필수였음).
그리고 점점 더 인간의 사고방식(OOP)로 개발하기 시작했으며 이전보다 강력한 코딩도우미(lint, auto code complete, 코드스니펫, 템플릿 제너레이터…)로 개발자가 타이핑만 치기만 하더라도 코드가 만드어지기 시작했다. 그러나가 AI가 나오면서 코드가 아닌 사람의 말로 코드가 만들어지기 시작했다. 30년전 개발자와 지금의 개발자는 상당히 다른 환경에서 개발을 한다. 그리고 업무의 형태도 많이 다르다.
이런 복잡한 맥락을 일반인들에게 설명하다보면 소스코드보다 더 아스트랄한 내용이 되어버릴 때가 있다. 그럴 때마다 AI를 활용한다. 마치 인간의 사고방식을 기계에 전달하기 위해 소스코드로 작성하고 컴파일하여 바이너리를 만들 듯이 개발자의 사고방식을 순수인간(?)들에게 전달하기 위해 AI를 활용한다.
개발자의 사고방식은
인간과 기계의 중간단계에서
설계되고 수행되고 있다.
이 점은 미래에도 변하지 않을 것이다.
개발자는 위험을 발견하고
유지보수를 해야 하는 사람이기 때문이다.
