Haandol - mysetting

12:37 5/31

haandol.github.io

mobile screenshot relative

12:37

haandol.github.io

mobile screenshot

Haandol
https://haandol.github.io/

TL;DR

최종 피드 수집: 2026-10-06 14:16

전체 (85)

1d

Software Factory를 돌리기 전에 정해야 할 것들

TL;DR
Software Factory는 개발과 검증, 운영 피드백을 반복하는 시스템이다.
자율적으로 맡길 범위가 넓어질수록 Eval이 더 중요해진다.
목표 지표에는 품질 저하를 드러낼 tension metrics를 함께 둔다.

000

1d

에이전트 애플리케이션 평가 플레이북

TL;DR
하나의 사용자 흐름과 최소 성공 조건부터 정한다.
Trace 분류와 반복 평가는 가능한 한 자동화한다.
목표 지표와 텐션 메트릭으로 개선을 함께 판단한다.
시작하며
영어 연습을 도와주는 앱을 만들었다고 하자. 사용자가

000

4d

에이전트가 강해질수록, 서비스의 해자는 어디로 옮겨갈까

TL;DR
비즈니스의 해자가 애플리케이션 레이어에서 데이터로 옮겨가고 있다.
에이전트가 여러 서비스를 이용하는 다음 웹 브라우저가 될 것이다.
MCP나 플러그인으로 서비스의 데이터와 기능을 에이전트에 연결하려고 한다.
시작하며
최

001

1M

AWS AI-DLC에 대한 단상 — 내가 믿는 에이전틱 개발의 방향

TL;DR
AI-DLC는 컨셉·프로세스·구현 전반에서 내가 믿는 에이전틱 개발과 크게 다르다.
개발자 출신인 나는 제품의 결과를 함께 소유하고 학습하는 팀이 더 필요해졌다.
시작하며
최근 지금의 역할과 내가 믿는 방향 사이의 거리

003

1M

내가 믿지 않는 방향을 더는 전달할 수 없어서 — AI-DLC와 이직을 결심한 이유

TL;DR
AI-DLC의 방향은 내가 믿는 에이전틱 엔지니어링의 미래와 반대에 가깝다.
개발자 출신인 나는 제품의 결과를 함께 소유하고 학습하는 팀이 더 필요해졌다.
시작하며
최근 지금의 역할과 내가 믿는 방향 사이의 거리를 오래

003

1M

Agent로 개발을 자동화한 다음, 개발자는 어디로 갈까

TL;DR
Agent로 개발이 빨라지면 업무 프로세스가 다음 병목이 된다.
외부 FDE가 떠난 뒤 SOP와 평가를 고칠 사람이 필요하다.
고전 개발자의 다음 형태 중 하나가 FDE인 것 같다.
시작하며
최근 기존 개발자가 앞으로

003

1M

같은 AI 도구를 썼는데 왜 어떤 팀은 10배까지 빨라졌을까 — Frontier Development의 다섯 습관

TL;DR
같은 도구에서도 일하는 방식에 따라 성과가 크게 갈렸다.
Frontier 팀은 다섯 가지 습관으로 Agent의 자율성을 높였다.
코드 다음 병목은 리뷰와 의사결정이었다.
시작하며
최근 CTS-SW 글을 정리하면서 AI

003

1M

AI로 코드는 빨리 만들었는데 왜 리뷰는 더 힘들까 — 이동한 인지부하 줄이기

TL;DR
AI는 구현 과정의 인지부하를 리뷰 시점으로 옮긴다.
사람은 코드보다 비즈니스 계약을 이해해야 한다.
계약 준수와 숨은 가정이 드러나야 HITL을 줄일 수 있다.
시작하며
고객과 AI 코딩에 관해 이야기하다가, Agen

005

1M

AI로 코드는 빨리 만들었는데, 왜 리뷰는 더 힘들까 — Builder Experience에 대한 생각

TL;DR
AI는 구현의 집중 시간을 리뷰의 인지부하로 옮긴다.
Builder Experience의 병목은 사람의 이해 속도다.
계약 기반 리뷰가 HITL 제거에 더 유리해 보인다.
시작하며
얼마 전 Max Kanat-Alexan

004

1M

AI 도입 성과는 언제 비즈니스 지표로 봐야 할까 — AHEAD·LEVER 다시 보기 2/2

