SH.Consulting
Insights

Insights

AX·AI 에이전트·하네스 엔지니어링에 대한 관점. LinkedIn에 발행한 글의 확장판 정본을 보관합니다.

2026-06-19

AX는 왜 교육이 아니라 환경 설계인가

AX는 구성원에게 도구 사용법을 교육하는 일이 아니라, AI로 일하는 환경 자체를 설계하는 일입니다. 매주 쏟아지는 업데이트를 개인이 100% 따라잡으려 하면 지치기만 합니다. 핵심은 "예전엔 못 하던 걸 이제 한다"고 말할 수 있도록 일하는 방식을 바꾸는 것이고, 그 출발점은 반복되는 짜증나는 업무를 찾아 자동화하는 작은 실험입니다.

더 읽기 →
2026-06-17

AI 시대에는 어떤 회사가 살아남을까

살아남는 회사는 AI를 도입한 회사가 아니라 일하는 방식 자체를 100% 다시 짠 회사입니다. 같은 도구를 써도 엔지니어의 90%가 AI를 쓰는 조직과 100%가 쓰는 조직 사이엔 10배 차이가 납니다. 도구는 모두에게 같고, 그 위에 어떤 프로세스를 새로 쌓느냐가 격차를 만듭니다.

더 읽기 →
2026-06-15

AX는 누가 만들어야 성공하는가

AX(AI 전환)는 외부 개발자가 아니라 그 업무를 매일 하는 현업의 손에서 만들어질 때 성공합니다. 워크플로에 숨은 예외와 암묵 규칙은 그 일을 매일 하는 사람만 알기 때문입니다. 그래서 AX 교육의 본질은 개발자를 늘리는 것이 아니라, 현업이 바이브 코딩으로 자기 일을 스스로 자동화하게 만드는 것입니다. 재무·경영관리 담당자가 매일의 발주 업무를 직접 자동화한 사례가 이를 보여 줍니다.

더 읽기 →
2026-06-14

일상 자동화는 왜 AX의 가장 좋은 출발점인가

내가 매일 반복하는 작은 일 하나를 통째로 없애 보는 것이 AX(AI 전환)의 가장 좋은 출발점입니다. 효율을 몇 퍼센트 높이는 게 아니라 그 작업 자체를 손에서 떼어 내는 경험을 하면, AI가 무엇을 대신할 수 있고 어디까지 믿고 맡길 수 있는지를 몸으로 알게 되기 때문입니다. 흩어진 카카오톡 일정을 AI가 추려 캘린더에 등록하고 아침마다 한 장으로 브리핑하는 개인 자동화가 그 예입니다.

더 읽기 →
2026-06-13

AI 결과물은 왜 마크다운이 아니라 HTML로 받아야 하나

완성된 결과물이라면 마크다운 대신 HTML로 받는 편이 이해 속도를 크게 높입니다. AI가 문서를 만드는 속도가 사람이 읽는 속도를 추월한 지금, 100줄 넘는 마크다운은 사실상 읽히지 않기 때문입니다. Anthropic의 Claude Code 엔지니어도 "HTML이 새로운 마크다운"이라며 산출물을 HTML로 받기 시작했고, 동적 화면이 필요하면 Playground 플러그인이 그 간극을 메웁니다. 기준은 단순합니다. 구조를 봐야 이해되는 완성물은 HTML, 중간 산출물은 텍스트입니다.

더 읽기 →
2026-06-13

AI 코딩 생산성을 가르는 것은 모델인가 워크플로인가

AI 코딩의 결과물 품질은 모델 선택보다 워크플로가 더 크게 가릅니다. 진짜 병목은 약한 모델이 아니라 모호한 명세와 끝맺지 못한 작업이기 때문입니다. oh-my-claudecode(OMC)는 Claude Code 위에서 세 가지 습관을 도구로 굳힌 오케스트레이션 레이어입니다. deep-interview가 무엇을 만들지를 명확히 하고, ralplan이 어떻게 만들지를 검증하며, ralph가 끝까지 완성됨을 보장합니다. '무엇을·어떻게·끝까지'를 강제된 파이프라인으로 바꾸는 것이 핵심입니다.

더 읽기 →
2026-06-12

고객센터는 비용 부서인가, 신규 사업의 원천인가

