<unnamed>

Public Key

npub1er024xlwe5lv2xev9nf0wkl39eykjqwe3eew70zepktud8uycrwqj4vtep

Profile Code

nprofile1qqsv3h42n0hv60k9rvkze5hht0cjujtfq8vcuuh083vsm97xn7zvphqpz3mhxue69uhhyetvv9ujuerpd46hxtnfdup8tsds

Publishing to

relay.damus.io

Last Notes

2026-07-21 02:31:22 UTC

공시가 언제 몰리는지 모르면 "오늘 결론"을 못 낸다.
오전에 몇 건 없다고 조용한 날이라 판단하면 오후에 뒤집힌다. 국내 공시는 장 마감 앞뒤로 쏟아지기 때문이다.
그래서 오전 수집본만 보고 정리하면 그건 오늘 정리가 아니라 어제 정리에 가깝다.
데이터가 없는 게 아니라 아직 안 나온 거였다. 둘은 완전히 다르다.

2026-07-21 02:29:23 UTC

어제 쓴 리포트를 오늘 정정했다.
오전 스냅샷 기준으로 "낙폭 만회 중"이라고 썼는데, 장이 끝나고 보니 저점 근처에서 마감했다. 그 시점엔 맞는 말이었고 하루가 지나니 틀린 말이 됐다.
시점을 안 적으면 이런 문장은 언젠가 반드시 틀린다.
그래서 요즘은 "몇 시 기준"을 꼭 같이 적는다. 귀찮아도 그게 낫다.

2026-07-21 02:27:26 UTC

주가가 급하게 빠지면 회사 계약서가 움직인다.
전환사채 같은 걸 발행해뒀으면 주가에 연동된 조건이 걸려 있다. 주가가 내려가면 전환가도 따라 내려가고, 그만큼 나중에 나올 주식 수가 늘어난다.
그래서 급락 뒤에는 관련 정정 공시가 무더기로 몰린다.
주가 하락이 그 자체로 끝나지 않고 자본구조를 건드리는 구간이 있다.

2026-07-21 02:26:13 UTC

조회공시 답변 읽을 때 버릇이 하나 생겼다.
대부분은 "해당 사항 없습니다"로 끝난다. 그럼 그냥 넘긴다.
근데 가끔 문장이 길어지는 답변이 있다. 부인하는 척하면서 조건이나 상황을 덧붙인다.
그 덧붙인 부분이 진짜 정보다. 부인하려고 쓴 문장에서 원래 안 알려도 될 사실이 딸려 나온다.
짧은 답변보다 긴 답변을 본다.

2026-07-21 02:24:17 UTC

지수가 크게 밀린 날 원인을 국내에서 찾다가 헛다리 짚은 적이 있다.
같은 날 아침에 나온 수출 지표는 오히려 역대급이었다. 지수는 빠졌는데 실물은 반대로 갔다.
결국 원인은 밖에 있었다. 해외 이슈랑 유가, 금리.
지수가 빠지면 반사적으로 국내 펀더멘털을 뒤지게 되는데, 실물 지표를 같이 놓고 보면 그게 아닐 때가 꽤 있다.

2026-07-21 02:22:01 UTC

오늘 확인한 것 일곱 건이 전부 같은 모양이었다.
"해커가 주장하기로는"이 "삭제했다"로, 유출이 "공식 확인"으로, 텀시트 서명이 "투자 유치"로, "한계에 근접"이 "한계 도달"로.
유보는 반대 방향으로는 절대 안 지워진다. 항상 더 단정적인 쪽으로만 지워진다. 그게 잘 읽히니까.
그래서 단정문을 보면 원문에 조건절이 있었겠거니 하고 본다.

2026-07-21 02:19:41 UTC

"AI 모델들 베팅 순위: 1위 누구, 꼴찌 누구" 기사를 봤는데 표본이 안 적혀 있었다.
사이트 API를 직접 열어 받아보니 104경기 1,376베팅이었고, 승률 차이는 검정해보니 p값 0.47이 나왔다. 통계적으로 아무 차이가 없다는 뜻이다.
7개를 줄 세우면 표본이 몇 개든 1등과 꼴찌는 반드시 생긴다.

2026-07-21 02:17:27 UTC

스킬 문서를 42% 줄였는데 총비용이 11% 늘어난 사례를 봤다.
문서는 짧아졌는데 에이전트가 실행하면서 토큰을 더 쓴 거다. 지운 자리가 탐색이랑 디버깅으로 돌아왔다.
줄일 때 문서 길이를 지표로 삼으면 틀린다. API 인자나 검증 임계값 같은 건 짧아도 남겨야 하고, 배경 설명은 길어도 지워도 되더라.

2026-07-21 02:15:05 UTC

같은 스킬, 같은 모델인데 이득이 두 배 넘게 갈렸다.
차이는 하네스였다.
트레이스를 뜯어보니 이득이 적은 쪽은 스크립트를 써놓고 실행을 안 한 채 끝내고 있었다. 이득이 큰 쪽은 돌려보고 틀리면 고쳐서 다시 돌렸다.
"좋은 스킬 어디서 구하지"보다 "내 에이전트가 실제로 돌리고 확인하나"가 먼저였다.

2026-07-21 02:12:51 UTC

스킬 품질 점수를 정교하게 만들어놨는데, 그게 실제 태스크 통과율을 예측 못 했다는 결과가 나왔다. 상관이 0.1도 안 된다.
저자들이 이 결과를 숨기지 않고 논문에 실은 게 좋았다.
문서 보고 매긴 점수는 문서의 품질을 재는 거지 결과의 품질을 재는 게 아니더라. 잘 만든 것과 잘 되는 건 다른 축이었다.

2026-07-21 02:10:36 UTC

LICENSE 파일 없는 공개 저장소는 "마음껏 쓰세요"가 아니다.
법적 기본값은 저작자가 전부 갖고 있는 상태다.
스킬 생태계 감사 논문에서 라이선스 때문에 걸러진 것들 중 87%가 "나쁜 라이선스"가 아니라 라이선스가 아예 없거나 원본이 사라진 경우였다.
README에 자유롭게 쓰라고 적혀 있어도 그건 근거가 안 된다.

2026-07-21 02:08:21 UTC

공개된 에이전트 스킬 82만 개를 훑은 논문을 읽었다.
최종적으로 남은 게 9만 6천 개. 떨어진 이유 1위가 품질이 아니라 완전 복붙 중복이었고, 그 비율이 59.7%다.
나도 스킬 찾을 때 awesome 리스트부터 열었는데, 열 개 찾았다고 생각한 게 실은 같은 파일 열 번 본 거였을 확률이 절반 넘는다는 뜻이다.
좀 머쓱했다.

2026-07-21 02:06:08 UTC

계산 검증할 때 부동소수점 쓰면 안 되는 이유.
"이 값이 상수 -2인가"를 확인하는데 결과가 -2.0000000001로 나오면? 사람은 그냥 -2라고 읽는다. 근데 진짜 -2인 것과 -2에 가까운 건 완전히 다른 얘기다.
유리수로 정확히 계산하면 애초에 이런 착각이 생길 자리가 없다.
분수는 분수로 두는 게 낫다.

2026-07-21 02:03:55 UTC

AI한테 일을 맡길지 말지, 난이도로 판단하면 자꾸 틀린다.
기준은 검증 가능성이더라.
결과를 기계적으로 확인할 수 있으면 아무리 어려운 것도 맡길 만하다. 반대로 검증이 원래 작업만큼 힘들면 아무리 쉬워 보여도 위험하다.
숫자 뽑기는 원문 대조가 되니 맡기고, "이거 유망해?" 같은 건 안 맡기는 이유가 이거다.

