▲

프로그래머 정체성 위기

 (hojberg.xyz)
28P by GN⁺ 22시간전 | ★ favorite | 댓글 1개
  • 프로그래머의 정체성이 최근 AI와 LLM 도구의 등장으로 위협받고 있음
  • 프로그래밍 문화는 1950년대 MIT의 해커 윤리에서 시작되어 코드 작성 그 자체를 깊이 있는 기술(craft)로 여기며, 정밀한 논리와 문제 해결의 몰입을 핵심 가치로 삼아왔음
  • 그러나 현재 AI 산업과 LLM 도구들은 개발자를 단순 명세 작성자나 오퍼레이터로 전환시키려 하며, 직접 코드를 작성하는 대신 자연어로 지시만 내리는 "vibe-coding" 방식을 강요하고 있음
  • LLM 생성 코드는 비결정적이고 부정확하며, 개발자가 직접 코드를 읽고 작성하는 과정에서 얻는 깊은 이해와 몰입을 제거하여 코드베이스와의 연결을 단절시킴
  • 기업들은 생산성 증대를 명분으로 도구 사용을 강제하고, 팀 내 협업과 멘토링 문화를 AI와의 상호작용으로 대체하면서 개발자 간 인간적 연결을 약화시키고 있음
  • 프로그래밍을 단순 산출물이 아닌 사고와 이해의 과정으로 보는 본질적 가치가 상실되고 있으며, 개발자들은 자신의 기술과 즐거움, 그리고 직업적 정체성을 지키기 위해 이러한 변화에 저항해야 함

프로그래머의 본질과 전통

  • 코드 작성은 단순한 업무가 아니라 개발자의 정체성 그 자체이며, 에디터는 작업장이자 성소로서 기술을 연마하고 몰입 상태(flow)에 들어가는 공간임

    • Vim과 같은 도구를 통해 생각과 코드 사이의 장벽 없이 작업하며, 현실 세계에 영향을 미치는 비물질적 세계를 창조함
    • 퍼즐을 푸는 과정 자체가 완성된 그림보다 중요하며, 손가락에서 버퍼로 이어지는 기술의 흐름 속에서 시간이 사라짐

  • 1950년대 후반 MIT에서 새로운 프로그래밍 문화가 탄생했으며, 실험적이고 반체제적인 성향을 가진 해커들이 Flexowriter와 TX-0 컴퓨터를 사용하며 완벽한 프로그램을 추구함

    • "The Right Thing"이라는 개념을 중심으로 우아하고 간결한 코드를 작성하는 것을 목표로 삼음
    • Tech Model Railroad Club 멤버들은 기계 언어에 몰두하며 디지털 마법을 익혔고, 발견한 지식을 다른 학생들과 공유하는 문화를 확립함

  • Building 26의 컴퓨팅 도가니에서 코딩 기술이 단련되었으며, 약 70년 전 확립된 이 문화는 현재까지 이어져 개발자들의 마음과 기계에 여전히 존재함

    • 고대 해커들의 유산은 깊고 운동적인 기술로 남아있으며, 이를 기반으로 열정적인 산업이 구축됨
    • 개발자들은 여전히 동일한 경이로움, 성취감, 퍼즐 해결의 우아함에 의해 동기부여되고 있음

  • 그러나 프로그래머의 정체성을 구성하는 이러한 핵심 가치들이 위협받고 있으며, 한때 밝고 명확했던 프로그래밍의 미래가 이제는 불길한 어둠과 사기, 불확실성으로 가려져 있음

AI 산업의 새로운 정체성 강요

  • 수십억 달러 규모의 AI 산업, Hacker News 커뮤니티, LinkedIn의 LLM 지지자들은 소프트웨어 개발의 미래가 프로그래밍과 거의 닮지 않았다고 주장하며, 1년 전 밈처럼 보였던 "vibe-coding"이 주류가 되고 있음

    • 개발자들은 코드 대신 Markdown으로 명세를 작성해야 하며, 코드베이스의 구석구석을 탐험하고 퍼즐을 풀며 비밀을 발견하는 깊은 몰입과 기술의 깊이가 사라짐
    • 대신 개발자를 위해 에이전트들이 사고하는 동안, 산만한 인지와 컨텍스트 스위칭을 받아들여야 하며, 창의적 문제 해결은 기계에 맡기고 개발자는 단순 오퍼레이터가 됨

  • 일부 개발자들은 이러한 변화와 "Specification Engineering"이라는 새로운 정체성을 환영하며, 오퍼레이터가 되어 Steve Jobs처럼 "오케스트라를 지휘"하는 것에 흥분함

    • 코딩에 대한 관심이 없는 것으로 보이는데도 왜 프로그래머가 되었는지 의문이며, Woz와 Jobs를 혼동한 것이 아닌가 생각됨
    • Prompt, Context, Specification "Engineering"이 프로그래머에게 밝고 번영하는 직업을 가져다줄 것으로 보이지 않음

  • 이는 기술, 숙련도, 노동의 가치 하락을 의미하며, 개발자의 고유한 추상적 사고 능력이 더 이상 필요하지 않은 영역으로 이동하여 이미 제품 매니저와 디자이너가 차지하고 있는 공간으로 들어가게 됨

