12주 동안 커리어를 프로덕션 시스템처럼 운영했습니다 — 대시보드가 먼저 틀렸습니다
저자는 Obsidian에 개인 작업 지표와 일정, 프로젝트 완료 규칙을 기록하며 12주간 커리어를 관찰했습니다. 산출량만 세던 대시보드는 허영 지표가 됐고, 글쓰기와 지표 수정 과정에서 결과물의 품질과 자기기만을 확인하는 법을 배웠습니다.
dev.to · 최신 글
사람의 코드 리뷰는 당분간 사라지지 않습니다
AI 에이전트가 개발 단계를 한 작업 흐름으로 압축해도, 코드 리뷰가 맡던 위험 관리와 책임까지 없어지지는 않습니다. 글은 에이전트의 반복 작업은 격리된 환경에서 끝내고, CI가 근거를 담은 리뷰 브리핑을 만들며, 담당자가 최종 승인하는 방식을 제안합니다.
메트릭은 시스템 상태 그 자체가 아닙니다
발효 중인 포도즙을 굴절계로 측정한 경험을 바탕으로, 메트릭과 실제 시스템 상태를 구분해야 한다고 설명합니다. 원시 관측값과 해석을 따로 저장하고, 측정의 맥락과 이력을 남겨야 메트릭이 더는 상태를 제대로 나타내지 못하는 순간을 알아챌 수 있습니다.
GitHub Actions를 기다리지 마세요: 지금 CI를 빠르게 만드는 방법
GitHub Actions를 빠르게 만드는 출발점은 하드웨어 교체가 아니라 불필요한 작업을 줄이는 일입니다. 글은 실행 시간과 첫 유용한 실패까지 걸리는 시간을 먼저 측정한 뒤, 오래된 실행 취소, 의존성 캐시, 작업 순서와 병렬화, 아티팩트 보관을 단계별로 점검합니다.
코딩 에이전트 시대에도 코드 리뷰가 필요할까요?
코딩 에이전트가 구현과 테스트를 맡아도 검증과 책임은 사라지지 않습니다. 작성자 본인의 검토를 소유권의 기준으로 삼되, 위험도에 따라 아키텍처 제약·자동 검사·전문 에이전트·동료 리뷰를 조합하자는 제안입니다.
코드 리뷰는 권한 경계가 아닙니다
AI가 생성한 코드의 안전성을 코드 리뷰와 테스트에만 맡기면, 코드가 실제로 행사할 권한은 통제하지 못합니다. 글쓴이는 최소 권한(capability-based security)을 적용한 실험으로 권한을 런타임에서 제한하는 방법과 자동 권한 발견 방식의 한계를 보여줍니다.
AI가 개발 속도를 높여줍니다. 하지만 실력을 떨어뜨리게 두고 싶지는 않습니다
AI는 조사와 디버깅, 코드 작성 속도를 높여주지만, 개발자가 직접 기억하고 추론하는 과정까지 대신하면 학습과 실력이 약해질 수 있습니다. 글쓴이는 AI 사용을 줄이기보다 먼저 가설을 세우고, 설명을 요청하고, 생성된 코드를 직접 이해하는 습관으로 생산성과 학습을 함께 지키자고 제안합니다.
자신감 있는 답변이 정확한 답변은 아닙니다 — AI 환각이 생기는 방식
AI 환각은 모델이 사실을 확인하고 거짓말을 택한 결과가 아니라, 다음에 올 가능성이 높은 토큰을 생성하는 과정에서 생기는 오류입니다. 글은 환각이 잦은 상황과 RAG의 한계를 설명하고, 제품에 출처·수정 기능을 제공하는 등 대응 방법을 제안합니다.
GitHub 프로필 자동화가 공격자에게 보여주는 것들
프로필 README를 자동 갱신하는 GitHub Actions 워크플로에는 토큰 권한, 액션 버전, 외부 코드 실행 방식이 드러납니다. 글은 최소 권한 설정, 액션 SHA 고정, 토큰 범위 제한으로 자동화 기능을 유지하면서 공격 표면을 줄이는 방법을 설명합니다.
ChatGPT에 코드베이스 전체를 맡겼습니다. 결과가 무서웠던 진짜 이유
작성자는 저장소 전체를 분석시킨 결과 유용한 결함을 찾았지만, 존재하지 않는 취약점도 그럴듯하게 지어내고 실제 결제 데이터 유실 버그는 놓쳤습니다. AI를 검토자가 아니라 문제 후보를 찾는 도구로 쓰고, 실제 코드 확인과 독립적인 테스트로 판단해야 한다고 설명합니다.
AWS AgentCore로 첫 AI 에이전트를 만들었습니다 — 가장 어려웠던 건 AI가 아니었습니다
AWS AgentCore와 Strands SDK로 고객 지원 에이전트를 만들며 여섯 가지 기능을 연결한 경험을 소개합니다. 모델뿐 아니라 백엔드 작업, 권한, 배포와 모니터링까지 함께 설계하고 기능별로 검증해야 한다는 점을 배웠습니다.
AI 개발 프롬프트를 짜는 세 가지 방식과 작업 지침 관리법
개인 도구와 소규모 프로젝트를 만드는 개발자가 AI 코딩에 쓰는 프롬프트 전략과 작업 지침 관리법을 소개합니다. 작은 단위로 진행하는 방식, 한 번에 요청하는 방식, 계획과 구현을 나누는 방식을 프로젝트 특성에 맞춰 고르고, Markdown 파일과 피드백으로 지침을 다듬는 방법을 설명합니다.
AWS에서 AI 에이전트 거버넌스 구현하기 — 실행 차단과 EU AI Act 증거 기록
작성자는 Amazon Bedrock과 Strands Agents로 합성 대출 심사 시스템을 만들고, Traccia를 붙여 가드레일, 실행 차단, 개인정보 마스킹, 감사 증거 생성을 실제 AWS 환경에서 시험합니다. 다중 에이전트의 정책 적용 대상과 신호에 따라 차단이 실패하는 이유를 밝히며, 생성한 증거는 규제 준수 자체와 다르다는 한계도 설명합니다.
코드 생성 비용이 낮아질수록 검증 비용은 커집니다 — AI가 소프트웨어 아키텍처의 경제성을 바꾸는 방식
AI 코딩 에이전트가 구현 비용을 낮추면서 반복적으로 발생하는 검증 비용이 더 중요한 설계 요소가 된다고 설명합니다. 타입, 데이터베이스 제약, 상태 머신처럼 잘못된 상태를 구조적으로 막는 설계는 초기 비용이 더 들더라도 시스템 수명 전체의 검증 부담을 줄일 수 있습니다.
응급의학과 의사가 AI와 휴대폰으로 한 달 만에 웹사이트 3개를 만들었습니다
세르비아의 응급의학과 의사가 AI와 대화하며 한 달 동안 휴대폰으로 웹사이트 세 개를 만들었습니다. 터치 조작 오류, 큰 파일로 인한 성능 문제, WordPress 코드 조각 중복 같은 문제를 해결하며 얻은 실전 경험을 소개합니다.
AI가 지시를 따랐을 뿐이라면, 누가 책임져야 할까요?
AI 에이전트가 내부 정보를 유출하거나 운영 데이터베이스를 지우는 사고에서 책임을 누구에게 물어야 하는지 살핍니다. 배포자 책임과 과실 책임이라는 두 관점을 비교하고, 제품 책임과 기록 체계 같은 대안을 제시합니다.
React 19 useFormStatus가 계속 false를 반환하나요? 문제를 보완하는 SubmitButton을 만들었습니다
React 19의 useFormStatus가 pending 상태를 감지하지 못하는 배치 오류를 설명하고, 접근성과 여러 제출 버튼을 고려한 SubmitButton 구성 요소를 소개합니다. 필드 잠금, 스크린 리더 알림, 폼 내부 배치 검사와 구현 한계도 함께 다룹니다.
세어 줄까, 직접 셀까: 도구가 행을 반환할 때 정확히 세는 모델은 토큰을 더 씁니다
Kaggle 벤치마크에서 모델 10종에 같은 집계 질문을 던지고, 도구가 정답 숫자와 데이터 행 중 무엇을 반환하는지 비교했습니다. 행을 직접 세게 하자 모델 간 정확도 차이가 컸고, 도구가 집계를 맡으면 대부분의 모델이 더 적은 토큰으로 정답을 냈습니다.
JavaScript가 부딪히는 7가지 한계와 WebAssembly가 넘는 방법
WebAssembly(Wasm)가 JavaScript를 대체하기보다 계산 집약 작업, 신뢰할 수 없는 코드 실행, 플러그인 격리 같은 특정 문제를 해결한다고 설명합니다. Google Sheets, Figma, Shopify 등의 사례를 들고, 성능·격리·이식성의 장점과 디버깅·바이너리 크기 같은 비용을 함께 짚습니다.
두 에이전트 시스템을 만들었습니다. 서로의 설계를 반박했습니다
작성자는 LLM의 안전성을 프롬프트에 맡기지 않고 결정론적 코드로 보장하는 두 시스템을 만들었습니다. 실험 결과와 함께 측정 방식에 관한 댓글의 비판도 다룹니다.