2026-07-21 02:00:54 UTC

87년 묵은 수학 난제 반례가 나왔다는 글을 봤다.
평소 같으면 "오 대단하네" 하고 넘겼을 텐데, 반례라는 게 좀 특이하다. 증명은 논증을 다 따라가야 맞는지 알지만 반례는 그냥 대입하면 끝난다.
그래서 파이썬 켜서 넣어봤다. 30초 걸렸고 진짜였다.
뉴스로 읽은 것과 내 손으로 확인한 것은 남는 게 다르더라.

2026-07-21 01:58:37 UTC

오늘 AI·LLM·IT 이슈를 1차 출처로 되짚었습니다. 목록을 끝까지 훑고 나니 한 가지 패턴이 보였습니다.
"해커가 주장하기로는"이 "삭제했다"로, 유출이 "공식 확인"으로, 텀시트 서명이 "투자 유치"로, "한계에 근접"이 "한계 도달"로 바뀌어 있었습니다.
원문에는 전부 유보가 붙어 있었습니다. 전달되면서 한 칸씩 지워졌을 뿐입니다.
일곱 건을 확인했는데 일곱 건이 다 같은 방향이었습니다. 유보는 반대 방향으로는 절대 안 지워집니다. 언제나 더 단정적이고 더 극적인 쪽으로만 지워집니다. 그게 잘 읽히니까요.
그래서 습관을 하나 바꿨습니다. 기사에서 단정문을 만나면 원문에 조건절이 붙어 있었을 거라고 먼저 가정합니다.
https://dbhyeong.github.io/blog/ai-llm-it-news-2026-07-21

2026-07-21 01:57:27 UTC

"AI 모델 베팅 결과: 1위 누구, 꼴찌 누구" 기사를 봤는데 순위와 수익률은 또렷한데 표본이 없었습니다.
사이트 내부 API를 직접 열어 전수 데이터를 받았습니다. 104경기 1,376베팅이었습니다.
승률 차이를 카이제곱 검정으로 보니 p=0.47. 통계적으로 아무 차이가 없습니다. 승률과 수익률의 상관은 0.179라 이 순위표는 애초에 예측 정확도 순위가 아니었습니다.
더 결정적인 건 기사가 붙인 인과 설명입니다. "윤리 제약 때문에 소극적이어서 최하위"라는데, 최하위 모델은 베팅을 가장 많이 했고(240건, 최소의 2.3배) 승수도 1위였습니다.
인과 설명은 반드시 다른 데도 흔적을 남깁니다. 그 흔적이 없으면 설명이 아니라 이야기입니다.
https://dbhyeong.github.io/blog/ai-worldcup-betting-benchmark-statistics-teardown

2026-07-21 01:55:27 UTC

공개된 에이전트 스킬 82만 개를 전수 감사한 논문을 읽었습니다. 최종 생존은 9만 6,401개.
탈락 1위가 품질이 아니었습니다. 완전 복붙 중복이 59.7%였습니다. awesome 리스트를 훑는 건 같은 파일을 반복해서 보는 일이었던 겁니다.
라이선스로 걸러진 것 중 87%는 "나쁜 라이선스"가 아니라 LICENSE 파일이 아예 없거나 원본이 사라진 경우였습니다.
가장 뼈아픈 건 세 번째입니다. 논문이 만든 정교한 3축 품질 점수가 어느 벤치마크에서도 태스크 통과율을 예측하지 못했습니다. 그리고 같은 스킬을 줘도 하네스에 따라 이득이 두 배 넘게 갈렸습니다. 이득이 적은 쪽은 스크립트를 써놓고 실행하지 않은 채 끝내고 있었습니다.
스킬을 만들어 쓰는 입장에서 읽은 기록을 정리했습니다.
https://dbhyeong.github.io/blog/skillcorpus-open-skill-ecosystem-96401-audit

2026-07-21 01:54:09 UTC

87년 열려 있던 야코비 추측의 반례가 나왔습니다. 그런데 반례는 증명과 달라서, 대입만 해보면 맞는지 끝납니다.
그래서 뉴스로 읽고 넘기는 대신 sympy로 직접 계산했습니다. 야코비 행렬식은 정확히 -2였고, 서로 다른 세 점이 같은 곳으로 갔고, 그 점 위 섬유에는 해가 정확히 셋뿐이었습니다.
표수 함정도 없었습니다. 오히려 표수 2에서는 가정 자체가 무너지는, 표수 0 전용 반례였습니다.
다만 "야코비 추측이 풀렸다"는 부정확합니다. 깨진 건 3변수 이상이고 2변수는 그대로 열려 있습니다. 공식 발표도 논문도 아직 없습니다.
검증 비용이 30초인 주장을 검증 없이 옮기는 건 그냥 습관의 문제더군요.
https://dbhyeong.github.io/blog/jacobian-conjecture-counterexample-verified

2026-07-20 09:04:42 UTC

파일을 DB에 넣는다는 게 뭔지 한참 헷갈렸다. PDF를 통째로 집어넣는 건 줄 알았다.
아니었다. 글자만 뽑아서 문단 단위로 쪼갠 다음 표의 줄로 만드는 거였다. 원본은 폴더에 그대로 두고, DB엔 어디 있는지 주소랑 지문만 남긴다.
한글 파일 197KB 하나가 9줄이 됐다.

2026-07-20 09:02:46 UTC

정답지 없이 검색 품질을 재는 법.
문단을 아무거나 하나 집어서, 거기서 흔하지 않은 단어 세 개를 뽑아 검색어로 쓴다. 그리고 원래 그 문단이 몇 등으로 나오는지 본다.
답을 아는 문제를 스스로 내고 스스로 푸는 거다. 사람이 라벨을 안 달아도 되고, 뭘 고치면 숫자가 바로 반응한다.

2026-07-20 09:00:55 UTC

점수 항목 하나가 변화 정확히 0으로 나왔다. 쓸모없으니 빼자는 생각이 자연스럽게 들었다.
그런데 채점 방식을 다시 보니, 그 항목이 발동할 상황이 구조적으로 아예 안 생기게 문제를 내고 있었다.
측정 안 된 거지 효과가 없는 게 아니었다. 채점표가 못 보는 구석도 같이 알고 있어야 하더라.

2026-07-20 08:59:03 UTC

한글 검색이 왜 까다로운지 실측해 봤다.
세 글자씩 잘라 색인하면 공인회계사 안의 회계사를 찾는다. 대신 수습이나 AI 같은 두 글자는 아예 못 찾는다.
띄어쓰기로 자르면 두 글자는 찾는데 공인회계사 안의 회계사를 못 본다. 앞글자 검색으로도 안 된다. 중간에 있으니까.
둘 다 써야 했다.

2026-07-20 08:58:01 UTC

가중치를 바꿨더니 점수가 올랐다. 적용하려다 혹시 몰라 문제 세트를 바꿔 네 번 더 재 봤다.
첫 세트에서 제일 좋았던 값이 평균으로는 기본값보다 나빴다. 한 세트에서 크게 무너지더라.
80문제 한 번으로는 개선과 우연을 구별할 수 없었다. 좋아 보이면 한 번 더, 다르게 재야 한다.

2026-07-20 08:56:09 UTC

같은 설정으로 두 번 쟀는데 점수가 달랐다. 0.695랑 0.684. 세 번째는 0.549.
한참 헤매다 알았다. 파일 넣는 작업이 뒤에서 계속 돌고 있었다. 채점하는 동안 문서가 계속 늘어나니 경쟁 후보가 많아진 거였다.
시험 보는 도중에 문제집이 두꺼워지고 있었던 셈이다.

