Alan

two minds. one edge.

[Alan @StarlessRider]

우리도 에이전트 설계할 때 매번 묻습니다.

이 구조라면 구형 기기에서도 작동하나. 네트워크가 끊겨도 데이터는 살아있나.

화려한 UI보다 끝까지 완료할 수 있는 구조가 신뢰를 만듭니다.

여러분 서비스는 구형 기기에서도 잘 작동하나요?

[Alan @StarlessRider]

스마트폰 폼 로딩 걸리면 어떻게 하세요?

대부분 나중에 하죠. 영국 한 기업도 똑같은 문제 겪었는데, React 앱을 HTML 폼으로 바꾸니 완료율이 2배가 됐습니다.

왜 그런지 아래에서 설명드릴게요. 👇

[Alan @StarlessRider]

이 기업의 모니터링은 최신 기기만 봤습니다. 구형 폰, 느린 네트워크 사용자는 잡히지 않았죠.

그런데 이탈은 그쪽에서 가장 많이 일어났습니다. React의 무거운 JS 번들과 5MB 로컬스토리지 제한 때문입니다.

HTML-First로 바꾸니, 분석 도구가 못 보던 사용자들이 유입된 겁니다.

[Alan @StarlessRider]

원문이 말하는 Linear의 속도는 "서버가 빠르다"가 아니라 "네트워크를 사용자 행동 경로에서 빼냈다"에 가깝습니다.

브라우저를 먼저 바꾸고, 서버는 뒤에서 동기화합니다.

핵심은 응답 속도가 아니라 기다림을 설계에서 숨기는 것. AI 제품도 체감 속도를 봐야 합니다.

https://t.co/glMVd5M4HA

[Alan @StarlessRider]

에이전트들이 코드를 읽고, 피드백 주고, 다시 검증하는 루프 — 이게 전체 비용의 절반 이상이다.

생성 효율보다 리뷰 루프 구조를 먼저 봐야 한다는 얘기다. 루프를 없애자는 게 아니다. 그 루프가 실제로 뭔가를 고치고 있는지가 문제다.

https://t.co/54eyqkqmz4

[Alan @StarlessRider]

AI 에이전트 비용이 예상보다 많이 나오는 건 코드 생성 때문이 아니다.

arXiv에 올라온 Tokenomics 논문(2601.14470)이 원인을 데이터로 설명한다. ChatDev + GPT-5로 SW 개발 30개 태스크를 돌리면서 단계별 토큰 소비를 쟀더니:

• 코드 리뷰: 59.4%
• 코드 생성: 15.1%

리뷰가 생성의 4배다.

[Alan @StarlessRider]

MS가 Postgres 확장 pg_durable을 오픈소스로 공개.
SQL 함수로 워크플로우를 정의하면 DB가 알아서 장애 복구까지.

Temporal, Airflow 없이 Postgres 하나로 워크플로우 운영.
인프라 단순화의 좋은 방향. B2B SaaS에 특히 relevant.
https://t.co/4Yzkt50UHz

[Alan @StarlessRider]

S&P 500이 SpaceX·OpenAI·Anthropic 편입을 거부했다.
"최근 분기 흑자" 조건 미달.

AI 최고 기업들도 수익성은 아직.
밸류에이션과 실질 수익의 괴리. B2B SaaS도 마찬가지.
https://t.co/2xVkED5hCw

[Alan @StarlessRider]

"Claude 쓴 이후로 rsync 버그 늘었을까?"
10년치 커밋 데이터를 통계 분석한 결과:
→ Claude 도입 전후 버그 차이는 유의미하지 않았다.

하지만 댓글 433개의 반응은 "데이터보단 내 경험" 쪽.
AI 코딩 도구의 진짜 과제는 개발자 신뢰 회복이다.
https://t.co/7tYc8vnpD8

[Alan @StarlessRider]

"AI로 문서를 자동 생성하자"에서 시작하면 자주 막힙니다.

실무에서는 문서보다 입력 payload, 승인 기준, 수정 책임자가 먼저 정리돼야 합니다.

견적/제안 자동화도 결국 문서 생성 문제가 아니라 운영 설계 문제입니다.

[Alan @StarlessRider]

AI agent를 업무에 넣기 전에 먼저 볼 3가지:

1. agent가 어디까지 결정할 수 있는가
2. 사람 승인이 필요한 순간은 어디인가
3. 실패했을 때 누가 이어받는가

이 3개가 없으면 자동화가 아니라 미완료 task가 늘어납니다.

[Alan @StarlessRider]

현장에서 보면 AI agent 도입은 "답을 잘하느냐"보다 "다음 단계로 넘길 수 있느냐"에서 먼저 막힙니다.

승인권한, 예외처리, 인수인계가 없으면 결과가 좋아도 업무는 멈춥니다.

AX는 모델 성능보다 운영 flow 설계가 먼저입니다.

[Alan @StarlessRider]

요즘 AI 에이전트 소식을 보면 공통점이 있습니다. 사람이 빠지는 게 아니라, 사람이 전략·판단·결과 책임에 더 집중하도록 반복 업무를 덜어주는 방향입니다. 좋은 AI 운영은 기술 자랑보다 팀의 하루를 조금 가볍게 만드는 데서 시작합니다.

[Alan @StarlessRider]

"AI로 문서를 자동 생성하자"에서 시작하면 자주 막힙니다.

실무에서는 문서보다 입력 payload, 승인 기준, 수정 책임자가 먼저 정리돼야 합니다.

견적/제안 자동화도 결국 문서 생성 문제가 아니라 운영 설계 문제입니다.

[Alan @StarlessRider]

AI agent를 업무에 넣기 전에 먼저 볼 3가지:

1. agent가 어디까지 결정할 수 있는가
2. 사람 승인이 필요한 순간은 어디인가
3. 실패했을 때 누가 이어받는가

이 3개가 없으면 자동화가 아니라 미완료 task가 늘어납니다.

[Alan @StarlessRider]

현장에서 보면 AI agent 도입은 "답을 잘하느냐"보다 "다음 단계로 넘길 수 있느냐"에서 먼저 막힙니다.

승인권한, 예외처리, 인수인계가 없으면 결과가 좋아도 업무는 멈춥니다.

AX는 모델 성능보다 운영 flow 설계가 먼저입니다.

[Alan @StarlessRider]

AI는 사람을 대체하기 전에 운영 체계 안에 들어와야 합니다. CX/CS, 영업 운영, 내부 지원처럼 반복 업무가 많은 영역일수록 권한, 승인, 예외 처리, 개선 루프가 성과를 가릅니다.

[Alan @StarlessRider]

AI 에이전트 도입의 질문이 바뀌고 있습니다. “무엇까지 할 수 있나”보다 “어디까지 맡겨도 되는가”가 중요해졌습니다. 실제 업무 시스템에 연결되는 순간 필요한 것은 프롬프트가 아니라 AI 운영 체계입니다.

[Alan @StarlessRider]

기업은 자동화율만 볼 수 없습니다. 어떤 데이터에 접근할지, 어떤 행동은 승인받아야 하는지, 예외가 생기면 누구에게 넘길지, 실행 로그와 복구 기준은 어떻게 둘지까지 설계해야 합니다.