▲

나를 뒤처지게 두라

 (androidessence.com)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Android 개발은 2014년 Java 수업에서 알게 된 무료 강의와 첫 할 일 앱에서 시작됐고, 손안의 소프트웨어가 현실에 닿는 경험이 동력이 됨
  • 10년의 커리어는 데이트 앱, 약물 접근성, 여행 지원처럼 사용자에게 실제 이익이 있는 앱을 유지보수하며 기술의 목적을 확인한 시간이었음
  • 강의, 해커톤, 첫 직장, Droidcon NYC를 거치며 결과물보다 사람들과의 연결과 공개 지식의 전달이 더 오래 남는다는 사실을 체감함
  • LLM은 컴파일되는 코드와 리뷰까지 제공할 만큼 개선됐지만, Stack Overflow식 탐색과 반박, 투표, 시행착오에서 생기는 이해를 약화시킴
  • 소프트웨어 개발은 반복 작업 자동화만으로 대체되지 않는 예술이자 공예이며, 인간이 인간을 위해 함께 만들고 나누는 활동이어야 함

Android 개발을 시작하게 된 계기

  • Android 개발은 2014년 대학 Java 수업 중 동급생이 공유한 무료 온라인 강의에서 시작됐고, 첫 목표는 로컬 저장소가 있는 할 일 목록 앱을 만드는 것이었음
  • 완성한 앱을 휴대폰에서 실행해 부모에게 보여준 순간은 “전구가 켜진 순간”으로 남았고, 손에 들고 다니며 직접 상호작용할 수 있는 실제 소프트웨어라는 점이 강한 의미를 만들었음
  • 앱은 주머니 속에 항상 존재하며 정리와 생산성을 돕는 도구였고, 이 경험을 통해 사람들에게 긍정적 영향을 주는 도구를 제공하는 일이 기술의 목적임을 체감함
  • 2018년에는 훗날 아내를 만나게 된 데이트 앱을 직접 다루는 일을 하며, 소프트웨어가 현실에 미치는 영향을 더 직접적으로 경험함
  • 이후 10년 동안 Android 개발자로 역량을 다듬으며, 특별한 사람을 찾는 일, 약물 접근성을 높이는 일, 여행을 지원하는 일처럼 실제 사용자에게 이익이 있는 앱들을 유지보수함

개발 여정을 만든 사람들

  • 앱 자체보다 더 오래 남은 것은 앱을 가능하게 만든 사람들과의 연결이었음

  • 강의와 공개 지식

    • 초기 목표는 가능한 한 많은 정보를 흡수하는 것이었고, 매주 강의를 들으며 교수가 가르치는 Android 내용을 익힘
    • Googler들이 날씨 앱을 만드는 방법을 가르치는 또 다른 강의도 들었고, 수업 사이와 점심시간까지 활용해 앱을 만들 만큼 몰입함
    • 카메라 뒤에 있는 사람들이 가진 깊은 지식과 이를 공개적으로 공유하려는 태도가 강한 인상을 남김

  • 해커톤과 팀 빌딩

    • 이후 몇 년은 직접 만들며 연습하는 시간으로 이어졌고, 10개가 넘는 해커톤에 참석하며 수백 명의 예비 소프트웨어 엔지니어와 연결됨
    • 친구들과 차를 타고 2~8시간 이동해 3일 동안 거의 잠을 자지 않고 소셜 앱, 반려동물 추적기, NFC 태그 CTF 게임 등을 만듦
    • 카페인으로 버티고 기술 스택을 두고 다투면서도, 웃음과 우정, 팀으로 무언가를 만들었다는 자부심이 주된 보상이었음
    • 무엇을 만들었는지나 상을 받았는지는 중요하지 않았고, 경험 자체가 보상으로 남음

  • 첫 직장과 RxJava

    • 졸업 후 디지털 마케팅 회사에서 전문 Android 개발자로 첫날을 시작했고, 옆자리 동료에게 “RxJava에 대해 무엇을 알고 있느냐”는 질문을 받음
    • RxJava를 전혀 몰라 당황했지만, 동료는 판단하지 않고 반응형 프로그래밍, 함께 작업할 앱의 맥락, 빠르게 따라잡는 방법을 알려줌
    • 두 사람은 사무실에서 웃음을 만드는 동료가 되었고, 동시에 일과 성장에 깊은 열정을 유지함

  • Droidcon NYC와 지식 환원

    • 같은 동료가 첫 Android 콘퍼런스인 Droidcon NYC에 데려갔고, 같은 좁은 관심사를 가진 수백 명의 엔지니어와 수십 명의 발표자가 모인 환경이 큰 영향을 줌
    • 발표자들이 자발적으로 지식을 공유하는 모습은 다음 세대 Android 엔지니어에게 자신의 전문성을 나누고 싶게 만든 계기가 됨
    • 다른 엔지니어를 도울 기회를 찾고, 이전에 받은 도움을 앞으로 전달하는 일이 커리어의 중요한 원칙이 됨