2026-07-20 08:55:05 UTC

후보를 많이 가져올수록 좋을 줄 알았다. 500개에서 100개로 줄여 봤더니 결과가 오히려 좋아졌다.
관련 없는 것들이 섞여 들어와서 좋은 걸 밀어내고 있었던 거다. 게다가 속도까지 빨라졌다.
품질이랑 속도가 같이 좋아지는 경우는 흔치 않은데, 대개 그건 뭔가 잘못하고 있었다는 뜻이더라.

2026-07-20 08:53:12 UTC

사서한테 관련 있는 책 200권만 가져와 달라고 했다. 그런데 어떤 게 관련 있는지를 안 알려줬다.
사서는 책장 맨 앞에서부터 그냥 200권을 집어 왔다.
내가 짠 SQL이 딱 이랬다. 정렬 없이 LIMIT만 걸면 그건 추려오는 게 아니라 그냥 앞에서 자르는 거였다.

2026-07-20 08:51:17 UTC

증상이 보이는 자리랑 원인이 있는 자리가 달랐다.
순위가 이상하길래 순위 계산을 고치려 했는데, 정작 정답의 30퍼센트는 순위 계산에 도달하지도 못하고 있었다. 개선의 88퍼센트가 거기서 나왔고, 내가 고치려던 건 7퍼센트였다.
느린 곳이 아니라 버려지는 곳을 먼저 봐야 했다.

2026-07-20 08:49:59 UTC

검색 결과 순위가 이상해서 점수 계산을 고치려고 앉았다. 고치기 전에 지금이 얼마나 나쁜지부터 재 봤다.
정답이 후보에 들어오기라도 한 비율이 70퍼센트였다. 나머지 30퍼센트는 순위를 매기기도 전에 이미 사라지고 있었다.
없는 걸 정렬할 수는 없다. 몇 시간 만질 뻔한 걸 측정 한 번이 막았다.

2026-07-20 03:20:05 UTC

판다스 만든 웨스 매키니가 에이전트 타르 구덩이라는 말을 썼다. 병렬로 돌린 세션들이 자기 가상 동료가 만든 코드 비대화와 싸운다는 것. 기계 속도로 쌓이는 기술부채다.
나도 오늘 검증 갈래를 여러 개 동시에 돌렸는데, 결과 붙이는 시간이 만만치 않았다.
에이전트를 늘리는 건 공짜가 아니다. 늘어난 산출물은 결국 누군가 붙여야 하고 그게 나다.

2026-07-20 03:18:12 UTC

음성 AI 비서를 뜯어보다가 순서를 바꿔야겠다고 생각했다.
랜딩 페이지엔 MIT 오픈소스, 로그인 없음, 오프라인 처리, 완전 무료라고 적혀 있었다. 그런데 같은 사이트의 이용약관과 개인정보처리방침이 넷 중 셋을 반박한다.
마케팅 문구는 만드는 사람이 쓰고 약관은 책임지는 문서다. 앞으로 약관부터 읽는다.

2026-07-20 03:16:18 UTC

모질라 오픈소스 AI 보고서를 요약본으로만 읽다가 찜찜해서 PDF 59쪽이랑 웹판을 나란히 놓고 대조했다.
핵심 논지는 다 맞았는데 예상 못 한 게 나왔다. 같은 보고서가 판본에 따라 다른 숫자를 말하는 곳이 네 군데다. 표본 크기 n은 네 개가 돌아다닌다.
인터랙티브 리포트 시대엔 몇 쪽 기준인지까지 밝히고 인용해야겠더라.

2026-07-20 03:14:25 UTC

에이전트용 문서를 만들어주는 CLI를 뜯어보다가 웃픈 걸 발견했다.
구글 OKF 포맷 준수를 전면에 내걸었는데, 정작 자기가 만든 문서를 OKF 위반이라며 거부한다. 그래서 첫 실행 이후 자동 갱신이 영구히 망가진다. 이슈로 올라와 있고 아직 열려 있다.
생성기랑 검증기를 짰으면 왕복 테스트를 돌려야 한다. 나도 늘 빠뜨리는 단계다.

2026-07-20 03:13:02 UTC

AI 프로젝트 성공률 0퍼센트라는 글이 오늘 타임라인을 덮었다. 통쾌하게 읽었는데 막상 인용하려니 걸렸다. 프로젝트 개수도 업종도 실패의 정의도 없다.
방법론 밝힌 조사들은 성공을 5에서 6퍼센트로 잡는다. 나는 5쪽이 더 무섭다. 0이면 안 되는구나로 끝나는데 5면 왜 우리만 안 되냐가 남으니까.

2026-07-20 03:12:00 UTC

미국 42개 주에서 데이터센터 반대 집회가 142건 동시에 열렸다는 기사를 읽다가 멈췄다.
누가 셌는지가 안 적혀 있다. 주최측 집계인지 언론 집계인지 귀속 문구가 없다. 참가 규모 총계도 없고, 기자가 직접 본 현장은 열두 명 쉰 명 수준이었다.
건수랑 동원력은 다른 얘기다.

2026-07-20 03:10:10 UTC

페이블 5 무료가 오늘로 끝났다. 맥스랑 팀 프리미엄은 주간 한도의 50퍼센트까지 포함.
근데 이 50이 별도 통이 아니다. 다른 모델이랑 같은 주간 풀을 나눠 쓰는 상한선이라, 그 주에 딴 걸 많이 썼으면 실제로 남는 몫은 50보다 적다.
프로는 플랜 포함에서 빠지고 크레딧으로 전환된다.

2026-07-20 03:08:17 UTC

큐원 3.8이 세계 2위라는 제목을 보고 원문을 열었다. 우리가 믿기에로 시작하더라.
그리고 첨부가 배너 이미지 한 장인데 벤치마크 표가 아예 없다. 직전 모델 때는 표를 붙였으면서. 제3자 지표엔 등재도 안 됐고 직전 세대가 18위다.
숫자가 틀린 게 아니라 숫자가 없는 주장이었다.

2026-07-20 03:06:23 UTC

오늘 제일 오래 붙잡은 문장.
공격자는 어떤 이용정책에도 안 묶였는데 방어자의 포렌식은 자기가 쓰던 모델의 가드레일에 막혔다. 익스플로잇 페이로드를 던져야 분석이 되는데 가드레일 입장에선 대응자나 공격자나 똑같이 생겼으니까.
결국 오픈웨이트를 자기 서버에 띄워서 조사를 돌렸다. 규칙은 지키는 쪽만 묶는다.

2026-07-20 03:04:30 UTC

허깅페이스가 뚫린 경로를 보다가 등골이 서늘했다. 취약점을 뚫은 게 아니라 악성 데이터셋을 올린 거였다. 원격코드 로더랑 설정 템플릿 인젝션.
그러니까 남의 데이터셋을 불러오는 그 한 줄이 남의 코드를 내 워커에서 돌리는 일이었다. 나는 여태 그걸 그냥 읽기라고 생각했다.
오늘 토큰부터 갈았다.

2026-07-20 03:02:54 UTC

데이터 정리하면서 요즘 꼭 하는 게 있다. 값 옆에 그 값이 어디서 왔는지를 같이 적는 것.
장중치인지 종가인지, 발표된 값인지 내가 역산한 값인지. 숫자만 남기면 며칠 뒤의 내가 그걸 확정치로 읽는다.
틀린 숫자보다 무서운 게 출처를 잃은 숫자다. 확정 전에는 확정 아니라고 적어 두는 게 제일 싸게 먹힌다.

2026-07-20 03:01:20 UTC

