인사이트 임팩트

인사이트 임팩트팀은 26년 3월을 끝으로 영업을 종료합니다.
그동안 감사했습니다.
AI라는 거대한 변화의 흐름 속에서 저희 팀은 더 나아가지 못했지만, 그 과정 자체는 의미 있는 도전이었습니다.
각자의 길에서 더 큰 성취를 이루시길 진심으로 바랍니다.

[인사이트 임팩트 @insight_impact_]

왜 내 AI는 말을 안 듣지?
성능 좋은 모델을 쓰면 결과물이 뚝딱 나올까요? 챗GPT를 쓰다가 제미나이로 넘어가고, 제미나이를 쓰다가 클로드로 넘어가면 문제가 해결될까요? 서점에 이런 종류의 책은 이미 넘쳐납니다. 프롬프트 엔지니어링이나 도구 사용법으로는 이 문제를 해결할 수 없습니다. 문제를 해결하려면 패러다임을 전환해야 합니다.

코더에서 지휘자로!
프롬프트를 입력하고 코드를 확인하는 코더의 방식이라면 인간이 명확한 병목입니다. 에이전트 팀을 지휘하는 지휘자가 되어야 합니다. 코드를 중심으로 생각하는 코더의 방식에서 벗어나 계획, 위임, 검토하는 지휘자의 방식으로 전환해야 합니다. 프롬프트 기법 같은 구체적인 요령이 아니라 사고방식의 전환을 배워야 합니다.

구조화된 접근 방식
에이전트를 에이전트답게 활용하려면 요청 → 결과라는 단일 사고방식에서 벗어나야 합니다. 에이전트를 프로젝트 단위로 굴리려면 구조적인 방법론이 필요합니다. PLAN 프레임워크는 AI 모델이나 도구 중립적인 방법론을 제시합니다. 에이전트에 일을 맡기는 요령이 아니라 에이전트 기반 개발을 안정적으로 운영하기 위한 실행 프레임워크로 시작하세요. "왜 내 AI는 말을 안 듣지?"라고 고민하고 있다면 PLAN 프레임워크로 구조부터 설계하세요.

예스24
https://t.co/fIaLM6sq7B

[인사이트 임팩트 @insight_impact_]

https://t.co/NpgtcU50Pb

[인사이트 임팩트 @insight_impact_]

요즘은 답을 찾는 데 시간이 거의 들지 않는다.

질문을 입력하면,
몇 초 안에 그럴듯한 답이 나온다.
정리도 되어 있고,
논리도 맞고,
빠진 것도 없어 보인다.

문제는 그 다음이다.
그 답을 읽고 나면
이상하게 선택이 더 쉬워지지 않는다.
오히려 비슷한 답을 몇 개 더 확인하고 싶어진다.

[인사이트 임팩트 @insight_impact_]

“무엇이 맞는가?”가 아니라, “무엇을 버릴 것인가?”
이 질문을 할 수 있는 순간, AI는 도구가 된다.

[인사이트 임팩트 @insight_impact_]

무언가를 보고 있다고 생각하지만 사실은 제대로 보고 있지 않다. 사고의 인지 자원을 절약하기 위해 많은 것을 무시하고 있다. 따라서 ‘무엇에 주목할 것인가?’, ‘어떻게 주목할 것인가?’를 의식적으로 생각하고 주의 깊게 살피면 새로운 통찰이 생긴다. 이를 위해서는 방법을 배우고 훈련을 반복해 제대로 준비해야 한다.

“자네는 보기만 하지 관찰하지는 않잖아. 이 두 가지는 분명히 달라. 예를 들어 자네는 현관에서 이 방으로 이어지는 계단을 수없이 보았을 거야.”
“그렇지.”
“몇 번이나 봤을까?”
“글쎄, 수백 번.”
“그럼 계단이 몇 개야?”
“계단이 몇 개냐고? 모르겠는데.”
“이것 봐. 자네는 관찰하지 않은 거야. 그냥 보기만 한 거라고. 그게 요점이야. 나는 계단이 17개라는 걸 알지. 눈으로 보면서 동시에 관찰했기 때문이야.” (후략)

#해상도 #해상도를높여라

[인사이트 임팩트 @insight_impact_]

https://t.co/ZQanRTuVU7

이제 이런 책들에서 인사이트를 찾는 시대가 아니거든

[돈룩백 @dontlookback_x]

@insight_impact_ 이제는 코드 한줄 잘짜는거보다 AI 지휘하는 능력이 더 중요해진것 같습니다.

