나는 Digital Twin Universe 개념에 공감함
내 코드베이스도 외부 서비스 통합이 많아서 테스트 시 외부 호출을 막으면 거의 아무것도 검증할 수 없었음
그래서 Okta, Jira, Slack, Google Docs 등처럼 각 API의 가짜 구현체를 만들어 테스트함
다만 UI까지 복제하진 않고 API 동작만 흉내냈음
“엔지니어 1인당 하루 $1,000 토큰을 안 쓰면 개선 여지가 있다”는 말은 너무 비현실적으로 들림
이게 진짜 주장인지 의심스러움
계산해보면 연간 약 $250k 수준임
만약 AI가 그만큼의 생산성을 낸다면 합리적일 수도 있음
현실적으로는 두 명의 주니어 엔지니어 정도의 효율일 듯함
결국 인간은 리드 역할로 계획과 검증만 담당하게 될 것 같음
과장된 낙관론이긴 하지만 완전히 미친 얘기는 아님
나는 월 $20짜리 Claude, OpenAI 구독만 쓰고 있음
토큰 다 쓰면 산책하거나 책 읽음 가속주의자는 아니지만 그래도 일은 충분히 함
나는 StrongDM 팀 중 한 명임
하루 $1,000 토큰을 쓰는 건 쉽지만, 생산적으로 쓰는 건 어렵다는 게 핵심임
이건 단순한 허세처럼 보임
“우린 너희보다 더 AI에 앞서 있다”는 신호 보내기 같음
글을 읽으며 민망함을 느꼈음
기존의 mocks나 시뮬레이션 테스트를 “혁신”처럼 포장한 느낌임
그래도 이들이 비용 구조를 솔직히 드러낸 점은 인정함
나는 그들의 사이트에서 실제 코드나 제품을 찾고 있었음
유일하게 찾은 건 strongdm/attractor였음
“캐나다 여자친구 코딩”이 이제 비즈니스 모델이 된 셈임
추가로 strongdm/cxdb도 발견했지만 커밋 히스토리가 정리돼 있었음
Products 페이지에 데이터베이스와 ID 시스템도 있음
여러 에이전트가 협업하려면 공유 컨텍스트와 권한 시스템이 필수적임
BoundaryML의 BAML 관련 웨비나를 들었음 Spec-driven development는 인간이 루프 안에 있는 구조화된 워크플로우를 만드는 접근임 /research → /plan → /implement 루프를 명확히 정의하고, 각 단계에서 인간 검증을 거치게 함
StrongDM의 “인간이 코드를 쓰거나 읽지 않는다”는 주장과는 정반대의 철학임
또 하나의 공허한 블로그 글처럼 느껴짐
실질적인 결과물은 없고, $1,000/일 토큰 이야기는 투자자 어필용 같음
검증 문제를 해결하지 못하면 이 모든 건 허세에 불과함
자동 리뷰나 가드레일을 세워도 결국 사양과 결과의 일치를 확인할 사람은 인간임
우리는 Speedscale에서 트래픽 캡처와 재생으로 검증을 자동화하고 있음
사실 인간 개발도 완벽하지 않음
코드 리뷰, 테스트, QA 등 여러 체계적 검증 절차가 이미 존재함
중요한 건 AI가 완벽하냐가 아니라 시스템 전체 품질이 수렴하느냐임
내 경험상 Opus 4.5 기준으로는 약간의 순이익 효과가 있음
나도 거의 동의함
핵심은 생성보다 검증임
여러 독립 에이전트가 서로 이견을 드러내며 합의하는 구조를 만들고 있음
간단히 말해, 검증과 보안 테스트를 최종 사용자에게 떠넘기는 셈임
명세 기반 언어와 정형 검증을 더 적극적으로 써야 함
결국 프로그래밍이란 “명세를 구체화하는 행위”로 재정의될 것임
하루 $1,000 토큰이라면 인간보다 AI에 더 많은 돈을 쓰는 셈임
이건 AI 비전의 붕괴 지점처럼 보임
연간 $240k면 신입 FANG 엔지니어 급임
솔직히 Claude보다 못한 주니어도 많음
결국 소수의 인간이 꼭대기에 있는 피라미드 구조로 재편될 듯함
만약 같은 일을 5일 만에 끝낼 수 있다면, 속도 대비 비용은 합리적일 수 있음
산출물이 비례해 커진다면 비용 대비 효율은 맞을 수도 있음
게다가 토큰 단가도 내려갈 가능성이 있음
법률·보험 업계는 이 변화에 가장 고전할 것임
인간의 실수는 모델링 가능하지만, 자율 루프의 연쇄 오류는 완전히 다른 문제임
보험업계는 단순하게 갈 것 같음
AI의 결정은 결국 인간의 책임으로 귀결될 것임
이게 전체 agentic shift의 제동장치가 될 듯함
하루 $1,000 토큰은 말도 안 되는 지표임
코드 품질이 나쁘면 토큰 소모가 폭증함
결국 정리되지 않은 코드베이스가 비용을 키움
하루 천 달러를 태우는 팀이라면 효율은 거의 없을 것임
(참고: 이 짤)
단기 vs 장기 최적화의 문제임
지금 효율을 높일지, 시스템 전체를 개선할지의 선택임
어쩌면 이제야 경영진이 리팩터링의 중요성을 깨달을지도 모름
나는 예전에 언급했던 Dark Factory 패턴의 팀이 바로 이들이었음 관련 글을 썼는데, 이 팀은 가장 야심찬 실험자들임
하지만 실제로는 결과물이 거의 없음
대학생 몇 명에게 $10k 주면 더 나은 걸 만들 듯함
하루 $1,000 토큰이라니, 내 팀 예산으로는 꿈도 못 꿀 일임
개인적으로도 생활비 때문에 불가능함
결국 “해도 망하고 안 해도 망하는” 기분임
검증 가능한 결과가 없으면 그저 말뿐임
이제 말조차도 LLM 덕분에 훨씬 싸졌음
윤리적 공개가 필요함
사이트의 용어는 기존 개념을 새로 포장한 수준임
“Digital Twin Universe”는 mocks, “Gene Transfusion”은 참고 코드 읽기, “Semport”는 트랜스파일링임
실제 데이터나 벤치마크는 전무함
AI 마케팅이 엔지니어링 통찰로 포장된 사례임
사실 대부분의 핵심 코드는 이미 GitHub에 있음
진짜 차별점은 메커니즘 설계와 가치관임
미래는 정형 검증(formal methods)과 AI의 결합으로 갈 것임
“시나리오를 holdout set으로 두고 테스트하는 방식”이 흥미로움 QA 팀의 공격적 테스트를 모방하는 개념임
빌드 팀과 버그 탐지 팀을 분리해 상호 경쟁 구조로 만드는 게 인상적임
다만 하루 $1,000 토큰은 오픈소스 개발자에겐 절망적임
로컬 모델을 쓰면 비용을 줄일 수 있음 이 스레드처럼 로컬 에이전트 자동화도 충분히 가능함
언젠가 에이전트들이 서로 뇌물 주고받는 상황이 올지도 모름
나는 여전히 인간이 루프 안에 있는 방식을 선호함
무작정 토큰을 태우는 건 낭비임
나는 “LLMs aren’t tools” 글에서 LLM 활용의 정신적 프레임워크를 탐구했음
“소프트웨어 공장”은 현재의 종착점이지만, 그 다음 단계는 LLM을 하나의 애플리케이션으로 보는 것임
즉, 단순한 워크플로우 자동화가 아니라 맞춤형 하네스를 만드는 단계임
Hacker News 의견들
나는 Digital Twin Universe 개념에 공감함
내 코드베이스도 외부 서비스 통합이 많아서 테스트 시 외부 호출을 막으면 거의 아무것도 검증할 수 없었음
그래서 Okta, Jira, Slack, Google Docs 등처럼 각 API의 가짜 구현체를 만들어 테스트함
다만 UI까지 복제하진 않고 API 동작만 흉내냈음
“엔지니어 1인당 하루 $1,000 토큰을 안 쓰면 개선 여지가 있다”는 말은 너무 비현실적으로 들림
이게 진짜 주장인지 의심스러움
계산해보면 연간 약 $250k 수준임
만약 AI가 그만큼의 생산성을 낸다면 합리적일 수도 있음
현실적으로는 두 명의 주니어 엔지니어 정도의 효율일 듯함
결국 인간은 리드 역할로 계획과 검증만 담당하게 될 것 같음
과장된 낙관론이긴 하지만 완전히 미친 얘기는 아님
나는 월 $20짜리 Claude, OpenAI 구독만 쓰고 있음
토큰 다 쓰면 산책하거나 책 읽음
가속주의자는 아니지만 그래도 일은 충분히 함
나는 StrongDM 팀 중 한 명임
하루 $1,000 토큰을 쓰는 건 쉽지만, 생산적으로 쓰는 건 어렵다는 게 핵심임
이건 단순한 허세처럼 보임
“우린 너희보다 더 AI에 앞서 있다”는 신호 보내기 같음
글을 읽으며 민망함을 느꼈음
기존의 mocks나 시뮬레이션 테스트를 “혁신”처럼 포장한 느낌임
그래도 이들이 비용 구조를 솔직히 드러낸 점은 인정함
나는 그들의 사이트에서 실제 코드나 제품을 찾고 있었음
유일하게 찾은 건 strongdm/attractor였음
“캐나다 여자친구 코딩”이 이제 비즈니스 모델이 된 셈임
추가로 strongdm/cxdb도 발견했지만 커밋 히스토리가 정리돼 있었음
cxdb 저장소에 실제 코드가 있음
이게 미친 건지 미래의 단면인지는 모르겠음
Products 페이지에 데이터베이스와 ID 시스템도 있음
여러 에이전트가 협업하려면 공유 컨텍스트와 권한 시스템이 필수적임
BoundaryML의 BAML 관련 웨비나를 들었음
Spec-driven development는 인간이 루프 안에 있는 구조화된 워크플로우를 만드는 접근임
/research → /plan → /implement루프를 명확히 정의하고, 각 단계에서 인간 검증을 거치게 함StrongDM의 “인간이 코드를 쓰거나 읽지 않는다”는 주장과는 정반대의 철학임
또 하나의 공허한 블로그 글처럼 느껴짐
실질적인 결과물은 없고, $1,000/일 토큰 이야기는 투자자 어필용 같음
검증 문제를 해결하지 못하면 이 모든 건 허세에 불과함
자동 리뷰나 가드레일을 세워도 결국 사양과 결과의 일치를 확인할 사람은 인간임
우리는 Speedscale에서 트래픽 캡처와 재생으로 검증을 자동화하고 있음
사실 인간 개발도 완벽하지 않음
코드 리뷰, 테스트, QA 등 여러 체계적 검증 절차가 이미 존재함
중요한 건 AI가 완벽하냐가 아니라 시스템 전체 품질이 수렴하느냐임
내 경험상 Opus 4.5 기준으로는 약간의 순이익 효과가 있음
나도 거의 동의함
핵심은 생성보다 검증임
여러 독립 에이전트가 서로 이견을 드러내며 합의하는 구조를 만들고 있음
간단히 말해, 검증과 보안 테스트를 최종 사용자에게 떠넘기는 셈임
명세 기반 언어와 정형 검증을 더 적극적으로 써야 함
결국 프로그래밍이란 “명세를 구체화하는 행위”로 재정의될 것임
하루 $1,000 토큰이라면 인간보다 AI에 더 많은 돈을 쓰는 셈임
이건 AI 비전의 붕괴 지점처럼 보임
Simon Willison이 글을 업데이트했다고 함
연간 $240k면 신입 FANG 엔지니어 급임
솔직히 Claude보다 못한 주니어도 많음
결국 소수의 인간이 꼭대기에 있는 피라미드 구조로 재편될 듯함
만약 같은 일을 5일 만에 끝낼 수 있다면, 속도 대비 비용은 합리적일 수 있음
산출물이 비례해 커진다면 비용 대비 효율은 맞을 수도 있음
게다가 토큰 단가도 내려갈 가능성이 있음
법률·보험 업계는 이 변화에 가장 고전할 것임
인간의 실수는 모델링 가능하지만, 자율 루프의 연쇄 오류는 완전히 다른 문제임
AI의 결정은 결국 인간의 책임으로 귀결될 것임
이게 전체 agentic shift의 제동장치가 될 듯함
하루 $1,000 토큰은 말도 안 되는 지표임
코드 품질이 나쁘면 토큰 소모가 폭증함
결국 정리되지 않은 코드베이스가 비용을 키움
하루 천 달러를 태우는 팀이라면 효율은 거의 없을 것임
(참고: 이 짤)
단기 vs 장기 최적화의 문제임
지금 효율을 높일지, 시스템 전체를 개선할지의 선택임
어쩌면 이제야 경영진이 리팩터링의 중요성을 깨달을지도 모름
나는 예전에 언급했던 Dark Factory 패턴의 팀이 바로 이들이었음
관련 글을 썼는데, 이 팀은 가장 야심찬 실험자들임
하지만 실제로는 결과물이 거의 없음
대학생 몇 명에게 $10k 주면 더 나은 걸 만들 듯함
하루 $1,000 토큰이라니, 내 팀 예산으로는 꿈도 못 꿀 일임
개인적으로도 생활비 때문에 불가능함
결국 “해도 망하고 안 해도 망하는” 기분임
검증 가능한 결과가 없으면 그저 말뿐임
이제 말조차도 LLM 덕분에 훨씬 싸졌음
윤리적 공개가 필요함
사이트의 용어는 기존 개념을 새로 포장한 수준임
“Digital Twin Universe”는 mocks, “Gene Transfusion”은 참고 코드 읽기, “Semport”는 트랜스파일링임
실제 데이터나 벤치마크는 전무함
AI 마케팅이 엔지니어링 통찰로 포장된 사례임
사실 대부분의 핵심 코드는 이미 GitHub에 있음
진짜 차별점은 메커니즘 설계와 가치관임
미래는 정형 검증(formal methods)과 AI의 결합으로 갈 것임
“시나리오를 holdout set으로 두고 테스트하는 방식”이 흥미로움
QA 팀의 공격적 테스트를 모방하는 개념임
빌드 팀과 버그 탐지 팀을 분리해 상호 경쟁 구조로 만드는 게 인상적임
다만 하루 $1,000 토큰은 오픈소스 개발자에겐 절망적임
로컬 모델을 쓰면 비용을 줄일 수 있음
이 스레드처럼 로컬 에이전트 자동화도 충분히 가능함
언젠가 에이전트들이 서로 뇌물 주고받는 상황이 올지도 모름
나는 여전히 인간이 루프 안에 있는 방식을 선호함
무작정 토큰을 태우는 건 낭비임
나는 “LLMs aren’t tools” 글에서 LLM 활용의 정신적 프레임워크를 탐구했음
“소프트웨어 공장”은 현재의 종착점이지만, 그 다음 단계는 LLM을 하나의 애플리케이션으로 보는 것임
즉, 단순한 워크플로우 자동화가 아니라 맞춤형 하네스를 만드는 단계임