AI는 우리를 '접착제'로 만들고 있다

• AI 도구들이 개발자의 핵심 업무 일부를 대체하면서 사람은은 ‘문제 해결자’에서 ‘연결자’ 역할로 밀려나고 있음
• "바이브 코딩"처럼 AI가 구현을 맡고 인간은 아이디어만 제시하는 미래가 제시되지만, 현실은 아직 복잡함
• 개발자는 AI의 눈과 손이 되어 결함을 파악하거나 설정을 만지는 '배관공' 역할로 전락할 수 있음
• 시간이 지나면 이마저도 AI가 넘보게 되어, 인간은 물리 세계와 AI를 연결하는 '풀 역할'로 축소될 가능성이 있음
• 창의성과 자율성을 잃은 인간 노동이 ‘글루(glue)’ 같은 존재로 전락하는 미래에 대한 불안과 회의감을 담은 글

---

아마 그런 식은 아닐 거야

AGI를 걱정하지 않고 사랑하는 법을 배우려고 애쓰고 있지만, 솔직히 좀 암울한 기분임.

나는 소프트웨어를 만드는 일을 하고 있고, 지금 시점에서 내가 아는 거의 모든 사람들처럼 LLM을 활용해서 작업 속도를 높이고 있음.
어제 o3가 출시됐고, 벌써 복잡한 버그를 해결하는 데 큰 도움이 됐어
예전 같았으면 수많은 시행착오를 겪었을 문제였는데, 훨씬 덜 헤매고 해결했지.
겉보기엔 좋은 일이지. 근데 뭐가 문제냐고?

문제는, 나는 그런 복잡한 버그를 해결하는 걸 좋아한다는 점이야!
그건 퍼즐 같고, 파고들다 보면 평소에 잘 안 보이던 컴퓨터의 부분들을 배우게 돼.
리팩터링도 마찬가지야—잘 하고 있을 땐 내 시스템의 형태를 더 깊이 이해하고, 그걸 구조로 정제해 나가는 과정이거든.
그런 문제들을 푸는 건 뇌가 간질간질할 정도로 즐거운 자극이야.
내 일이 가장 보람 있는 부분인지는 모르겠지만, 내가 가장 좋아하는 부분인 건 확실해.

아직 그 시점에 도달한 건 아니지만, 분위기는 이미 정해져 있어.
아주 보수적으로 봐도, 10년 안에 대부분의 '구체적인 문제를 깊이 있게 사고하는' 일은 컴퓨터가 나보다 더 잘하게 될 거야.

어떤 역할을 이 작업에서 도려내고 나면, 남는 건 서로 거의 닿지 않는 두 덩어리야.
배를 조종하는 사람, 그리고 배관을 잇는 사람 (은유가 뒤섞여 있는 건 양해 부탁).
AI에 기대를 거는 사람들의 말을 들어보면, 예외 없이 전자가 될 생각에 들떠 있더라.
“바이브 코딩”[1] 이라는 개념의 약속은 이래—작업의 최상단 레이어, 그러니까 감각, 아이디어, 디자인, 철학 같은 것만 신경 쓰면 되고, 나머지는 머신이 알아서 해준다는 거지.
그렇게 되면 인간은 인간만이 할 수 있는 일에 집중할 수 있게 된다는 논리야.

나도 몇 가지 아이디어가 있고, 솔직히 말하면 그런 세상도 나쁘진 않겠다는 생각이 들기도 해.[2]
근데 내 경험상, 그건 복잡한 현실의 절반 정도만 담긴 이야기야.
예를 들어보자. 내가 어떤 에이전트를 도구들과 함께 쓰고 있어도, 시스템이 보지 못하는 문제는 결국 사람이 본다.
웹 애플리케이션을 만들고 있다고 해보자. Claude Code가 내 지시에 따라 스타일을 짜줬어.
근데 이게 실제 브라우저에서 어떻게 보일지 확인하는 건 결국 나야.
그리고 당연하게도, 뭔가 이상해. 왜냐면 CSS라는 게 원래 그렇거든.
그리고 내가 그 스타일을 직접 짠 게 아니라서 낯설다 보니, 가장 쉬운 해결책은 다시 Claude에게 가져가서 굴려보는 것뿐이야.
다시 요청하고, 다시 수정하고. 버그 리포트를 쓰는 일은 버그를 고치는 일보다 훨씬 재미없고,
결국 난 Claude가 내 컴퓨터를 둘러보는 데 필요한 “눈” 역할만 하게 돼.