[인사이트 임팩트 @insight_impact_]

https://t.co/mRb0Gh1sS0

"'프롬프트 작성'과 '사고 구조 설계'는 다르다. 프롬프트는 가속 페달일 뿐입니다. 진정한 통제력은 프롬프트들이 배치되는 상위의 시스템 구조에서 나옵니다."

비전공자, 비개발자도 AI로 3개월 동안 코딩하면서 도달한 결론. 프롬프트 한 줄이 중요한 게 아니라 구조가 중요.

[로그 Logue @AlexZio00]

https://t.co/e6JJ0yGICv

[인사이트 임팩트 @insight_impact_]

개발자 인사이트의 방향이 달라졌는데...

예전 같으면 코딩을 더 잘하려면? 자료구조와 알고리즘을 공부하세요 같은 식이었는데 지금은 아무도 관심이 없는 주제가 되어버렸음

코드 만들어 줘 하기 전에 플래닝을 하는 게 더 낫다는 지식이 퍼지면서 기본이 되었는데 그러면 클로드 코드에 플래닝 모드가 추가되고, 코파일럿에 추가된 건 25년 11월 18일, 코덱스가 추가된 건 26년 2월 2일.

<어쨌든, 에이전틱 코딩>의 원서 출간일은 25년 11월 6일, 번역서의 출간일은 26년 4월 10일.

사람들이 바이브 코딩에서 임계점을 넘어 에이전트 본격적으로 넘어간 임계점은 아마도 25년 12월.

그러나 바이브 코딩을 매일 8시간 이상 파던 사람들은 에이전트를 팠고, 에이전트를 매일 8시간 이상 파던 사람들은 결국 에이전틱 코딩, 하네스 엔지니어링으로 넘어갔음.

에이전틱 코딩에서는 에이전트에 장기간 목표를 주고 일을 할당하는 것인데, 그렇게 해보면 결국 결과물이 원하는 대로 나오지 않게 되는 순간이 오는데, 이걸 어떻게 보완할까? 인 것.

<어쨌든, 에이전틱 코딩>에서는 22개의 튜토리얼이 있지만, 거기서 실습한 에이전트를 에이전트 팀으로 만들어서 운용하는 단계가 15장인 것.

프런티어들이 제공하는 플래닝 모드가 없다면? 클로드 코드 소스 코드 유출로 보면 알겠지만, 모델 자체의 성능이 뛰어난 게 아니라 그 안에 하네스 구조가 잘 짜여 있다는 게 핵심이었던 것.

로컬 LLM을 쓰고 플래닝을 한다면? 프런티어가 제공하는 플래닝 모드보다 더 정교한 플래닝을 하고 싶다면?
이게 인사이트의 방향이 바뀌었다는 얘기임.

과거엔 코딩을 더 잘 하려면? 알고리즘? 자료구조? 운영체제? 하드웨어 구조?

이젠 바이브 코딩이든, 에이전틱 코딩이든 용어는 뭐라고 해도 좋은데,
그래서 프런티어들이 제공하는 플랜 모드가 동작하는 원리는?
보안을 더 챙긴다는데 어떻게? 그걸 내가 직접하려면 어떻게?

이게 지금 인사이트의 방향이 바뀌었다는 얘기고, <어쨌든, 에이전틱 코딩>을 읽어봐야 하는 이유.
이 책은 모델 중립이라 클로드 코드, 챗GPT 같은 건 아예 없고, 친절하지도 않음.
프롬프트로 이렇게 구조를 짜고 이렇게 해야 해! 라는 가이드인데 지금은 상당수 내용이 프런티어들이 제공하고 있음.
책에서는 에이전트 코딩 매니페스토(ACM)를 작성하는 걸로 시작하는데 지금은 AGENTS.md를 작성하는 걸로 표준화했음.
샌드박스를 구성해서 쓰는 사람들이 많으니까 프런티어들이 샌드박스 모드를 추가했음.
그런데 결국 사람들이 자생적으로 알아서 많이 쓰기 시작한 베스트 프랙티스를 프런티어들이 서비스에 내장해서 제공하는 것뿐임. 프런티어들이 제공하지 않는다면? 나 스스로 이런 구조를 만들고 싶다면? 샌드박스는? 안전은? 플래닝은? 리뷰 프로세스는? 보안은? 팀 구조에는 어떻게 결합할까?
보안을 이유로 로컬 LLM으로 내가 직접 이런 구조를 만들어야 한다면?
그럴 때 필요한 인사이트를 제공하는 책임.

