사기성 만병통치약에 가까움. 읽을 가치는 있고 그럴듯해 보이지만, 그래도 결국 사기성 만병통치약임
이유는 슬롯머신 같은 모델이 AGENTS.md, memory.md, 수십 개의 스킬 마크다운에 적어 둔 필수 요구사항을 언제든 빠뜨릴 수 있고, 사실상 보장된다는 데 있음
이런 하네스 접근은 LLM이 엄격하고 완벽하게 규칙을 따르며, 문제는 규칙을 충분히 명확히 많이 쓰지 못한 것뿐인 척함. 이는 LLM 작동 방식에 대한 근본적인 인지 오류임
결국 신뢰할 수는 없지만 상대적으로 더 신뢰할 수 있는 선택지는 사람의 검토와 감독뿐이고, 가능하면 두 번 연속으로 하는 것임
나머지는 전부 사기성 만병통치약이고, 그 지점에 이르면 약속된 생산성 향상도 마찬가지라는 걸 깨닫게 됨. 코드를 읽고 머릿속 모델을 만드는 일이, 이미 머릿속 모델이 있는 상태에서 코드로 옮기는 것보다 훨씬 어렵기 때문임
사기성 만병통치약이라는 표현은 좀 과함. 그런 약은 절대 안 듣지만, LLM이 들어간 것은 확률적이어도 꽤 높은 확률로 작동하기 때문임
코드 읽기는 어떤 코드냐에 따라 다르지만, 다른 기술처럼 연습하면 쉬워짐. 오래전부터 존재하던 거대하고 복잡한 코드베이스를 다뤄야 할 때처럼, 쓰는 것보다 읽는 코드가 훨씬 많은 상황에서는 흔한 일임
더 쉬워지는 경우는 문서, 과거 경험, 동료에게 물어보기 등을 통해 이미 코드에 대한 머릿속 모델을 갖고 있을 때임
에이전트로도 이게 가능함. 보통 AI에 프롬프트를 넣기 전에 이미 코드 구조를 잘 알고 있고, 작업을 조심스럽게 나누면 생성된 코드 검토가 매우 쉬워짐. 이미 읽은 책을 다시 읽는 느낌이고, 드물게 뭔가 틀리면 바로 눈에 띄어 초기에 대부분 잡을 수 있음. 어느 쪽이든 속도 향상은 큼
사람도 지정한 필수 요구사항을 자주 빠뜨리고, 마찬가지로 검토가 필요함. 그래도 프로세스와 리뷰를 통해 사람 산출물의 신뢰성을 높여 왔고, 하네스에서 쓰는 방법 대부분도 신뢰성 있게 전달하기 어려운 인간의 문제를 줄이려던 경험에서 가져온 것임
말한 내용은 모두 가능하고 이론적으로는 동의함
하지만 지난 몇 달 동안 spec-kit, 즉 이런 방식의 AI 사용을 해봤고 실제로는 놀라울 정도로 좋았음. 훌륭한 것들을 만들고 있으며, 가정으로 제기한 문제들은 아직 겪지 않았음. 언젠가 생길 수는 있고 그래서 조심하고 있음
그래도 어느 정도 오래 직접 써본 뒤에는 그냥 사기성 만병통치약이라고 치부할 수 없음. 30년 넘게 프로그래머로 일해 왔고, 실제로 무엇이 통하고 무엇이 안 통하는지 꽤 잘 판단한다고 느낌
이건 +5 검이 있어도 1이 나오면 빗나가니 쓸모없다는 말과 비슷함. 기대값으로 봐야 함. 누군가가 괜찮은 PR 다섯 개를 머지하고 세 개를 버리는 동안, 그중 하나가 형편없었다고 크게 불평하는 식이면 비교가 안 됨
사람들이 이런 마크다운 제안을 워크플로라고 부르는 이유가, 더 구조화된 접근을 다듬는 사이에 구식이 될까 두려워서이길 바람. 기반 모델의 혁신 속도가 영원히 이렇게 유지될 것 같지는 않음
앞으로는 요청이 아니라 요구하는 하네스를 보고 싶음. 계획 모드에 있으라고 했는데 정해진 계획 절차를 따르지 않는 에이전트는 죽이는 식임. 완벽하지 않더라도 사람이 끼어 있는 현재 방식보다는 나아야 함
“스킬은 상황에 맞을 때 에이전트 문맥에 주입되는 frontmatter가 있는 마크다운 파일”이라고 하지만, 그 상황인지 결정하는 건 LLM임
“에이전트가 따르는 일련의 단계이며, 증거를 만드는 체크포인트와 명확한 종료 기준으로 끝난다”고 하지만, 그 단계를 따를지 결정할 수 있는 것도 LLM임
스킬은 사용자가 명령형으로 호출하는 경우가 많음. LLM이 직접 쓰도록 의도된 경우에는 문맥 어딘가에 넣으면 됨. 예를 들면:
After implementing the feature, read the testing skill for instructions on how to test.
공정하게 말하면 Codex 같은 곳에서는 $my-skill로 스킬을 직접 호출할 수 있고, 그러면 실제로 그 스킬이 문맥에 주입됨. 그 뒤에는 LLM이 프롬프트, 지시, 문맥의 다른 부분을 따르는 정도만큼 그 스킬도 따름
모두가 에이전트 만지작거리며 1년 넘게 보내고 가짜 생산성 느낌만 경험했다는 걸 깨닫는 날이 기대됨
어느 정도 회의론은 이해하고, AI가 여러 이유로 나쁘다고 근본적으로 믿을 수도 있음. 하지만 이런 단정적인 표현이 점점 더 이해가 안 됨. AI 개발이 이렇게 망했다고 어떻게 그렇게 확신하는지 궁금함
실제 경험과 전혀 맞지 않음. AI 코딩의 필연적 몰락을 그렇게 확신하게 만든 경험이 무엇인지 궁금함. AI가 도덕적으로 나쁘다는 철학적 믿음인지, 아니면 실제로 AI로 뭔가를 만들어 보고 충분히 탐색한 끝에 강한 결론을 낸 것인지 알고 싶음
30년 넘게 매일 코드를 썼고, 20년 넘게 직업으로 해왔음. 유행이 왔다가 가는 것도 봤고, 일하는 방식을 바꾼 진짜 발전도 여러 번 봤음. AI로 더 많은 프로젝트를 만들수록, 이것이 소프트웨어를 만들고 컴퓨터를 쓰는 방식에 대한 지속적이고 근본적인 변화라는 확신이 커짐
AI가 나아지는 것도 봤고, 실제 업무를 끝내는 데 내가 더 능숙해지는 것도 봤음. 그 작업은 이미 현실 세계의 프로덕션 부하로 테스트됐음. 벌어지는 일이 싫고 AI와 일하는 느낌이 싫을 수는 있지만, 그렇다고 그것이 사람들에게 실제 가치를 주고 실제 일을 하고 있지 않다는 뜻은 아님
이런 관점이 궁금함. 선의로 묻자면, AI/에이전트/하네스를 쓰는 사람들은 기능을 배포하지 않는다는 전제가 깔린 건가?
우리는 9월쯤부터 Claude Code에 전면적으로 들어갔고, 향상을 성공적으로 추적할 수 있었음. 실제 프로덕션에서 쓰이는 기능들을 배포하고 있음. 인프라 쪽도, 비즈니스 로직 구현도, 프론트엔드와 백엔드 모두 마찬가지임
사람들이 그렇게 시간을 낭비한다고 보지는 않음. 다만 이런 글 대부분은 허튼소리라는 데는 동의하고, 이 글도 포함됨. 그래도 AI 개발은 전 세계 많은 회사에서 이미 일어나고 있음
사람들이 종이 장부를 그만 쓰고 소위 데이터베이스라는 걸 만지작거리느라 생산성을 잃었다는 말과 비슷함
산출물을 측정하는 프로젝트에서 일하고 있는데, 거기엔 “가짜”가 전혀 없음
Minecraft 자동화처럼 대함. 그냥 재미와 시간 보내기용임
에이전트식 워크플로는 아직 거기까지 도달하지 않았다고 보지만, 수동으로 호출해서 AI와 나란히 일할 때 쓰는 스킬 구현은 확실히 괜찮음. 우리 회사는 요즘 샌드박싱과 안전한 스킬에 많이 집중하고 있음
기능 개발은 아직 잘 잡지 못했다고 보지만, 작성해 둔 리뷰 스킬과 Grafana 스킬은 꽤 탄탄했음
예전에 더 큰 에이전트 스킬 묶음을 써봤는데, 너무 많은 일을 하려 해서 시간 낭비처럼 느껴졌음. Vim처럼 스킬을 IDE처럼 통째로 설치하기보다 커뮤니티에서 골라 쓰는 편이 나은 경우가 많음
스킬은 개발자와 팀마다 달라서 너무 개인적임. 남의 설정을 대량 설치하기보다, 자기 설정을 만들기 위한 참고 자료로 다루는 편이 좋음
MCP와 시스템 지시도 마찬가지임. 이해하지도 않고 전부 설치하는 사람이 많고, 필요 없는 도구 때문에 문맥을 어지럽히며 5만 토큰 이상을 낭비한 뒤, 한도에 너무 빨리 닿아서 월 100달러 넘게 내야 한다고 불평함
실제로 superpowers를 쓰는 사람이 얼마나 되는지 알고 싶음
superpowers 이전부터 에이전트 개발 쪽에 있었는데, 직접 만든 프로세스의 50% 이상이 이제 superpowers로 커버되는 것 같아 걱정됨
더 이상 GitHub 별을 신뢰하지 않음. 누가 알려줬으면 함. superpowers가 이제 정말 채택된 건가? 정말 가치 있다면 Boris는 왜 아직 그 개념을 통합하지 않았을까?
NextJS와 경쟁하려고 React 프레임워크 이름을 ReactJS로 짓는 것 같음
플러그인으로 제공되는 미리 만들어진 스킬 묶음처럼 보임
superpowers가 실제로 작동하나? 메인 스킬 파일은 그다지 신뢰를 주지 않음:
“하고 있는 일에 스킬이 적용될 가능성이 1%라도 있다고 생각하면, 그 스킬을 반드시 호출해야 한다”
왜 다들 자기 일자리를 없애는 데 그렇게 신나 하는지 모르겠음
이런 것들이나 어떤 “스킬”이 정말 그렇게 하지는 않겠지만, 원칙적으로 말임. 이건 노동으로부터의 소외가 대규모로 벌어지는 것 같음
우리는 수십 년 동안 예전 일의 큰 부분을 자동화해 왔음. 그렇지 않았다면 모두가 일이 최대한 오래 걸리도록 가장 비효율적인 방식으로 만들려 했을 텐데, 좋은 생각은 아님
인류는 추적 가능한 한 언제나 일정한 산출을 내는 데 필요한 노동을 줄여 왔고, 그게 문명임. 쓰는 노동을 극대화하려고 괭이로 손농사를 짓던 시절로 돌아가야 하나? 가로등을 하나씩 켜던 시대로 돌아가야 하나?
자동화에서 뒤처지는 사회는 더 가난해지고 결국 죽음. 그곳에서 태어난 사람들조차 생산성이 더 높은 곳으로 떠나기 때문임. 동유럽에도, Amish에게도, 이민이 생기는 가난한 사회 어디서나 일어났음. 더 적은 것으로 더 많이 하는 것은 늘 흥미로운 일이었음
컴퓨터 프로그래머로서는 이런 생각을 이해하기 어려움. 평생 컴퓨터가 일을 하게 만들어 사람이 더는 하지 않도록 하는 일을 해왔음. 작성된 모든 소프트웨어는 누군가의 일을 없애기 위한 것임
만드는 모든 자동화에 대해 이렇게 느끼는지 궁금함. 예전식 시스템 관리자 중에는 인프라 자동화 발전을 이렇게 보는 사람들도 있었고, 예전에는 손으로 하던 일을 스크립트와 시스템이 하게 만드는 걸 싫어했음
우리 팀은 한 직장에서 3만 대 서버에 패치를 자동으로 실행하고, 시스템을 자동으로 프로덕션에서 빼고 넣는 자동 패치 시스템을 만들었음. 전체 과정이 손이 안 가게 됐고, 예전에는 그 과정을 수동으로 돌리는 전담 팀이 있었음. 자동화로 그들의 일을 빼앗았나?
어떤 의미에서는 그렇지만, 해야 할 다른 일이 있었고 이제 그 일을 할 수 있게 됐음
프로그래밍, 컴퓨터, 기술을 좋아하는 이유가 바로 우리 대신 일을 해주기 때문임. 내 유토피아는 로봇이 힘든 일을 다 해서 인간이 원하는 것을 할 수 있는 세상임. AI는 그쪽으로 한 걸음 더 가게 해주고 있음. 인간이 원하지도 않는 일을 하며 바쁘게 지낼 만큼 충분한 일거리를 남겨두려 하기보다, 로봇이 일자리를 가져가는 혜택을 부유한 소유자만이 아니라 전 세계가 누리게 할 방법에 집중하고 싶음
보통 일자리를 잃는 사람은 시장에 적응하지 못한 사람임
지금은 모든 것이 어느 방향으로 진화하는지 명확하지 않아서, 사람들이 자기 데이터를 무작위 에이전트에 넘겨 보고, 문맥을 저장하고 접근하는 법을 찾고, 프롬프트를 재사용하고, 이 기술을 다루려는 여러 시도를 하는 중임
이 중 대부분은 1년 뒤에는 다음 세대 모델에 깊이 통합되어 쓸모없어질 수도 있음. 그래도 발전을 따라가는 일은 이 분야에서 일하는 재미의 일부였음
생존 본능임. 주변의 모두와 모든 것, 직장까지 “AI를 쓰라”고 외치면 반대 입장을 취하거나 주의를 제기하기 어렵다. 신나서라기보다는 파도를 놓치고 뒤처질까 봐 그러는 쪽에 가까움
장기 데이터가 평균적으로 생산성 향상은 제한적이었고, 고급 최신 모델의 지원이 있어도 품질 좋은 소프트웨어를 만들려면 여전히 세심함과 사람의 주의가 필요하다는 걸 보여주면 찬성 쪽과 반대 쪽 모두 조금 놀랄 것 같음
같은 일인데 드라이버 대신 전동 드릴을 갖게 된 것뿐임. 어떤 사람은 수백 년 버티는 집을 짓고, 어떤 사람은 그렇지 못함
좋은 개발자가 아니던 사람들이 갑자기 “정상”까지 가속된 것처럼 느낀 쪽이 가장 적극적으로 보임. 내가 아는 좋은 개발자들은 모두 도입에 좀 더 조심스러웠음
요즘 같은 말을 계속 듣고 있음. 개발자 팀을 관리하는 데 좋은 것들이 LLM 관리에도 좋다는 것임
좋은 테스트 케이스, 명확하고 간결한 문서, CI/CD, 모범 사례와 온보딩 문서가 그렇음
LLM을 관리하는 일이 점점 사람 팀을 관리하는 것과 비슷해지고 있음
아무것도 다르지 않음. 코드를 쓸 때 AI를 신중하게 쓸 생각은 없으면서 대량 해고를 불평하는 개발자들을 위한 같은 쓰레기임
몇몇 스킬이 이렇게 길어서 놀랐음. 표, 체크박스 목록, 코드 예제 등으로 여러 페이지에 걸쳐 있음
이게 얼마나 일반적인지 궁금함. 이런 것 몇 개만 있어도 문맥을 꽤 많이 채울 것 같음
긴 이유는 이런 스킬들이 대부분 Claude Code와 Opus로 만들어졌고, 제정신인 사람이라면 그 파일들을 읽지도, 그걸 바탕으로 머릿속 모델을 만들지도 않을 것이기 때문임. 이게 작동한다는 가정이 여러 겹 쌓여 있지만, 현실에서는 작동하지 않고 낭비적임
재미있는 실험이 있음. LLM에게 막연하게 익숙한 것을 쓰라고 해보면 됨. 예를 들어 “write a fib”라고 요청하면, 거의 모든 LLM은 코드로 미세조정되어 있어서 비프로그래머에게는 “사소한 거짓말을 써라”라는 뜻일 수 있는데도 피보나치 수열 알고리즘으로 답함
즉 압축이 일어남. 피보나치 수열이 정확히 무엇인지 자세히 설명하지 않고도, 모호한 토큰 3개만으로 결과를 표현할 수 있음
그래서 프롬프트 길이는 중요하지 않다는 걸 알 수 있음. 중요한 건 올바른 단어, 빈도, 순서임. 두 페이지짜리 프롬프트와 두 문장짜리 프롬프트가 같은 결과를 낼 수도 있음
빠르게 훑어보니 적어도 몇 개는 스킬이라기보다 좁은 범위의 하위 에이전트를 위한 시스템 프롬프트에 가까워 보였음. 오래 지속되는 작업 세션에서 이런 것들을 많이 쓰고 싶지는 않다는 데 동의함
지금까지는 짧고 집중된 스킬로 성공적이었음. 재사용 가능한 문맥 조각처럼 다루되 작게 유지함. 예를 들어 내 프로젝트에서 Python을 어떻게 쓰고 단위 테스트를 어떻게 실행하는지에 대한 몇 문단 정도임
또한 에이전트에게 지시를 주지는 않고 필요하면 끌어올 수 있는 유용한 문맥 정보만 담은 짧은 “info” 스킬도 여러 개 있음
스킬이 너무 많아도 문제가 될 수 있음. 스킬 이름과 설명 목록이 결국 어느 시점에는 문맥에 들어가기 때문임
스킬을 하나도 작성해 보지 않아서 얼마나 일반적인지는 모르겠음. 몇 개의 단어 수를 세어 보니 대략 2천 단어 수준이었음. 스킬 5개면 1만 단어 정도임
작은 LLM 문맥인 128k에서도 약 10% 정도이고, 큰 모델의 1M 문맥 창에서는 거의 티도 안 남
기본적으로 문맥에는 스킬의 frontmatter, 즉 이름, 설명, 트리거 등만 로드되므로 스킬 수천 개가 있지 않은 한 그런 일은 잘 생기지 않을 것임
내 프로젝트의 스킬 파일 줄 수를 확인해 보니 상위 3개가 805줄, 660줄, 511줄이었음
어쩌면 내가 여기서는 너무 보수적인지도 모름. 더 탐색할 게 많음
“시니어 엔지니어의 일은 대부분 diff에 보이지 않는 부분이다”
Agent Skills는 Addy가 그 일까지 없애려는 시도임. 건배, Addy :P
Hacker News 의견들
사기성 만병통치약에 가까움. 읽을 가치는 있고 그럴듯해 보이지만, 그래도 결국 사기성 만병통치약임
이유는 슬롯머신 같은 모델이
AGENTS.md,memory.md, 수십 개의 스킬 마크다운에 적어 둔 필수 요구사항을 언제든 빠뜨릴 수 있고, 사실상 보장된다는 데 있음이런 하네스 접근은 LLM이 엄격하고 완벽하게 규칙을 따르며, 문제는 규칙을 충분히 명확히 많이 쓰지 못한 것뿐인 척함. 이는 LLM 작동 방식에 대한 근본적인 인지 오류임
결국 신뢰할 수는 없지만 상대적으로 더 신뢰할 수 있는 선택지는 사람의 검토와 감독뿐이고, 가능하면 두 번 연속으로 하는 것임
나머지는 전부 사기성 만병통치약이고, 그 지점에 이르면 약속된 생산성 향상도 마찬가지라는 걸 깨닫게 됨. 코드를 읽고 머릿속 모델을 만드는 일이, 이미 머릿속 모델이 있는 상태에서 코드로 옮기는 것보다 훨씬 어렵기 때문임
코드 읽기는 어떤 코드냐에 따라 다르지만, 다른 기술처럼 연습하면 쉬워짐. 오래전부터 존재하던 거대하고 복잡한 코드베이스를 다뤄야 할 때처럼, 쓰는 것보다 읽는 코드가 훨씬 많은 상황에서는 흔한 일임
더 쉬워지는 경우는 문서, 과거 경험, 동료에게 물어보기 등을 통해 이미 코드에 대한 머릿속 모델을 갖고 있을 때임
에이전트로도 이게 가능함. 보통 AI에 프롬프트를 넣기 전에 이미 코드 구조를 잘 알고 있고, 작업을 조심스럽게 나누면 생성된 코드 검토가 매우 쉬워짐. 이미 읽은 책을 다시 읽는 느낌이고, 드물게 뭔가 틀리면 바로 눈에 띄어 초기에 대부분 잡을 수 있음. 어느 쪽이든 속도 향상은 큼
하지만 지난 몇 달 동안 spec-kit, 즉 이런 방식의 AI 사용을 해봤고 실제로는 놀라울 정도로 좋았음. 훌륭한 것들을 만들고 있으며, 가정으로 제기한 문제들은 아직 겪지 않았음. 언젠가 생길 수는 있고 그래서 조심하고 있음
그래도 어느 정도 오래 직접 써본 뒤에는 그냥 사기성 만병통치약이라고 치부할 수 없음. 30년 넘게 프로그래머로 일해 왔고, 실제로 무엇이 통하고 무엇이 안 통하는지 꽤 잘 판단한다고 느낌
앞으로는 요청이 아니라 요구하는 하네스를 보고 싶음. 계획 모드에 있으라고 했는데 정해진 계획 절차를 따르지 않는 에이전트는 죽이는 식임. 완벽하지 않더라도 사람이 끼어 있는 현재 방식보다는 나아야 함
“스킬은 상황에 맞을 때 에이전트 문맥에 주입되는 frontmatter가 있는 마크다운 파일”이라고 하지만, 그 상황인지 결정하는 건 LLM임
“에이전트가 따르는 일련의 단계이며, 증거를 만드는 체크포인트와 명확한 종료 기준으로 끝난다”고 하지만, 그 단계를 따를지 결정할 수 있는 것도 LLM임
$my-skill로 스킬을 직접 호출할 수 있고, 그러면 실제로 그 스킬이 문맥에 주입됨. 그 뒤에는 LLM이 프롬프트, 지시, 문맥의 다른 부분을 따르는 정도만큼 그 스킬도 따름모두가 에이전트 만지작거리며 1년 넘게 보내고 가짜 생산성 느낌만 경험했다는 걸 깨닫는 날이 기대됨
실제 경험과 전혀 맞지 않음. AI 코딩의 필연적 몰락을 그렇게 확신하게 만든 경험이 무엇인지 궁금함. AI가 도덕적으로 나쁘다는 철학적 믿음인지, 아니면 실제로 AI로 뭔가를 만들어 보고 충분히 탐색한 끝에 강한 결론을 낸 것인지 알고 싶음
30년 넘게 매일 코드를 썼고, 20년 넘게 직업으로 해왔음. 유행이 왔다가 가는 것도 봤고, 일하는 방식을 바꾼 진짜 발전도 여러 번 봤음. AI로 더 많은 프로젝트를 만들수록, 이것이 소프트웨어를 만들고 컴퓨터를 쓰는 방식에 대한 지속적이고 근본적인 변화라는 확신이 커짐
AI가 나아지는 것도 봤고, 실제 업무를 끝내는 데 내가 더 능숙해지는 것도 봤음. 그 작업은 이미 현실 세계의 프로덕션 부하로 테스트됐음. 벌어지는 일이 싫고 AI와 일하는 느낌이 싫을 수는 있지만, 그렇다고 그것이 사람들에게 실제 가치를 주고 실제 일을 하고 있지 않다는 뜻은 아님
우리는 9월쯤부터 Claude Code에 전면적으로 들어갔고, 향상을 성공적으로 추적할 수 있었음. 실제 프로덕션에서 쓰이는 기능들을 배포하고 있음. 인프라 쪽도, 비즈니스 로직 구현도, 프론트엔드와 백엔드 모두 마찬가지임
사람들이 그렇게 시간을 낭비한다고 보지는 않음. 다만 이런 글 대부분은 허튼소리라는 데는 동의하고, 이 글도 포함됨. 그래도 AI 개발은 전 세계 많은 회사에서 이미 일어나고 있음
에이전트식 워크플로는 아직 거기까지 도달하지 않았다고 보지만, 수동으로 호출해서 AI와 나란히 일할 때 쓰는 스킬 구현은 확실히 괜찮음. 우리 회사는 요즘 샌드박싱과 안전한 스킬에 많이 집중하고 있음
기능 개발은 아직 잘 잡지 못했다고 보지만, 작성해 둔 리뷰 스킬과 Grafana 스킬은 꽤 탄탄했음
예전에 더 큰 에이전트 스킬 묶음을 써봤는데, 너무 많은 일을 하려 해서 시간 낭비처럼 느껴졌음. Vim처럼 스킬을 IDE처럼 통째로 설치하기보다 커뮤니티에서 골라 쓰는 편이 나은 경우가 많음
스킬은 개발자와 팀마다 달라서 너무 개인적임. 남의 설정을 대량 설치하기보다, 자기 설정을 만들기 위한 참고 자료로 다루는 편이 좋음
검색 최적화나 LLM 최적화 관점에서 보면, 이름을 바꾸지 않으면 이런 스킬의 발견 가능성이 어려울 듯함: https://agentskills.io/
Addy가 본다면, 이것을 Superpowers와 비교해 어떻게 설명할지 궁금함: https://github.com/obra/superpowers
superpowers 이전부터 에이전트 개발 쪽에 있었는데, 직접 만든 프로세스의 50% 이상이 이제 superpowers로 커버되는 것 같아 걱정됨
더 이상 GitHub 별을 신뢰하지 않음. 누가 알려줬으면 함. superpowers가 이제 정말 채택된 건가? 정말 가치 있다면 Boris는 왜 아직 그 개념을 통합하지 않았을까?
“하고 있는 일에 스킬이 적용될 가능성이 1%라도 있다고 생각하면, 그 스킬을 반드시 호출해야 한다”
왜 다들 자기 일자리를 없애는 데 그렇게 신나 하는지 모르겠음
이런 것들이나 어떤 “스킬”이 정말 그렇게 하지는 않겠지만, 원칙적으로 말임. 이건 노동으로부터의 소외가 대규모로 벌어지는 것 같음
인류는 추적 가능한 한 언제나 일정한 산출을 내는 데 필요한 노동을 줄여 왔고, 그게 문명임. 쓰는 노동을 극대화하려고 괭이로 손농사를 짓던 시절로 돌아가야 하나? 가로등을 하나씩 켜던 시대로 돌아가야 하나?
자동화에서 뒤처지는 사회는 더 가난해지고 결국 죽음. 그곳에서 태어난 사람들조차 생산성이 더 높은 곳으로 떠나기 때문임. 동유럽에도, Amish에게도, 이민이 생기는 가난한 사회 어디서나 일어났음. 더 적은 것으로 더 많이 하는 것은 늘 흥미로운 일이었음
만드는 모든 자동화에 대해 이렇게 느끼는지 궁금함. 예전식 시스템 관리자 중에는 인프라 자동화 발전을 이렇게 보는 사람들도 있었고, 예전에는 손으로 하던 일을 스크립트와 시스템이 하게 만드는 걸 싫어했음
우리 팀은 한 직장에서 3만 대 서버에 패치를 자동으로 실행하고, 시스템을 자동으로 프로덕션에서 빼고 넣는 자동 패치 시스템을 만들었음. 전체 과정이 손이 안 가게 됐고, 예전에는 그 과정을 수동으로 돌리는 전담 팀이 있었음. 자동화로 그들의 일을 빼앗았나?
어떤 의미에서는 그렇지만, 해야 할 다른 일이 있었고 이제 그 일을 할 수 있게 됐음
프로그래밍, 컴퓨터, 기술을 좋아하는 이유가 바로 우리 대신 일을 해주기 때문임. 내 유토피아는 로봇이 힘든 일을 다 해서 인간이 원하는 것을 할 수 있는 세상임. AI는 그쪽으로 한 걸음 더 가게 해주고 있음. 인간이 원하지도 않는 일을 하며 바쁘게 지낼 만큼 충분한 일거리를 남겨두려 하기보다, 로봇이 일자리를 가져가는 혜택을 부유한 소유자만이 아니라 전 세계가 누리게 할 방법에 집중하고 싶음
지금은 모든 것이 어느 방향으로 진화하는지 명확하지 않아서, 사람들이 자기 데이터를 무작위 에이전트에 넘겨 보고, 문맥을 저장하고 접근하는 법을 찾고, 프롬프트를 재사용하고, 이 기술을 다루려는 여러 시도를 하는 중임
이 중 대부분은 1년 뒤에는 다음 세대 모델에 깊이 통합되어 쓸모없어질 수도 있음. 그래도 발전을 따라가는 일은 이 분야에서 일하는 재미의 일부였음
장기 데이터가 평균적으로 생산성 향상은 제한적이었고, 고급 최신 모델의 지원이 있어도 품질 좋은 소프트웨어를 만들려면 여전히 세심함과 사람의 주의가 필요하다는 걸 보여주면 찬성 쪽과 반대 쪽 모두 조금 놀랄 것 같음
같은 일인데 드라이버 대신 전동 드릴을 갖게 된 것뿐임. 어떤 사람은 수백 년 버티는 집을 짓고, 어떤 사람은 그렇지 못함
요즘 같은 말을 계속 듣고 있음. 개발자 팀을 관리하는 데 좋은 것들이 LLM 관리에도 좋다는 것임
좋은 테스트 케이스, 명확하고 간결한 문서, CI/CD, 모범 사례와 온보딩 문서가 그렇음
LLM을 관리하는 일이 점점 사람 팀을 관리하는 것과 비슷해지고 있음
이것이 spec-kit보다 무엇이 더 낫거나 다른지 궁금함. 철학이 매우 비슷해 보이고, 같이 쓸 수 있을지도 궁금함. 아니면 그냥 중복일까?
https://github.com/github/spec-kit
몇몇 스킬이 이렇게 길어서 놀랐음. 표, 체크박스 목록, 코드 예제 등으로 여러 페이지에 걸쳐 있음
이게 얼마나 일반적인지 궁금함. 이런 것 몇 개만 있어도 문맥을 꽤 많이 채울 것 같음
재미있는 실험이 있음. LLM에게 막연하게 익숙한 것을 쓰라고 해보면 됨. 예를 들어 “write a fib”라고 요청하면, 거의 모든 LLM은 코드로 미세조정되어 있어서 비프로그래머에게는 “사소한 거짓말을 써라”라는 뜻일 수 있는데도 피보나치 수열 알고리즘으로 답함
즉 압축이 일어남. 피보나치 수열이 정확히 무엇인지 자세히 설명하지 않고도, 모호한 토큰 3개만으로 결과를 표현할 수 있음
그래서 프롬프트 길이는 중요하지 않다는 걸 알 수 있음. 중요한 건 올바른 단어, 빈도, 순서임. 두 페이지짜리 프롬프트와 두 문장짜리 프롬프트가 같은 결과를 낼 수도 있음
지금까지는 짧고 집중된 스킬로 성공적이었음. 재사용 가능한 문맥 조각처럼 다루되 작게 유지함. 예를 들어 내 프로젝트에서 Python을 어떻게 쓰고 단위 테스트를 어떻게 실행하는지에 대한 몇 문단 정도임
또한 에이전트에게 지시를 주지는 않고 필요하면 끌어올 수 있는 유용한 문맥 정보만 담은 짧은 “info” 스킬도 여러 개 있음
스킬이 너무 많아도 문제가 될 수 있음. 스킬 이름과 설명 목록이 결국 어느 시점에는 문맥에 들어가기 때문임
작은 LLM 문맥인 128k에서도 약 10% 정도이고, 큰 모델의 1M 문맥 창에서는 거의 티도 안 남
어쩌면 내가 여기서는 너무 보수적인지도 모름. 더 탐색할 게 많음
“시니어 엔지니어의 일은 대부분 diff에 보이지 않는 부분이다”
Agent Skills는 Addy가 그 일까지 없애려는 시도임. 건배, Addy :P