물론 누군가는 이렇게 반론할 수도 있겠지: “이런 사이버 배관 역할은 머지않아 사라질 거야.”
맞아, 최전선의 연구소들은 지금도 전체 컴퓨터 조작이 가능한 에이전트를 개발 중이니까.
걔들이 브라우저 탭을 열고 화면을 확인하는 것쯤은 나만큼 잘 하게 될 거야.
근데 아직까진 AI의 공간 추론 능력이 형편없어서, 솔직히 말하면 지금은 약간의 안전지대(moat)[3]가 있는 느낌이야.
그렇다 해도, 배관 작업은 한동안 남아있을 거야.
예를 들어, 로그를 한 플랫폼에서 다른 쪽으로 파이프라인 구성하거나,
스토리지 버킷의 접근 정책을 설정해서 에이전트가 제대로 파일을 쓸 수 있게 해주는 일.
이런 작업은 내 직업 안정성에는 도움이 되지만, 솔직히 말해 별로 좋아하진 않아.
차라리 프로젝트의 핵심 아이디어를 고민하고 싶지, n번째 클라우드 서비스의 2FA 코드를 찾아다니고 싶진 않거든.
근데 앞으로는 이 시간조차도 “풀 같은 일”과 비교되면서 정당화하기 어려워질 거야.

좋은(…그런가?) 소식은, 이런 역할조차도 조만간 AI에게 넘겨질 거라는 점이야.
그 시점이 오면, 나는 AI와 현실 세계[4] 사이를 잇는 연결 고리 같은 존재가 될 것 같아.
당분간은 하드웨어 프로젝트를 한다면, 점퍼 와이어를 브레드보드에 연결하거나 안테나를 만지는 건 아직 내가 할 일이겠지.
나는 이런 손작업을 좋아해, 근데 컴퓨터가 전체 게임 플랜을 알고 있는 상황이라면… 그건 좀 재미가 덜할 거야.
운이 좋으면 나는 배의 “아이디어 선장” 역할을 맡을 수 있을지도 몰라.
하지만 배가 어디로 가야 할지를 AI한테 물어봐야 하는 선장이라면, 그 역할도 오래 못 갈 거야.
그리고 솔직히 말하면, 모든 사람이 각자 자기 배의 선장이 되어 생계를 유지할 수 있다고는 생각하지 않아.

그 이후에는 무슨 일이 일어날지 전혀 모르겠어.
존재론적인 위험은 일단 제쳐두고 보더라도, 많은 직업이 사라질 거라는 건 분명해 보여.
낙관적인 시나리오는, 우리가 지금은 상상도 못할 새로운 직업들을 만들고,
그걸 통해 사람들은 전에 없이 자아실현을 하게 될 거라는 거야.
하지만 슈퍼지능이 상품처럼 보급된 세상에서,
그 새로운 직업들이 결국은 **‘풀처럼 연결만 하는 일’**로 보일까 봐, 난 그게 걱정이야.

---

1. 사족이지만, "바이브 코딩(vibe coding)"이라는 표현은 어딘가 좀 거슬리긴 함.
   하지만 이미 위키백과 문서까지 있는 걸 보면, 이제는 그냥 업계 용어인 모양.

2. 이 방식의 장점은 굳이 설명할 필요도 없을 정도로 명확함.
   이전에는 상상도 못 했던 것들을 만드는 사람들이 지금 정말 많음.

3. 솔직히 말해, 나는 ‘화살표 연결하기’가 내 전문 역량이라고 생각해본 적은 없음.

4. 좀 더 일반적인 이야기로, 화면 속 지능에 비해 로보틱스의 발전 속도가 상대적으로 느리기 때문에,
   당분간은 인간의 ‘육체를 가진 존재성’이 기계에 대한 주요 이점으로 남을 것 같아.
   말 그대로의 배관공(아이러니하게도, 이들의 일은 앞에서 말한 ‘디지털 배관’보다 오히려 버그 수정에 더 가까울 것 같지만)은
   여전히 한동안은 괜찮을 거고, 다른 기술직 종사자들도 마찬가지.
   그리고 어떤 직업은 ‘접착제 역할’이 되더라도, 내가 묘사한 것처럼 꼭 무의미하게 느껴지지는 않을 수도 있음.
   예를 들어, 변호사는 판결문의 주 저자가 아니라 배심원에게 전달하는 역할로 변할 수도 있고,
   의사는 진단 능력보다는 환자와의 태도나 공감 능력이 더 중요해질 수도 있음.
   (창작 활동에 대해서는 여기서 길게 말하진 않겠지만, 아마 가장 큰 혜택과 가장 큰 고통을 동시에 겪게 될 분야라고 생각함.)

[kandk]

천공카드 쓰자고 주장하실분..

[GN⁺]

Hacker News 의견

• 이 글을 정말 재미있게 읽었음

  • 존재론적 위험을 제쳐두고, 많은 직업이 사라지지 않을 미래를 보지 못하겠음
  • 개인적으로 LLMs의 정체 효과에 베팅하고 있음
  • 두 가지 정체가 올 것이라고 봄: LLMs 자체의 정체와 인간의 정체
  • LLMs는 이미 새로운 모델이 더 나빠지는 현상을 보이고 있음 (예: Sonnet 3.5가 3.7보다 코딩에 더 나음)
  • 인간은 AI에 의존하면서 스킬이 퇴화하고, 새로운 프로그래밍 형태를 창조하거나 이를 기록하는 데 동기부여가 줄어듦
  • 단기적으로는 그렇지 않겠지만, 장기적으로는 무서운 일이 될 것임
  • AI로 인해 의도치 않게 망가진 시스템을 고치거나 대체하는 일이 미래의 일이 될 것임
  • "AI 문제 해결사"가 되거나 "수제 소프트웨어"를 만드는 기업가가 될 것임
  • 둘 다 꽤 수익성이 있을 것으로 예상함