분명 다른 책들은... 아직 에이전틱 코딩은 이 책이 유일하지만, + 버튼 클릭하세요, PLAN MODE 클릭하세요. 이런 식의 따라 하기를 가르쳐주겠지만, 사용법 이후의 인사이트를 설명하지는 않을 거라는 얘기.

<어쨌든, 바이브 코딩>도 툴 중립적이고, 그런 구성이 불친절하게 느껴질 수 있지만, 교보 컴퓨터 분야 베스트 29위까지 역주행 중임. 4개월차에 역주행 중이라는 건 지난 3개월 동안 구매 독자가 읽고 추천할만 하다고 느껴서 주변에 추천해야 가능한 것이지, SNS에 글 쓰고 마케팅한다고 되는 게 아님. 특히나 IT 전문서는...

구매 독자의 90%가 남성인 전통적인 IT 책과 달리 이 책은 구매 독자의 55%가 여성임. 여성 독자들의 입소문에 감사감사.

툴 중심의 따라 하기가 과거만큼 중요하지 않음. 직접 실습해 보면 프롬프트로 되어 있는 게 오히려 직관적이고 따라 하기도 편할 정도. 잘 안 되는 게 있으면 AI에 물어보면 되니까 책이 모든 걸 책임지지 않아도 되는 면이 있음.

<어쨌든, 에이전틱 코딩>도 모든 걸 다 친절하게 설명하지는 않음. 물론 가능하면 초보자를 배려해서 곳곳에 역주를 추가하는 편집을 했지만. 그럼에도 읽어보면 왜 이런 구조로 해야 하는지, 그래서 지금 프런티어들이 왜 이런 구조로 서비스를 제공하고 명령어를 추가했는지 이해할 수 있음. 즉, 인사이트를 얻을 수 있음.

AI로 어떤 구조를 짜야 하는가에 대한 인사이트를 찾고 싶다면 읽어 보시라.

스타트업 대표님이 일괄 구매해서 회사 기획자에게도 다 보라고 뿌려주셨다고 해서 그저 감사감사.
비전공자도 모르는 건 패스하면서 읽으면 되고, 전체적인 구조를 이해하기엔 좋은 책이라고 추천했거든...

어쨌든, 에이전틱 코딩을 다루는 책은 이 책이 유일하고 배우고 싶다면 이 책을 사시라.
25년 11월이면 다들 바이브 코딩 책 판권 가져와서 지금 바이브 코딩 책 번역서 출간하네 마네 하는 시기인데, 그러면 많이 늦음. 집필서도 많이 나온 상황이니...

이렇게 빨리 내도 벌써 사람들은 에이전틱을 파다보니 하네스 엔지니어링으로 가는 건데...
결국 내가 지금 하고 있는 게 뭐지?에 대해 개념화, 용어화되다보니 하네스라는 말이 붙은 것.
이 책엔 하네스라는 단어는 없지만, 결국 15장이 그 내용. 부록에 하네스에 필요한 각 에이전트 구성 프롬프트가 정리되어 있음.

[INSIGHTBOOK @insightbook]

하니스(하네스) 엔지니어링이 궁금하신가요?
플랜 에이전트, 코딩 에이전트, 리뷰 에이전트, 테스트 에이전트처럼 에이전트의 역할을 분할해서 서로가 서로를 견제하게 만드는 게 하니스 엔진니어링이라 할 수 있을 텐데요.
예약 판매 중인 《어쨌든, 에이전틱 코딩》 https://t.co/L1ey1mlhaL

[인사이트 임팩트 @insight_impact_]

https://t.co/ZQanRTuVU7

이제 이런 책들에서 인사이트를 찾는 시대가 아니거든

[Ryan Kim @ryan_kim_dev]

개발책 알라딘에 다 던지고 오면서 느낀점
- 매입가 개똥값이구나
- ai시대라 책 안읽는다고 다들 중고로 던진건가 매입불가 상품 개많다

[인사이트 임팩트 @insight_impact_]