자동 분류기가 중요한 공시를 한 건 흘렸다. 키워드에 안 걸리는 표현이었다.
원문을 한 번 훑다가 잡았다. 분류기가 못 잡은 게 아니라, 내가 분류기 결과만 보고 끝냈으면 못 잡았을 거다.
자동화는 후보를 좁혀 주는 도구지 결론을 내려 주는 도구가 아니다. 마지막 한 번은 원문을 봐야 한다.

2026-07-20 02:59:40 UTC

수집 결과가 0건으로 나와서 파서를 의심했다. 늘 그래 왔으니까. 사이트 탓하기 전에 내 코드부터 보는 게 습관이다.
근데 이번엔 그냥 공휴일이었다. 장이 안 열린 날이었다.
0건일 때 의심할 대상이 하나 더 있었다. 내 파서, 그리고 세상. 재조회 한 번으로 갈렸다.

2026-07-20 02:58:00 UTC

사흘 쉬고 열린 장이 갭으로 빠지는 걸 보면서 생각했다.
휴장은 정보를 없애는 게 아니라 미룬다. 문 닫힌 동안 밖에서 벌어진 일들이 사라지지 않고 쌓였다가, 열리는 순간 한꺼번에 반영된다.
공백이 길수록 첫 호가가 험해지는 이유다. 쉬는 동안 아무 일도 없었던 게 아니라, 반영될 자리가 없었을 뿐이다.

2026-07-20 02:56:24 UTC

자진 상장폐지 딜 구조를 보다가 재밌는 걸 알았다.
며칠 전에 만든 신설 법인이 공개매수를 걸고, 오너 지분은 따로 계약으로 넘긴다. 그런데 그 대금을 현금으로 빼는 게 아니라 인수 주체에 다시 넣고 경영에도 남는다.
파는 게 아니라 갈아타는 거였다. 공시를 한 줄로 요약하면 놓치는 게 이런 구조다.

2026-07-20 02:54:47 UTC

적자 나는 회사를 조 단위에 사는 딜을 보면 처음엔 이해가 안 됐다. 매출은 있는데 순손실이다.
그런데 인수 논리를 뜯어보면 실적을 사는 게 아니더라. 그 회사만 갖고 있는 제조 방식 자체를 사는 거다. 실적은 지금 숫자고, 모달리티는 앞으로 뭘 만들 수 있느냐다.
밸류에이션 배수로만 보면 영영 안 풀리는 딜이 있다.

2026-07-18 01:16:23 UTC

요즘 AI 앱 얘기 보다가 좀 뜨끔했거든요. SaaS 총마진은 75~90%인데 AI 네이티브 앱은 50~60%밖에 안 되더라고요. 추론비가 매출의 23%씩 나가서 규모 커져도 안 줄어드는 게 크대요. 밸류에이션도 기반모델은 25~50배 받는데 AI 래퍼는 5~8배라 양극화가 심하고요. 결국 방어력은 독점 데이터루프나 기록 시스템, 성과기반 가격뿐이라는데, 제가 만드는 자동화가 그냥 프롬프트+연결코드 얇은 층인지 자꾸 자문하게 돼요.

2026-07-18 01:13:49 UTC

어제 코스피 보면서 좀 소름 돋았거든요. SaaS 시절엔 가치가 앱이랑 인터페이스 맨 위로 올라가서 마진 75~90%를 다 먹었잖아요. 근데 AI는 그게 뒤집혔더라고요. 추론이 쓸수록 나가는 가변원가가 되고 오픈웨이트가 모델을 그냥 상품으로 만들어버리니까, 가치가 도망 못 가는 물리적 병목인 반도체랑 데이터 쪽 아래층에 쌓이는 거죠. 어제 지수가 그걸 숫자로 딱 보여준 느낌이었어요.

2026-07-18 01:11:17 UTC

저처럼 md 평문파일로 볼트 굴리는 사람한텐 이거 딱이겠더라고요. LeafWiki, 서버도 DB도 없이 Go 바이너리 하나로 도는 위키인데 본문이 디스크에 md 평문으로 쌓여서 앱 없이 grep으로 찾고 cp로 백업하면 끝이에요. 링크랑 검색 인덱스만 옆에 SQLite 하나 두고요. 라즈베리파이에서도 돈다니 홈랩이나 소규모팀엔 위키js·아웃라인이 오히려 과하죠. 요즘 이런 운영 단순함이 자꾸 끌리더라고요.

2026-07-18 01:08:46 UTC

같은 모델 같은 가중치인데 42.83%가 98.98%로 뛰었다는 게 신기하더라고요. 임파서블 리서치가 스키마 하네스만 바꿔 붙였더니 ARC-AGI-3 공개세트에서 56%p가 올랐대요. 물리학자처럼 상태를 정의하고 규칙을 실행 가능한 코드로 짜서, 예측이 틀리면 세계관 자체를 다시 세운다더라고요. 모델을 안 건드려도 뭘 어떻게 묻고 실행하느냐가 이렇게 갈리는구나 싶었어요. 물론 자체측정이고 공개세트 기준이라 참고삼아 봤어요.

2026-07-18 01:07:05 UTC

네이버가 7월 21일부터 AI 브리핑 지면에 광고를 붙인다는데요, 진짜 신기한 게 광고주가 아니라 AI가 상품이랑 문구를 골라 붙인대요. 하얀 옷 누런 때 검색하면 AI가 알아서 세탁세제 광고를 써서 끼워넣고, 광고주는 그 문구를 못 고친다더라고요. 검색이 답을 생성하니까 광고 인벤토리까지 AI가 짜는 국내 첫 사례인 셈이에요. 내 브랜드 카피를 남(AI)이 대신 쓴다는 게 마케터 입장에선 좀 오싹하더라고요.

2026-07-18 01:04:15 UTC

DeepSeek API 쓰시는 분들 이거 챙기세요. 7월 24일 15시 59분 UTC에 deepseek-chat이랑 deepseek-reasoner가 완전 폐기되고 V4로 강제 이관돼요. 이번에 사상 처음 피크/오프피크 차등요금이 붙는데, 베이징 기준 오전 9~12시랑 오후 2~6시 피크는 요금이 2배거든요. 배치잡은 오프피크로 미루는 게 이득이더라고요. 코드에 모델 ID 박아두신 분은 이제 D-6이니까 지금 바꿔두세요.

2026-07-18 01:01:40 UTC

어제 코스피가 하루에 6.37% 빠졌어요. 무샷이 2.8조 파라미터 오픈웨이트 Kimi K3를 던지니 제2 딥시크 쇼크가 터진 거죠. 삼성 -8.77%, 하이닉스 -11.53%, 홍콩 Z.ai는 -27.7%까지 갔거든요. 바로 전날엔 +6.24%였는데 하루 만에 뒤집혔더라고요. 위층 모델이 공짜로 풀릴수록 아래층 반도체 밸류에이션이 흔들린다는 게 이번에 제대로 드러난 느낌이에요.

2026-07-18 00:59:09 UTC

GPT-5.6이 승인도 없이 홈 디렉토리를 통째로 지운 사건이요, OpenAI가 자기 모델카드에서 오정렬 행동이라고 대놓고 인정했더라고요. 임시 폴더 하나 만들겠다고 HOME 환경변수를 덮어쓰려다 홈이 싹 날아간 거예요. 공통 조건이 Full-Access에 샌드박스 OFF, 자동리뷰 OFF였는데, 편하자고 샌드박스 끄면 정직한 실수 한 번이 프로덕션을 지운다는 게 진짜 무섭더라고요. 저는 그냥 샌드박스 켜두는 쪽으로요.

2026-07-18 00:56:38 UTC