LLM이 약속한 개발 방식과 실제 경험

  • LLM이 대중화되며 “이제 코딩을 배울 필요 없이 원하는 것을 프롬프트로 입력하면 코드가 생성된다”는 단순한 약속이 기존 소프트웨어 개발 방식을 위협함
  • 처음에는 새로운 기술 가능성에 기대했지만, 실제 사용에서는 존재하지 않는 메서드를 제안하거나 명백한 버그를 만들거나 최악의 경우 컴파일되지 않는 코드를 생성함
  • 더 좋아질 것이라는 약속 이후 다시 사용했을 때는 실제로 개선되어, 컴파일되는 코드를 작성하고 스택 트레이스를 분석해 수정안을 제안하며 코드 리뷰까지 수행함
  • 하지만 개선된 기능은 동시에 인간적 경험을 고갈시킴
  • 모르는 것이 생기면 AI에 묻고 목표 달성에 작동하는 첫 답변에 의존하게 되었고, 이전처럼 Stack Overflow에서 같은 문제를 겪은 사람이 공개적으로 공유한 해결 과정을 따라 배우는 일이 줄어듦
  • Stack Overflow에는 단순한 도움뿐 아니라 가정을 반박하고 도전하는 피드백이 있었고, 검색과 검토, 커뮤니티 투표를 통해 해결책의 승인과 반대를 살피며 문제와 해법을 근본적으로 이해할 수 있었음

자동화가 약화시키는 학습과 협업

  • 엔지니어는 자동화를 좋아하지만, 자동화가 가장 잘 작동하는 영역은 사소하고 반복적인 작업임
  • 무언가를 만들어야 할 때 10년간 다듬은 기술을 쓰기보다 기계에 위임하면, 회복력 있고 오래가는 소프트웨어를 만드는 데 필요한 비판적 사고 역량이 약해질 수 있음
  • LLM이 빠르게 코드를 만들어주기 때문에 시스템에 대해 더 비판적으로 생각할 수 있다는 관점도 있지만, 소프트웨어 개발 학습의 핵심인 시행착오를 놓치기 쉬움
  • 시행착오는 앱이 작동하는지 충돌하는지에 그치지 않고, 목표 달성에 가장 적합한 아키텍처, 라이브러리, 패턴, 스타일을 찾기 위해 여러 방식을 시도하는 과정임
  • 해결책에 대한 피드백도 동료와 마주 앉아 구현 선택과 트레이드오프를 논의하기보다 블랙박스에 묻게 되면, 실제 프로젝트에서 무엇이 되고 안 됐는지에 기반한 대화가 사라짐
  • 트레이드오프 논의는 이론이 아니라 다른 사람이 직접 겪은 경험에 기반하는 경우가 많았고, 그런 대화가 구현 판단을 더 깊게 만듦

