Human-in-the-Loop

Coinbase는 AI가 코드를 작성하는 환경에 맞춰 엔지니어 채용 면접을 1년 동안 다시 설계했다. 핵심 변화는 코드를 제한 시간 안에 직접 쓰는 능력에서 벗어나, AI를 어떻게 지시하고 결과를 검증하며 잘못된 판단을 교정하는지를 평가하는 방향으로 이동한 데 있다. 원문: Interviewing Engineers in the AI Era: Lessons from a Year of Rebuilding (Coinbase, 2026-07-13) TL;DR 핵심 정리 Coinbase의 AI 생성 코드 비중은 2025년 1분기 5.7%에서 4분기 50%를 넘었고, 현재는 인간 검토를 전제로 거의 100%까지 늘었다. 기존의 URL 단축기·메시지 큐 설계 같은 문제는 AI가 1분 안에 그럴듯한 답을 만들 수 있어, 암기력보다 판단력을 측정해야 하는 상황이 됐다. 면접은 프론트엔드 파일럿, 백엔드 저장소 기반 과제, 2026년 3월 전사 AI 역량 평가의 세 단계로 바뀌었다. 평가 기준은 AI 도구 사용, 적절한 적용, 한계 이해이며, 실무에 가까운 저장소 디버깅과 코드 리뷰가 핵심 과제가 됐다. 아직 검증 중인 영역은 면접 성과와 실제 업무 성과의 상관관계, 그리고 빠르게 낡는 AI 면접 문항의 유효기간이다. 1. 코드 생성이 빨라질수록 판단이 병목이 된다 Coinbase에 병합되는 코드 가운데 AI가 생성한 코드의 비중은 2025년 1분기 5.7%였다. 4분기에는 처음으로 50%를 넘었고, 글이 공개된 시점에는 인간이 모든 코드를 검토한다는 전제 아래 거의 100%에 도달했다고 설명한다. ...

Vivek Haldar는 매일 자신의 과거 글을 다시 발굴해 LinkedIn 게시물 초안을 만드는 에이전트 스킬을 운영한다. 이 워크플로우는 원래 자연어 지시만으로 작성되어 있었다. 어떤 소스를 검색할지, 최근에 다룬 글인지 어떻게 확인할지, 어떤 글을 고를지, 최종 초안을 어떤 형태로 만들지 모두 스킬 문서에 적어 둔 방식이다. 원문: How I Cut an AI Agent’s Token Use by 94% — Vivek Haldar 핵심 핵심 정리 출발점: 자연어 스킬은 처음부터 완벽한 프로그램을 만들지 않고, 반복 실행하며 실제 워크플로우를 발견하게 한다. 컴파일 대상: 소스 조회, 콘텐츠 인벤토리 생성, 최근 게시물 확인, 필터링, 상태 관리는 일반 코드로 옮긴다. LLM이 맡을 일: 필터링된 후보 중 좋은 글을 고르고, LinkedIn 초안을 작성하는 의미 중심 작업만 남긴다. 측정 결과: 저자의 실행에서 토큰 사용량은 94%, 지연 시간은 87% 감소했고 출력 품질은 사실상 같았다. 자연어 스킬은 탐색 단계에 적합하다 처음부터 전용 프로그램을 만드는 일은 성급할 수 있다. 어떤 규칙이 정말 필요한지, 어느 단계에서 사람의 판단이 개입하는지, 예외가 얼마나 자주 발생하는지 아직 알 수 없기 때문이다. ...

LinkedIn Engineering이 2026년 6월 18일 공개한 **“Quality Assurance Agent: Reimagining Software Quality with AI-Driven Autonomous Testing”**는 AI 에이전트가 실제 대규모 서비스의 품질 관리를 어떻게 바꿀 수 있는지 보여주는 사례입니다. 원문: Quality Assurance Agent: Reimagining Software Quality with AI-Driven Autonomous Testing AI 핵심 정리 문제 배경: LinkedIn은 iOS, Android, Web, 36개 이상 언어, 사용자 유형, 멤버십, 실험 조합 때문에 전통적인 UI 자동화만으로 모든 변화를 따라가기 어렵다. 해결 방식: QA Agent는 selector에 의존하지 않고 VLM으로 화면을 읽으며, planner, analytical reasoning model, fine-tuned visual grounding model을 나눠 쓴다. 운영 구조: 안정적인 흐름은 deterministic replay로 빠르게 실행하고, 화면이 바뀌면 vision-based planning으로 넘어간다. 검증 장치: view tree, tracking log, action history, error detection pipeline, golden dataset을 통해 phantom bug보다 실제 버그 탐지를 우선한다. 현재 규모: LinkedIn은 350개 이상 테스트를 30분 주기로 실행하며, QA Agent가 200개 이상 유효 버그를 찾았다고 밝혔다. 1) 전통적인 UI 테스트가 막히는 지점 LinkedIn의 품질 문제는 단순히 화면이 많다는 수준이 아닙니다. 같은 기능이라도 사용자 유형, 언어, 멤버십, 실험군, 개인화 상태에 따라 다른 화면이 나옵니다. LinkedIn은 이 조합을 “하나의 앱이 아니라 수천 개의 permutation"에 가깝게 설명합니다. ...