기업 내 권력 역학의 변화

  • 기업 내에서 이 새로운 정체성이 강요되면서 권력 역학이 변화하고 있으며, 잘못된 곳에서 생산성을 높이려는 광적인 시도로 개발자들은 점점 더 구체적인 방식으로 LLM을 사용하도록 강제됨

    • 순응하지 않으면 쫓겨나고, 자신의 쓸모없음을 알리는 제품을 사용하거나 사직해야 함
    • 과거에는 경영진이 개발자의 도구를 이렇게 구체적으로 지시한 적이 거의 없었음

  • 개발자들은 셰프나 목수처럼 자신의 도구를 큐레이팅하고 연마하는 데 큰 자부심을 가져왔으며, 에디터의 세심한 설정, 닷 파일 조정, 개발 환경 구성 등을 통해 자신의 사고방식에 맞게 도구를 개인화해왔음

    • 기술의 일부로서 도구 세트를 개인화하는 데 헌신해왔으나, 일상 업무와 거의 연결되지 않은 경영진이 이를 명령하는 것은 침해처럼 느껴짐
    • 수십 년간 기업 내에서 우대받았던 프로그래머들에게, 이러한 내러티브는 경영진이 균형을 다시 자신들에게 유리하게 기울일 새로운 방법을 제공함

LLM과 프로그래밍 언어의 본질적 차이

  • 일부는 LLM의 영향을 저수준 언어에서 고수준 언어로의 전환에 비유하지만(Assembly에서 Fortran으로), 이는 여러 측면에서 잘못된 비유임

    • Fortran은 프로그래밍에 뿌리를 두고 기술을 제거하려 하지 않고 그 위에 구축했으며, 프로그래밍의 정밀성과 표현력을 제거하지 않고 확장함
    • Fortran은 입력에 대해 항상 올바른 결과를 성공적으로 생성했지만, LLM의 세계에서는 이 중 어느 것도 사실이 아님

  • 컴퓨터와 프로그래밍은 매우 좌절스러울 수 있지만, 적어도 정밀성에 대해서는 항상 신뢰할 수 있었으며, 프로그래밍을 통해 지시한 대로 정확히 수행함

    • 컴퓨터의 정밀성에 대한 의존과 신뢰 때문에, 챗봇이 요청한 작업을 수행했다고 가스라이팅할 때 이를 믿기 쉬움

  • LLM과 그 작업은 본질적으로 부정확하며, 대형 언어 모델의 속성과 자연어로 지시하는 방식 모두에서 오해의 여지가 있음

    • 비결정성을 싫어하는 프로그래머들이 이러한 접근 방식을 선택한 것은 흥미로우며, 예측 가능성, 조합성, 멱등성, 불안정하지 않은 통합 테스트를 선호함
    • LLM 코드는 그 반대인 일관성 없는 혼돈을 나타냄

  • Dijkstra는 "자연어 프로그래밍의 어리석음에 대하여"에서 자연어가 작업을 단순화할 것이라는 가정에 도전해야 한다고 지적했으며, 형식적 텍스트의 장점은 합법적이기 위해 몇 가지 간단한 규칙만 충족하면 된다는 점이라고 강조함

