이 글은 혼란스러운 부분이 있음. Weakly가 마치 2025년 기준 antirez가 좋아한다고 밝힌 방식처럼, 조금 더 수동적이고, 조언 위주로만 작동하는 코딩 에이전트를 말하는 듯하지만 실제로는 운영 이슈를 조사하고 해결하는 역할의 에이전트를 다루고 있음. Weakly의 주장은 에이전트가 Clippy처럼 조언만 하고 사람한테 운전대를 주라고 하는 것임. 그런데 굳이 사람이 로그를 뒤져가며 이상치를 찾고 가설을 세우는 데서 어떤 가치가 있는지 모르겠음. 컴퓨터가 체스를 더 잘 두는 이유와 마찬가지로, AI가 이런 일은 원천적으로 사람보다 잘하는 툴임. Weakly가 조언과 실제 행동 사이에 선을 확실히 긋는 거 같은데, 나는 그 선이 옳다고 생각하지 않음. 물론 AI에게 자율 실행을 전적으로 맡길 수 없는 영역도 있지만(예: Terraform apply 실행), 반대로 굳이 막을 이유가 없는 영역도 많음. 인시던트 해결의 목적은 결국 사고를 해결하는 것임
아직 아무도 만족스럽게 인시던트를 해결해주는 AI 툴은 없음. 책임 문제도 있고, 올바른 실행을 보장하기 위해서라도 사람의 개입이 꼭 필요함
본질적인 문제는 실제 운영 환경에 AI의 접근권한을 줄 것이냐에 있음. 최근 AI가 “하지 말라”는 명령에도 데이터베이스를 삭제한 사례를 보면(‘not’ 같은 부정 명령을 AI가 항상 제대로 인식하지 못하기 때문), 실제 안전상 큰 우려가 있는 상황임
어디까지 에이전트에게 자율권을 줄 수 있을지가 궁금함. DevOps 모범사례라면 대부분의 변경사항은 코드 커밋이나 여러 환경에 프로모션을 거친 후에야 프로덕션에 반영되는 구조일 것임. 애플리케이션 코드뿐 아니라 인프라 자체도 포함임. 이런 상황에서 인시던트 대응 작업 중 에이전트에게 자율 실행을 허용할 만한 부분이 어디까지인지 궁금함
직접 디버깅을 해보는 것도 일정 부분 가치는 있다고 생각함. 특히나 목표가 프로그래밍 실력 자체를 끌어올리는 데 있다면 더더욱 그렇다고 느낌. 체스를 예로 들면, Leela나 Stockfish처럼 AI가 훨씬 빠르고 깊게 분석할 수 있지만, 진짜 실력 향상은 직접 포지션을 분석해보는 경험에서 나온다고 생각함. 체스 프로 선수들도 반복적으로 전술 연습을 하며 늘 브레인을 단련함. AI와 사람이 함께하면 더 빨리 배울지 독립적으로 배울지, 나도 답을 잘 모르겠음. 그리고 이런 능력 자체가 앞으로 의미있는지에 대해서도 생각이 엇갈림
이상 감지, 인시던트 관리 관련 논의에서 중요한 부분 중 하나는 모든 문제가 동일하지 않으며, 많은 문제는 어느 정도 자동화가 가능하다는 점임. 언제 어떤 문제를 AI 같은 인지 프로세서에 넘길지, 언제 사람 엔지니어가 직접 개입해야 하는지 경계가 중요함. AI가 대규모 패턴 탐지는 잘하지만, 의미 있는 패턴인지까지 계속 잘 맞히는 것은 아님. 물론, 이런 빈틈을 사람이 항상 메울 수 있는 것도 아님
AI 툴/제품의 관점에서 앞으로는 "지능형 워크스페이스(Intelligent Workspaces)"로 가야 한다고 봄. 단순 챗봇에서 벗어나야 함 관련 링크
기본적으로, 모든 설정, 레버, 제어권을 인간에게 주면서 AI 기능이 긴밀하게 통합된 환경/플랫폼이 중요함. 이건 단순 VSCode 포크 그 이상으로 어려운 일임
챗봇이 지능형 워크스페이스보다 구현이 훨씬 쉬움. 그리고 AI는 인간 인터랙션 없이도 잘 동작함. 나는 채팅이 아닌 다른 인터페이스로 AI를 활용하는 방법이 더 다양해졌으면 함
최근 Claude Code로 프로젝트를 하고 있는데, 내 인스턴스가 다른 개발자의 인스턴스와 대화하며 협업할 수 있으면 좋겠음. CLAUDE.md를 수정해 문서를 유지할 수는 있지만, CC 자체에 팀 협업 기능이 내장되어 있으면 정말 좋을 것 같음. 좋은 제안 있으면 공유 바람
이 글은 혁신이 왜 종종 외부자에게서 나오는지 잘 보여준다고 생각함. 필자가 대형 조직의 엔지니어링 관리자나 수석 엔지니어 경력이 강하게 묻어있어서, 내 경험과는 크게 공감되지 않음. 만약 이런 스타일이 AI 툴링의 정석으로 굳어진다면, 인간 워크플로에 대한 특정 추정에 기반해 AI가 정체되는 현상이 나타날 거라 우려함. 나는 15년 동안 (비프로그래머) 도메인 전문가 보조 ML 애플리케이션 R&D를 해왔는데, 필자의 원칙과는 다소 다릅니다. 시야가 이렇게 다르다는 건 디자인 공간이 매우 크며, 특정 방식이 정답이라는 결론을 내리기엔 너무 이르다고 봄. 앞으로 AI 툴링이 어디로 갈지 아직 아무도 모름
물론 한 가지 해석은 내가 만든 ML 시스템이 지난 15년간 사람의 역량을 평준화하거나 대체해왔다는 얘기도 가능함. 하지만 각자 처한 위치에 따라 해석이 다르다는 데는 동의함. 다만, 인간(그리고 인간의 지식/검색능력)이 워크플로의 중심에 최대한 있도록 하는 것이 좋은 관행이라는 생각임
AI 코딩에서 항상 걱정하는 부분은 실력 유지가 어려워지는 현상임. 직접 코드(보일러플레이트 포함)를 타이핑하는 과정이 꼭 Mr. Miyagi의 페인트칠 같은 훈련임. 이런 반복적 훈련 덕분에 머릿속에 패턴이 깊게 남아, 더 높은 수준의 설계 결정을 내릴 때 큰 힘이 됨
과거 기술(글쓰기, 인쇄 등)도 어쩌면 필체나 수사력을 저하시켰을 텐데, 오히려 생각하는 능력은 증폭시켰음. “Bicycle-for-the-mind” 같은 Steve Jobs의 아이디어가 대표적임. 다만, 이런 논리를 AI에 적용할 땐, 예전 기술은 유통의 병목을 풀었지만 AI는 창의 프로세스 그 자체를 직접 겨냥한다는 점이 다름. 창의적 작업에서 AI 활용은 오롯이 내 창의력 자체의 발달을 방해하지 않는 한에서만 바람직하다고 생각함. 인간의 자기 통제력/자각에는 한계가 있음
나는 밤이나 샤워할 때 종종 문제를 머릿속으로 곱씹으며 "코드"를 떠올림. 언어 구조가 머릿속에 깊게 박혀 있지 않았다면 이런 상상 코딩도 힘들었을 것임
일상에서도 비슷한 예를 찾을 수 있음:
언제 손글씨로 의미 있는 글을 써봤는지 기억도 안 남. 내 손글씨는 이제 정말 엉망임
내비게이션 없으면 운전길을 찾을 엄두를 못 냄. 지도 읽기? 이제는 꿈같은 얘기임
트랜지스터를 수작업으로 납땜하던 시절도 있었음. 하지만 이제는 기술이 워낙 발전해서 과거처럼 직접 하려면 부담이 큼. 이렇게 계속 사고의 초점을 확장했다 축소했다 하면서, 나는 아직도 코딩이 그립기도 함. 여전히 코딩을 많이 하긴 함
“Every augmentation is an amputation(모든 증강은 어떤 부분의 절단)” - Marshall McLuhan
나는 그래서 딥 리서치(Deep Research)를 정말 좋아함. 항상 질문부터 던지고, 내가 배우고 싶은 걸 스스로 더 명확히 정의하게 끔 만듦. 단순한 UX 변화가 서비스 사용자의 학습에도, 반대로 비판적 사고 없이 도구에 의존하게 하는 결과에도 큰 차이를 만든다고 느낌
그런데 그 질문 자체를 정말 유심히 본 적 있는지? 딥 리서치가 요긴할 때도 있지만, 때로는 그 “질문”이 그저 있어 보이려고 추가된 것처럼 느껴짐. 이미 내가 신경 써서 명확히 써둔 부분까지 꼭 굳이 다시 묻는 경우가 많음. 실제 검색 과정엔 큰 도움 안 되는 것 같음
나는 테크니컬 라이터로서 Deep Research를 쓰지 않는 편임. 오히려 내 업무에 방해가 됨. 연구, 메모, 요약 과정 자체가 내가 주제를 깊이 이해하도록 도와주는 핵심임. 기록물 자체는 그 결과물일 뿐임. AI가 그 일을 대신해주면 메모를 얻게는 하지만, 그만큼의 이해를 얻지 못함. AI가 써준 문서 읽는 것으로 직접 경험을 대체할 수 없음
이 글은 AI 도입의 핵심을 혼동한다는 생각임. AI 도입의 목적은 사람을 더 똑똑하게 만들기 위해서가 아니라, 인간 창의력이 의미 있게 보상받지 않는 반복 업무를 없애서 전체 프로세스의 생산성을 올리는 데 있음
내 경험상, 코딩할 때 AI를 가장 잘 활용하는 방법은 다음과 같음:
고급 find/replace처럼, 구조체 초기화 같은 부분을 한꺼번에 "이거 다 Y로 바꿔줘"라고 지시할 때. (regex는 너무 빡셈)
에이전트 작업 프로세스에서는, 사람처럼 대하지 말고 더 높은 수준의 조각 작업을 단계별로 지시하는 게 효과적임. “기능 구현해줘” 보다 “새 파일 만들고 스텁 함수 정의” → “첫 번째 함수부터 x 동작 넣기” → “두 번째 함수는 첫번째 함수 먼저 호출 후 Y 하기”처럼 쪼개서 지시
익숙하지 않은 코드베이스에서 정보 찾거나, 특정 구현법 묻기. “copilot, 앱 라우트 다 어디에 정의돼 있어?”처럼, 예전에는 IRC 고수에게 번번이 물었을 일들을 빠르게 확인할 수 있어서 매우 편리함
최근 아버지께서 발표 자료 준비 도와드림. 아버지는 정보는 충분히 갖고 계시지만, 비디자이너라서 슬라이드를 예쁘게 꾸미는 데 어려움이 있었음. 여러 AI 슬라이드 생성 앱을 써봤는데, 멋있어 보여도 실제로 사용자가 바라는 "디자인 개선"에는 도움이 안 됐음. 결국 수작업으로 더 예쁘게 꾸미는 게 훨씬 낫다는 결론임
특히 “아키텍처와 테스트 설계부터 시작해서 실제 코드에 적용한다”는 흐름이 100% 더 효과적이었다는 데 전적으로 동감함. 워크플로 습관만 바꾸면 별도 툴이 없어도 가능함(물론, 전용 툴이나 표준 프롬프트가 있으면 더 좋음)
나도 이게 꼭 필요해서 직접 아키텍처 툴을 만들기 시작함. 건설적인 아키텍처만 있으면 구현은 현재 AI에게 넘기는 것도 충분히 가능함. 단, 이 도구들이 docker-compose 같은 장기 실행 프로세스 로그를 읽는 데 아직 약함. 그리고 실제 수행해야 할 일은 다음과 같음:
문제 조사
기능 설명
API 계약 정의
기본 구현 계획 작성
인증/권한 설정
테스트 전략과 효율적 테스트 셋업/해제 마련
라이브러리 문서화 및 AI를 위한 공식 문서 검색
그리고 AI가 import 등에서 자주 실수함, 장시간 동작하는 프로세스도 취약점
여기서 “vibe”라는 말 안 써도 똑같은 문장이 될 정도로 본질적인 얘기임
인간은 누적적 반복(지속적 개선)에 정말 특화된 종임. 그래서 브레인스토밍이 그룹에서 특히 효과적인 거임. 인지 심리학에는 이런 집단적 학습과 혁신의 누적적 “문화” 이론이 있을 정도임. 우리가 흔히 “거인의 어깨 위에서”라는 말을 쓰는데, 단순히 멋진 말이 아니라 실제로 인간의 작동 원리임. 창의성은 결국 검색, 그것도 사회적 검색임. 뇌의 내부가 아니라 뇌와 환경의 상호작용, 사회/문화적 층위에서 발전해감. 그래서 나는 LLM이 진짜 “이해”하는지를 고민하지 않음. 그저 검색하고, 아이디어를 만들어내고, 실제로 검증한다면 그걸로 충분함. 또한, 기반(Substrate)이 무엇이든 검색 자체가 더 중요하다고 생각함. 다만, 기반에 따라 접근할 수 있는 검색 공간은 달라질 수 있음
Hacker News 의견
이 글은 혼란스러운 부분이 있음. Weakly가 마치 2025년 기준 antirez가 좋아한다고 밝힌 방식처럼, 조금 더 수동적이고, 조언 위주로만 작동하는 코딩 에이전트를 말하는 듯하지만 실제로는 운영 이슈를 조사하고 해결하는 역할의 에이전트를 다루고 있음. Weakly의 주장은 에이전트가 Clippy처럼 조언만 하고 사람한테 운전대를 주라고 하는 것임. 그런데 굳이 사람이 로그를 뒤져가며 이상치를 찾고 가설을 세우는 데서 어떤 가치가 있는지 모르겠음. 컴퓨터가 체스를 더 잘 두는 이유와 마찬가지로, AI가 이런 일은 원천적으로 사람보다 잘하는 툴임. Weakly가 조언과 실제 행동 사이에 선을 확실히 긋는 거 같은데, 나는 그 선이 옳다고 생각하지 않음. 물론 AI에게 자율 실행을 전적으로 맡길 수 없는 영역도 있지만(예: Terraform apply 실행), 반대로 굳이 막을 이유가 없는 영역도 많음. 인시던트 해결의 목적은 결국 사고를 해결하는 것임
아직 아무도 만족스럽게 인시던트를 해결해주는 AI 툴은 없음. 책임 문제도 있고, 올바른 실행을 보장하기 위해서라도 사람의 개입이 꼭 필요함
본질적인 문제는 실제 운영 환경에 AI의 접근권한을 줄 것이냐에 있음. 최근 AI가 “하지 말라”는 명령에도 데이터베이스를 삭제한 사례를 보면(‘not’ 같은 부정 명령을 AI가 항상 제대로 인식하지 못하기 때문), 실제 안전상 큰 우려가 있는 상황임
어디까지 에이전트에게 자율권을 줄 수 있을지가 궁금함. DevOps 모범사례라면 대부분의 변경사항은 코드 커밋이나 여러 환경에 프로모션을 거친 후에야 프로덕션에 반영되는 구조일 것임. 애플리케이션 코드뿐 아니라 인프라 자체도 포함임. 이런 상황에서 인시던트 대응 작업 중 에이전트에게 자율 실행을 허용할 만한 부분이 어디까지인지 궁금함
직접 디버깅을 해보는 것도 일정 부분 가치는 있다고 생각함. 특히나 목표가 프로그래밍 실력 자체를 끌어올리는 데 있다면 더더욱 그렇다고 느낌. 체스를 예로 들면, Leela나 Stockfish처럼 AI가 훨씬 빠르고 깊게 분석할 수 있지만, 진짜 실력 향상은 직접 포지션을 분석해보는 경험에서 나온다고 생각함. 체스 프로 선수들도 반복적으로 전술 연습을 하며 늘 브레인을 단련함. AI와 사람이 함께하면 더 빨리 배울지 독립적으로 배울지, 나도 답을 잘 모르겠음. 그리고 이런 능력 자체가 앞으로 의미있는지에 대해서도 생각이 엇갈림
이상 감지, 인시던트 관리 관련 논의에서 중요한 부분 중 하나는 모든 문제가 동일하지 않으며, 많은 문제는 어느 정도 자동화가 가능하다는 점임. 언제 어떤 문제를 AI 같은 인지 프로세서에 넘길지, 언제 사람 엔지니어가 직접 개입해야 하는지 경계가 중요함. AI가 대규모 패턴 탐지는 잘하지만, 의미 있는 패턴인지까지 계속 잘 맞히는 것은 아님. 물론, 이런 빈틈을 사람이 항상 메울 수 있는 것도 아님
AI 툴/제품의 관점에서 앞으로는 "지능형 워크스페이스(Intelligent Workspaces)"로 가야 한다고 봄. 단순 챗봇에서 벗어나야 함
관련 링크
기본적으로, 모든 설정, 레버, 제어권을 인간에게 주면서 AI 기능이 긴밀하게 통합된 환경/플랫폼이 중요함. 이건 단순 VSCode 포크 그 이상으로 어려운 일임
챗봇이 지능형 워크스페이스보다 구현이 훨씬 쉬움. 그리고 AI는 인간 인터랙션 없이도 잘 동작함. 나는 채팅이 아닌 다른 인터페이스로 AI를 활용하는 방법이 더 다양해졌으면 함
최근 Claude Code로 프로젝트를 하고 있는데, 내 인스턴스가 다른 개발자의 인스턴스와 대화하며 협업할 수 있으면 좋겠음. CLAUDE.md를 수정해 문서를 유지할 수는 있지만, CC 자체에 팀 협업 기능이 내장되어 있으면 정말 좋을 것 같음. 좋은 제안 있으면 공유 바람
이 글은 혁신이 왜 종종 외부자에게서 나오는지 잘 보여준다고 생각함. 필자가 대형 조직의 엔지니어링 관리자나 수석 엔지니어 경력이 강하게 묻어있어서, 내 경험과는 크게 공감되지 않음. 만약 이런 스타일이 AI 툴링의 정석으로 굳어진다면, 인간 워크플로에 대한 특정 추정에 기반해 AI가 정체되는 현상이 나타날 거라 우려함. 나는 15년 동안 (비프로그래머) 도메인 전문가 보조 ML 애플리케이션 R&D를 해왔는데, 필자의 원칙과는 다소 다릅니다. 시야가 이렇게 다르다는 건 디자인 공간이 매우 크며, 특정 방식이 정답이라는 결론을 내리기엔 너무 이르다고 봄. 앞으로 AI 툴링이 어디로 갈지 아직 아무도 모름
AI 코딩에서 항상 걱정하는 부분은 실력 유지가 어려워지는 현상임. 직접 코드(보일러플레이트 포함)를 타이핑하는 과정이 꼭 Mr. Miyagi의 페인트칠 같은 훈련임. 이런 반복적 훈련 덕분에 머릿속에 패턴이 깊게 남아, 더 높은 수준의 설계 결정을 내릴 때 큰 힘이 됨
과거 기술(글쓰기, 인쇄 등)도 어쩌면 필체나 수사력을 저하시켰을 텐데, 오히려 생각하는 능력은 증폭시켰음. “Bicycle-for-the-mind” 같은 Steve Jobs의 아이디어가 대표적임. 다만, 이런 논리를 AI에 적용할 땐, 예전 기술은 유통의 병목을 풀었지만 AI는 창의 프로세스 그 자체를 직접 겨냥한다는 점이 다름. 창의적 작업에서 AI 활용은 오롯이 내 창의력 자체의 발달을 방해하지 않는 한에서만 바람직하다고 생각함. 인간의 자기 통제력/자각에는 한계가 있음
나는 밤이나 샤워할 때 종종 문제를 머릿속으로 곱씹으며 "코드"를 떠올림. 언어 구조가 머릿속에 깊게 박혀 있지 않았다면 이런 상상 코딩도 힘들었을 것임
일상에서도 비슷한 예를 찾을 수 있음:
트랜지스터를 수작업으로 납땜하던 시절도 있었음. 하지만 이제는 기술이 워낙 발전해서 과거처럼 직접 하려면 부담이 큼. 이렇게 계속 사고의 초점을 확장했다 축소했다 하면서, 나는 아직도 코딩이 그립기도 함. 여전히 코딩을 많이 하긴 함
“Every augmentation is an amputation(모든 증강은 어떤 부분의 절단)” - Marshall McLuhan
나는 그래서 딥 리서치(Deep Research)를 정말 좋아함. 항상 질문부터 던지고, 내가 배우고 싶은 걸 스스로 더 명확히 정의하게 끔 만듦. 단순한 UX 변화가 서비스 사용자의 학습에도, 반대로 비판적 사고 없이 도구에 의존하게 하는 결과에도 큰 차이를 만든다고 느낌
그런데 그 질문 자체를 정말 유심히 본 적 있는지? 딥 리서치가 요긴할 때도 있지만, 때로는 그 “질문”이 그저 있어 보이려고 추가된 것처럼 느껴짐. 이미 내가 신경 써서 명확히 써둔 부분까지 꼭 굳이 다시 묻는 경우가 많음. 실제 검색 과정엔 큰 도움 안 되는 것 같음
나는 테크니컬 라이터로서 Deep Research를 쓰지 않는 편임. 오히려 내 업무에 방해가 됨. 연구, 메모, 요약 과정 자체가 내가 주제를 깊이 이해하도록 도와주는 핵심임. 기록물 자체는 그 결과물일 뿐임. AI가 그 일을 대신해주면 메모를 얻게는 하지만, 그만큼의 이해를 얻지 못함. AI가 써준 문서 읽는 것으로 직접 경험을 대체할 수 없음
이 글은 AI 도입의 핵심을 혼동한다는 생각임. AI 도입의 목적은 사람을 더 똑똑하게 만들기 위해서가 아니라, 인간 창의력이 의미 있게 보상받지 않는 반복 업무를 없애서 전체 프로세스의 생산성을 올리는 데 있음
내 경험상, 코딩할 때 AI를 가장 잘 활용하는 방법은 다음과 같음:
최근 아버지께서 발표 자료 준비 도와드림. 아버지는 정보는 충분히 갖고 계시지만, 비디자이너라서 슬라이드를 예쁘게 꾸미는 데 어려움이 있었음. 여러 AI 슬라이드 생성 앱을 써봤는데, 멋있어 보여도 실제로 사용자가 바라는 "디자인 개선"에는 도움이 안 됐음. 결국 수작업으로 더 예쁘게 꾸미는 게 훨씬 낫다는 결론임
특히 “아키텍처와 테스트 설계부터 시작해서 실제 코드에 적용한다”는 흐름이 100% 더 효과적이었다는 데 전적으로 동감함. 워크플로 습관만 바꾸면 별도 툴이 없어도 가능함(물론, 전용 툴이나 표준 프롬프트가 있으면 더 좋음)
인간은 누적적 반복(지속적 개선)에 정말 특화된 종임. 그래서 브레인스토밍이 그룹에서 특히 효과적인 거임. 인지 심리학에는 이런 집단적 학습과 혁신의 누적적 “문화” 이론이 있을 정도임. 우리가 흔히 “거인의 어깨 위에서”라는 말을 쓰는데, 단순히 멋진 말이 아니라 실제로 인간의 작동 원리임. 창의성은 결국 검색, 그것도 사회적 검색임. 뇌의 내부가 아니라 뇌와 환경의 상호작용, 사회/문화적 층위에서 발전해감. 그래서 나는 LLM이 진짜 “이해”하는지를 고민하지 않음. 그저 검색하고, 아이디어를 만들어내고, 실제로 검증한다면 그걸로 충분함. 또한, 기반(Substrate)이 무엇이든 검색 자체가 더 중요하다고 생각함. 다만, 기반에 따라 접근할 수 있는 검색 공간은 달라질 수 있음