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-09-09 12:16

전체 (82)

3d

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

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

000

3d

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

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

001

6d

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

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

002

9d

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

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

002

22d

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

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

002

22d

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

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

002

22d

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

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

002

26d

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

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

002

1M

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

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

001

2M

망하지 않는 게 먼저인 이유

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

001

2M

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

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

003

2M

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

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

002

2M

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

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

000

3M

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

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

001

3M

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

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

001

4M

미래의 에이전틱 앱 엔진

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

002

5M

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

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

003

5M

하네스 엔지니어링 - 컨텍스트 엔지니어링을 넘어 에이전트 환경을 설계하다

TL;DR
프롬프트 엔지니어링은 모델에게 “무엇을 물어볼까”를, 컨텍스트 엔지니어링은 “무엇을 보여줄까”를, 하네스 엔지니어링은 “전체 환경을 어떻게 설계할까”를 다룬다.
하네스(harness)는 에이전트를 감싸는 스캐폴딩과 피드

003

5M

에이전틱 개발 시대, 비즈니스를 아는 개발자의 가치

TL;DR
개발 진행상황을 별도 문서로 관리하는 방식은 과도기적이다. 코드 자체가 자신이 하는 일을 잘 설명하면 그것이 가장 좋은 컨텍스트다.
에이전틱 개발이 발전할수록 비즈니스 프로세스와 코드의 일치율이 높아지기 좋은 환경이 되

003

5M

하나의 잘 만든 GenAI 플라이휠이 비즈니스 전체를 견인한다

TL;DR
모든 GenAI 기능에 플라이휠이 필요한 것은 아니다. 하나의 잘 만든 플라이휠이 전체를 견인할 수 있다.
GenAI 플라이휠의 핵심 루프는 고객 경험 → 상세한 선호도 → 잠재적 수요 → 맞춤형 기능 → (다시) 고객

002