깊은 이해와 몰입의 상실

  • AI 보조 개발을 엄격함과 관료주의로 vibe-coding과 구분하려는 움직임이 있지만, 이는 근본적인 본질을 무시함

    • LLM이 생성한 코드를 자신이 작성했거나 PR에서 리뷰했을 때만큼 면밀히 읽지 않게 되며, LLM 코딩에는 눈을 멍하게 만드는 본질적인 무언가가 있음
    • 대충 훑어보게 되고 압도당하고 지루해하며, CI가 통과하고 프로그램이 컴파일되면 위험한 함정을 맹목적으로 받아들임
    • 테스트가 실행되도록 설정되었는지, 존재하지 않는 라이브러리를 가져왔는지, 전체 라이브러리를 스스로 구현했는지 확인하지 않음

  • 책의 리뷰나 요약은 직접 읽는 경험을 대체할 수 없으며, 수백 페이지에 걸쳐 각 문장을 신중하게 소비하며 아이디어를 숙고하는 과정이 필요함

    • 마찬가지로 AI가 완료한 작업의 요약을 훑어보는 것은 도메인, 문제, 가능한 솔루션에 대한 깊은 이해를 형성하는 것을 빼앗으며, 코드베이스와의 연결을 차단함
    • 무지의 심연에 뛰어들어 주제와 그 함의를 드러내고 배우고 이해하는 것은 만족스럽고 좋은 소프트웨어에 필수적임
    • 소유권, 주체성, 깊고 만족스러운 작업은 에이전트 탭 사이의 산만한 주의로 대체됨

  • Joan Didion은 "나는 내가 무엇을 생각하고 있는지, 무엇을 보고 있는지, 무엇을 보고 그것이 무엇을 의미하는지 알아내기 위해 글을 쓴다"고 말했으며, Peter Naur는 "Theory Building으로서의 프로그래밍"에서 동일한 개념을 탐구함

    • Naur의 "Theory"는 코드베이스의 이해를 구현하며, 작동 방식, 형식주의, 현실 세계의 표현을 포함함
    • 이러한 맥락과 통찰은 오직 몰입을 통해서만 얻어지며, Naur는 "Theory"를 소프트웨어보다 프로그래밍의 주요 결과물이자 실제 제품으로 설명함
    • 잘 발달된 "Theory"가 있어야만 코드베이스에 확장과 버그 수정을 효과적으로 적용할 수 있음

  • 좋은 디자인은 몰입에서 나오며, 텍스트 버퍼에서의 왔다 갔다 하는 작업과 종종 키보드에서 떨어진 곳에서의 작업을 통해 나타남

    • 전체 코드베이스를 마음속에 담을 수 없기에, 모듈, 클래스, 함수에 뛰어들어 흐릿한 정신 모델을 선명하게 해야 함
    • 코드를 읽고 작성하여 인지를 확장하고, 익숙함과 문제 도메인에 대한 이해를 회복해야 함

  • 맥락의 일부가 구축되고 많은 부족한 시도를 통해 마침내 해결책을 발견할 수 있으며, 나쁜 디자인의 불협화음을 느껴야 함

    • 혐오스럽고 반복적인 코드를 작성할 때만 더 나은, 더 간결하고 우아하며 조합적이고 재사용 가능한 방법이 있다는 것을 깨달음
    • 이는 문제에 대해 깊이 생각하기 위해 멈추게 하고, 한 걸음 물러서서 처음부터 다시 시작하게 함
    • 반대로 AI 에이전트 작업은 마찰이 없어 대안적 솔루션을 피하게 되며, 수락하는 것이 완벽한지, 평범한지, 끔찍한지, 심지어 해로운지 알 수 없음

팀 협업과 인간 연결의 붕괴

  • LLM 중심 코딩의 인지적 부채는 기술 이탈을 넘어 확장되며, 주의 집중 시간이 짧은 "slop-jockey"들이 풀 리퀘스트와 디자인 문서에 자신의 작업물을 던지며 협업을 저해하고 팀을 방해함

    • 코드 리뷰를 하는 동료들은 자신이 이제 마지막 품질 관리 레이어가 아니라 첫 번째 레이어라는 충격적인 깨달음에 정신을 잃어가고 있음
    • 새로 추가되었지만 호출되지 않는 함수, 환각된 라이브러리 추가, 명백한 런타임 또는 컴파일 오류를 지적해야 함
    • 자신의 코드를 명백히 훑어보기만 한 작성자는 책임을 지지 않으며, "Claude가 그렇게 작성했어요. 바보 같은 AI, 하하"라고 말함

  • 간섭하는 관리자와 돈을 아끼려는 임원들은 팀에서 인간 상호작용을 줄이도록 (희망컨대 무의식적으로) 압박하고 있음

    • 고립되고 연결이 박탈된 상태에서, 이제 작업 경험 주위에 벽을 쌓도록 권한을 부여받고 장려됨
    • 페어 프로그래머가 필요하거나, 솔루션을 주고받으며 논의하거나, 프로토타입을 만들거나, 아키텍처를 스케치하거나, 코드베이스의 난해한 부분에 대한 전문가 질문에 답하는 데 도움이 필요할 때 사람 대신 LLM에 의존함
    • 더 이상 온보딩 버디, 멘토, 동료가 필요하지 않으며, 대신 기계와 대화할 수 있음
    • LLM으로 인간 접촉을 피하는 것이 너무 쉬워져 이것이 표준이 될 수 있음