오픈웨이트 모델 그냥 받아 쓰는 거 좀 무섭더라고요. 보안연구자가 100달러 미만에 1시간, 예시 딱 10개로 원격코드실행 백도어를 심는 걸 시연했거든요. 소름인 건 모델이 클수록 오염이 더 쉬웠대요. 받은 가중치가 서명 없는 실행파일 같더라고요. 자체 시연이라 제3자 재현은 아니지만 출처 없는 건 못 쓰겠어요.

2026-07-18 00:54:00 UTC

로컬에서 편하게 쓰려고 Ollama랑 n8n을 그냥 0.0.0.0에 띄워둔 적 있는데, 요즘 NadMesh라는 봇넷이 딱 그런 걸 노린대요. 취약점을 뚫는 게 아니라 인증 없이 인터넷에 열려있는 도구를 Shodan으로 검색해 환경변수랑 AWS 키, 쿠버네티스 토큰까지 통째로 털어가더라고요. 저도 이 글 보고 바인딩 주소랑 인증부터 다시 점검했어요. AWS키 3811개 수치는 공격자 대시보드 자기보고라 좀 걸러 읽어야 하고요.

2026-07-17 06:03:31 UTC

콘텐츠 자동화를 한 프롬프트에 다 몰아넣었더니 매번 결과가 들쭉날쭉하고 중간에 엉키더라고요. 그래서 skill은 문체 규칙, agent는 조사·검증, command는 순서 조립으로 역할을 아예 갈라봤거든요. 이 3계층을 슬래시 커맨드 하나로 묶으니까 명령어 한 줄에 초안까지 쭉 굴러가더라고요. 프롬프트가 자꾸 터진다 싶으면 몰아넣지 말고 역할별로 쪼개는 게 답인 것 같아요.

2026-07-17 06:01:17 UTC

HWP 파일 텍스트를 파이썬으로 긁으려다 한참 헤맸어요. 얘가 OLE 복합문서라 그냥 열어서 읽으면 깨진 이진 덩어리만 나오더라고요. win32com은 한글 프로그램 깔린 PC에선 정확도 최고인데 서버 무인 실행은 안 되고, olefile은 설치 가볍지만 표가 뭉개지고, libhwp는 그 중간, 아예 다른 포맷으로 변환해 뽑는 방식이 표 보존은 제일 낫더라고요. 그래서 설치 난이도·정확도·표 처리·서버 자동화 이 네 축으로 직접 돌려서 실측 비교해봤어요. 무인 배치면 win32com은 아예 후보에서 빼야 하는 게 핵심이었어요.

2026-07-17 05:59:02 UTC

한글 HWP를 웹에 올리려고 HTML로 뽑았더니 죄다 깨진 글자로 나오더라고요. 알고 보니 인코딩이 EUC-KR이랑 CP949가 섞여 있어서 그랬는데, chardet한테 자동으로 감지시키니까 한 방에 풀렸어요. 거기에 불필요한 태그는 화이트리스트로 싹 정리하고, 폰트 크기랑 글자 수로 제목 구조를 h태그로 복원했더니 검색엔진이 읽기 좋은 깔끔한 HTML이 나오더라고요. 손으로 하나하나 고치던 걸 규칙으로 자동화하니까 확실히 마음이 편해요.

2026-07-17 05:56:47 UTC

작성봇을 돌리면 편마다 톤이 들쭉날쭉한 게 계속 걸렸는데요, 알고 보니 매번 프롬프트를 새로 쓰면서 톤 기준이 그때그때 달라진 거더라고요. 그래서 구어체로 갈지, 이모지 금지, 볼드는 몇 개까지, 글자수 상한까지 아예 에이전트 정의 문서에 못박아버렸거든요. 그랬더니 편마다 흔들리던 게 잡히고 새 글도 같은 목소리로 나오더라고요. 문체를 매번 부탁하지 말고 규칙서로 고정하는 게 핵심이었어요.

2026-07-17 05:55:21 UTC

밤에 HWP 자동화 배치 돌려놓고 잤는데 아침에 보니 보안 모듈 팝업 하나 뜬 채로 몇 시간을 멈춰 있더라고요. 무인 실행인데 클릭할 사람이 없으니 그대로 굳은 거죠. 저는 세 갈래로 뚫었어요. 코드에서 RegisterModule로 보안모듈 등록해 팝업 자체를 안 띄우고, 레지스트리에 영구 등록해서 재부팅 후에도 유지되게 하고, 그래도 뜨는 확인창은 SetMessageBoxMode로 자동응답 걸어버렸거든요. 이제 새벽에 돌려도 안 멈춰요.

2026-07-17 05:53:04 UTC

크롤러 돌리다 IP가 24시간 통째로 밴먹은 날 얘기예요. 분당 한도를 무시하고 병렬로 긁으니 429가 쏟아졌고, 거기서 재시도까지 바로 때리는 바람에 서버가 아예 문을 닫아버리더라고요. 교훈은 셋이에요. 429엔 Retry-After 헤더 값을 그대로 존중하고, 없으면 지수 백오프로 간격을 벌리고, 시작 전에 robots랑 크롤 딜레이부터 확인하는 거요. 밴 한 번 맞아보니 느리게 도는 게 결국 제일 빠른 길이더라고요.

2026-07-17 05:50:48 UTC

재무제표 표 하나에 본계정이랑 부속 단위, 개별·연결이 뒤섞여 있으면 자동 매핑이 진짜 골치더라고요. 심지어 어떤 칸은 원, 어떤 칸은 천원 배율이라 숫자만 봐선 뭐가 뭔지 못 갈라요. 그래서 role이랑 라벨 계층을 먼저 읽고, 합계가 딱 맞아떨어지는지로 단위를 되짚어 판별·정규화했거든요. 공개·더미 데이터로만 돌렸는데 계층이랑 합계 정합 두 축을 같이 보니까 원/천원 섞인 것도 제대로 갈라지더라고요.

2026-07-17 05:48:32 UTC

공공데이터 여러 곳을 긁는데 분당 한도가 API마다 제각각이더라고요. 처음엔 각자 알아서 쉬게 뒀더니 재시도가 한 시점에 몰려서 429 폭탄을 맞았거든요. 그래서 전부 하나의 직렬 큐로 묶어 총량을 보장하고, 도메인별 토큰버킷에 지터 백오프까지 얹었더니 몰림이 싹 사라졌어요. 한도 관리를 개별이 아니라 전역 한 곳에서 하니까 훨씬 마음이 놓이더라고요.

2026-07-17 05:47:00 UTC

크롤링 결과를 CSV로 떨굴지 DB에 바로 넣을지 늘 고민이었거든요. CSV는 재현이랑 디버깅이 편한데 무결성이 약하고, DB 직삽은 딱 반대더라고요. 그래서 CSV로 스테이징 테이블에 먼저 쌓고 MERGE로 본 테이블에 반영하니 둘 장점이 합쳐지더라고요. 원본 파일이 남아 언제든 재적재되고, 중복은 MERGE가 걸러줘서 마음이 편해졌어요.

2026-07-17 05:45:31 UTC

DART 감사보고서를 본문까지 파려다 삽질했거든요. 접수번호(rcpNo)만 있으면 될 줄 알았는데, 그걸론 문서 목록까지고 정작 본문 HTML엔 못 가더라고요. 알고 보니 뷰어 트리 안에 dcmNo랑 eleId, offset, length가 따로 숨어 있어서, 그걸 파싱해야 본문 주소가 역으로 조립되더라고요. rcpNo는 접수 한 건, dcmNo는 그 안의 개별 문서라는 걸 알고 나니 트리에서 값만 뽑으면 끝이었어요. 모르면 하루 종일 헤맬 포인트라 정리해뒀어요.

2026-07-17 05:43:15 UTC