Hamel Husain의 글 “It’s Hard to Eval” Is a Product Smell은 AI 제품에서 자주 나오는 말, “이 제품은 평가하기 어렵다"를 다르게 봅니다. 저자의 주장은 단순합니다. 평가가 어렵다면 평가 방식만의 문제가 아니라, 제품이 사용자의 검증 과정을 충분히 돕지 못한다는 신호일 수 있습니다. TL;DR 핵심 정리 중심 주장: AI 산출물이 제품을 만든 사람에게도 확인하기 어렵다면, 사용자는 더 큰 비용을 들여 다시 검증해야 한다. 설계 방향: 최종 답만 보여주지 말고 출처, 가정, 중간 계산, 확인하지 못한 항목을 함께 보여줘야 한다. 반복 패턴: 데이터 분석, 수업 계획, 의료 보고서 모두 “완성본 생성"보다 “검증 가능한 작은 단위"가 중요하다. 실무 질문: 사용자는 무엇을 확인해야 하는가, 무엇과 비교할 수 있는가, 어떤 단위로 승인하거나 거절할 수 있는가. 1) 어려운 평가는 제품 냄새다 많은 AI 팀은 평가를 나중 문제로 둡니다. 먼저 모델이 그럴듯한 결과를 내게 만들고, 이후에 자동 평가나 사람 평가를 붙이려 합니다. Hamel은 순서가 반대여야 한다고 말합니다. 제품이 검증하기 쉬운 산출물을 만들도록 설계되어야 평가도 쉬워집니다. ...

Shreya Shankar의 2026년 5월 21일 글 **“Exploring Agent-Assisted Qualitative Analysis”**는 “정성 분석(qualitative analysis)을 에이전트가 어디까지 도울 수 있는가"를 실제 실험으로 검토한 기록입니다. 핵심은 단순합니다. 에이전트가 텍스트를 많이 다루는 것과, 연구적으로 좋은 해석을 만드는 것은 전혀 다른 문제라는 점입니다. 원문: Exploring Agent-Assisted Qualitative Analysis TL;DR 핵심 정리 문제 설정: 저자는 grounded theory 기반 정성 분석을 대상으로, 사람 개입 정도와 멀티에이전트 구성을 바꿔 6개 조건을 비교했다. 핵심 관찰 1: 무개입 또는 약한 개입 조건에서 에이전트는 분석보다 재진술(paraphrase)에 가까운 출력을 내는 경향이 강했다. 핵심 관찰 2: exp1에서 “트윗 길이 ↔ 코드 수” 상관이 ρ=0.81로 높았고, 메모 피드백 조건(exp2-memo)에서는 ρ=0.15까지 낮아졌다. 핵심 관찰 3: 코드 재사용이 거의 일어나지 않아(예: exp1에서 코드 93.8%가 1회 사용) 누적적 코드북 형성이 약했다. 실무 결론: 정성 분석 자동화의 병목은 모델 성능보다 “언제·어떻게 사람 판단을 끼워 넣는지"를 정의하는 워크플로우 설계에 있다. 1) 왜 이 문제가 어려운가 정성 분석은 정답이 고정된 작업이 아닙니다. 같은 데이터라도 연구 질문, 독자, 맥락에 따라 서로 다른 해석이 성립할 수 있습니다. 저자는 이 지점을 AI 시스템의 난제로 봅니다. 즉, “정확도 하나"로 환원할 수 없는 작업이며, 평가 기준도 분석 과정에서 계속 변합니다. ...

출처: https://larsfaye.com/articles/agentic-coding-is-a-trap Lars Faye는 “AI가 코드를 쓰고 인간은 오케스트레이션만 하면 된다”는 흐름이 생산성 혁신처럼 보이지만, 실제로는 팀의 핵심 개발 역량과 비용 구조를 동시에 흔들 수 있다고 경고한다. TL;DR 핵심 정리 핵심 문제: 에이전틱 코딩은 초반 산출 속도를 높이지만, 사람이 코드에서 멀어질수록 장기적으로 이해·설계·디버깅 능력 저하가 발생할 수 있다. 감독자 역설: AI 출력을 제대로 검증하려면 숙련 개발자의 판단력이 필수인데, AI 의존이 커질수록 그 판단력 자체가 약화되는 모순이 생긴다. 주니어 성장 리스크: ‘직접 작성→실패→수정’ 경험이 줄면 코드 리뷰만으로는 학습 곡선이 가파르게 떨어질 수 있다. 비용/벤더 리스크: 토큰 사용량과 모델 성능은 고정비가 아니라 변동성이 큰 외생 변수이므로, 전면 도입 시 예산·운영 안정성이 낮아질 수 있다. 실무 결론: 에이전트를 기본값으로 두기보다, 문제 유형별 사용 경계와 수동 코딩 훈련 루프를 함께 유지해야 한다. 1) 글의 핵심 주장: “속도”와 “역량”은 같은 축이 아니다 글은 에이전트 중심 개발이 단기적으로는 빠르게 많은 코드를 만들어내지만, 그 과정에서 사람이 코드의 실제 인과관계와 설계 의도를 놓치기 쉬워진다고 본다. 즉, 산출량이 늘어도 팀의 실질적 문제 해결 능력이 같이 성장한다는 보장은 없다는 지적이다. ...