이 글은 AI의 발전으로 누구나 소프트웨어를 쉽게 ‘만드는 것’처럼 보이지만, 실제 **‘제품을 구축하는 것’**과 ‘시스템을 엔지니어링하는 것’ 사이에는 거대한 간극이 존재함을 지적합니다. 원문/참고 링크: https://uphack.io/blog/post/the-illusion-of-building 1. 진흙으로 만든 부가티 (The Clay Bugatti) 최근 “코딩 경험 없이 앱을 만들었다”, “주말 만에 스포티파이를 복제했다"는 식의 글들이 넘쳐납니다. 하지만 이는 베트남의 유튜버들이 진흙으로 부가티 모양을 빚어낸 것과 비슷합니다. 겉모습은 똑같지만, 시속 400km로 달려도 안전하게 설계된 실제 부가기의 ‘엔지니어링’은 전혀 들어있지 않습니다. 개발의 환상이란, 작동하는 것처럼 보이는 소프트웨어를 만드는 것이 실제로 작동하는 소프트웨어를 엔지니어링하는 것과 같다고 믿는 착각입니다. ...
오픈 소스 대규모 언어 모델(LLM)들의 아키텍처 구조와 각 모델이 선택한 공학적 전략을 분석합니다. 출처: https://blog.bytebytego.com/p/the-architecture-behind-open-source 이 글은 주요 오픈 소스 대규모 언어 모델(LLM)들의 아키텍처 구조와 각 모델이 선택한 공학적 전략을 다루고 있습니다. 주요 내용은 다음과 같습니다. 1. 핵심 아키텍처: Transformer 대부분의 오픈 소스 LLM은 Transformer 아키텍처를 기반으로 합니다. 하지만 효율성을 높이기 위해 오리지널 구조에서 몇 가지 변형을 가합니다. Decoder-only 구조: GPT 시리즈와 마찬가지로 대부분의 오픈 소스 모델(Llama, Mistral 등)은 다음 단어를 예측하는 데 최적화된 디코더 전용 구조를 채택합니다. 2. 주요 최적화 기술 성능과 효율성을 잡기 위해 사용되는 대표적인 기술들입니다. ...
출처: https://every.to/guides/compound-engineering Every의 가이드 “Compound Engineering” 은 AI 에이전트를 활용한 새로운 소프트웨어 개발 패러다임을 설명하고 있습니다. 핵심은 “전통적인 개발은 코드가 쌓일수록 복잡해져 속도가 느려지지만, 컴파운드 엔지니어링은 할수록 다음 작업이 더 쉬워지고 빨라진다” 는 것입니다. 1. 핵심 철학 (The Philosophy) 복리 효과(Compounding): 모든 단위 작업(코드, 문서, 툴링)이 다음 작업을 더 쉽게 만들어야 합니다. 시스템에 ‘취향’ 반영: 코드 리뷰 시 매번 수동으로 수정하는 대신, 설정·스키마·자동 검사 도구에 판단 기준을 녹여내어 시스템 자체가 학습하게 합니다. 직접 하기보다 가르치기: 코드를 직접 타이핑하는 시간보다 AI 에이전트에게 더 많은 컨텍스트를 제공하는 데 시간을 투자합니다. 2. 4단계 루프 (The Loop) 컴파운드 엔지니어링은 다음의 반복적인 과정을 통해 완성됩니다. ...
출처: https://addyosmani.com/blog/bias-towards-action/ 이 글에서 저자는 “행동 지향성"이 단순히 무모하게 빨리 움직이는 것이 아니라, 학습 속도를 높이되 실패해도 치명적이지 않은 시스템을 구축하는 것 이라고 강조합니다. 1. 핵심 개념: “실행 가능한 최소한의 단계” 정의: 행동 지향성이란 실제 피드백을 얻을 수 있는 가장 작고 책임감 있는 단계 를 기본값으로 설정하는 것입니다. 오해: 단순히 스타트업 창업자가 소리치는 무모한 구호가 아닙니다. 제대로 된 행동 지향성은 “내가 틀렸을 때 어떻게 회복할지"를 정확히 아는 상태에서 움직이는 것입니다. 2. 가드레일(안전장치)의 중요성 빠르게 움직이는 팀은 단순히 속도가 빠른 것이 아니라, 실패해도 죽지 않는 시스템을 갖추고 있습니다. ...
출처: https://cra.mr/context-management-and-mcp/ 이 글은 Sentry의 창립자인 David Cramer가 작성한 것으로, 최근 개발자들 사이에서 벌어지는 “MCP(Model Context Protocol)냐 CLI(명령줄 인터페이스)냐” 의 논쟁이 본질을 벗어난 것임을 지적하며 ‘컨텍스트 관리와 조종(Steering)’ 의 중요성을 강조하고 있습니다. 1. MCP vs CLI 논쟁의 핵심 잘못된 비교: 많은 사람들이 CLI가 나왔으니 MCP를 쓸 필요가 없다고 말하지만, 이는 LLM이 컨텍스트를 어떻게 처리하는지 이해하지 못한 결과입니다. MCP의 진정한 가치: MCP는 단순한 API 프록시가 아니라, LLM이 도구를 더 정확하게 사용하도록 ‘조종(Steering)’ 하는 데 최적화되어 있습니다. MCP는 마크다운, XML 구조, 힌트 등을 활용해 모델이 이해하기 쉬운 형태로 정보를 전달합니다. 2. 조종(Steering)의 중요성 LLM 맞춤형 응답: 일반적인 API나 CLI는 기계(Machine) 중심의 출력을 내놓지만, 우수한 MCP 서버(예: Sentry MCP)는 LLM이 다음 행동을 결정하기 좋게끔 요약된 정보와 가이드를 제공합니다. 토큰 효율성: “항상 켜져 있는 MCP 도구가 토큰을 낭비한다"는 비판도 있지만, 초기 조종 컨텍스트에 토큰을 투자하는 것이 나중에 모델이 길을 잃어 발생하는 ‘컨텍스트 부패(Context Rot)‘를 막는 데 더 효과적입니다. 3. 점진적 공개(Progressive Disclosure)의 한계 필요할 때만 도구 설명을 불러오는 방식은 모델로부터 ‘도구의 의도’를 숨기게 되어, 결국 모델의 추론 능력을 떨어뜨리고 API 호출기 수준으로 전락시킵니다. 4. 해결책: 서브에이전트(Subagents) 저자는 현재의 한계를 극복하기 위해 서브에이전트 방식 을 제안합니다. 특정 작업에만 필요한 MCP 도구와 컨텍스트를 격리된 서브에이전트에 할당함으로써, 컨텍스트 부패를 최소화하고 각 모델이 전문적인 작업을 수행하도록 만들 수 있습니다. 요약 결론 결국 중요한 것은 어떤 프로토콜을 쓰느냐가 아니라 “어떻게 하면 모델이 실수 없이 작업을 완수하도록 컨텍스트를 잘 설계하고 전달(Steering)하느냐” 입니다. 저자는 이를 위해 모델의 한계를 인정하고 서브에이전트와 같은 구조적 접근이 필요하다고 주장합니다.
출처: https://deadneurons.substack.com/p/chat-is-going-to-eat-the-world 1. 인터페이스의 혁명: 채팅이 모든 것을 삼킨다 과거 소프트웨어는 복잡한 메뉴와 버튼으로 구성된 GUI(그래픽 사용자 인터페이스) 중심이었습니다. 하지만 이제 ‘채팅’은 단순한 기능이 아니라, 사용자가 컴퓨터와 상호작용하는 기본 운영 체제(OS) 가 되고 있습니다. 마크 안드레센이 “소프트웨어가 세상을 먹어치운다"고 했듯, 이제는 “채팅이 소프트웨어를 먹어치우고” 있습니다. 2. ‘앱’의 종말과 ‘에이전트’의 시대 사용자는 더 이상 특정 목적을 위해 개별 앱을 찾아다니거나 복잡한 사용법을 익힐 필요가 없습니다. 대신 자연어로 요청하면 AI 에이전트가 뒤에서 필요한 도구와 데이터를 호출해 결과를 가져다줍니다. 이로 인해 기존의 수많은 개별 앱과 웹사이트의 경계가 무너지고, 모�어와 비즈니스는 도태될 것이라는 경고와 기대를 동시에 전달합니다. ...
출처: https://addyo.substack.com/p/the-80-problem-in-agentic-coding 1. 80% 문제란 무엇인가? 초기 성과(80%)의 함정 : AI 에이전트는 복잡한 코드 작성, 라이브러리 선택, 기본 구조 설계 등 작업의 80%를 순식간에 해냅니다. 하지만 이는 사용자에게 “거의 다 끝났다"는 착각을 줍니다. 나머지 20%의 난이도 : 실제 배포 가능한 수준으로 만드는 나머지 20%(엣지 케이스 처리, 기존 코드와의 완벽한 통합, 보안 및 성능 최적화 등)는 훨씬 더 어렵고 시간이 많이 걸립니다. 2. 왜 이런 문제가 발생하는가? 맥락 파악의 한계 : 에이전트가 전체 코드베이스의 비즈니스 로직이나 사소한 종속성을 완벽히 이해하지 못해 “그럴듯하지만 틀린” 코드를 생성할 때가 많습니다. 검증의 어려움 : AI가 짠 코드를 검토하는 것이 사람이 처음부터 짜는 것보다 더 많은 인지적 에너지를 소모할 수 있습니다. 루프의 부재 : 에이전트가 스스로 실행 결과를 확인하고 수정하는 과정(Agentic Workflow)이 아직 인간 개발자의 직관만큼 정교하지 않습니다. 3. 해결을 위한 제언 (어떻게 나아가야 하는가?) 인간과 AI의 협업 모델 : AI를 단순히 ‘코드 생성기’가 아닌, 인간의 의도를 끊임없이 확인하고 피드백을 받는 ‘파트너’ 로서 설계해야 합니다. 테스트 자동화의 중요성 : 80% 지점에서 멈추지 않으려면, 에이전트가 직접 단위 테스트를 작성하고 통과할 때까지 반복하는 능력이 필수적입니다. 작은 단위의 작업 분할 : 한 번에 큰 기능을 맡기기보다, 명확하게 정의된 작은 단위로 작업을 나누어 에이전트에게 맡길 때 성공률이 높아집니다. 요약하자면: 아디티아 아가왈(Aditya Agarwal)은 AI 코딩 에이전트가 ‘마법처럼 코드를 짜주는 도구’에서 ‘실제로 업무를 끝마칠 수 있는 도구’ 가 되기 위해서는, 단순히 생성 능력을 키우는 것이 아니라 추론, 검증, 그리고 인간 개발자와의 긴밀한 상호작용 이 핵심이 되어야 한다고 강조합니다.
AI(LLM)와 노코드 툴의 발전으로 코드 작성 비용이 0에 수렴하는 시대에, 소프트웨어 엔지니어링의 미래는 무엇일까? 출처: The future of software engineering is SRE - Swizec Teller 1. 핵심 요지: “코드가 저렴해질수록 운영 능력이 승리한다” AI(LLM)와 노코드 툴의 발전으로 코드를 작성하는 비용은 0에 수렴하고 있습니다. 누구나 작동하는 데모(Greenfield demo)는 만들 수 있는 시대가 되었지만, 그 서비스를 안정적으로 ‘운영’하는 것 은 여전히 어렵고 중요한 문제라는 것이 글의 핵심입니다. 2. 소프트웨어 엔지니어링의 정의: “시간 위의 프로그래밍” 저자는 프로그래밍과 소프트웨어 엔지니어링을 구분합니다. ...
OpenAI에서 발표한 “Unrolling the Codex Agent Loop” 는 AI 에이전트인 Codex가 사용자 요청을 처리하기 위해 내부적으로 어떻게 동작하는지(에이전트 루프)를 심층 분석한 기술 블로그 글입니다. 출처: Unrolling the Codex Agent Loop - OpenAI 1. 에이전트 루프 (The Agent Loop) AI 에이전트의 핵심은 모델 자체가 아니라, 모델과 도구를 연결하는 ‘루프(순환 구조)’ 에 있습니다. 프로세스: 사용자 입력 → 프롬프트 구성 → 모델 추론(Inference) → 도구 호출(Tool Call) → 실행 결과 반영 → 재추론 → 최종 응답. 특징: 하나의 질문(Turn)에 대해 모델은 단순히 답변만 하는 것이 아니라, 수십에서 수백 번의 도구 호출(파일 읽기, 셸 명령어 실행 등)을 반복하며 스스로 문제를 해결합니다. 2. 프롬프트 구성 방식 Codex는 사용자의 입력을 그대로 모델에 전달하지 않고, 복잡한 ‘프롬프트 스티칭(Stitching)’ 과정을 거칩니다. ...
AI 에이전트를 설계할 때 규칙(Rules), 기술(Skills), 명령(Commands) 을 어떻게 구분하고 사용할지가 핵심입니다. Builder.io 블로그 글을 바탕으로 세 개념의 정의, 사용 시점, 그리고 효과적인 기술 작성 방법을 정리했습니다. 원문: Agent skills, rules, and commands 1. 핵심 개념 정의 규칙 (Rules): 예외 없이 항상 적용되는 원칙입니다. (예: “절대 .env 파일을 커밋하지 마라”, “명명 규칙 준수”) 기술 (Skills): 특정 작업 시에만 불러오는 선택적 전문 지식입니다. 에이전트가 필요할 때만 ‘지연 로딩(Lazy loading)‘하여 컨텍스트 낭비를 줄입니다. (예: “UI 변경 시 체크리스트”, “배포 가이드”) 명령 (Commands): 사용자가 직접 실행하는 반복 가능한 워크플로우입니다. (예: /release, /refactor) 2. 기술(Skills)의 특징과 장점 점진적 공개(Progressive Disclosure): 에이전트가 처음부터 모든 내용을 읽지 않고, 메타데이터(설명)를 보고 필요할 때만 전체 내용을 로드합니다. 이는 모델의 컨텍스트 창을 아끼고 성능 저하를 방지합니다. 구성 요소: 기술은 지침이 담긴 SKILL.md 파일과 관련 스크립트, 템플릿, 참고 문서로 이루어진 폴더 형태입니다. 3. 언제 무엇을 사용해야 하는가? (결정 기준) 규칙: 내가 생각하고 있지 않을 때도 에이전트가 지켜야 하는가? (Yes → 규칙) 기술: 특정 상황이나 특정 파일 작업 시에만 필요한 전문 지식인가? (Yes → 기술) 명령: 내가 직접 제어권을 갖고 특정 동작을 시작하고 싶은가? (Yes → 명령) 4. 효과적인 ‘기술(Skill)’ 작성 팁 설명(Description) 최적화: 에이전트가 기술을 잘 찾아낼 수 있도록 키워드 중심의 구체적인 설명을 작성해야 합니다. 절차 중심: 기술 본문은 위키처럼 정보를 나열하기보다, 구체적인 작업 절차와 성공 기준(Success Criteria)을 명시하는 것이 좋습니다. 분리: 내용이 너무 길어지면 별도의 참조 파일로 분리하여 에이전트가 필요할 때만 읽게 합니다. 5. 요약 비교표 개념 실행 주체 용도 컨텍스트 비용 규칙 (Rules) 도구/시스템 저장소 기본 요구사항 항상 발생 명령 (Commands) 사용자 반복적인 워크플로우 사용 시 발생 기술 (Skills) 에이전트 작업별 전문 가이드 필요 시에만 발생 결론적으로, 모든 지침을 ‘규칙’에 쏟아붓는 대신, 상시 규칙은 최소화하고 작업에 필요한 전문 지식은 ‘기술’ 단위로 모듈화하여 관리하는 것이 최신 AI 에이전트 활용의 핵심 전략입니다.