인간을 위한 소프트웨어

  • LLM은 예측 기계이며, 열린 곳에서 배우고 만들기를 선택한 엔지니어들의 오랜 헌신 위에서 학습된 텍스트 생성기이자 통계적 시스템으로 규정됨
  • 공개적으로 만드는 일은 기술을 가두지 않고, 젊은 엔지니어들이 탐색하고 이해하고 배울 수 있는 실제 예시를 만드는 행위였음
  • LLM은 코드가 컴파일되지 않을 때 함께 웃지 않고, 누군가 “이게 어떻게 동작하느냐”고 물었을 때 열정적으로 설명할 수 있을 만큼 소프트웨어 이해를 길러주지 않음
  • 무엇보다 고개를 돌려 웃으며 “우리가 이걸 만들었다”고 함께 말하는 기쁨에 참여하지 못함
  • 사람과 연결되고, 취약함을 드러내며 어려움을 공유하고, 도움을 받은 뒤 블로그 글이나 발표로 다시 나누는 습관이 AI 사용으로 약해졌지만 다시 회복할 필요가 있음
  • 소프트웨어 개발은 헌신, 인내, 강한 공동체가 필요한 예술이자 공예이며, 인간이 인간을 위해 만든 것이어야 함
  • AI와 함께 만드는 경험이 정말 미래라면, 그 미래에서는 뒤처져도 된다는 결론에 도달함

함께 보면 좋은 글 β

