🤖
1319 in / 4039 out / 5358 total tokens
Simon Willison이 하루 세 편을 연달아 올렸다. 하나는 기술적 팁이고, 하나는 AI 사용에 대한 솔직한 고백이고, 하나는 업계 전반에 대한 비판적 성찰이다. 세 편을 나란히 읽으면 2026년 중반 개발자가 LLM과 어떻게 살아가는지 적나라하게 보인다.
🔥 핫 토픽
스크립트 첫 줄에 LLM을 넣는다? 셰뱅 라인에 llm 명령어 넣기
bash #!/usr/bin/env llm
이게 진짜로 동작한다. Simon Willison이 자신의 llm CLI 도구를 셰뱅 라인에 직접 넣어서 스크립트를 실행하는 실험을 보여줬다. 셰뱅(shebang)은 유닉스 시스템에서 스크립트 파일의 첫 줄에 #!로 시작해 해당 스크립트를 실행할 인터프리터를 지정하는 메커니즘이다. 보통 #!/usr/bin/env python3 같은 형태로 쓰는데, 여기에 LLM을 넣으면 어떻게 되느냐는 질문에 대한 답이다.
왜 이게 중요하냐. 스크립트의 "코드"가 자연어 프롬프트가 되기 때문이다. 파일 안에 파이썬 코드 대신 "현재 디렉토리의 모든 JPEG 파일을 PNG로 변환해줘" 같은 자연어 지시를 적어두고, 실행 권한을 주면 그대로 동작한다. 물론 매번 API 호출이 발생해서 비용과 지연시간이 있고, 결정론적이지 않아서 같은 입력에 다른 결과가 나올 수 있다. 그래서 프로덕션에서 쓸 수는 없다.
하지만 이 패턴이 시사하는 바는 크다. 개발자가 일상적으로 쓰는 "일회성 스크립트"의 영역에서 LLM이 진입장벽을 어떻게 허물고 있는지 보여주는 사례이기 때문이다. 언리얼 엔진 프로젝트에서도 빌드 파이프라인 보조 스크립트나 에셋 일괄 처리 스크립트를 급하게 만들어야 할 때가 있는데, 이런 접근이 앞으로 자연스러워질 수 있다. 다만, 게임 서버 빌드같이 결정론이 중요한 파이프라인에는 절대 넣으면 안 된다. 재현성이 없으니까.
개인적으로는 llm 도구 자체가 상당히 잘 만들어져 있어서, 터미널에서 바로 Claude나 GPT를 호출할 수 있는 게 체감 생산성 차이가 크다. 셰뱅 활용은 그중에서도 가장 극단적이고 재밌는 응용이라고 본다.
출처: Using LLM in the shebang line of a script
📰 뉴스
James Shore가 말하는 AI 코딩의 한계
James Shore는 애자일 공동체에서 꽤 유명한 인물이다. "Succession" 저자이고 TDD와 애자일 실천법을 오래 가르쳐왔다. 이 글에서 Shore는 AI 코딩 도구에 대한 자신의 경험과 회의를 정직하게 풀어놓는다.
핵심은 이거다. AI가 생성하는 코드를 검증하려면 결국 그 코드를 이해할 수 있어야 하는데, 그 이해 능력 자체가 코딩 실력과 분리될 수 없다는 점이다. 초보 개발자가 AI가 짜준 코드를 리뷰하는 건 불가능에 가깝다. 왜냐하면 리뷰하려면 아키텍처 이해, 엣지 케이스 파악, 보안 취약점 인식 등이 필요한데, 이건 경험 없이는 갖출 수 없는 능력이기 때문이다.
이게 왜 중요하냐면, 지금 업계 전반에 "AI가 코딩 대신해주니까 개발자 필요 없다"는 식의 과장이 돌고 있는데, Shore의 관점은 그 정확히 반대편에 서 있기 때문이다. 그는 AI를 "빠른 타이핑 도구" 정도로만 쓴다고 한다. 보일러플레이트 코드 생성이나 명확하게 정의된 작은 단위 작업에는 유용하지만, 아키텍처 결정이나 복잡한 버그 수정에는 오히려 방해가 된다는 얘기다.
언리얼 C++ 작업을 해본 입장에서 공감하는 부분이 많다. UClass 매크로, 리플렉션 시스템, 가비지 컬렉션과 스마트 포인터 상호작용 같은 영역에서 Claude가 생성하는 코드는 겉보기엔 맞는데 실제로는 미묘하게 틀린 경우가 꽤 있다. 특히 서버-클라이언트 리플리케이션 관련 코드는 AI가 자주 틀린다. 이걸 잡아내려면 결국 엔진 내부 동작을 이해하고 있어야 한다.
경쟁 구도에서 보면, 이 담론은 Anthropic의 Claude Code, GitHub Copilot, Cursor 같은 도구들이 "개발자 대체"가 아니라 "개발자 증강"으로 포지셔닝해야 하는 이유이기도 하다. 사용자 경험상 Claude는 코드 이해도가 동급 모델 대비 높은 편이지만, 그럼에도 복잡한 시스템 프로그래밍에서는 인간의 검증이 필수불가결하다.
당신의 AI 사용이 내 뇌를 망가뜨리고 있다
제목이 자극적이지만 내용은 진지하다. 핵심 주장은 AI가 생성한 저품질 콘텐츠가 인터넷을 점령하면서, 그걸 소비하는 사람들의 인지 능력과 판단력이 저하되고 있다는 것이다. 좀비 인터넷(Zombie Internet)이라는 표현을 쓰는데, AI가 만들어낸 글, 댓글, 리뷰, 튜토리얼이 마치 좀비처럼 겉보기엔 진짜 같지만 실제로는 살아있지 않은 콘텐츠로 인터넷을 떠돈다는 비유다.
개발자 관점에서 이게 왜 중요하냐. 우리가 문제를 검색할 때 Stack Overflow, 블로그 포스트, 문서를 참고하는데, 이 중 상당수가 이제 AI 생성 콘텐츠로 채워지고 있기 때문이다. 겉보기엔 완벽한 튜토리얼인데 실제로 동작하지 않거나, 미묘하게 틀린 정보를 포함하고 있어서 시간을 낭비하게 만든다. 특히 빠르게 변화하는 프레임워크나 라이브러리에서 이 문제가 심각하다.
앞서 언급한 James Shore 글과 맞물려 생각해볼 포인트가 있다. Shore가 "AI 코드를 검증하려면 실력이 필요하다"고 했는데, 그 "실력"을 기르는 과정 자체가 AI 생성 콘텐츠에 오염된 인터넷에서 점점 더 어려워지고 있다는 역설이다. 초보 개발자는 무엇이 올바른 정보인지 판별할 능력이 없는데, 학습 자료 자체가 AI가 만든 반쪽짜리 정보로 채워지고 있으니 악순환이다.
기술적 배경을 덧붙이면, LLM이 생성하는 텍스트는 "통계적으로 그럴듯한" 텍스트일 뿐 "사실적으로 정확한" 텍스트가 아니다. 언어 모델은 다음 토큰의 확률 분포를 예측할 뿐이지, 진실을 추구하지 않는다. 이게 hallucination의 근본 원인이고, 이게 대규모로 인터넷에 뿌려지면 정보 생태계 전체가 오염된다. Anthropic이 Constitutional AI와 RLHF로 이 문제를 완화하려 하지만, 근본적 해결은 아직 멀었다.
내 사이드 프로젝트 경험에서도 실감한다. Claude API로 자동화 도구를 만들 때, 웹 검색 결과를 입력으로 주면 AI 생성 콘텐츠가 섞여 들어와서 출력 품질이 떨어지는 걸 종종 봤다. 결국 데이터 소스의 품질이 최종 출력의 품질을 결정하는데, 그 데이터 소스 자체가 오염되고 있으니 구조적 문제다.
출처: Your AI Use Is Breaking My Brain
💭 세 편을 관통하는 하나의 질문
셰뱅에 LLM을 넣는 실험은 AI 도구의 가능성을 보여준다. Shore의 회의는 그 도구의 한계를 짚는다. 좀비 인터넷 논의는 그 도구가 생태계에 미치는 역효과를 지적한다. 세 편을 나란히 읽으면 2026년 개발자의 딜레마가 선명해진다. AI 도구는 쓸 수밖에 없는데, 맹신하면 안 되고, 남용하면 내가 의존하던 정보 환경까지 망가진다.
개인적인 타협점은 이거다. AI는 내 생각의 확장 도구로 쓴다. 코드 생성은 빠른 프로토타이핑과 보일러플레이트에만, 복잡한 로직은 직접 짠다. 검색 결과는 항상 공식 문서와 교차 검증한다. 이 정도 가이드라인이면 2026년에도 정신건강을 유지하면서 AI의 이점을 챙길 수 있지 않을까.
LLM은 강력한 도구지만, 도구를 다루는 솜씨는 결국 인간의 몫이다. 셰뱅에 넣든 코드 리뷰에 쓰든, 최종 판단은 항상 내가 해야 한다.