• 왜 이런 기사들은 항상 "LLMs를 사용해서 일을 더 빨리 끝냈다"고 말하면서, LLMs가 더 많은 시간과 돈을 들여 더 나쁜 결과를 내게 한다고 설명하는지 모르겠음

  • LLMs 없이도 기준을 낮추는 데는 스스로의 힘이 충분했음

• "접착제"라는 댓글은 주로 소프트웨어 작업을 하는 사람의 관점을 반영함

  • 기계화된 생산 라인이 처음 만들어졌을 때부터 그랬음
  • 인간의 일은 직접적인 노동이 아니라 기계를 모니터링하고, 재시작하고, 고치는 것임
  • 파워 룸은 아마도 이런 장치의 첫 번째 사례일 것임
  • 생산 라인은 많은 스테이션을 가지고 있으며, 드릴 비트가 부러지거나 렌즈에 먼지가 끼거나 소모품이 떨어지면 중단됨
  • 예외를 자동화하기 어렵고, 공장 설계는 예외를 최소화하고 막힌 셀을 우회하는 데 중점을 둠
  • 소프트웨어 개발이 어떻게 변화하고 있는지 볼 때 공장의 작동 방식을 이해하는 것이 도움이 됨
  • "vibe coding"이라는 표현은 두 달 전에 생겨났음
  • 2년 후에는 얼마나 널리 퍼질지 궁금함

• AI가 소프트웨어 엔지니어의 일자리를 빼앗을 가능성은 낮음

  • 소프트웨어는 자동차, 음식, 주택과 달리 사람들이 소비할 수 있는 양에 자연적인 상한선이 없음
  • 소프트웨어 엔지니어는 궁극적으로 "만들고자 하는 의지"를 가진 사람들임
  • 코드나 도구는 단지 수단에 불과함

• "복잡한 버그를 고치는 것을 좋아함"

  • 나는 아님
  • 더 빠르게 해결책을 찾을 수 있는 도구는 언제나 환영임
  • AI는 지루한 부분을 잘 처리함

• 다른 경험을 하고 있음

  • Claude에게 버그를 고치라고 계속 요청하는 것이 짜증남
  • 그래서 "한 번에 한 조각씩 이해하며" 버그를 직접 고치는 작업을 계속하고 있음
  • 실제로 LLM을 사용하여 작은 라이브러리를 만들어 실행 앱에서 LLM의 필요성을 피하고 있음
  • StackOverflow의 강화 버전처럼 느껴짐
  • 나는 접착제가 아니라 필요한 정보를 빠르게 얻기 위한 우수한 도구를 가지고 있는 것뿐임

• 이 모든 것에 대해 여전히 꽤 비관적임

  • 오늘 LLM 코딩 어시스턴트가 도와줄 수 있는 명백한 승리를 기대했음
  • 매우 긴 구조체를 다른 매우 긴 구조체로 변환하는 go 함수를 작성 중이었음
  • 변환은 거의 전적으로 첫 번째 구조체의 필드를 래퍼에 감싸는 방식이었음
  • LLM이 이를 수행하지 못했음
  • 필드를 미리 채워 넣고 그것들을 채우라고 했지만, 새로운 필드를 상상하려고 했고, 한두 개를 한 후 내가 추가한 필드를 삭제하고 '나머지를 수행하라'는 주석을 추가함
  • 여러 가지 다른 프롬프트를 시도했음
  • 일부 vibe coders가 유용한 것을 만들 수 있는 방법을 볼 수 있지만, 대부분의 시도는 좌절의 연속이었음

• Stanislaw Lem의 이야기가 있음

  • "다른 곳에서 Tichy는 완벽한 조화를 원하여 자신을 기계에 맡기고, 기계가 그들을 반짝이는 디스크로 변환하여 행성 전체에 즐거운 패턴으로 배열하는 외계인 종족을 만남"
  • (접착제는 아니지만, 충분히 가까움)

• 복잡한 버그를 재미로 고치는 것을 막는 것은 없음

  • 취미 컴퓨팅은 이제 그 어느 때보다 접근성이 높음
  • 다른 사람들을 위해 무언가를 만들면 AI가 대부분 타이핑과 디버깅을 제거함
  • 이는 무엇을 만들고 있는지, 어떻게 가장 유용하게 만들지를 더 깊이 생각할 수 있게 해줌
  • 일반적으로 더 빨리 완료되므로 사용자에게 더 빨리 전달할 수 있어 반복 횟수가 증가함
  • 모두에게 이익임

• 잘 작성된 글임

  • 기본 아이디어의 전제에 동의함
  • 변화가 훨씬 더 극적일 것이라고 생각함
  • 많은 사람들이 정체되어 있으며, 주변의 다른 것들이 자동화될 것이라고 생각하지만, 자신은 그렇지 않을 것이라고 생각함
  • "나는 특별하다"고 생각하지만, 많은 사람들이 자신이 얼마나 특별하지 않은지를 알게 될 것임