고객센터는 비용 부서로만 볼 곳이 아니라 신규 서비스와 사업을 발굴하는 원천이 될 수 있습니다. 매일 들어오는 고객 문의에는 미충족 수요의 단서가 이미 담겨 있고, STT와 LLM 위키로 상담 기록을 자산화하면 이 단서를 체계적으로 캐낼 수 있습니다. 남은 관문은 개인정보 마스킹이며, 이를 풀면 CS는 비용 부서에서 사업 발굴 엔진으로 바뀝니다.

더 읽기 →
2026-06-11

AI가 코드를 짜 주는 시대, 프론트엔드 지식은 왜 여전히 필요한가

프론트엔드 지식은 AI에게 시킬 수 있는 일의 수준을 결정하는 지도입니다. React, npm, 빌드, SSR 같은 단어는 암기 대상이 아니라 문제 해결의 연쇄이며, 각 기술이 어떤 문제를 풀려고 태어났는지 알면 지시의 언어가 달라지고 같은 AI를 써도 결과물이 갈립니다. 바이브 코딩 교육에서 도구 사용법보다 기술의 진화 과정을 먼저 다뤄야 하는 이유입니다.

더 읽기 →
2026-06-11

백엔드란 무엇인가: 1993년 방명록에서 시작된 문제 해결의 계보

백엔드는 서버가 요청을 받아 데이터를 처리하고 결과를 돌려주는 영역으로, 1993년 방명록 문제를 풀다가 태어났습니다. 미리 만들어 둔 HTML 파일로는 방금 방문자가 남긴 글을 다음 사람에게 보여 줄 수 없어서, 서버가 요청이 올 때마다 그 자리에서 화면을 새로 조립하기 시작한 것이 출발점입니다. 이후 30년의 발전사도 같은 패턴의 반복입니다. 문제가 생기면 그것을 푸는 기술이 등장했고, 이 계보를 알면 비개발자도 AI에게 백엔드를 구체적으로 지시할 수 있게 됩니다.

더 읽기 →
2026-06-11

바이브 코딩에서 AI는 왜 자꾸 슈퍼베이스를 권하는가

AI가 바이브 코딩 중에 슈퍼베이스(Supabase)를 자주 권하는 이유는, 원래 별개로 발전해 온 데이터베이스와 스토리지라는 두 기술의 흐름이 이 플랫폼 하나로 합류했기 때문입니다. 슈퍼베이스는 파이어베이스의 편리함에 제대로 된 PostgreSQL을 얹고 인증과 스토리지까지 묶은 오픈소스 플랫폼이라, 따로 세팅하고 따로 연결하던 것들이 처음부터 연결된 채로 나옵니다. 이 계보를 알면 AI에게 내리는 지시의 수준이 달라집니다.

더 읽기 →
2026-06-11

배포란 무엇인가 — localhost는 왜 친구 컴퓨터에서 열리지 않는가

배포란 내 컴퓨터에만 있는 코드를 서버 컴퓨터에 올려 인터넷에 있는 누구나 쓸 수 있게 만드는 과정입니다. 바이브 코딩으로 만든 결과물이 localhost:3000에서만 도는 이유, FTP에서 Git·Docker·CI/CD로 이어진 배포의 진화, Vercel 같은 플랫폼이 대신해 주는 일과 그 대가를 정리했습니다. 이 지도가 머리에 있으면 AI에게 던지는 질문이 달라지고, 그 구체성이 비개발자 바이브 코딩의 실력을 가릅니다.

더 읽기 →
2026-06-11

AI는 왜 규칙이 아니라 확률을 내놓는가

지금의 AI는 사람이 작성한 규칙을 실행하는 기계가 아니라, 데이터에서 스스로 찾아낸 패턴으로 "스팸일 확률 93%" 같은 확률을 출력하는 기계입니다. 계좌 이체처럼 조건이 명확한 문제는 규칙 기반 코드가 완벽하게 풀지만, 이미지 인식처럼 예외가 많고 경계가 흐릿한 문제에서는 규칙이 무너지기 때문입니다. 머신러닝과 딥러닝은 규칙 기반 시스템의 이 실패에서 나왔고, 이 구분은 AX 컨설팅에서 업무를 분해하는 첫 번째 기준이 됩니다.

더 읽기 →
2026-06-11

ChatGPT는 왜 대화를 기억하지 못하는가