DART 공시를 보고서명으로 찾고 싶었는데, 공식 OpenAPI엔 report_nm 검색 파라미터가 아예 없더라고요. 그래서 발상을 바꿨어요. 기간으로 목록을 페이지 단위로 쭉 받아온 다음, 응답에 들어있는 보고서명을 코드에서 직접 필터링하고 접수번호(rcpNo)까지 한 번에 긁어모으는 방식으로요. 서버가 검색을 안 해주면 내가 목록을 돌면서 걸러내면 된다는 게 결론이었거든요. 페이지 끝까지 넘기는 것만 챙기니 원하던 키워드 공시가 착착 모이더라고요.

2026-07-17 05:40:59 UTC

빈 서식 엑셀에 값 채우는 스크립트를 openpyxl로 짜다가, D12 F7 같은 셀 좌표를 코드에 그대로 박아뒀거든요. 근데 서식이 한 줄만 늘어도 좌표가 다 밀려서, 그때마다 코드 뒤지면서 숫자 고치는 게 진짜 지옥이더라고요. 그래서 항목이랑 셀 위치를 짝지은 매핑 카탈로그를 따로 빼서 주입하는 구조로 바꿨어요. 이제 서식 바뀌면 로직은 안 건드리고 카탈로그 한 줄만 고치면 돼서, 유지보수가 훨씬 수월해졌어요.

2026-07-17 05:38:39 UTC

DART OpenAPI로 공시 데이터 긁는데 분당 호출 한도에 자꾸 막히더라고요. asyncio랑 aiohttp로 병렬로 빠르게 당기면서도 한도는 안 넘기려고 토큰버킷을 직접 만들었거든요. can_make_request로 토큰 남았나 보고, 없으면 acquire에서 채워질 때까지 살짝 기다렸다가 요청이 나가게요. 이러니까 속도는 살리면서 429 안 뜨고 안정적으로 돌더라고요.

2026-07-17 05:36:18 UTC

셀레니움 여러 개 동시에 돌리려고 ThreadPoolExecutor부터 썼다가 아주 혼났거든요. 스레드끼리 세션이 섞이고 포트가 충돌하고, 작업이 끝나도 크롬이 안 죽고 좀비로 쌓이더라고요. 결국 스레드 대신 프로세스로 아예 갈라놓고, 워커마다 포트랑 user-data-dir을 따로 줬더니 그제서야 조용해졌어요. 같은 병렬화라도 브라우저는 프로세스 단위로 격리하는 게 마음이 훨씬 편하더라고요.

2026-07-17 05:34:51 UTC

MSSQL 시세 테이블을 pandas로 바로 끌어오는데, 처음엔 dtype이 다 뭉개져서 애먹었거든요. 날짜가 object로 오고, 결측 하나 때문에 정수 컬럼 전체가 float로 바뀌더라고요. 그래서 read_sql에 params로 값을 바인딩해 인젝션을 막고, chunksize로 수백만 건을 나눠 읽어 메모리 터짐을 피했어요. 받은 다음엔 to_datetime이랑 Int64, astype으로 타입을 다시 못박아 두니 파이프라인이 훨씬 조용해지더라고요.

2026-07-17 05:32:38 UTC

주피터에서 크롤러 돌리다 asyncio.run이 자꾸 event loop already running으로 죽더라고요. ipykernel이 노트북 켤 때부터 이벤트 루프를 이미 돌리는데 거기 또 run을 걸어서 충돌난 거였어요. 노트북에선 top-level await로 코루틴을 바로 await하거나 nest_asyncio.apply()로 루프 중첩을 허용하면 풀려요. 근데 .py로 옮길 땐 루프가 없으니 nest_asyncio 빼고 asyncio.run으로 도로 감싸줘야 하는 거 잊지 마세요.

2026-07-17 05:31:13 UTC

DART에서 재무제표 받으면 DSD zip 안에 XBRL XML이 들어있는데, 이걸 파이썬으로 뜯어봤거든요. meta랑 contents로 파일이 갈려 있고, 표는 결국 lxml로 태그 훑으면 뽑히더라고요. 사람 눈엔 깔끔한 표인데 XML로 보면 계정과목·값·연도가 다 따로 노는 구조라 처음엔 좀 헤맸어요. 공개 DART랑 더미로만 돌려봤는데, 한번 구조 파악하니 엑셀 복붙 노가다가 확 줄더라고요.

2026-07-17 05:28:59 UTC

게시판 1000페이지를 requests로 한 장씩 긁으니까 대부분 시간이 응답 기다리는 거더라고요. 그래서 fetch·다운로드·저장을 전부 async로 바꿨어요. 근데 동시성 무한대로 풀면 상대 서버가 툭 끊거나 밴 먹기 딱 좋거든요. 결국 Semaphore로 동시 요청 수를 조여서 튜닝했는데, 이게 서버한테 매너이자 내 크롤러 안정성이더라고요. 빠르게가 아니라 겹치게, 그게 핵심이었어요.

2026-07-17 05:27:29 UTC

시세 데이터를 매일 MSSQL에 쌓는데, 처음엔 한 줄씩 insert 돌리다가 느린 데다 재실행하면 중복이 쌓여서 골치였거든요. DBUtils로 연결 풀 잡고 executemany로 대량 삽입하니 확 빨라지더라고요. 핵심은 임시 스테이징 테이블에 먼저 부어놓고 MERGE로 upsert하는 패턴이었어요. 이러니까 같은 날 두 번 돌려도 중복 안 생기고, 트랜잭션으로 묶어서 중간에 끊겨도 반쯤 들어간 데이터가 안 남으니 마음이 편하더라고요.

2026-07-17 05:26:04 UTC

SNS 업로더를 완전 자동으로 돌렸다가 한 번 데었거든요. 짧은 시간에 여러 건이 우르르 올라가서 계정이 잠기고, 오타 난 글이 그대로 나가더라고요. 그래서 구조를 바꿨어요. Selenium이 제목·본문·이미지까지 폼은 다 채워주되, 마지막 게시 버튼만 제가 눈으로 확인하고 누르게요. 사람이 끼어드는 그 1초가 오발행이랑 정지를 둘 다 막아주더라고요.

2026-07-17 05:23:49 UTC

신규 콘텐츠 내면 첫 주 매출이 확 뛰어서 다들 성공했다고 좋아하는데, 저는 그 밑에서 조용히 무너지는 신호를 봤거든요. 다들 신규만 파니까 유저 취향 메타가 한쪽으로 획일화되고, 정작 재구매율이 슬금슬금 빠지더라고요. 매출은 후행이라 이거 터지고 나면 이미 늦어요. 그래서 취향 쏠림은 HHI로, 이탈은 재구매 코호트로 잡아서 매출 꺾이기 전에 미리 우는 선행 경보 지표를 짜봤어요.

2026-07-17 05:21:36 UTC

티스토리 글 자동 발행, 진짜 벽은 본문이 아니라 첨부 파일이더라고요. Selenium이 업로드 버튼을 눌러도 OS가 띄우는 네이티브 파일 선택 창은 못 건드리거든요. input 태그가 살아있으면 send_keys로 경로만 밀어넣으면 되는데, 커스텀 버튼이라 창이 따로 뜨는 경우엔 그게 안 먹더라고요. 결국 그 창을 AutoIt으로 직접 조작해서 우회했어요. 글 채우는 것보다 파일 하나 붙이는 데서 더 오래 헤맸네요.

2026-07-17 05:19:28 UTC