프로그래머 정체성의 방어

  • 우리가 AI 과대광고 내러티브에 얼마나 순응적이며, 기술의 계획된 삭제에 적극적으로 참여하고, 사고 수단을 기꺼이 포기하는지가 충격적임

    • 취미로 생계를 꾸릴 수 있었던 행운아들이었는데, 슬롭에 대응하기 위해 엄격하고 꼼꼼한 프로세스를 만들더라도 여전히 일의 재미있는 부분을 아웃소싱하고 이를 지시적 고역으로 대체한 것임

  • LLM은 소프트웨어의 복잡성에 대한 궤도에서 핵폭탄을 투하하는 솔루션처럼 보이며, 실제 문제를 해결하는 대신 증상을 치료하기 위해 훨씬 더 복잡하고 모호한 것에 손을 뻗음

    • sed를 Claude로 대체하거나, 문서를 수 시간 동안 검색한 후에도 명확성을 찾는 라이브러리나 프레임워크에 대한 답변을 요청하는 것은 괜찮음
    • 그러나 단순히 오퍼레이터나 코드 리뷰어가 되어 재미있고 흥미로운 작업에서 뒷자리를 차지하는 것은 원하지 않음

  • 반복적인 작업을 돕고, 코드베이스를 이해하고, 올바른 프로그램을 작성하는 데 도움이 되는 도구를 선호하며, 나를 위해 생각하도록 설계된 제품에는 불쾌감을 느낌

    • 내가 생산하는 소프트웨어에 대한 자신의 이해의 주체성을 제거하고, 동료와의 연결을 끊는 제품을 거부함
    • LLM이 과대광고에 부응하더라도, 우리는 여전히 이 모든 것과 기술을 잃게 될 것임
    • 인간은 기계와 그들을 지원하는 기업보다 중요하며, 나머지 우리가 그들이 판매하는 새로운 아메리칸 드림을 쫓는 동안 그들은 이익을 얻고 있음
    • 대가로 우리는 비판적 사고 능력, 재미, 기술, 프라이버시, 그리고 아마도 지구를 제공하고 있음