▲
GN⁺   [-]
Hacker News 의견들

  • 여기서 프로그래밍 공동체에 속하지 못했던 상반된 경험을 털어놓는 댓글들은 잘 다뤄졌지만, 또 생각해야 할 지점이 있음
    이 모든 소프트웨어의 하류에 있는, 우리가 직접 대화하지 않을 수도 있는 사람들을 기억해야 함. 꼭 “사용자”만은 아니고 개발자를 위한 소프트웨어도 많지만, 그래도 사용자는 고려받아야 함
    확률적 코드 압출기에 소프트웨어 품질을 넘기는 일은 세상에 나오는 소프트웨어 품질을 급격히 떨어뜨리고 있음. LLM 이전에도 인간의 실수나 왜곡된 금전적 유인 같은 문제가 있었는데, 그 위에 더해지는 것임. 저품질이고 사용자에게 적대적인 소프트웨어를 배포하면 실제 사람들에게 크고 작은 피해가 감. 이런 “불가피한” 생성형 AI로의 미끄러짐은 개발자, 사용자, 투자자 등 닿는 모든 사람에게 해를 끼침. 피해가 서로 다른 시점과 방식으로 나타나고 서서히 진행되기 때문에 무시하기 쉬울 뿐, 실제로 일어나고 있음
    “AI”는 해악임. 나도 뒤에 남겨도 됨

    • “확률적 코드 압출기”에 품질을 넘기면 소프트웨어 품질이 급락한다는 말이 사실인지 정말 모르겠고, 당신도 확신하긴 어려울 것 같음. 지금은 전부 느낌에 가까움
      개인 프로젝트 몇 개를 운영하는 입장에서는, AI로 제대로 된 CI 파이프라인을 만들고 테스트 범위를 넓히고 더 나은 아키텍처를 구성하면서 품질이 객관적으로 좋아졌다고 말할 수 있음. 예전에는 그런 견고화에 투자할 여력이 없었지만, AI 덕분에 가능해졌기 때문임
      물론 내 코드가 형편없고 테스트도 별로일 거라고 할 수 있겠지만, 이미 결론을 정해둔 것처럼 보임. 업계에서 25년 일한 경험으로는 그 판단은 틀렸다고 말할 수 있음. 다만 중간값의 코드베이스가 어떻게 될지는 아무도 모름. 내가 특별히 성실한 편일 수도 있음. 에이전트형 코딩 시대가 이제 6~12개월 정도 된 만큼, 아직 판단은 유보해야 함
    • LLM이 만든 소프트웨어가 사람들의 삶에 부정적인 영향을 줄 가능성이 크다는 데는 동의함. 반대로, 예전에는 만들어질 수 없었던 소프트웨어도 많이 생길 것임
      어떤 용도에서는 형편없는 소프트웨어라도 없는 것보다 나을 수 있음. 전체적으로 좋은 일일지 나쁜 일일지는 예측하기 어려움
    • “AI는 해악”이라는 식으로 보면, 구조적 프로그래밍, 컴파일러, 객체지향 프로그래밍, 코드 생성, 에이전트형 엔지니어링도 모두 해악이라고 할 수 있음
      이런 것들의 공통점은 게으른 사람이 그럭저럭 돌아가지만 문제가 있는 코드를 내놓는 지팡이로 쓸 수 있는 도구라는 점임. 게으름은 선택이고, 선택은 의지와 책임이 있는 인간이 하는 것임
    • 저품질이고 사용자에게 적대적인 소프트웨어가 실제 사람들에게 피해를 준다는 말에는 전적으로 동의함
      AI 도구로 더 나쁜 소프트웨어를 더 빨리 만들고 있다면 사용 방식을 다시 생각해야 함. 이걸로 더 나은 소프트웨어를 제공하지 못한다면 대체 무엇을 위해 쓰는 건지 모르겠음
    • 품질이 낮아졌다는 증거는 없음. 오히려 반대에 가까움
      AI 코드 리뷰 도구가 배포됐을 결함을 잡아내는 데 엄청나게 효과적인 경우를 봤음

  • 내 프로그래밍 경험은 글쓴이와 너무 달라서 내가 뭘 놓쳤는지 궁금해짐. 항상 혼자 프로그래밍했고, 온라인이든 오프라인이든 프로그래밍에 대해 깊이 대화해 본 적이 떠오르지 않음. 재미있고 신나는 일처럼 들리지만, 안타깝게도 그런 기회가 없었음
    내게 AI는 내가 마주치는 구체적인 문제나 상황에 대해 처음으로 의견 비슷한 것을 얻을 수 있게 해준 존재임. 지금 작업 중인 것에 가장 좋은 접근법이 무엇인지 아주 구체적으로 물어볼 수 있고, 답을 읽고 검토한 뒤 어떤 방식으로 갈지 결정함. 여전히 말도 안 되는 답을 자주 받지만, 그럴 때조차 “AI가 한 말이 사실인가?”라고 스스로 물으면서 문제 접근을 더 깊이 생각하게 도와줌

    • AI는 Google과 노란 고무 오리 디버깅을 하나로 합친 것 같음
    • 오랫동안 Android 커뮤니티는 아주 끈끈했고, 온라인과 오프라인에서 이런 이야기를 계속 나눴음. 원글 작성자도 꽤 활발한 기여자였음
      안타깝게도 인수 전 Twitter가 중심지였고, 그 이후로는 커뮤니티가 예전 같지 않다고 느낌
    • 비슷해서 워크숍을 직접 열기 시작했는데, 정말 멋지고 매번 많이 배움. 어떤 주제로든 사람들을 만나고 싶다면 직접 워크숍을 주최하면 됨
    • 2차 효과를 나열하고 따져봐야 함. 이 동반자 같은 관점은 여러 관점 중 하나일 뿐일 수 있지만, 매우 강력함
    • 독점 AI의 문제는 Anthropic, Google, OpenAI 같은 회사들이 사용자보다 AI 사용에서 더 많은 이익을 얻는다는 점임
      PostgreSQL, GCC, Git, HTTP, Emacs 같은 도구들은 사용한다고 해서 무언가를 “얻지” 않음. 인기가 생기고 기여가 늘 수는 있지만 그 정도임. Claude를 더 많이 쓸수록 Anthropic은 더 부자가 되고, 세계의 프로그래밍을 지배할 수 있는 권력의 위치에 서기 쉬워짐. 그래서 독점 AI가 아무리 마음에 들어도 우리가 대가로 무엇을 넘기고 있는지 다시 생각해야 함. 그건 단지 월 200달러가 아님

  • Mario Savio가 산업혁명이 정점에 달했을 때 했던 말이 있음
    기계의 작동이 너무 혐오스러워지고, 마음이 너무 아파서 참여할 수 없고 수동적으로도 참여할 수 없게 되는 때가 온다. 그때는 몸을 톱니바퀴와 바퀴, 레버와 모든 장치 위에 올려놓고 멈춰 세워야 한다. 그리고 그 기계를 운영하고 소유한 사람들에게, 우리가 자유롭지 않다면 기계도 전혀 작동하지 못하게 될 것이라고 알려야 한다는 말임
    그때도 기계가 많은 일을 하게 됐지만 우리는 여전히 잘 기능하고 있음. 결국 이것도 도구 사용이 되어 인간 지능을 또 다른 정점으로 데려갈 것 같음

    • “인간 지능을 또 다른 정점으로” 데려간다는 말에는 동의하기 어려움. 현재 인간 지능이 역사적 정점에 가깝다는 신호는 보이지 않음
      인간 지식은 그렇겠지만 지능은 아님. 집단적으로 우리는 어리석고 더 어리석어지는 방향이며, AI가 낳는 게으른 무사고 경향이 그 흐름을 가속할 것임
    • 왜 지능을 장려해야 하는지 모르겠음. 모두가 “지능적”이면 무엇이 달라지나? 기껏해야 이 바위 위에서 건강하게 사는 시간은 50년 정도임
      나도 비교적 “지능적”이라고 생각하지만, 그 개념은 과대평가됐다고 봄. 멍청하고 걱정 없이 살고 싶음. 자전거를 타고, 하늘에 화살을 쏘고, 에스카르고를 먹고, 때가 되면 잠든 채 죽고 싶음. 그런데 현실에서는 일하고 요양원을 알아봐야 함
    • 우리를 육체노동에서 해방한 이전 도구들이 인간의 신체 능력을 또 다른 정점으로 데려갔나?
    • 그 말은 산업화 자체가 아니라 공모하지 않는 것에 관한 말이었음. 기계는 체제에 대한 은유였고, 1960년대 맥락임
    • 여기서 “우리”가 누구임? 공장에서 기계를 직접 다루나? 1900년에 기계를 조작하던 사람이 어떤 기분이었는지 아나?
      어쨌든 기계적 대체와 사고의 대체는 비교할 수 없는데, 가장 생각 없는 친-AI 댓글이 맨 위에 오는 경향이 있음

  • 이 글은 내게 많은 것을 깨닫게 해줬음. 글쓴이의 고통을 이해할 것 같고, 읽으면서 확실히 느껴졌음. 차이를 만든 것이 “사람들”이었다는 점이 조금 놀라웠고, 내가 그런 경험을 거의 하지 못했기 때문에 이 기술을 보는 방식에 큰 영향을 줬을 수 있겠다고 깨달음
    내게 소프트웨어 만들기는 대개 고독한 과정이었고, 주변 사람들보다 훨씬 더 집착하는 일이었음. 기술 중심 지역에 살지도 않고, 프로그래밍이나 소프트웨어 공학, AI에 대해 잘 아는 사람들과 많이 이야기할 수 있는 환경도 아님. 글쓴이처럼 새 기술이나 새 언어를 배워야 했던 적은 있지만, 훨씬 더 경험 많은 개발자의 도움을 받은 게 아니라 집에서 혼자 배웠음
    LLM은 우리를 몇 가지 사실이 동시에 성립하는 상황에 남겨뒀고, 앞으로 나아가려면 이를 어떻게 조정하고 해결할지 찾아야 함. LLM을 쓰면서 배울 수도 있고 배우지 않을 수도 있으며, 이는 사용자의 접근법과 욕구, 의지력의 결과임. LLM 사용에도 거의 모든 것처럼 숙련도가 있고, 사용자의 숙련도는 기술에 대한 인식과 주변 사람들이 그 기술을 보는 방식에 영향을 줌. 미숙한 사용자는 더 부정적인 감정을 만들어냄
    어떤 사람들은 기계가 잘하는 일을 직접 하는 걸 좋아해서 기계가 하길 원하지 않고, 다른 사람들은 그런 일을 싫어해서 기계가 해주길 원함. 올해 어느 순간, 나는 프로그래밍 자체보다 시스템을 만들고 설계하고 문제를 푸는 일을 훨씬 더 좋아한다는 걸 깨달음
    소프트웨어 개발은 여러 가지가 한데 묶인 것인데 하나로 이야기하면 더 혼란스러워짐. 어떤 사람은 애플리케이션의 논리를 직접 생각하고 LLM이 코드를 쓰게 하고, 어떤 사람은 LLM이 해결책을 생각하고 구현하고 테스트하길 원함. 이 둘은 목표와 욕망이 다른 아주 다른 사람들임. 누군가가 Claude나 ChatGPT를 볼 때, 당신이 보는 것과 완전히 다른 것을 볼 수도 있음

    • 정말 잘 정리했음. 나도 같은 쪽임. 코드의 세부를 두고 아이디어를 주고받고 브레인스토밍할 사람이 거의 없었음
      대부분은 책과 온라인 글을 파고들며 동작 원리에 대한 나만의 정신 모델을 만들어야 했고, 그 과정은 꽤 도움이 됐음
      이제 AI는 배울 수 있는 도구이자, 올바른 방식을 보여주고, 무엇이 되었는지 자세히 설명해주는 도구가 됨. 질문하고, 실수를 짚고, 여러 구현을 오가며 결국 더 나은 프로그래머가 될 수 있음. 많은 사람이 말했듯 AI는 사람마다 다른 의미를 가짐. 내게는 힘을 주고, 깨우쳐 주고, 겸손하게 만드는 도구였음. 배울 것은 항상 너무 많고 시간은 부족했지만, 이제는 꼭 그렇게만 느껴지지 않음

  • 독점 AI의 문제는 Anthropic, Google, OpenAI 같은 회사들이 사용자보다 AI 사용에서 더 많은 이익을 얻는다는 점임. PostgreSQL, GCC, Git, HTTP, Emacs 같은 도구들은 사용한다고 해서 무언가를 “얻지” 않음. 인기가 생기고 기여가 늘 수는 있지만 그 정도임
    Claude를 더 많이 쓸수록 Anthropic은 더 부자가 되고, 세계의 프로그래밍을 지배할 수 있는 권력의 위치에 서기 쉬워짐. 그래서 독점 AI가 아무리 마음에 들어도 우리가 대가로 무엇을 넘기고 있는지 다시 생각해야 함. 그건 단지 월 200달러가 아님
    오픈 모델과 오픈소스 에이전트는 찬성하지만, 거대 기업에 더 많은 힘을 주고 싶지는 않음. 5년 뒤 이 대기업들이 우리 위에 더 큰 권력을 갖게 되면 소프트웨어 공학이 어떻게 변할지 상상해보면 무서움. 예를 들어 Claude Code 프롬프트 사이에 광고를 안 보려면 더 내라거나, 생성된 코드가 앱 안에 광고를 박지 않게 하려면 더 내라는 식이 될 수 있음. 지금 전 세계 인터넷에서 겪는 형편없는 경험이 소프트웨어 공학 작업 흐름 깊숙이 박히는 걸 정말 원하는가?

    • 70~90년대 데이터베이스가 처음 나왔을 때는 Oracle, IBM, Sybase, SQL Server 같은 독점 데이터베이스 회사가 많았지만, 지금은 오픈소스 데이터베이스가 기본값임
      현재 LLM 상태만 보고 온갖 과격한 예측을 하고 있지만, 시장이 어떻게 전개될지는 모름
      프로그래밍 역량이나 바이브 코딩 문화도 전기차 초기와 비슷함. 전기차가 내연기관보다 더 잘 맞는 역할은 있었지만 같은 일을 완전히 하기까지는 10년은 더 걸렸음. 그동안 인프라가 없고 기술이 미성숙하다는 이유로 전기차를 신기한 장난감, 비실용적이고 비싸고 위험한 것으로 깎아내리는 사람들도 많았음
      지금 보이는 진짜 해자는 데이터센터 수요 정도인데, 이것도 규모가 커지고 상품화될 것이고 RAM 생산도 따라잡을 것임

  • 대부분의 인간은 일에서 목적과 의미를 얻음. 늘 그래왔음. 사람들의 삶에서 의미를 대규모로 제거하면 무슨 일이 생길 것 같나? 보기 좋지는 않을 것임

    • 의미를 제거하는 문제가 아님. 생각이 있는 평범한 사람이라면 할 일을 찾아 삶을 채울 수 있음. 사실 대부분에게 일은 오히려 그걸 방해함
      진짜 문제는 모든 프롤레타리아에게 필요한 급여를 제거했을 때부터 상황이 “흥미로워진다”는 점임
    • 사람들의 삶에서 의미를 대규모로 제거하면 이런 AI 찌꺼기 같은 문구가 나옴: “이메일을 테스트하고 고쳐주는 AI 이메일 도달률 전문가 — Top-Rated 전문가가 뒷받침합니다”

  • 이 글에 공감함. 지금 벌어지는 일에 대한 내 반응도 “나를 뒤에 남겨둬라”임
    다만 개발자로 성장하던 옛 방식의 즐거움을 그리워하는 것은 잘못된 이유일 뿐 아니라, 다윈식으로 보면 매우 위험함. 고객은 결국 어떻게 만들었는지 신경 쓰지 않고, 장기 지원, 비용, 예측 가능성 등을 신경 씀
    그렇다고 업계가 실제로 순효과가 긍정적인 진전을 했다고 말할 수 있는지는 모르겠음. 전체가 큰 난장판임. 많은 경우 AI는 우리를 같은 방향으로 터보 모드로 밀어붙여 더 지저분하고 비싸게 만들 뿐 아니라 위험하게도 만듦
    나는 이 난장판을, 첫 원칙에서 제대로 생각하면 기회로 볼 수 있기 때문에 “나를 내버려 둬라”고 말함

    • 어쩌면 고객도 어떻게 만들어졌는지 신경 쓸 수 있음

  • 이 글은 AI를 전혀 쓰지 않거나, 모든 일을 AI에 위임하거나 둘 중 하나라는 거짓 양분법을 만드는 것처럼 보임. 실제로는 그렇게 돌아가지 않음. 작업의 어느 정도를 AI에 맡길지는 스스로 선택할 수 있음. 인간의 전문성, 공동체, 기술에 대한 열정이 들어갈 공간은 여전히 엄청나게 큼
    AI를 둘러싼 공개 논쟁을 보면 인지행동치료에서 말하는 인지 왜곡이 떠오름. 특히 흑백논리와 파국화임. 이는 종종 불안이나 정신증의 증상이기도 한데, 가끔은 사회 전체도 이런 증상을 겪을 수 있는지 궁금해짐
    https://en.wikipedia.org/wiki/Splitting_(psychology)
    https://en.wikipedia.org/wiki/Cognitive_distortion#Decatastr...

    • 실제로 개인 프로젝트에서는 동의함. 다만 직장에서는 항상 선택할 수 있는 게 아님
      팀이 PR 처리량과 토큰 사용량으로 측정되기 시작하면, 완전히 바이브 코딩하는 사람 옆에서 나는 더 “나빠” 보일 수 있음. 내가 바이브 코딩을 하지 않으면 승진에서 밀릴까 봐 두려움
      바이브 코딩이 나쁠 수 있다는 지표는 후행 지표임. 성능 문제, 서비스 저하, 대규모 데이터 마이그레이션 같은 바이브 코딩의 문제는 항상 나중에 드러남
    • 맞음. 공정하게 보자면 전면 수용 쪽과 전면 거부 쪽 모두에 사람들이 있을 것이고, 그들이 목소리가 클 것임
      하지만 그들은 소수이고, 다수는 중간 지점을 찾을 것임

  • 나는 시니어 PHP 개발자인데 최근 Ruby on Rails 프로젝트로 옮겨졌음. 완전히 낯선 환경임. 고객은 LLM을 최대한 많이 쓰라고 권고했음
    문제는 AI로 코딩하게 되면 코드베이스를 배우기 거의 불가능하다는 점임. 일부러 파고들지 않으면 한 번에 몇 줄 이상의 코드를 볼 일이 거의 없고, 속도 요구 때문에 그럴 시간도 없을 수 있음. 결과적으로 팀의 누구도 코드의 어느 영역을 속속들이 알지 못하게 됨. 지난 25년간 코딩하던 방식과는 아주 다르고, 재미도 덜하지만
    100년 전에는 장인이 만든 가구만 살 수 있었음. 진짜 장인들임. 지금은 IKEA와 수제가 선택지임. 대부분은 어떻게 만들었는지 신경 쓰지 않고, 제 역할만 하면 되기 때문에 IKEA를 고름. 여전히 수제 가구를 선호하는 사람들은 있고, 그들은 큰돈을 냄
    소프트웨어도 그 방향으로 가는 것 같고, 안타깝지만 동의함. 소프트웨어 개발은 취미가 될 것임. 많은 사람이 여가에 목공을 하듯이 말임. 극소수의 진짜 전문가가 남아 주로 컨설팅을 할 수도 있음. 어쩌면 학습 데이터를 만들거나, AI가 숙달할 프레임워크를 설계할 수도 있음. 모르겠음. 다만 앞으로는 확실히 달라질 것이고, 전부 좋은 방향은 아닐 것임
    지금은 AI가 인간을 위해 만들고 있고, 때로는 다른 AI를 위해 만들기도 함. 아주 곧 AI가 다른 AI를 위해 만들고, 가끔 인간을 위해 만들 것임. 나중에는 AI가 주로 AI를 위해 만들고, 인간을 위한 경우는 드물어질 것임

    • 내가 사는 곳에서는 아직도 장인에게서 가구를 살 수 있음. 지역 가게에서 침대를 샀는데 전혀 비싸지 않았고 꽤 만족했음
      당신 나라에서도 그렇지 않은지 찾아보면 좋겠음. 사람들이 자동으로 IKEA가 모든 지역 가게를 죽였다고 생각하지만, 찾아보면 지역 가구점이 많이 있음
    • 나는 장인에게 줄 돈이 없어서 IKEA를 삼. 가격을 낮출 만큼 충분히 생산할 장인이 남아 있지 않음

  • 이 글은 LLM이 썼거나, 요즘 표준 블로그 글쓰기 스타일로 쓰인 것 같음. 그 스타일 자체가 점점 LLM처럼 되어가고 있음
    Sam Kriss가 최근 글에서 그런 “티”를 잘 짚었음: https://samkriss.substack.com/p/if-you-let-ai-do-your-writin...

    • 특히 HN에서는 “LLM 찾아내기” 게임이 벌어지는 것 같고, 링크된 글마다 거의 반드시 AI가 썼다는 댓글이 달림
      AI의 “티”라는 것은 정의상 인간에게서 온다는 걸 이해하지 못하는 건가? Sam Kriss의 글은 화려한 문체를 비판하면서도 Salman Rushdie와 Arundhati Roy가 AI와 같은 “싸구려 수법”을 쓴다고 예로 드는데, 아무리 존중해도 받아들이기 어렵다. 이상한 은유를 쓰면 LLM을 쓴 것처럼 몰아가는 주제에 위험하게 가까움. 인간은 LLM 없이도 아주 오래전부터 이상한 글을 써왔음
      그리고 이 글에는 대체 어떤 “티”가 있나? 아주 직설적으로 읽히고, 이상한 은유도 없음. 전각 대시도 실제로는 단서가 아니며, 오히려 이 글처럼 “ - ” 같은 공백-하이픈-공백을 쓰는 건 꽤 인간적으로 보임. 무엇보다 LLM으로 프로그래밍하고 싶지 않다는 글을 쓴 사람에게는 의심의 이익을 주고 싶음
      “고아를 때리는 기계가 나를 실존적 불안과 공포로 채우지만, 그걸 독자에게 전달하려면 그 기계가 고아 몇 명을 때리게 해야 한다”는 식은 이상함
    • AI가 만든 쓰레기를 볼 시간이 없음. Claude에게 코드를 쓰게 하러 돌아가야 함 ;)
답변달기