예상했던 과제가 일어나는 장면이나 자사 제품이나 서비스가 사용되는 장면을 관찰하면 우리는 고객의 문제를 세밀하게 이해할 수 있다.
단순히 현장에 가서 그 자리에서 일어나는 일을 그냥 보는 것만으로는 관찰이라고 할 수 없다. 이를 알기 쉽게 표현하는 것이 명탐정 셜록 홈스와 조수 왓슨의 대화다.
“자네는 보기만 하지 관찰하지는 않잖아. 이 두 가지는 분명히 달라. 예를 들어 자네는 현관에서 이 방으로 이어지는 계단을 수없이 보았을 거야.”
“그렇지.”
“몇 번이나 봤을까?”
“글쎄, 수백 번.”
“그럼 계단이 몇 개야?”
“계단이 몇 개냐고? 모르겠는데.”
“이것 봐. 자네는 관찰하지 않은 거야. 그냥 보기만 한 거라고. 그게 요점이야. 나는 계단이 17개라는 걸 알지. 눈으로 보면서 동시에 관찰했기 때문이야.” (후략)
우리는 무언가를 보고 있다고 생각하지만 사실은 제대로 보고 있지 않다. 사고의 인지 자원을 절약하기 위해 많은 것을 무시하고 있다. 따라서 ‘무엇에 주목할 것인가?’, ‘어떻게 주목할 것인가?’를 의식적으로 생각하고 주의 깊게 살피면 새로운 통찰이 생긴다. 이를 위해서는 방법을 배우고 훈련을 반복해 제대로 준비하는 것이 필요하다. 몇 가지 힌트를 알려 주고자 한다. _113~114p, 「과제의 해상도를 높인다 - ‘깊이’」 중에서

#해상도 #해상도를높여라

[인사이트 임팩트 @insight_impact_]

"해상도가 높은 사람은 더 많이 고민하지 않는다 - 먼저 정의하고 더 빨리 행동한다"

#해상도

[인사이트 임팩트 @insight_impact_]

해상도가 낮을 때의 또 다른 전형적인 증상은 추상적인 과제를 단순히 뒤집은 피상적인 해결책만 제시하는 것이다. 예를 들어 ‘기존 앱이 쓰기 어렵기 때문’에 ‘쓰기 쉬운 앱을 만든다.’, ‘정보가 부족하기 때문’에 ‘정보를 제공한다(미디어를 만든다).’, ‘채용이 어렵기 때문’에 ‘인재 매칭 서비스를 만든다.’, ‘제품의 인지도가 낮기 때문’에 ‘인지도를 높이는 활동을 한다.’와 같은 경우다. 과제가 남아 있는 데는 그 나름의 이유가 있을 것이다. 왜 그 과제가 해결되지 못하고 남아 있는지, 그 원인의 이해에 대한 깊이가 부족하면 이런 일이 생기는 경향이 있다. _28p, 「당신의 현재 해상도를 진단하자」 중에서

[인사이트 임팩트 @insight_impact_]

소프트웨어 하네스도 이 책에 설명이 잘 되어 있으며 부록에 정리도 되어 있음

[인사이트 임팩트 @insight_impact_]

왜 내 AI는 말을 안 듣지?
성능 좋은 모델을 쓰면 결과물이 뚝딱 나올까요? 챗GPT를 쓰다가 제미나이로 넘어가고, 제미나이를 쓰다가 클로드로 넘어가면 문제가 해결될까요? 서점에 이런 종류의 책은 이미 넘쳐납니다. 프롬프트 엔지니어링이나 도구 사용법으로는 이 문제를 해결할 수 없습니다. 문제를 해결하려면 패러다임을 전환해야 합니다.

코더에서 지휘자로!
프롬프트를 입력하고 코드를 확인하는 코더의 방식이라면 인간이 명확한 병목입니다. 에이전트 팀을 지휘하는 지휘자가 되어야 합니다. 코드를 중심으로 생각하는 코더의 방식에서 벗어나 계획, 위임, 검토하는 지휘자의 방식으로 전환해야 합니다. 프롬프트 기법 같은 구체적인 요령이 아니라 사고방식의 전환을 배워야 합니다.

구조화된 접근 방식
에이전트를 에이전트답게 활용하려면 요청 → 결과라는 단일 사고방식에서 벗어나야 합니다. 에이전트를 프로젝트 단위로 굴리려면 구조적인 방법론이 필요합니다. PLAN 프레임워크는 AI 모델이나 도구 중립적인 방법론을 제시합니다. 에이전트에 일을 맡기는 요령이 아니라 에이전트 기반 개발을 안정적으로 운영하기 위한 실행 프레임워크로 시작하세요. "왜 내 AI는 말을 안 듣지?"라고 고민하고 있다면 PLAN 프레임워크로 구조부터 설계하세요.

예스24
https://t.co/fIaLM6sq7B