소프트웨어를 만드는 일은 예술적 활동입니다
소프트웨어는 아이디어를 코드라는 매체와 그 제약에 맞춰 구현하는 과정에서 만들어집니다. 글쓴이는 그 과정에 필요한 판단과 취향이 결과물의 질을 좌우한다고 주장하며, Reddit에서는 예술과 공예의 경계, 업무 환경의 제약, AI가 창작감을 바꾸는지를 두고 의견이 갈립니다.
최신기사
AI, 개발 도구, 오픈소스, 보안과 인프라의 변화와 이용 조건을 설명하는 최신 기사와 해설입니다.
어느 순간부터 코딩을 재미로 해도 된다는 말을 하기 어려워졌습니다
AI가 코드를 더 빠르게 만들 수 있다는 이야기가 반복되면서, 프로그래밍을 즐기는 마음마저 경제적 가치로 증명해야 한다는 압박이 생겼다고 말합니다. 글쓴이는 결과물의 효용과 만드는 과정의 즐거움은 별개라며, 쓸모없는 프로젝트를 재미로 만들 권리를 되찾자고 제안합니다.
약속을 지켰습니다: DEV 명예의 전당, 작가 65명과 대표작 65편
DEV 커뮤니티에서 작가가 직접 고른 글 65편을 주제별로 묶고, 각 글을 읽은 편집자의 감상과 함께 소개합니다. 반응 수가 적거나 0인 글도 포함해 인기 지표와 별개로 저자가 아끼는 작품을 발견하도록 구성했습니다.
더는 존재하지 않는 일을 애도하는 엔지니어들
AI 코딩 도구 도입 뒤 엔지니어의 일이 코드 작성에서 에이전트 조율과 검증으로 옮겨가며 정체성 상실과 번아웃을 낳는다는 분석입니다. 연구에서는 AI 관련 업무량 증가와 조직의 압박이 번아웃을 키웠고, 자율성과 학습 지원은 이를 줄였습니다.
리누스 토르발스, AI를 활용한 커널 기여를 말하다
리누스 토르발스는 커널 기여에서 AI 사용 여부를 규칙으로 금지하기보다, 기여자가 결과를 이해하고 책임지는지를 봐야 한다고 주장합니다. 컴파일러와 편집기를 예로 들며 도구의 종류보다 기여자의 역량이 중요하다고 설명합니다.
고도에서 맞닥뜨린 존재론적 충격
Rocky Mountain Ruby의 여러 발표는 AI 시대에도 개발자의 역할과 판단이 중요하다는 질문을 던집니다. Rails와 Ruby로 에이전트·RAG를 구현하는 실무부터 테스트, 온보딩, 장애 대응까지 다루며, 코드 생성보다 사람의 경험과 야망을 강조합니다.
인간은 섬이 아닙니다
저자는 AI가 지식 노동을 대신하면 개인의 지적 활동을 뒷받침하던 공동체도 약해진다고 주장합니다. 코드를 쓰고 글을 읽는 사람이 줄면 공유 지식과 동료의 인정이 사라지고, 그 결과 오랫동안 이어지는 지적 활동도 줄어든다는 논지입니다.
클로드가 그러는데요
글쓴이는 논의에서 “Claude가 그러는데요”라고 내세우면 상대의 전문성을 신뢰하지 않는다는 신호가 되고, AI 답변을 검증 없이 받아들이면 불필요하게 복잡한 설계를 낳는다고 비판합니다. 댓글에서는 과잉 설계가 LLM 이전부터 이어진 문제라는 반론과, AI 대신 직접 자료를 찾아 검증하자는 의견이 나옵니다.
링크드인 ‘전문가 흉내’ 프로젝트를 직접 만들어봤습니다
링크드인(LinkedIn)에 반복해서 올라오는 간단한 컴퓨터 비전 프로젝트를 풍자하려고, 작성자가 직접 ‘슬롭 게시물 탐지기’를 만들었습니다. YOLOv8 모델은 약 90분 만에 완성됐고, 글은 프로젝트의 성능보다 그럴듯한 포장이 더 주목받는 플랫폼 문화를 비판합니다.
직관적인 인터페이스는 젖꼭지뿐입니다
컴퓨터 인터페이스는 직관적이지 않고 학습해야 한다는 문구의 유래를 추적합니다. 1994년부터 1995년까지 Usenet 게시물을 살펴보며 표현이 자리 잡은 과정을 정리하고, 2001년 Bruce Ediger가 제안한 더 급진적인 변형도 소개합니다.
12주 동안 커리어를 프로덕션 시스템처럼 운영했습니다 — 대시보드가 먼저 틀렸습니다
저자는 Obsidian에 개인 작업 지표와 일정, 프로젝트 완료 규칙을 기록하며 12주간 커리어를 관찰했습니다. 산출량만 세던 대시보드는 허영 지표가 됐고, 글쓰기와 지표 수정 과정에서 결과물의 품질과 자기기만을 확인하는 법을 배웠습니다.
서로 돕기를 멈추면 우리는 어떤 존재가 될까요?
Stack Overflow의 도움으로 힘든 시기를 버틴 한 개발자의 이야기를 통해, 온라인 공동체가 답변뿐 아니라 사람 사이의 연결과 소속감을 준다고 말합니다. LLM이 답을 대신하더라도 사람의 관심과 도움까지 대신하지는 못한다는 문제를 제기합니다.
오픈소스는 누구를 위한 것인가?
오픈소스가 유지관리자의 선물이라는 관점에 반박하며, 유지관리자와 사용자가 주고받는 혜택과 신뢰에 따른 책임을 살펴봅니다. 평판·영향력·학습·공동 유지보수라는 동기를 구분하고, 기대와 지원 범위를 명확히 소통해야 한다고 주장합니다.
코딩이 예전처럼 즐겁지 않아진 이유를 깨닫기까지
저자는 AI가 코딩의 시행착오와 막힘을 덜어내면서, 자신이 개발에서 느끼던 성취감도 함께 사라졌다고 말합니다. 결과물을 더 빠르고 많이 만드는 일과 직접 문제를 풀며 얻는 기쁨은 다르지만, 그 기쁨을 되찾을 방법은 아직 찾지 못했습니다.
AI를 의인화하지 않고 말하는 법
Emily M. Bender와 Nanna Inie는 소프트웨어에 사고력·감정·행위 의도가 있는 듯한 표현을 줄이고, 시스템 기능과 이를 사용하는 사람을 드러내는 대체 표현을 제안합니다. ‘환각’을 ‘바람직하지 않은 출력’으로, ‘AI 에이전트’를 ‘확률적·검증되지 않은 소프트웨어 조작기’로 바꾸는 식입니다.
좋은 소프트웨어 조언은 왜 따르기 어려울까요
작은 함수나 의미 있는 변수명처럼 실행 여부를 쉽게 확인할 수 있는 규칙과, 상황에 따라 판단해야 하는 원칙을 구분합니다. 경험은 규칙 사이의 충돌과 추상화의 비용을 가늠하는 판단력을 키우며, 좋은 엔지니어는 규칙을 외우는 데서 원칙을 적용하는 단계로 나아간다고 설명합니다.
코드 작성은 쉬워졌지만, 무엇을 만들지는 여전히 어렵습니다
AI가 구현 비용을 낮추면서 쓸모없는 아이디어도 빠르게 작동하는 제품으로 만들 수 있게 됐습니다. 글쓴이는 이제 생산성을 코드 작성량이 아니라 만들지 않아도 될 것을 가려내는 판단력으로 봐야 한다고 말합니다.
CSE 452: Google의 분산 시스템 설계 입문
Steve Yegge는 Amazon의 서비스 지향 아키텍처 전환에서 얻은 운영 경험을 바탕으로, 모든 내부 기능을 외부화 가능한 서비스로 설계해야 플랫폼이 된다고 주장합니다. Google+와 Google의 API 전략을 사례로 들어 제품 중심 문화를 비판합니다.
저는 자주 틀립니다
Boris Cherny는 문제와 제품을 다룰 때 정보 수집, 문제 정의, 단순한 해결책과 목표 설정, 실행을 반복한다고 설명합니다. 새 정보가 나오면 기존 판단을 고치고, 명확하지 않은 문제 정의와 복잡한 계획을 피하려면 실시간 피드백이 필요하다고 말합니다.
시니어 엔지니어의 죽음의 나선 — 증명하려다 번아웃에 빠지지 않는 법
새 직장이나 승진 뒤 더 큰 프로젝트로 자신의 역량을 증명하려다 고립과 과로에 빠지는 패턴을 설명합니다. 해법은 결과를 한 번에 만들려 하기보다 매일 진행 상황을 공유하고, 작은 업무와 협업으로 신뢰와 작업 리듬을 회복하는 데 있습니다.