▲
GN⁺ 22시간전  [-]
Hacker News 의견

  • 내게 가장 인상 깊었던 점은 코드 리뷰어들이 이제 품질 관리의 마지막 단계가 아니라 첫 번째 방어선이 되었음을 깨달으면서 점점 멘탈이 나가는 모습임. 리뷰 요청을 받았지만, 이제는 새로 추가된 호출되지 않는 함수, 갑자기 추가된 라이브러리, 명백한 런타임이나 컴파일 에러 등을 하나하나 잡아내야 함. 코드 작성자는 책임을 회피하며 “클로드가 쓴 거라서 그래요, AI가 실수했네요, 하하” 식으로 넘기는 현실임. LLM 도입 후 브란돌리니의 법칙(헛소리를 반박하는 데 드는 에너지가 만드는 것보다 훨씬 크다는 법칙)이 확실히 더 실감나는 상황임. 경험이 부족하거나 기술이 떨어지는 개발자가 몇 분 만에 수천 줄 코드를 쏟아내면, 이제 실제로 시스템의 건전성을 보장하는 책임은 코드 리뷰어들에게 전가됨. PR의 코드 증감량(added/removed LoC delta)을 보면, LLM이 쓴 PR은 거의 추가만 계속되고, 숙련된 시니어 엔지니어들은 새로운 코드만큼 기존 코드도 지우는 경우가 많음

    • 내 생각에 이건 기술 문제가 아니라 사람 문제라고 봄. 한 번 이런 일이 일어나면 엄중하게 경고해야 하고, 두 번 반복되면 매니저에게 보내서 거부해야 한다고 생각함. 누가 PR을 작성했든 결국 결과물에 자기 이름을 걸게 되는 것이므로, 코드가 엉망이면 그 책임 또한 본인이 져야 함

    • 나는 이제 더 이상 대규모 팀에서 코드 리뷰는 안 하지만, 만약 내가 그런 상황에 놓이면 이런 책임 회피는 한 번 정도는 봐줄 수 있지만 반복된다면 그 사람을 내보내려고 할 것임. 불가능하다면 내가 그만둘 것임. 그 정도로 끔찍한 환경임

    • 요즘 내가 생산성이 떨어졌다고 느끼는 것도 이와 관련이 있다고 생각함. 더 많은 코드를 더 빨리 생산하라는 압박과, 에이전트 같은 걸 사용하면 내가 쓴 코드의 전체 맥락을 제대로 파악하지 못한다는 점 때문임. 내가 라인 바이 라인으로 꼼꼼하게 리뷰할 수 있는 범위 안에서만 품질을 보장할 수 있는데, 이 부분이 한계임. 그래서 요즘은 더 천천히, 더 보수적으로 AI를 사용하고, 직접 손으로 짜는 비중을 늘림. 명확한 타입 정의나 스펙을 여러 속성에 반복 적용할 때는 AI가 좀 도움이 되지만, 그럴 때조차 결과물이 항상 확실하지는 않음

    • 경력 많은 시니어 엔지니어일수록 추가하는 코드만큼 기존 코드도 깎아내는 경우가 많음 Negative 2,000 Lines Of Code 글도 참고할 만함

    • LLM이 개입되는 순간 우리가 누구에게 책임을 전가하는지를 바라보는 관점이 더 넓은 사회적 문제라고 생각함. 사람들은 결과가 좋으면 자기 공으로 삼으면서, 안 좋으면 손쉽게 AI 탓을 해버림. 적절한 소송 사례만 몇 번 나와도 이런 문화는 크게 변화할 거라고 봄

  • 오랫동안 업계에 들어오는 사람들은 코드를 장인정신으로 여긴다기보다는 쉽게 돈 버는 수단으로 여긴다고 느낌. 오픈소스 인프라 개발자가 생계유지가 어려운 글을 보았을 때부터, 카페에서 코딩하는 개발자, 부트캠프나 ‘코드만 배우면 된다’라는 운동, Leetcode 그라인더, 샌프란시스코에서 집값이 비싸 차에서 사는 개발자까지, 이제는 AI로 자기 자신을 자동화해서 일자리 없어지는 게 이슈임. 개발자는 진짜 프로페셔널이 아니라는 인식이 문제임. 기준도 느슨하고, 윤리강령이나 일관된 스킬셋, 대표성도 없음. 심지어 업계 구성원이 자기 이익에 적대적일 정도로 주체적이지 못함. 변호사에겐 변호사 협회가, 의사에겐 의사회가 있지만, 개발자는 존재론적 불안감만 가짐. 이제는 상사가 "AI로 자동화해서 네 일자리 없애"라는 식으로 으름장을 놓음. 다른 전문직은 자기 이익에 이렇게 적대적이지 않은데, 왜 이 업계만 이런지 스스로 의문임

    • “코더”와 소프트웨어 엔지니어는 다르다고 생각함. 부트캠프만 마치고 파이썬으로 간단한 프로그램을 짤 수 있다고 해서 소프트웨어 엔지니어라고 할 수 없음. 내가 학위가 있다고 말하면 엘리트주의라며, 컴퓨터공학에서 배우는 건 실무에 쓸모 없는 것뿐이라는 소리도 들음. 하지만 학위 없이도 자체적으로 뛰어난 엔지니어로 성장한 사례도 분명 있음. 그럼에도 어떤 형태로든 기준이 필요하다는 데는 동감함. 최신 버즈워드 유니콘 스타트업에 합류하는 부트캠퍼는 그냥 축하해 주면 되지만, Therac-25(사고 사례) 같은 민감한 시스템은 반드시 정규 훈련 받은 사람들이 맡는 게 낫다고 봄

    • 상사가 “자동화하지 않으면 네 일자리 없어질 거다”라고 말하는 것? 그게 바로 우리의 일임. 노동을 자동화하는 건 우리 업무의 본질이며, 우리가 자기 일터를 스스로 자동화할 기회와 이해도가 가장 높은 직군임

    • 교직도 개발자와 유사한 점이 있다고 생각함. 뛰어난 교사, 형편없는 교사, 그 중간도 많음. 과목을 잘 안다고 해서 가르치는 능력이 뛰어난 건 아님. 어쩌면 개발자는 기계를 가르치는 교사라고 볼 수 있음. 한 글자, 한 생각씩 머천 캐릭터를 가르치거나, 전체적인 분위기로 가르치는 방식까지 다양함

  • LLM은 잠시 제쳐두고, 내가 스스로 자랑스러울 만큼 완성도 높게 짠 코드가 가끔 있음. 구조부터 모든 라인까지 이유 없는 결정이 없는 상태, 이 코드는 내가 전문가이고 완전히 숙지한 상태임. 하지만 대부분의 코드는 그렇게 완벽하게 쓰지 않음. 대부분은 “작업만 끝내면 돼”라는 식으로, 조금 낮은 기준을 스스로 허용함. 그래도 가끔 제대로 몰입해서 완성한 코드는 정말 보람 있고 내 인생 최고의 코드 경험임. LLM까지 생각해보면, 오히려 완성도 높게 코딩하기가 더 쉬워졌으면서도, 그만큼 더 어려워진 점도 있음. 심리적으로 깊게 몰입하면 LLM을 잘 활용해 더 빠르고 높은 기준의 결과를 만들 수 있음. LLM이 짠 코드보다 월등하게 잘 짤 수 있지만, LLM의 도움으로 더 뛰어난 코드를 쓸 수도 있음. 하지만 이 몰입 상태를 유지하기가 점점 더 어려워짐. LLM이 만들어 준 코드를 대충 훑고, 비주얼도 좋아 보이고 동작도 제대로 되니 그냥 넘겨버리게 됨. 하지만 그렇게 대충 넘어간 코드가 조금씩 점점 더 엉망이 되고, 그렇게 무딘 채로 계속 통과시키다 보면 이미 늦은 상황이 됨. 결과적으로는 자기 자신이 그 코드에 대한 전문가가 되지 못하고, 엉성한 코드만 쌓임

    • 최근 두 달 간 AI를 더 많이 사용해보며 이런 과정을 겪음:
      1. AI를 작은 일에만 활용했다가, 워낙 인상적으로 잘 해내서 감탄함
      2. 점점 더 큰 일을 맡겨보며 효율적으로 활용하는 법을 모색함
      3. 이제는 거의 에이전트처럼 AI가 알아서 다 하고, 나는 마지막에 코드만 리뷰함
      4. 그 결과 “결국 내가 스스로 코드를 모두 꼼꼼히 따져봐야 하며, AI가 내가 바라던 바로 그 지름길은 아니구나”라는 사실을 깨달음(예: 큰 틀만 던져주고 그럴싸한 최종 코드를 얻으려는 건 불가능함)
      5. 그래서 다시 AI에게 작은 작업 위주로만 시키게 됨 AI는 리서치, 프로토타입, POC, 혹은 “돌아는 가지만 프로덕션에서는 절대 못 쓸 코드” 등 짜다 버릴 코드에서는 유용하다고 느낌. 근본적인 설계나 구조는 내 손으로, 함수 구현이나 세부 논리 채우기 등 작은 작업에서는 AI가 꽤 도움 됨

  • 이 에세이는 정말 내 생각과 딱 맞아서 즐겁게 읽었음. 회사에서 AI를 써보려 했지만 대부분의 경우 결과물이 별로라서 결국은 거의 다 내가 직접 다시 짬. 불필요하게 사고하는 시간이나 문제 해결을 AI에게 맡기는 건 내 커리어에 최악의 선택이라는 확신이 듬. AI는 그저 미디엄 퀄리티의 텍스트 생성기에 불과함

    • 내가 제일 안타까운 건, 나는 사실 LLM 기반 코딩을 진짜 잘할 수 있다는 것임. 내 동료들은 새 세상에 푹 빠져서 AI 슬롭 코드만 계속 양산하고 일도 엄청 오래 걸림. 그에 비해 나는 소프트웨어 아키텍처 감각이 있고, LLM에게 중요한 코너 케이스를 요청하는 등 “AI에게 어떻게 시킬지” 더 잘 다룸. 게다가 나는 맥락 관리도 잘하고, 신경 발달 특성 덕분에 내 방식과 다른 존재와 소통을 오랫동안 훈련해 와서 LLM과 더 기계적으로 공감할 수 있음. 동료들은 LLM이 자기 생각을 못 읽어줘서 더 답답해함. 하지만 LLM도 점점 좋아지고 있어 내 우위가 영원하진 않을 것임. AI 슬롭이 쌓일수록 그걸 처리하려면 또 LLM을 더 써야 해서 악순환임. 결국 아무도 무슨 코드인지 모르게 되고, 나는 기계의 신에게 기도만 하게 될 수도 있음

  • “도대체 저 사람들은 왜 프로그래머가 되기로 했나, 코드 자체에 관심도 없어 보이는데”라는 의문에 대해, 나는 “문제 해결이 목적”이라는 점을 강조함. 코딩은 수단이지 목적 자체가 아님. “에디터 설정, 닷파일, 개발 환경 만지작거리기”가 재미는 있을 수 있지만, 나는 그걸 쓸데없는 복잡성이라고 보고 기꺼이 위임하겠음

    • 에디터, 닷파일, 개발 환경을 직접 세팅하는 건 결국 내 업무 환경에 대한 친숙함을 키우고, 도구 능력을 키우며 더 생산적인 환경을 만들어내는 작업임. 빌드 스크립트 건드려야 할 때 “부르는 사람”이 되는 건 이런 관리가 있기 때문임. 십 년, 이십 년 동안 Git을 쓰면서도 병합 충돌이나 기본 사용법을 모르는 사람들이 너무 많아서, 결국 제대로 도구 익힌 사람에게 모든 귀찮은 일이 다 몰리는 문제가 있음

    • “이건 가치가 없다”는 식의 주장은, 논리 끝까지 밀고 가면 “존재 자체가 무슨 가치가 있나”에 가버릴 수 있음

    • 세상 거의 모든 직업의 목적이 문제 해결이지만, 도대체 왜 그 많은 직업 중 소프트웨어를 택한 건지 궁금함

    • “문제 해결이 목적이고, 코딩은 그 수단일 뿐임”이라는 주장에 100% 동의함. AI가 코딩을 대신하면 슬퍼하는 사람들은 ‘코드 예술가’ 같은 부류이고, 무엇을 만드는지의 ‘형식’ 자체에 더 집착함. 난 문제 자체에 집중하는 스타일이라, AI가 코딩 대신해 주는 건 하나도 아쉽지 않음

    • “코딩은 목적이 아니라 수단”이라는 주장도, “에디터 만지는 게 재미있긴 해도 가치 없다는 것”도 다 지극히 주관적인 이야기임. 문제 해결이 사라져도 순수히 코딩 자체를 좋아할 사람들도 있고, 만약 세상에 문제가 하나도 없다 해도 코딩을 즐길 사람들이 많음

  • 이 글 정말 흥미롭게 읽었음. 내가 LLM 프로그래밍에 대해 느끼는 감정과 거의 일치함. 난 단순히 코딩이 좋아서 하는 사람이었고, 직업으로도 이걸 즐겨왔음. 그런데 요즘은 일에서 내가 좋아하던 내 취미를 살릴 수가 없어져서 아쉬움. 완전히 다른 작업이 되어버렸음

  • 나는 나이가 좀 있음. 1995년쯤에는 지금과는 완전히 다른 환경에서 프로그래밍했음. 그때는 엔지니어가 대상 고객, 기술스택, 업계 동향 다 알고 있었고, 정말 주도권을 쥔 상태였음. 자기 코드는 자기 놀이터였고, 원하는 대로 갈아엎고, 들여쓰기나 괄호 스타일도 스스로 정함(깨지면 스스로 고침). 단위 테스트 같은 건 없었고(그땐 파라미터 확인 정도), 공식적인 코드 리뷰도 거의 없이 동료들과 그냥 사무실에서 수다 떨고 화이트보드 두드리던 시절이었음. 버그 있으면 그냥 바로 고치던 문화였음. 결국 매니지먼트가 승리했고, 이젠 그런 ‘카우보이 코딩’ 시대는 다시 오기 힘들 것 같음. 90년대 Apple이 그리울 순 있지만, 이제는 그때로 돌아갈 수 없음. 그 땐 정말 즐거웠음

    • 나도 비슷한 시기에 시작했는데, 우리는 ISO 9001 때문에 정기적으로 코드 리뷰를 했었음. 결과물을 프린터로 뽑아서 3명이 한 방에 모여 모든 줄을 확인하고 사인해야 했음. 이를 산업 제어 RTOS에 운영함. 프로젝트 관리는 40피트짜리 간트차트를 프린트해서 벽에 붙여놓고 관리했음. 완전 워터폴 시절임

    • 나는 2000년대 후반에 시작했는데, 그때는 커리어 패스와 전문분야 경계가 훨씬 명확했음. 시스템 관리자와 개발자가 확실히 나뉘었는데, 이제는 시스템 운영자 역할까지 나에게 기대해서 오히려 일의 범위가 늘어났음. 나는 시스템 쪽 스킬을 취미로만 키웠고, 실제로는 일을 맡으면 현실에서 벤더 문서나 트레이닝이 너무 허접해서 외면하고 싶었음

    • 업계 전체가 다시 카우보이 코딩 형태로 돌아가진 않겠지만, 일부 환경에서는 여전히 이런 스타일이 남아 있을 거라 생각함. WhatsApp에서 2011~2019년 사이에는 꽤 자유로운 환경이었음. 환경마다 다르겠지만, 에러를 사전에 잡는 비용, 프로덕션 후 잡는 비용에 따라 무엇이 적합한지가 달라짐. 나는 개인적으로 에러 픽스 비용을 낮추는 접근을 선호함. 대신 당연히 부끄러운 실수는 하지 않으려 노력하고, 테스트도 꼭 필요한 것은 함

    • 지금은 비즈니스 마인드와, vibe coder, script kiddie들이 너무 많이 들어와서 모두 형편없어졌다고 느낌

    • 카우보이 코딩의 문제는 한 명의 비신뢰성 멤버가 팀 전체를 망칠 수 있기 때문임. 조직이 커질수록 불량 멤버도 불가피하게 늘고, 문제 폭발을 막으려면 점점 더 큰 장치가 필요함. 신뢰 기반의 소수 정예 팀에서는 카우보이 코딩이 최고의 효율이지만, 채용에서 후보자 실력 평가가 어려우니 대규모 조직에는 전혀 맞지 않음. 앞으로도 소규모 회사나, 대기업 내 소규모 팀 등에서만 이런 방식이 어쩌면 살아남을 수 있음

  • "<i>LLM은 소프트웨어 복잡성을 겨냥한 최후의 핵무기 같은 솔루션이다. 진짜 문제를 해결하기보다는 더 거대한 복잡성을 가져와 증상을 완화하려 한다</i>"는 저자의 말에 동의하기 힘듦. AI 도입의 핵심 목적은 "창의적이고 값비싼 고숙련 인재"를 AI를 설계하는 극소수 회사로 중앙집중화시키고, 나머지 모든 회사에서는 크리에이티브 워커를 해고하고 단순한 인력만 남기는 것임. 즉, 모든 비즈니스의 복잡성을 AI로 단순화하는 게 목적임. "오즈의 마법사"를 예로 들면, 다들 커튼 뒤를 보려 하지 않고 자기 일이 쉬워지기만 원함. 오래 봐야 한다는 장기 리스크는 모두 무시하고, 단기 이득만 챙기니까 생기는 현상임

    • 이런 중앙화 사례는 이미 많은 산업에서 일어남. 예를 들어 은행산업은 원래 지역 내에 뱅커가 지역 특성을 반영해 의사결정을 했지만, 전체 HQ가 중앙에서 모든 걸 결정하게 됨. 지역 뱅커들은 “API 아래” 세계로 밀려나고, HQ 엘리트가 모든 부를 가져가는 구조임. “Legibility(가시성)”와 “Seeing Like a State” 같은 개념 참고할 만함

  • 이 글이 정말 마음에 들었음. 문제 해결이 코드보다 더 중요하다는 일부 의견에도 동의함. 하지만 내 생각에는, AI에게 깊은 사고가 필요한 문제까지 맡기기 시작하면, 이런 깊이 있는 문제 해결 능력 자체가 시간이 지나면 퇴화할 수 있음. 단순히 "무언가를 만들어 달라"고 지시하는 것은 진짜 문제 해결이 아니라고 봄

    • 문제 해결과 장인정신, 둘 다 즐길 수 있다고 생각함. 논리적으로 보면 문제 해결이 가장 큰 가치이지만, 누군가에게는 “직접 짜고 만지고 만드는 재미”가 더 컸다는 점에서 그 즐거움이 사라진 것에 아쉬움을 느끼는 사람도 많음. 이 글처럼 자신을 “프로그래머”라 정의하는 사람들은 대체로 문제 해결, 만들기, 손수 해보기, tinkering을 진짜로 즐김
답변달기