ChatGPT를 비롯한 LLM은 대화를 기억하지 않습니다. 매 턴마다 이전 대화 전체를 다시 전송하면 모델은 그 뭉치를 처음 만난 텍스트처럼 읽고 다음 토큰을 예측할 뿐입니다. 대화가 길어질수록 컨텍스트 윈도우가 차오르고 비용이 불어나는 이유가 여기에 있습니다. 토크나이저의 한국어 비효율부터 환각, temperature, 시스템 프롬프트까지 모두 코드 몇 줄이면 화면에서 직접 확인할 수 있습니다.

더 읽기 →
2026-06-11

AI 오케스트레이션이란 무엇인가: RAG 챗봇이 멈추는 지점에서 시작하는 설계

AI 오케스트레이션은 질문을 받고 검색해 답하는 일직선 파이프라인 대신, 막히면 되돌아가는 루프와 상황에 따라 길을 바꾸는 분기를 설계해 AI가 복잡한 실제 업무를 처리하게 만드는 제어 흐름 설계입니다. 랭체인이 표준 부품을, 랭그래프가 제어 흐름을, 랭스미스가 가시성을 맡고, 셋이 모여야 하나의 시스템이 됩니다. 다만 API 한 번이면 끝날 일에는 낭비이고, 루프와 분기가 필요할 만큼 일이 복잡할 때 꺼내는 도구입니다.

더 읽기 →
2026-06-10

하네스 엔지니어링이란 무엇인가

하네스 엔지니어링(Harness Engineering)은 AI 모델 자체를 바꾸는 대신, 모델에 어떤 도구를 쥐여주고 어떤 규칙과 워크플로 안에서 움직이게 할지를 설계해 결과물의 품질을 끌어올리는 작업입니다. 같은 모델이라도 하네스 설계에 따라 성능이 크게 달라지기 때문에, 더 비싼 모델로 갈아타기 전에 먼저 점검해야 할 레이어입니다.

더 읽기 →
2026-06-10

AI 네이티브와 AI 어시스티드의 차이 — 우리 회사는 어느 쪽인가

AI 네이티브(AI Native)는 사람의 개입이 거의 없이 워크플로 전체가 AI로 완결되는 구조이고, AI 어시스티드(AI Assisted)는 사람이 하던 일은 그대로 둔 채 AI가 옆에서 일부를 거들어주는 구조입니다. 대부분 기업의 "AI 네이티브 선언"은 실제로는 AI 어시스티드에 머물러 있으며, 이 차이를 구분하지 못하면 AI 도입 후에도 생산성이 제자리에 머뭅니다.

더 읽기 →
2026-06-10

AX 프로젝트는 왜 실패하는가 — 팀을 돕지 말고 업무를 없애라

AX(AI Transformation) 프로젝트가 실패하는 가장 흔한 패턴은 AX 팀이 부서를 돌며 요건을 받아 도구를 만들어 주는 방식입니다. 만들어 줘도 현업이 쓰지 않기 때문입니다. 성공하는 AX의 출발점은 "저 팀을 도와주세요"가 아니라 "저 팀의 단위 업무를 통째로 없애세요"이며, 사람은 자르는 것이 아니라 새 직무로 전환하는 것입니다.

더 읽기 →
2026-06-10

생성형 UI와 MCP 앱 — 에이전트 시대의 인터페이스는 어디로 가는가

에이전트 UI는 정적(미리 만든 컴포넌트에 데이터만 채움), 선언적(에이전트가 JSON 기술서를 쓰면 렌더링 엔진이 디자인 시스템에 매핑), 생성형(모델이 런타임에 HTML·CSS를 즉석 생성)의 세 단계로 진화하고 있습니다. 현재의 균형점은 선언적 방식이며, 생성형으로 가는 관건은 모델의 능력이 아니라 신뢰 — 즉 샌드박스라는 안전한 유통 구조입니다. MCP 앱이 그 배포 채널로 주목받고 있습니다.

더 읽기 →
2026-06-10

K Public Data MCP란 무엇인가 — 대한민국 공공데이터를 AI에 연결하는 서버

K Public Data MCP는 법제처 국가법령정보센터, DART 전자공시시스템, 공공데이터포털 등 흩어져 있는 대한민국 공공데이터 API를 MCP(Model Context Protocol) 서버 하나로 통합해, AI 채팅창에서 "민법 검색해줘", "삼성전자 재무제표 보여줘", "강남구 약국 찾아줘"가 바로 작동하게 만드는 오픈소스 도구입니다. 커넥터 URL 등록만으로 사용할 수 있어 API 키 발급이나 설치가 필요 없습니다.

더 읽기 →