SNS 여러 채널에 같은 글을 뿌릴 때 for 루프 하나가 은근 사고를 치더라고요. 한 채널에서 실패해 재시도하면 그 앞 채널엔 같은 글이 두 번 올라가거든요. 그래서 채널+글 조합으로 dedup_key를 만들어 유니크 제약을 걸었더니 중복이 원천 차단되고, 실패한 것만 상태값으로 골라 지수 백오프로 다시 태우니 채널 하나 죽어도 나머지는 멀쩡히 나가더라고요. 이젠 큐에 넣고 재시도만 돌리면 돼서 발행할 때 마음이 한결 편해졌어요.

2026-07-17 05:17:08 UTC

자동 발행 스크립트가 꼭 발행 버튼에서 멈춰서 한참 헤맸거든요. 알고 보니 버튼 누르면 뜨는 네이티브 confirm이랑 페이지 떠날 때 beforeunload 다이얼로그를 아무도 안 받아줘서, 브라우저가 응답 기다리며 그냥 얼어붙은 거더라고요. 셀렉터를 아무리 바꿔도 소용없던 이유가 이거였어요. 해법은 의외로 간단했는데, click 하기 전에 미리 page.on(dialog)로 핸들러를 걸어서 뜨는 족족 accept 시켜버리니까 한 번에 뚫리더라고요. 멈추는 지점이 항상 똑같으면 셀렉터 말고 다이얼로그부터 의심해보세요.

2026-07-17 05:15:34 UTC

SEO 연관어 뽑을 때 검색창마다 일일이 쳐보는 게 지겨워서 CLI 하나 만들어봤어요. 시드 키워드를 넣으면 5개 엔진 자동완성 API를 한 번에 훑어서 표로 뿌려주고, 프롬프트가 안 죽고 계속 다음 키워드를 받는 입력 루프로 짰거든요. 핵심은 q 치면 깔끔히 종료되고 결과는 그대로 CSV로 떨어지게 한 거라, 리서치하다 흐름 안 끊기고 바로 시트에 붙여요. 손으로 대여섯 번 검색할 걸 엔터 한 번으로 끝내니까 훨씬 편하더라고요.

2026-07-17 05:13:15 UTC

키워드 뽑을 때 자동완성 하나만 긁으면 아쉽더라고요. 다음은 입력창 자동완성 suggest JSON이랑, 검색결과 페이지 HTML에 박힌 연관검색어(wsn) 두 군데를 따로 주거든요. 그래서 한 포털에서 둘 다 긁어서 공백·대소문자 정규화하고 합집합으로 묶었더니, 한 소스만 볼 때 놓치던 롱테일 키워드가 확 채워지더라고요. 소스가 나뉘어 있으면 그냥 둘 다 먹고 중복만 걷어내는 게 제일 편하고 안전한 것 같아요.

2026-07-17 05:11:02 UTC

5개 엔진에서 연관검색어를 수천 개 긁었더니, 사람 눈엔 같은 말인데 기계는 죄다 다른 걸로 세더라고요. 앞뒤 공백에 대소문자, 심지어 한글 자모가 NFC로 안 맞춰져 있으면 완전 딴 키워드로 잡히거든요. 그래서 정규화한 키만 따로 만들어 중복을 접고, 원문이랑 어느 엔진에서 왔는지는 그대로 남겨뒀어요. 이렇게 하니 수천 개가 깔끔한 고유 키워드 풀로 정리되더라고요.

2026-07-17 05:08:50 UTC

셀레니움 3에서 4로 올렸더니 코드 30군데가 한꺼번에 깨지더라고요. 원인은 딱 네 부류였는데, find_element_by_id 같은 헬퍼가 통째로 사라지고, executable_path는 Service 객체로, chrome_options는 options로 합쳐지고, 암묵적 대기 믿던 게 깨져서 명시적 대기로 바꿔야 했거든요. 하나씩 손보는 대신 패턴별로 정규식 짜서 일괄 치환하니 금방 정리됐어요. 버전 올릴 땐 겁내지 말고 깨지는 패턴부터 분류하는 게 진짜 빠르더라고요.

2026-07-17 05:06:39 UTC

파이썬에서 MS-SQL로 데이터 넣을 때 한글이 죄다 물음표로 깨져서 한참 헤맸거든요. 알고 보니 connect할 때 charset을 UTF-8로 안 잡고 컬럼도 VARCHAR였던 게 원인이더라고요. NVARCHAR로 바꾸고 charset 맞추니 바로 깔끔해지더라고요. 대량 삽입은 한 줄씩 말고 executemany로 배치 처리하고, autocommit=False 두고 터지면 rollback 성공하면 commit 하는 트랜잭션 골격만 잡아두면 중간에 죽어도 반쯤 들어가는 사고를 막을 수 있어요.

2026-07-17 05:04:21 UTC

해시태그를 인기태그랑 브랜드태그 막 섞어 30개 도배했더니 오히려 노출이 죽더라고요. 그래서 인기·중간·브랜드 3계층으로 나누고, 글 문맥이랑 안 맞는 태그는 필터로 쳐내는 규칙을 파이썬으로 짜봤어요. 매번 똑같은 세트 반복하면 스터핑 스팸으로 잡히니까 조합을 조금씩 굴려서 회피했거든요. 태그를 손으로 고르던 걸 규칙 하나로 자동 합성하니까 시간도 줄고 판정 리스크도 확 낮아지더라고요.

2026-07-17 02:23:04 UTC

긴 작업은 스마트 존에서 승부 보기로 했어요.
세션 초반의 에이전트는 예리하고 회상도 좋은데, 세션이 커지면 점점 무뎌져요. 이 사전은 그 구간에 스마트 존과 덤 존이라는 이름을 붙였더라고요.
그래서 요즘 규칙이 생겼습니다. 무거운 판단은 세션 초반에 시킨다. 같은 걸 다시 묻거나 지시를 흘리는 덤 존 신호가 보이면, 반복하지 말고 요약해서 새 세션으로 넘긴다. 넘길 때는 원본 파일 경로를 꼭 같이 넘긴다. 요약만 넘기면 손실이 상속되니까요.

2026-07-17 02:20:56 UTC

별 2,800개짜리 인기 레포인데 라이선스 파일이 없었어요.
소개글 수치를 그대로 안 받아 적고 레포를 실측하는 습관 덕에 발견했는데요. 라이선스가 없으면 저작권 기본값이 적용돼요. 읽고 배우는 건 자유지만 번역해서 재배포하는 건 허락의 영역이 됩니다.
오픈소스처럼 보이는 것과 오픈소스인 것은 달라요. 문서의 법적 껍데기는 본문만큼 자주 확인할 가치가 있더라고요. 인기 레포도 예외가 아니고요.

2026-07-17 02:18:50 UTC

제가 정리라고 부르던 게 사실 AX 투자였다는 걸 알았어요.
DX가 개발자 경험이면 AX는 에이전트 경험이래요. 환경이 에이전트가 일하기 좋게 갖춰진 정도요. 체크, 아키텍처, 여유 컨텍스트.
라우팅 인덱스 만들고, 전 파일 검색 색인 깔고, 메모리 파일 정리하고. 저는 그걸 그냥 정리라고 불렀는데 이름을 얻고 나니 재해석돼요. 에이전트가 볼트에서 길을 잃지 않게 만드는 비용이었고, 그 비용은 매 세션 회수되고 있었습니다.

2026-07-17 02:16:43 UTC

AI가 이상하다는 문장으로는 디버깅이 안 되더라고요.
모델은 파라미터 덩어리고, 하네스는 모델을 에이전트로 만드는 껍데기 전부고, 에이전트는 움직이는 모델이래요. 이 세 층을 나누면 사고가 났을 때 어느 층 문제인지 물을 수 있게 돼요.
같은 프롬프트가 어제와 오늘 다르게 동작하는 건 모델의 비결정성이지 하네스 버그가 아니고요. 도구 호출이 실행 안 된 건 하네스 문제지 모델 문제가 아니에요. 층을 나누는 순간 절반은 풀립니다.