TL;DR
Shape에서는 하네스와 리뷰 부담의 변화를 본다.
Scale에서는 CTS-SW와 비즈니스 성과를 함께 본다.
AHEAD와 LEVER는 종합점수가 아닌 질문 목록이다.
시작하며
1/2 글에서 설명한 3S를 처음 정리했을

005

1M

AI 코딩 도구가 정말 개발 비용을 줄였을까 — CTS-SW 시작하기

TL;DR
CTS-SW는 고객에게 전달된 소프트웨어 단위당 비용을 본다.
개발과 배포 중 한쪽만 빨라지면 다른 쪽이 병목이 된다.
AI 효과는 테스트·CI/CD·배포 안전장치가 갖춰질수록 커진다.
시작하며
AI 코딩 도구를 도입하

004

2M

프로덕션에서 살아남는 하네스 0층 만들기 — ALPS와 ADR로 추상화 경계 지키기

TL;DR
저장소의 모든 텍스트는 최신 컨텍스트여야 한다.
ALPS Writer는 요구사항을 source of truth로 지킨다.
요약과 태스크는 세션 안에서만 휘발시킨다.
시작하며
최근 모델이 좋아지면서 에이전틱 개발에 필요했

002

3M

망하지 않는 게 먼저인 이유

TL;DR
성공은 저마다 다르지만, 실패는 비슷한 이유로 온다.
성공법은 아무도 모르니, 할 수 있는 건 시도 횟수를 늘리는 것이다.
실험이 싸지는 환경을 먼저 만들고, AI로 시도 비용을 낮춘다.
시작하며
옛날에 사업을 하다가

003

3M

EncBird에 하네스를 한 겹씩 씌워온 과정 — 실전 하네스 엔지니어링

TL;DR
하네스 엔지니어링은 에이전트에게 자율성을 부여하기 위한 것이다.
처음부터 거창하게 설계하는 게 아니라, 에이전트가 실수할 때마다 한 겹씩 덧씌워 쌓아가는 점진적 과정이다.
시작하며
이전 글들에서 하네스 엔지니어링이 무엇

004

3M

토큰 가치와 비즈니스 가치의 괴리, 그리고 조직의 AI 도입 3단계

TL;DR
토큰 가격과 토큰당 비즈니스 가치 사이의 괴리를 줄이는 것이 하네스 엔지니어링이고, 조직의 AI 도입은 Stream → Shape → Scale 세 단계를 거칠 수밖에 없으며 모든 투자는 마지막 단계에서 복리로 돌아온다

003

3M

현상을 해석하는 렌즈, 그리고 에이전틱 엔지니어링

TL;DR
렌즈는 수많은 변수를 의도에 맞게 상수로 고정해 현상을 예측 가능하게 만드는 틀이고, 나는 에이전틱 엔지니어링을 human in the loop의 제거라는 렌즈로 본다.
1. 렌즈란 무엇인가
경제학에서는 경제 현상을 설

002

4M

에이전트의 다음 진화는 똑똑한 도구에서 온다

TL;DR
지금의 smart pipeline, dumb edge 구조는 SOA가 그랬듯 점차 한계에 닿을 수 있고, 도구 자체가 똑똑해지는 dumb pipeline, smart edge 쪽으로 흐름이 옮겨가지 않을까 싶다.
시작하

003

4M

에이전틱 엔지니어링과 과도기적 기술들

TL;DR
에이전틱 엔지니어링의 최종 방향은 human in the loop의 제거이며, 이 흐름 속에서 사람을 파이프라인 안에 유지하기 위해 설계된 도구들은 과도기적 기술로 남을 가능성이 크다.
시작하며
소프트웨어 개발이라는 일

002

5M

미래의 에이전틱 앱 엔진

TL;DR
소프트웨어 개발의 목적은 결국 비즈니스 요구사항을 코드로 전환하는 것이고, VM→컨테이너→서버리스의 흐름은 그 목적에서 멀어지는 인프라 레이어를 계속 추상화해온 결과다.
에이전틱 개발의 이상적인 다음 단계는 에이전트가

002

6M

하네스 없는 멀티 에이전트는 그냥 컨텍스트 엔지니어링이다

TL;DR
에이전트는 “프롬프트가 다른 LLM”이 아니라, LLM·도구·컨텍스트·하네스가 결합된 실행 단위다.
멀티 에이전트가 의미 있으려면, 각 에이전트가 자기만의 도구·복구 루프·검증 방식·컨텍스트 경계를 가진 독립적인 실행

004