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]

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