AI 없이 한 달
오픈소스 프로젝트를 유지하는 개발자가 업무에서 AI 코딩 에이전트를 쓰다 코드 이해와 검토 능력이 약해졌다고 느껴 사용을 중단한 경험을 소개합니다. 그는 TDD와 직접 코드 작성으로 돌아간 뒤 변경 사항을 설명하고 배포하는 자신감을 되찾았다고 말합니다.
개발·오픈소스 · 최신기사
개발 도구와 언어, 웹 기술과 오픈소스 프로젝트의 변화를 다룹니다.
LLM 시대에도 프로그래밍을 즐기는 법
Haskell 개발자인 글쓴이는 LLM에게 코딩을 맡기는 대신 조사·계획·기록·검토를 맡기고, 직접 코드를 쓰는 작업 흐름을 제안합니다. 생산성을 조금 얻으면서 코드 이해와 프로그래밍 기술, 작업의 즐거움을 지키는 방법을 설명합니다.
Rails World에 못 가서 아쉬웠을까? 컨퍼런스에서 실제로 얻고 싶은 것
Rails World에 참석하지 못한 Ruby 개발자가 대형 행사와 소규모 컨퍼런스의 장단점, 사람을 만나고 새로운 아이디어를 얻는 경험을 돌아봅니다. 첫 컨퍼런스라면 작고 부담 없는 행사부터 시작하고, 자신이 속한 커뮤니티가 모이는 곳을 고르라고 권합니다.
제1원칙 사고와 에이전트 시대의 엔지니어링
좋은 시니어 엔지니어는 익숙한 기술적 제약을 답으로 받아들이기보다, 무엇을 왜 만드는지부터 따져 가장 작은 다음 단계를 찾습니다. 에이전트를 쓸 때도 경험을 잠시 내려놓고 가능성을 살피되, 설계와 검토에서 사람의 판단을 놓치지 말아야 한다는 글입니다.
구글을 떠납니다
Robert O’Callahan이 AI를 더 저렴하고 빠르게 만드는 일에 기여하지 않겠다며 Google을 떠납니다. AI 위험과 사회적 영향을 우려하는 한편, Pernosco와 rr을 계속 관리하고 AI 에이전트의 디버깅을 연구하겠다고 밝혔습니다.
클로드식 문체에 지쳤습니다 — AI 보조 개발은 어디로 갈까요
개발자 Kristian Polso는 AI 도구 사용을 강하게 밀어붙이는 경영진이 코드 품질과 유지보수성을 놓친다고 지적합니다. 비용 상승과 개발자의 불만이 쌓이면 AI 사용이 조정되고, 다른 도구와 함께 쓰는 균형점에 도달하리라고 전망합니다.
사이드 프로젝트를 그만 만드세요. 아무도 신경 쓰지 않습니다 — 불편한 계산
사이드 프로젝트가 취업, 학습, 사업에 도움이 된다는 통념을 반박합니다. AI가 구현 결과물을 빠르게 만들어내는 시대에는 실제 사용자에게 배포하고 운영하며 얻는 판단력이 더 가치 있다고 주장합니다.
AI에는 지혜가 없고, 당신도 그렇게 될 수 있습니다
AI가 코드를 빠르게 만들더라도 유지보수성과 설계 품질을 즉시 평가하기는 어렵습니다. 글은 코드 읽기와 실수에 대한 책임을 포기하면 개발자의 숙련도도 자라지 않는다고 지적하며, AI를 도구로 쓰되 판단과 학습을 넘겨서는 안 된다고 주장합니다.
엔지니어가 말한 Claude Code의 그늘 — 하루 12시간 엔터만 누르는 일
익명 엔지니어 voxium은 Claude Code가 사양서·테스트·티켓·보고서까지 만들면서 엔지니어가 하루 12~13시간 프롬프트와 엔터 입력만 반복한다고 주장합니다. 커뮤니티에서는 생산성보다 검토·책임·학습 부담이 커졌다는 증언과 가드레일을 갖추면 유용하다는 반론이 맞섭니다.
충분히 잘하고 있나요? 기준은 누가 정하나요?
기술 면접에서 수동 코드 리뷰를 놓친 한 개발자가 면접 평가의 기준과 개발자 역량의 관계를 묻습니다. 즉각적인 코드 패턴 기억보다 문제 해결, 학습, 도구 활용, 실제 결과물을 평가해야 하며, 한 번의 실수가 연봉 기대치를 낮춰서는 안 된다고 주장합니다.
전통적 코딩과 에이전틱 코딩의 차이 — 플로우 상태의 문제
AI 코딩 에이전트는 코드 생산량을 크게 늘릴 수 있지만, 프롬프트와 대기·알림·컨텍스트 전환이 전통적인 코딩의 촘촘한 피드백 루프와 몰입을 끊을 수 있습니다. 글은 작업을 작게 나누고 같은 프로젝트 안에서 결과를 검토하는 체크포인트를 두어, 생산성과 코드 이해도를 함께 유지하는 방법을 제안합니다.
AI는 여러분을 더 나쁜 엔지니어이자 더 나은 직원으로 만들고 있습니다
AI 코딩 도구는 티켓 처리와 기능 출시 같은 가시적 생산성을 높이지만, 그 과정에서 디버깅 감각과 낯선 문제를 스스로 푸는 능력의 성장을 막을 수 있습니다. 이 글은 AI를 쓰지 말자는 주장이 아니라, 처리량을 엔지니어링 역량의 대리 지표로 삼아 온 평가 방식의 한계를 지적합니다.
부정적 피드백의 아름다움과 두려움
첫 컨퍼런스 발표에서 익명의 날카로운 피드백을 받은 경험을 통해, 불편한 평가는 즉시 거부하기보다 감정을 가라앉힌 뒤 개선의 단서로 살펴볼 필요가 있다고 이야기합니다. 접근성을 지키면서도 발표를 더 역동적으로 만드는 방법을 고민하게 된 과정이 핵심입니다.
EchoCadence를 만들었습니다 — 단어를 오래 기억하게 하는 어휘 앱
EchoCadence는 사용자가 직접 어휘를 추가하고, 복습 난이도에 따라 다음 복습 시점을 정하는 spaced repetition 기반 앱입니다. 개발자는 복습 이력을 TimescaleDB hypertable로 저장하고 continuous aggregate로 일별 통계를 만들어, PostgreSQL 모델 안에서 학습 데이터를 시계열로 다루는 방법을 구현했습니다.
거대한 미지의 코드베이스에 갑자기 투입됐나요? 생존 가이드입니다
대규모 코드베이스를 처음 접했을 때 모든 파일을 읽으려 하지 말고, 애플리케이션을 실행한 뒤 진입점과 실제 기능의 흐름을 추적하며 구조를 파악하라고 제안합니다. 작은 변경과 팀원·Git 기록·테스트 활용, 학습 내용 문서화를 통해 일주일 안에 실용적인 코드베이스 지도를 만들 수 있다고 설명합니다.
첫 AI 심사관 인터뷰 — 대체 무엇이 잘못될 수 있을까요?
AI의 도움으로 금융 의사결정 도구를 만든 뒤 AI 심사관의 기술 인터뷰를 받은 참가자의 회고입니다. 구현 세부사항과 검증 한계를 설명하지 못했던 경험을 통해, AI-assisted 개발에서도 설계·코드·실패 조건을 직접 이해하고 설명하는 능력이 중요하다는 점을 보여줍니다.
배우면서 바로 글을 씁니다
새로운 기술을 배울 때 겪은 질문과 탐색 과정을 해결 직후 기록하자는 글입니다. 초보자용 설명과 전문가용 문서 사이에는 용어와 맥락을 연결해 주는 자료가 부족하므로, 성공뿐 아니라 실패와 막혔던 지점까지 남기는 것이 다른 학습자와 문서 유지보수자 모두에게 도움이 된다고 설명합니다.
면접에서 AI를 사용했다는 이유로 탈락했습니다 — 그런데 면접관도 AI를 쓰고 있었습니다
AI를 사용한 사실을 공개했다가 면접에서 탈락한 개발자가, 같은 면접에서 AI를 사용하는 면접관을 봤다고 말합니다. 글은 코딩 평가가 문법 암기보다 AI의 오류를 판별하고 결과를 통제하는 판단력을 측정해야 한다고 주장합니다.
스스로 바보가 되는 법 101 — AI 의존이 기술 면접에서 드러낸 것
Wasmer 기술 면접을 위해 엣지 배포, 대시보드, 내구성 워크플로 시스템까지 준비했지만, 간단한 캐시 파일의 수동 코드 리뷰에서 코드의 문제를 발견하고도 설명하지 못해 고전합니다. 글쓴이는 AI를 활용한 개발 역량과 기초 코드를 직접 읽고 설명하는 능력 사이의 간극, 그리고 AI 시대에 맞지 않는 채용 방식이 무엇인지 되묻습니다.
흑백 ATS 세계에서 다채로운 경력을 살아가기
Applicant Tracking System(ATS)은 이력서를 직함·회사·기간·기술 같은 구조화된 필드로 압축하면서 비선형 경력의 연결고리와 전이 가능한 역량을 버립니다. 글은 편향을 줄이려는 구조화된 채용의 필요성을 인정하면서도, 모든 지원자에게 같은 질문과 평가 기준을 적용해 경력 간 연결을 기록할 필드를 추가하자고 제안합니다.