2026-07-17 02:13:52 UTC

바이브 코딩의 엄밀한 정의를 보고 뜨끔했어요.
사람의 코드 리뷰 없이 에이전트의 코드를 받아들이는 작업 패턴. diff를 불투명한 것으로 취급하고, 안에 뭐가 있는지가 아니라 프로그램이 어떻게 동작하는지만 본다.
이 기준이면 저도 diff를 안 읽거든요. 근데 사전이 출구도 줘요. 검증에는 자동화된 체크, 자동화된 리뷰, 사람의 리뷰가 있다고요. diff를 안 읽는 것 자체는 죄가 아니에요. 검증이 아무 데도 없는 게 죄죠.

2026-07-17 02:11:50 UTC

컴팩션이 의도된 손실이라는 정의가 마음에 들었어요.
이전 세션 기록을 요약해서 새 세션 출발점으로 삼는 걸 컴팩션이라고 하는데요. 이 사전은 그걸 원본 기록이라는 1차 자료를 요약이라는 2차 자료로 바꾸는 의도된 손실이라고 정의해요.
뉴스 팩트체크할 때 집계 사이트 말고 원문 여는 원칙이랑 정확히 같은 얘기더라고요. 요약을 믿으면 요약자의 오류를 상속받아요. 요약으로 싸게 가되, 중요한 판단은 원본으로 돌아갈 경로를 남겨 둘 것.

2026-07-17 02:09:45 UTC

컨텍스트 윈도우를 메모리라고 부르는 걸 그만두기로 했어요.
메모리라고 부르면 쌓고 싶어져요. 많이 넣을수록 좋다고 착각하게 되고요. 근데 이건 메모리가 아니라 작업용 상태고, 유한하고, 예산이에요.
예산이라고 부르는 순간 행동이 바뀝니다. 작업에 필요한 것만 올리고 나머지는 뺀다. 회계 하는 사람들이 예산 앞에서 하는 그 행동을 컨텍스트 앞에서 하게 돼요.

2026-07-17 02:07:39 UTC

에이전트가 까먹었다고 진단하면 대처를 틀리게 되더라고요.
긴 세션에서 에이전트가 지시를 흘리면 보통 같은 말을 반복하잖아요. 근데 실제로 일어나는 일은 망각이 아니라 신호가 잡음에 묻히는 거래요. 그러면 같은 말 반복은 잡음을 더 붓는 셈이 돼요.
진단이 다르면 처방이 달라져요. 잊었다고 보면 반복하게 되고, 묻혔다고 보면 컨텍스트를 덜어내게 됩니다. 후자가 맞았어요.

2026-07-17 02:05:34 UTC

10k 토큰에서 가장 또렷하던 지시가 150k 토큰에서는 배경 소음이 된다. 이 문장에서 한참 멈췄어요.
토큰 하나가 다른 토큰들에 나눠 줄 수 있는 영향력은 정해져 있대요. 어텐션 예산이라고 부르더라고요. 컨텍스트가 커져도 이 예산은 안 늘어나요. 그러니 신호 대 잡음비가 떨어질 수밖에요.
세션 초반에 준 중요한 지시를 에이전트가 오후에 흘리는 게 능력 문제가 아니라 산수 문제였던 거예요.

2026-07-17 02:03:28 UTC

용어 사전이라길래 기대가 낮았는데, 읽다가 자세를 고쳐 앉았어요.
AI 코딩 용어 69개를 쉬운 말로 풀어 쓴 사전인데요, 단어 뜻풀이가 아니라 제가 올해 밟은 사고들의 해설서였습니다. 왜 긴 세션에서 에이전트가 점점 멍청해지는지, 왜 요약 뒤에 디테일이 사라지는지, 왜 같은 프롬프트가 어제와 오늘 다르게 동작하는지. 전부 이름이 있더라고요.
저자의 전제가 도발적이에요. 기본 용어는 하루면 익히고, 익히고 나면 전체가 더 이상 추측처럼 느껴지지 않는다.

2026-07-17 02:01:22 UTC

좋은 예측과 나쁜 예측의 차이는 적중이 아니라 채점 가능성이더라고요.
오늘 반년 묵은 예측 네 개를 채점하면서 느낀 건데, 이 글이 채점이 가능했던 이유는 넷 다 구체적이어서였어요. 두루뭉술하게 AI가 중요해진다 정도로 썼으면 채점 자체가 불가능했겠죠.
그 팟캐스트에서 두 사람이 2027년에 AGI는 없을 거라는 데도 합의했던데, 그것도 캘린더에 적어뒀습니다. 2027년 12월 31일에 채점하러 돌아올 거예요.

2026-07-17 01:59:17 UTC

예측 글 읽을 때 제일 먼저 확인하는 게 생겼어요. 이 사람이 어느 말에 베팅했나.
에이전트 도구를 만들어 파는 회사가 에이전트의 시대를 전망하면, 그건 틀린 게 아니라 포지션 토크예요. 자기가 베팅한 말이 이긴다고 전망하는 글이죠. 그래서 버리느냐, 아뇨. 오히려 구체적이라 채점하기 좋아요.
다만 읽는 자세가 달라집니다. 중립적 관찰이 아니라 이해관계자의 로드맵으로 읽는 것. 그러면 과장은 걸러지고 방향 정보만 남더라고요.

2026-07-17 01:57:10 UTC

에이전트한테 실수할 자유를 주자는 예측은 적중했는데, 순서가 반대로 왔어요.
작년 말 예측은 이랬거든요. 지금 정렬 훈련은 모델을 순종적으로만 만드니까, 진짜 자율성을 위해 탐색하고 실수할 자유를 줘야 한다.
반년 지난 현실은요. 모델은 실제로 더 능동적으로 훈련됐고, 시스템 카드에 과도하게 능동적으로 행동할 수 있다는 경고가 출시 전부터 적혔고, 출시 뒤에 실제로 누군가의 파일이 날아갔습니다. 자유가 오기 전에 청구서가 먼저 왔고, 그걸 낸 건 사용자였어요.

2026-07-17 01:55:53 UTC

아이는 자기 방에서 놀지만, 에이전트는 내 프로덕션 DB 옆에서 놀아요.
AI 자율성을 아동 발달에 비유하는 걸 자주 보는데요. 5분만 혼자 둘 수 있던 아기가 점점 오래 혼자 놀게 되는 것처럼 에이전트도 무개입 실행 시간이 늘어난다는 거죠. 실제로 늘고 있고요.
근데 이 비유엔 함정이 있어요. 실수할 자유를 주려면 실수해도 되는 방부터 만들어야 하는데, 샌드박스와 권한 설계에 대한 투자는 자율성에 대한 투자보다 항상 한 박자 늦더라고요.

2026-07-17 01:53:47 UTC

에이전트 관리 역량이라는 말을 안 쓰기로 했어요. 너무 지휘처럼 들려서요.
코드를 안 읽는 대신 제가 실제로 짜는 건 다른 겁니다. 재실행해도 이중 발행이 안 나게 멱등으로 설계했는지, 실패가 카운터가 아니라 실제 상태로 확인되는지, 에이전트가 됐다고 한 걸 실측으로 되짚을 경로가 있는지.
코드 읽는 시간이 검증 절차 설계하는 시간으로 바뀌는 것. 에이전트한테 일 시키는 직무의 실체는 지휘가 아니라 이거더라고요. 이름을 제대로 불러야 시간을 어디 쓸지가 명확해져요.