2026년 6월 10일 수요일

루프 엔지니어링 - 에이전트를 프롬프트하는 시스템을 설계하기 - 링크 걸어둡니다.

 

21P by GN⁺ | ★ favorite | 댓글 4개
  • 코딩 에이전트에게 매 턴마다 직접 프롬프트하던 방식을 끝내고, 에이전트를 대신 프롬프트하는 시스템을 설계하는 작업 방식으로의 전환
  • 루프는 목적을 정의하면 AI가 완료될 때까지 반복하는 재귀적 목표이며, 약 다섯 개의 구성 요소로 이루어짐
  • 다섯 요소는 Automations, Worktrees, Skills, Plugins·connectors, Sub-agents이며, Claude Code와 Codex 양쪽 모두 현재 다섯 가지를 전부 보유
  • 여섯 번째 요소인 메모리는 단일 대화 밖에 상태를 저장하는 markdown 파일이나 Linear 보드로, 매 실행마다 잊는 모델을 보완
  • 아직 초기 단계이며 토큰 비용 주의가 필수, 검증·이해는 여전히 사람의 몫임 (build the loop, stay the engineer)

루프 엔지니어링의 정의와 등장 배경

  • 루프 엔지니어링은 에이전트에 프롬프트하는 사람의 자리를 자신에서 시스템으로 대체하는 것, 그 일을 대신하는 시스템을 직접 설계
    • 루프는 목적을 정의하면 AI가 완료될 때까지 반복하는 재귀적 목표(recursive goal)
    • 코딩 에이전트와 일하는 미래의 방식일 수 있으나 아직 초기 단계이며, 토큰 비용 주의가 필수 (token rich/poor 여부에 따라 사용 패턴이 크게 달라짐)
  • 인용
    • Peter Steinberger "더 이상 코딩 에이전트에 프롬프트하지 말고, 에이전트에 프롬프트하는 루프를 설계하라"
    • Boris Cherny (Anthropic의 Claude Code 책임자) "이제 Claude에 프롬프트하지 않고, Claude에 프롬프트하고 무엇을 할지 정하는 루프를 돌린다. 내 일은 루프를 작성하는 것"
  • 지난 약 2년간은 좋은 프롬프트와 충분한 컨텍스트를 주고, 한 턴씩 주고받으며 에이전트를 도구로 직접 쥐고 있는 방식이었으나 그 방식은 끝나가는 중
  • 이제는 작업을 찾아 분배하고, 검증하고, 완료된 것을 기록하고, 다음 작업을 결정하는 작은 시스템을 만들어 그 시스템이 에이전트를 찌르게 함
    • 이전 글 agent harness engineering(에이전트 하나가 도는 환경)과 factory model(소프트웨어를 만드는 시스템)의 상위에 위치
    • 타이머로 실행되고, 작은 헬퍼를 생성하며, 스스로에게 먹이를 주는 harness
  • 더 이상 도구의 문제가 아님 — 1년 전엔 루프를 원하면 bash 더미를 직접 작성·유지해야 했으나, 이제 구성 요소가 제품 안에 그대로 탑재
    • Steinberger의 목록이 Codex 앱과 거의 정확히 일치하고 Claude Code와도 거의 동일하므로, 어느 도구냐를 다투는 대신 어느 쪽에서도 동작하는 루프를 설계

루프의 다섯 가지 구성 요소와 메모리

  • 루프에는 다섯 가지가 필요하고, 거기에 상태를 기억할 한 곳이 추가됨
    • Automations — 스케줄에 따라 발동해 스스로 발견·분류(triage)를 수행
    • Worktrees — 병렬로 일하는 두 에이전트가 서로 충돌하지 않도록 함
    • Skills — 에이전트가 추측으로 메울 프로젝트 지식을 기록해 둠
    • Plugins·connectors — 이미 쓰는 도구에 에이전트를 연결
    • Sub-agents — 한쪽이 아이디어를 내고 다른 쪽이 검증
  • 여섯 번째는 메모리, markdown 파일이나 Linear 보드 등 단일 대화 밖에 살며 완료된 것과 다음 할 것을 보관
    • 너무 단순해 보이지만 모든 장기 실행 에이전트가 의존하는 동일한 트릭(이전 글 long-running agents)
    • 모델은 실행 사이에 모든 것을 잊으므로 메모리는 컨텍스트가 아니라 디스크에 있어야 함 — 에이전트는 잊어도 repo는 잊지 않음
  • 두 제품 모두 현재 다섯 가지를 전부 보유, 이름만 조금 다를 뿐 능력은 동일

Automations — 루프의 심장 박동

  • Automations는 루프를 한 번의 실행이 아닌 실제 루프로 만드는 요소
    • Codex 앱에서는 Automations 탭에서 생성, 프로젝트·실행할 프롬프트·주기·로컬 체크아웃인지 백그라운드 worktree인지를 선택
    • 무언가 발견한 실행은 Triage 인박스로 가고, 아무것도 못 찾은 실행은 스스로 아카이브됨
    • OpenAI는 일일 이슈 triage, CI 실패 요약, 커밋 브리핑 작성, 지난주 추가된 버그 사냥 같은 지루한 일에 내부적으로 사용
    • 자동화가 skill을 호출할 수 있어, 거대한 지시문 벽을 붙여 넣는 대신 $skill-name을 발동해 반복 작업을 유지보수 가능하게 함
  • Claude Code는 스케줄링과 hooks로 동일 지점에 도달
    • /loop으로 일정 간격마다 프롬프트나 명령을 실행, cron 작업 스케줄링, 에이전트 라이프사이클 특정 시점에 hooks로 셸 명령 발사 가능
    • 노트북을 닫은 뒤에도 계속 돌리려면 전체를 GitHub Actions로 넘길 수 있음
  • 세션 내 두 번째 프리미티브로 이 글의 핵심에 가까운 기능 존재
    • /loop은 정해진 주기마다 재실행
    • /goal은 작성한 조건이 실제로 참이 될 때까지 계속하며, 매 턴 후 별도의 작은 모델이 완료 여부를 검사해 코드를 쓴 에이전트가 채점자가 되지 않게 함
      • 예: "test/auth의 모든 테스트 통과, lint clean" 같은 조건을 주고 자리를 떠남
    • Codex도 동일하게 /goal을 제공, 검증 가능한 정지 조건이 성립할 때까지 턴을 넘기며 작동하고 pause·resume·clear 지원

Worktrees — 병렬이 혼돈이 되지 않도록

  • 에이전트를 둘 이상 돌리는 순간 파일이 충돌하기 시작, 이것이 실패 지점
    • 두 에이전트가 같은 파일을 쓰는 것은 두 엔지니어가 서로 말 없이 같은 줄을 커밋하는 것과 같은 두통
    • git worktree가 이를 해결 — 같은 repo 히스토리를 공유하면서 각자의 브랜치 위 별도 작업 디렉터리이므로 한 에이전트의 편집이 다른 쪽 체크아웃에 닿을 수 없음
  • Codex는 worktree 지원을 내장해 여러 스레드가 한 repo를 동시에 건드려도 부딪히지 않음
  • Claude Code는 git worktree, 세션을 자체 체크아웃으로 여는 --worktree 플래그, subagent에 붙이는 isolation: worktree 설정으로 동일한 격리 제공 (각 헬퍼가 끝나면 스스로 정리되는 새 체크아웃을 받음)
  • worktree는 기계적 충돌을 없애주지만 당신이 여전히 상한선 — 실제로 돌릴 수 있는 수는 도구가 아니라 본인의 리뷰 대역폭이 결정 (이전 글 the orchestration tax)

Skills — 매번 프로젝트를 다시 설명하지 않도록

  • skill은 매 세션 금붕어처럼 같은 프로젝트 컨텍스트를 다시 설명하는 일을 멈추는 방법
    • 두 도구 모두 동일 포맷 사용 — 지시문과 메타데이터를 담은 SKILL.md가 든 폴더, 그리고 선택적 스크립트·참조·에셋
    • Codex는 $/skills로 호출하거나, 작업이 skill 설명과 맞으면 스스로 실행하므로 영리한 설명보다 간결하고 지루한 설명이 더 나음
    • Claude Code도 같은 방식 (이전 글 agent skills)
  • skill은 의도(intent)가 반복 비용이 되지 않게 하는 곳
    • 에이전트는 매 세션을 차가운 상태로 시작하고 의도의 빈틈을 자신만만한 추측으로 메움 (이전 글 the intent debt)
    • skill은 그 의도를 외부에 적어둔 것 — 컨벤션, 빌드 단계, "그 사건 때문에 이렇게는 안 한다" 같은 것을 한 번 적어두면 에이전트가 매 실행마다 읽음
    • skill이 없으면 루프가 매 사이클마다 프로젝트 전체를 0에서 재유도, 있으면 누적되어 복리처럼 쌓임
  • skill은 저작 포맷이고 plugin은 배포 방법 — 여러 repo에 공유하거나 묶을 때 plugin으로 패키징 (Codex·Claude Code 모두 동일)

Plugins·connectors — 루프가 실제 도구에 닿게

  • 파일시스템만 볼 수 있는 루프는 작은 루프
    • MCP 기반의 connector가 에이전트로 하여금 이슈 트래커 읽기, DB 질의, 스테이징 API 호출, Slack 메시지 전송을 가능하게 함
    • Codex와 Claude Code 모두 MCP를 말하므로 한쪽용 connector가 보통 다른 쪽에서도 그대로 동작
    • plugin은 connector와 skill을 묶어, 동료가 기억으로 전체를 다시 구축하지 않고 한 번에 설치
  • 이것이 "여기 수정안이 있다"고 말하는 에이전트와, PR을 열고 Linear 티켓을 연결하고 CI가 green이 되면 채널에 핑을 보내는 루프의 차이
    • connector는 루프가 단지 가능성을 말하는 데 그치지 않고 실제 환경 안에서 행동하게 하는 이유

Sub-agents — 만드는 쪽과 검사하는 쪽을 분리

  • 루프에서 가장 유용한 구조는 단연 코드를 쓰는 쪽과 검사하는 쪽의 분리
    • 코드를 쓴 모델은 자기 숙제를 채점할 때 너무 관대함
    • 다른 지시문과 때로는 다른 모델을 가진 두 번째 에이전트가 첫 번째가 스스로 납득해 버린 것을 잡아냄
  • Codex는 요청할 때만 subagent를 생성, 동시에 실행한 뒤 결과를 하나의 답으로 합침
    • .codex/agents/TOML 파일로 자체 에이전트 정의 (name·description·instructions, 선택적 model·reasoning effort)
    • 예: 보안 리뷰어는 high effort의 강한 모델, explorer는 빠른 read-only 모델
  • Claude Code는 .claude/agents/의 subagents와 작업을 주고받는 agent teams로 동일하게 처리
    • 두 도구의 통상 분담은 한 에이전트가 탐색, 하나가 구현, 하나가 스펙 대비 검증 (이전 글 the code agent orchestra, adversarial code review)
  • 루프는 보지 않는 동안 돌므로 신뢰할 수 있는 검증자(verifier) 가 있어야 자리를 떠날 수 있음
    • subagent는 각자 모델·도구 작업을 하므로 토큰을 더 소모, 두 번째 의견이 값어치 있는 곳에 사용
    • Claude Code의 /goal이 내부적으로 하는 일도 이것 — 새 모델이 작업한 쪽 대신 완료 여부를 판단, 정지 조건 자체에 maker·checker 분리를 적용

하나의 루프는 어떻게 생겼는가

  • 합쳐 놓으면 단일 스레드가 작은 제어판으로 바뀜, 반복해 쓰는 한 가지 형태
    • automation이 매일 아침 repo에서 실행, 그 프롬프트가 triage skill을 호출해 어제의 CI 실패·열린 이슈·최근 커밋을 읽고 결과를 markdown 파일이나 Linear 보드에 기록
    • 할 가치가 있는 각 항목마다 스레드가 격리된 worktree를 열어 sub-agent에게 수정 초안을 맡기고, 두 번째 sub-agent가 그 초안을 프로젝트 skill과 기존 테스트 대비로 리뷰
    • connector가 루프로 하여금 PR을 열고 티켓을 갱신하게 함, 루프가 처리하지 못한 것은 triage 인박스로 들어옴
    • 상태 파일(state file) 이 전체의 척추 — 무엇을 시도했고 통과했고 아직 열려 있는지를 기억해 다음 날 아침 실행이 오늘 멈춘 지점에서 이어감
  • 핵심은 그 단계들 중 어느 것도 프롬프트하지 않고 한 번 설계했다는 점 — Codex든 Claude Code든 구성 요소가 같아 같은 루프

루프가 여전히 대신해 주지 않는 것

  • 루프는 일을 바꿀 뿐 사람을 지우지 않음, 오히려 루프가 좋아질수록 더 날카로워지는 세 가지 문제 존재
  • 검증은 여전히 본인 몫
    • 무인으로 도는 루프는 무인으로 실수하는 루프이기도 함
    • verifier sub-agent를 maker와 분리하는 이유는 루프의 "끝났다"에 의미를 부여하기 위함이나, 그래도 "done"은 증명이 아니라 주장 (이전 글 code review in the age of AI — 일은 동작을 확인한 코드를 출하하는 것)
  • 이해는 방치하면 썩음
    • 루프가 직접 쓰지 않은 코드를 빨리 출하할수록 존재하는 것과 실제로 이해하는 것 사이 간극이 커짐
    • 이것이 comprehension debt, 매끄러운 루프는 루프가 만든 것을 읽지 않으면 그 간극을 더 빨리 키움
  • 편안한 자세가 위험한 자세
    • 루프가 스스로 돌면 의견 갖기를 멈추고 돌려받은 것을 그대로 받기 쉬움 (cognitive surrender)
    • 루프 설계는 판단을 갖고 하면 치료제, 사고를 피하려고 하면 가속제 — 같은 행동, 정반대의 결과

루프를 만들되, 엔지니어로 남아라

  • 일이 진화하는 방식의 예고편으로 보이나, 코드를 직접 리뷰하지 않거나 자동 루프에만 의존하면 제품 품질이 떨어지고 점점 더 깊은 구멍으로 빠지는 하향 나선에 갇힐 수 있음
  • 루프를 설정하되 에이전트에 직접 프롬프트하는 것도 여전히 효과적, 핵심은 적절한 균형 찾기
  • 루프는 사람에 따라 정반대 결과 — 같은 루프를 만든 두 사람 중 한 명은 깊이 이해한 일을 더 빨리, 다른 한 명은 일을 이해하지 않으려고 사용
    • 루프는 그 차이를 모르지만 당신은 앎
  • 이것이 루프 설계를 프롬프트 엔지니어링보다 쉽지 않고 더 어렵게 만드는 이유 — Cherny의 요점은 일이 쉬워졌다는 게 아니라 레버리지 지점이 옮겨졌다는 것
  • 결론: 루프를 만들되, 그저 시작 버튼을 누르는 사람이 아니라 엔지니어로 남을 사람처럼 만들 것



https://news.hada.io/topic?id=30336&fbclid=IwY2xjawSW6glleHRuA2FlbQIxMQBzcnRjBmFwcF9pZBAyMjIwMzkxNzg4MjAwODkyAAEexhJ0i8uUUrb_B6soLh_mMGRl_1MxFQHKO3hK20HEHX2QyORjp-nL0Heuk-w_aem_YWdncwDctXaFScMLXXOqWafG9NlO&brid=YWdncwECvQPJAmdhWGueP2Jvkw-i

인공지능 시대에 가장 가치 있는 개발자는 장인 정신과 뛰어난 제작 능력을 모두 갖춘 인재가 될 것입니다. - 멋진 글 링크 걸어둡니다. ㅎㅎ

 

인공지능 시대에 가장 가치 있는 개발자는 장인 정신과 뛰어난 제작 능력을 모두 갖춘 인재가 될 것입니다.

인공지능이 개발자들을 위한 새로운 강력한 도구가 되었다면, 누구나 제작자가 될 수 있는 시대에 장인 정신이 깃든 수공예는 여전히 가치가 있을까요?

기사 주인공 이미지

인류 역사를 통틀어 우리는 삶을 더 편리하게 해주는 도구를 발명해 왔습니다. 창, 바퀴, 인쇄기, 인터넷—이 모든 것들은 우리의 뛰어난 두뇌가 만들어낸 결과물이며, 덕분에 우리는 우리의 뛰어난 두뇌를 덜 사용하게 된 것입니다.

인공지능(AI)은 우리가 사물을 만들고 소비하는 방식을 바꾼 수많은 발명품 중 하나일 뿐입니다. AI가 인류를 어디로 이끌지는 아직 미지수이지만 (개인적으로는 현재의 AI 혁신적 영향력을 인터넷보다는 낮고 킨들보다는 높다고 평가합니다), 기술 세계에는 확실히 급진적인 변화를 가져왔습니다. AI 도구는 현대 사회의 근간 이라고 할 수 있는 기술과 소프트웨어의 거의 모든 측면을 뒤흔들었고 , 전 세계 기술 종사자들이 일상적인 업무와 워크플로를 처리하는 방식을 바꿔놓았습니다.

특히 코드 작성 방식에서 이러한 현상이 두드러집니다. 2023년 GitHub는 모든 언어를 아우르는 자사 사용자 코드의 46%가 GitHub Copilot에 의해 생성되었다고 발표했습니다 . 2026년 4월에는 Google에서 생성되는 모든 새 코드의 75%가 AI에 의해 생성될 것이라고 합니다. 출처는 바로 CEO의 최근 블로그 게시글입니다 . Google은 이러한 추세를 오랫동안 지속해 왔으며, 불과 1년 반 만에 그 비율을 25% 에서 75%로 끌어올렸습니다. 그리고 아시다시피… Google, 보기 좋게 딱 떨어지는 숫자네요.

많은 AI 코드가 쓸모없고, 보안에 취약하며, 엉망진창인 코드 덩어리라는 점에는 우리 모두 동의할 수 있을 것입니다. 하지만 그럼에도 불구하고, AI가 생성하는 코드의 양은 인간 개발자가 따라잡을 수 없을 정도로 기하급수적으로 증가하고 있습니다.

하루에 37,000줄을 작성한다는 이야기는 다소 과장된 면이 있지만(토큰 최적화는 칭찬할 만합니다), 코딩 어시스턴트가 소프트웨어 개발 업계를 강타했다는 것은 부인할 수 없는 사실입니다. 2025년 개발자 설문조사 에 따르면 개발자와 기술 전문가의 84%가 AI를 도입했으며, 그중 51%는 매일 AI 도구를 사용하고 있습니다.

솔직히 말해서, 부끄러워할 일은 아닙니다. 저도 제미니(Gemini)를 이용해서 그런 통계 자료를 조사했다는 걸 인정하니까요. 하지만 몇 가지 의문점이 생깁니다. 첫 번째 질문은 이겁니다. AI라는 신비롭고 마법 같은 블랙박스 에서 37,000줄이나 되는 코드를 쏟아낼 때, 우리는 도대체 무엇을 만들어내는 걸까요 ? 아마 그 코드를 만든 CEO조차도 답을 모를 거라고 생각합니다.

두 번째 질문: 우리가 만들어내는 것들의 생성 과정에서 우리 자신을 배제하면 어떻게 될까요? 그리고 이어서, 인공지능이 완전히 생성한 것을 과연 우리 자신의 창작물이라고 부를 수 있을까요?

기술의 철학적 난제

제가 묻는 질문들은 1440년 최초의 편지가 종이에 찍힌 이후로 우리가 끊임없이 논쟁해 온 철학적 난제들과 같습니다. 어딘가에서는 항상 누군가 새로운 기술이 모든 것의 종말이라고 생각하는 것 같습니다. 물론 언젠가는 그들의 생각이 맞을 수도 있겠지만, 지금은 부분적으로만 맞습니다. 기술은 한 가지 특정한 것의 종말을 가져올 뿐입니다. 바로 현상 유지의 종말입니다.

오늘날 우리는 직접 가구를 만들거나 소중한 사람들에게 손편지를 쓰지 않습니다. 하지만 예전에는 새 의자가 필요하거나 장거리 연애 중인 연인과 헤어지려면 직접 만들고 편지를 써야 했습니다. 그것이 당시의 관습이었습니다. 오늘날에는 이케아와 왓츠앱이 있기 때문에 그런 관습은 시대에 뒤떨어졌습니다. 그렇다고 손글씨나 목공예 같은 예술 형식이 완전히 사라진 것은 아닙니다. 단지 우리는 그런 단순한 기술과 전통적인 수공예를 인내심과 정성을 가진 장인들에게 맡기는 경향이 있을 뿐입니다. 여기서는 나무를 깎을 필요도 없습니다.

바로 그 '장인'이라는 단어가 우리의 시대를 초월하는 철학적 문제의 핵심에 있습니다. 기술이 우리에게 원하는 것은 무엇이든 그 어느 때보다 빠르게 만들 수 있는 강력한 도구를 제공해 준다면, 장인이 된다는 것은 무슨 의미가 있을까요? 같은 시간 동안 이케아 의자 수백 개를 조립할 수 있는데, 누가 의자 하나를 천천히 손으로 만들겠습니까? 누가 그저 의자를 만들기 위해 의자를 만들겠습니까? 인공지능이 절반의 시간으로 무엇이든 만들어 줄 수 있는데, 누가 그저 코드를 작성하기 위해 코드를 작성하겠습니까?

장인과 단순 제작자라는 이분법은 개발자 커뮤니티에서 AI 도구 사용을 둘러싼 담론의 핵심입니다. 최근 메이저 리그 해킹(Major League Hacking)의 마이크 스위프트는 코딩 어시스턴트가 소프트웨어 개발 세계에 "패러다임 전환"을 일으키고 있으며, 개발자의 작업 방식, 개발 속도, 그리고 정체성에 대한 인식까지 바꾸고 있다고 말했습니다. "과거에는 개발자라는 직업 자체가 하나의 정체성이었습니다. 코딩 기술을 알아야만 할 수 있었기 때문이죠."라고 마이크는 말했습니다. "하지만 이제는 더 이상 그렇지 않습니다." 그리고 이러한 정체성 파괴는 사실 AI가 약속했던 것 중 하나였습니다. 이제 누구나 코더, 비디오 편집자, 작가, 수학자, 디자이너가 될 수 있으며, 특정 분야의 기술을 배우지 않아도 됩니다 . 스탠드업 코미디를 제외하면 , AI는 거의 모든 분야의 진입 장벽을 낮췄습니다. 심지어 질병 진단까지 가능해졌습니다 . 물론 ChatGPT를 주치의로 삼는 것은 절대 안 되겠지만 요.

좋든 나쁘든, 우리는 인공지능 덕분에 끝없는 지름길을 만들어냈습니다 . 이제 월 20달러라는 저렴한 가격으로 학습 , 업무, 대인관계, 심지어 건강 관련 결정까지 챗봇에 맡길 수 있습니다! 이러한 업무 위임은 특히 소프트웨어 개발 분야에서 두드러지는데, 직원들은 최대한 빠르게 무언가를 만들라는 요구를 받습니다. 기업은 느리고 꼼꼼한 작업으로 최고의 품질을 자랑하는 장인을 원하지 않습니다. 그들은 당장 자리에 앉을 수 있는 사람 , 몇 분 만에 수백 개의 이케아 의자를 조립할 수 있는 사람을 원합니다.

AI 코딩 도우미는 누구나 특별한 기술 없이도 초고속으로 무언가를 만들 수 있는 편리하고 효율적인 방법입니다. 하지만 이케아 의자가 내구성이 좋도록 만들어진 것이 아니듯이, AI로 생성된 소프트웨어 역시 마찬가지입니다. 기업들이 조악하게 만든 의자나 AI 소프트웨어에 문제가 생기면 어떻게 될까요?

솔직히 말해서, 장인과 건설자라는 이분법이 꼭 이분법적일 필요는 없다고 생각합니다. AI의 등장으로 우리는 기술 발전 역사에서 또 다른 변곡점에 도달했습니다. 이는 현재의 상황을 끝내고 새로운 상황을 만들어내는 변곡점입니다. 그 새로운 상황에서는 개발자들이 미래의 기술을 빠르고 대규모로 구축하는 장인으로 진화할 것입니다.

건축가이기도 한 장인들과 장인이기도 한 건축가들

제가 제안하는 '건축 장인'과 '장인 정신을 가진 건축가'라는 개념에 대해 이야기하기 전에, 개발자의 정체성이 진화해야 하는지 분석하는 것이 중요합니다. 하지만 그 전에, 제 소개부터 하겠습니다.

저는 제가 경험 많은 개발자라고 주장한 적도 없고, 기술에 대해 많이 안다고 말한 적도 없습니다(물론 Stack Overflow 면접 때 미래의 동료들에게 깊은 인상을 주기 위해 AI에 대해 많이 아는 척했던 적은 있습니다). 저는 코딩에 대해 열정 넘치는 초보 라는 사실을 자랑스럽게 생각합니다 . 하지만 AI 코딩 도구의 힘을 빌려 단 몇 시간 만에 완전히 작동하는(물론 부분적으로 작동하는) 애플리케이션을 만들 수 있었습니다 .

저는 스스로를 개발자나 장인이라고 부르지는 않겠습니다(저는 기술 분야의 신동이라고 생각합니다). 하지만 바이브 코딩 도구를 사용하는 사람들 중에는 스스로를 소프트웨어 개발자라고 부르는 사람들이 많다는 것을 알고 있습니다. 어떻게 알았냐고요? 그들은 코드 한 줄도 모르면서 링크드인 프로필 제목에 "차세대 XYZ를 개발 중"이라고 써놓거든요. ​​이런 야심 찬 사람들을 폄하하려는 건 아닙니다. 혼자서 무언가를 만들어내는 데에는 엄청난 용기와 투지가 필요하다는 것을 저도 잘 알고 있습니다. 하지만 그들이 소프트웨어 개발자라고 불리는 것을 보면 코드를 아는 것이 얼마나 필수적인지에 대한 의문이 생깁니다. 여러분도 이제 소프트웨어 개발자가 될 수 있습니다! 그렇다면 과거 소프트웨어 개발자들은 어떻게 될까요?

AI는 수작업 코딩이라는 기술을 완전히 쓸모없게 만들지는 않았더라도, 선택 사항으로 만들었습니다. 하지만 코드를 작성하는 사람이 아니라면 개발자란 무엇일까요? 마이크 스위프트가 말했던 패러다임의 변화가 바로 여기에 있습니다. 개발자와 비코더를 구분하는 것은 더 이상 통하지 않습니다. 누가 소프트웨어를 만들 수 있고 누가 만들 수 없는지의 문제가 아닙니다. 클로드 구독권만 있으면 (저를 포함해서) 누구나 소프트웨어를 만들 수 있습니다. 그렇다면 중요한 질문은 바로 "소프트웨어 개발 과정에서 개발자가 없어서는 안 될 존재인 이유는 무엇일까?"가 됩니다.

그 필수불가결함은 개발자들의 오랜 경험, 즉 장인정신에서 비롯됩니다. 그 장인정신을 활용하여 무언가를 만들어낼 수 있다면, 성공의 열쇠를 쥐게 되는 겁니다. 저 역시 작가로서 이를 직접 경험했습니다. AI가 코드를 생성하는 데 능숙하다면, 글을 쓰는 데는 훨씬 더 뛰어납니다.

인공지능 초창기, 사람들이 봇에게 구체적이지 않은 네 단어짜리 프롬프트만 입력해도 여러 단락의 논리적인 글을 써낼 수 있다는 사실을 알아차리자 갑자기 모두가 작가가 된 듯했습니다. 경험이 전혀 없는 사람들도 저와 비슷한 수준의 글을 쓸 수 있게 된 거죠. 글쓰기 실력을 갈고닦는 건 이제 의미가 없어진 셈이었습니다. 작가라는 건 더 이상 단순히 글을 잘 쓰는 능력만으로 결정되는 게 아니었습니다. 명료하고 사려 깊은 문단에 어려운 단어와 의미심장한 비유를 섞어 쓰는 게 너무나 흔해졌습니다. 클로드 구독자라면 (당신도 포함해서) 누구나 할 수 있는 일이 되어버린 겁니다. 좋은 작가가 되기 위한 전제 조건이 글을 잘 쓰는 것이 아니라면, 제가 진정한 작가라는 걸 어떻게 증명해야 할까요?

인공지능이 생성한 글에 대한 열풍이 사그라들고 사람들이 3단어 규칙, 하이픈(-) 기호, 대조적인 문장 등에 질려버리자, 글쓰기는 다시금 하나의 기술이 되었습니다. 인공지능 시대에 작가가 되려면 단순히 글 몇 편을 제출하는 것만으로는 부족했습니다. 사람들에게 감동과 공감을 불러일으키는 좋은 이야기를 들려줘야 했습니다. 결국, 그것이 제가 수년간 갈고닦아 온 장인 정신의 진정한 가치였습니다. 그리고 제 장인 정신은 인공지능의 도움을 받든 받지 않든, 제가 만들어내는 결과물을 만들어내는 데 있어 매우 중요한 요소입니다. 저는 제 두 손으로 직접 고품질의 이야기를 만들어낼 줄 알기 때문에 , 인공지능은 제가 빠르고 효율적으로 글을 쓸 수 있도록 도와줍니다. 덕분에 제 손가락 속도보다 더 빠른 속도로 작업하려는 개발자들과 보조를 맞출 수 있습니다. 저는 이러한 방식으로 제 기술을 활용하여 제가 진정으로 아끼는 것들을 만들어내고, 빠르게 움직이는 개발자들과 협력하여 현실적이고 의미 있는 글을 쓸 수 있습니다. 다시 말해, 저는 이케아가 더 나은 의자를 디자인하도록 돕는 목수입니다.

개발자는 빌더 중심의 세상에서 장인과 같은 존재가 될 기회를 갖고 있습니다. 마이크 스위프트는 이렇게 말했습니다. "가치가 창출되는 곳은 아이디어, 소통, 그리고 감각입니다. 무엇을 만들어야 하는지, 왜 만들어야 하는지, 그리고 LLM이나 팀이 그것을 어떻게 만들도록 해야 하는지 아는 것이죠." 스위프트가 말하는 "감각"은 오직 전문성과 경험에서만 나옵니다. 바로 장인 정신이죠. 의자를 튼튼하게 만드는 방법을 아는 사람은 의자 를 만들어 본 사람뿐입니다. 마찬가지로 코드베이스를 안전하게 만들거나, 애플리케이션을 빠르게 만들거나, 헤드리스 소프트웨어를 구현하는 방법을 아는 사람은 코딩을 할 줄 아는 사람뿐입니다.

인공지능 이 성숙 단계에 이르면 장인 정신이 깃든 전문 인력이 필요하게 될 것입니다 . AI가 생성하는 코드는 초기 개발 단계에는 유용하지만, 안전하고 신뢰할 수 있는 시스템을 구축하려면 여전히 기술 전문 지식이 필요합니다. 마이크로소프트 개발자 커뮤니티 부사장인 스콧 한셀만은 "목표가 프로토타입 제작인가요? 아니면 수백만 명의 사용자를 수용하고 그들이 데이터를 안심하고 맡길 수 있는 견고하고 안전한 뱅킹 플랫폼을 출시하는 것인가요?"라고 질문했습니다. AI 생성 코드는 전자의 경우에 효과적이지만, 우리 디지털 세상은 후자를 기반으로 합니다. 견고하고 안전한 플랫폼을 구축하는 유일한 방법은 지식과 기술 전문 지식을 활용하는 것입니다. 한셀만은 "전문적인 코딩 지식이 부족한 비기술적인 개발자는 AI와 자신을 혼동하여 이상한 하드코딩을 할 수 있습니다."라고 말했습니다. "특정 기능을 구현하는 것과 윈도우, .NET 또는 피라미드의 기초를 이루는 기본적인 시스템을 출시하는 것에는 큰 차이가 있습니다."

한셀만이 말하는 것처럼 견고하고 안전한 소프트웨어를 계속해서 출시하고 싶다면(그리고 우리는 반드시 그렇게 해야 합니다), AI가 생성한 코드로는 충분하지 않습니다. 하지만 소프트웨어에 대한 우리의 갈증은 끝없이 커지고 있으며, 손으로 코드를 작성하는 속도로는 결코 충족될 수 없습니다. 하지만 어쩌면 우리는 빠르게 움직이다가 문제를 일으키는 방식과 느리게 만들다가 제대로 만드는 방식 사이에서 선택할 필요가 없을지도 모릅니다. 이제 개발자들은 빠르게 움직이면서도 제대로 만들 수 있는 도구를 갖게 되었습니다. 마치 장인이 되어 직접 만들어내는 것처럼 말입니다.

장인정신의 가치

우리는 건설업자들이 지배하는 세상에 살고 있습니다. 기업들은 속도와 효율성을 최우선으로 하는 건설업자식 접근 방식으로 운영됩니다. 하지만 스콧 한셀만이 말하는 견고한 소프트웨어를 만들기 위해서는, 실제로 작동하고 안전한 코드베이스를 구성하는 요소들을 아는 장인들의 전문성이 점점 더 중요해질 것입니다. 우리는 글쓰기와 스토리텔링에서 이미 이러한 현상을 목격했습니다. 좋은 글과 그렇지 않은 글을 가르는 기준이 바로 큐레이션과 안목이 된 것입니다.

개발 분야도 곧 비슷한 추세를 보일 것이라고 생각합니다. 특히 AI가 무한한 코드 가능성을 제시함에 따라 코드에 대한 수요 또한 무한해질 것이기 때문입니다. 개발자들은 이제 코드를 통해 무한한 가능성을 갖게 되었지만, 동시에 대규모로 제대로 작동하지 않거나 악의적인 공격자에게 민감한 데이터를 노출시키는 프로그램들을 계속해서 만들어낼 것입니다. 이러한 무수히 많은 소프트웨어 문제를 해결하려면 코드를 진정으로 이해하는 전문가들이 나서서 실질적인 작업을 수행해야 할 것입니다.

하지만 건설업계에서는 장인들이 시대의 흐름에 맞춰 자신의 기술을 발전시키고 조정하는 것이 중요합니다. 인쇄기를 무시할 수 없고, 바퀴를 없앨 수 없고, 인터넷을 끌 수 없는 것처럼, AI 기반 작업은 이제 피할 수 없는 현실이 되고 있습니다. 하지만 이 모든 것은 단지 도구일 뿐이며, 장인과 전문가의 작업을 훨씬 수월하게 만들어주는 도구입니다. 마이크 스위프트는 "지금 우리가 처한 상황은 사실상 전동 공구의 탄생과 같습니다."라고 말했습니다. "[전동 공구처럼] 우리는 문제를 해결하고, 제품을 만들고, 최종 사용자의 요구를 충족하기 위해 도구의 흐름을 최적화해 왔습니다." 개발자에게 있어 이러한 강력한 도구를 능숙하게 활용하는 것은 새로운 AI 세상에서 성공하기 위한 필수 요소입니다.

느리고, 꼼꼼하고, 장인 정신이 깃든 모든 것이 사라진 것은 아닙니다. 현상 유지는 변했을지 모르지만, 바퀴를 발명했다고 해서 사람들이 더 이상 걷지 않는다는 뜻은 아닙니다. 장인이 되는 것과 건축가 가 되는 것의 문제가 아니라 , 둘 다 조금씩 갖추는 것이 중요합니다. 아마도 이러한 장인과 건축가의 장점을 결합한 인재가 새로운 시대의 소프트웨어 개발자를 차별화하는 요소가 될 것입니다. 제 주장을 뒷받침하기 위해, 저는 이 글의 초고를 노트북에 만년필로 노트에 썼습니다. 만년필은 글쓰기에 더 집중할 수 있도록 도와주기 때문입니다. 노트북에는 Gemini라는 책이 옆에 열려 있었지만 말입니다.

장인 정신이 깃든 수공예는 결코 사라지지 않았습니다. 글쓰기는 물론 소프트웨어 개발에서도 마찬가지입니다. 우리가 특별한 기술 없이도 이케아 의자를 조립할 수 있는 이유는 숙련된 장인이 의자의 구성 요소를 설계하고, 테스트하고, 생산해냈기 때문입니다. 우리의 의자와 소프트웨어에는 여전히 경험 많은 장인이 필요합니다. 우리의 코드에는 여전히 개발자가 필요합니다. 그리고 직접 만들어낼 줄 아는 장인 정신을 가진 개발자는 어떤 인공지능보다도 더 가치 있을 것입니다.


https://stackoverflow.blog/2026/05/28/artisans-and-builders/


2026년 6월 9일 화요일

마이크로소프트 빌드 2026 키노트 영상입니다.

 

내용이 많아서 영상을 보면서 클로드 코드로 정리해 보았습니다. 치열한 AI싸움에서 누가 승기를 잡을 것인가? 마소, 구글, 앤트로픽.... 



















































Microsoft Build 2026 핵심 정리

📅 2026년 6월 2~3일 | 샌프란시스코 발표자: Satya Nadella CEO + Mustafa Suleyman (Microsoft AI)


1️⃣ MAI 자체 모델 패밀리 공개 — "OpenAI 의존 탈피 선언"

Microsoft가 드디어 자체 AI 모델 패밀리를 공개했습니다. MAI-Thinking-1은 최초의 추론(reasoning) 전용 모델이고, MAI-Code-1은 GitHub 전용으로 설계된 코딩 모델로 이미 Copilot과 VS Code에 적용됐습니다. Gizbot

모델특징
MAI-Thinking-1추론 모델, 350억 파라미터, 256K 컨텍스트, 독자 개발(distillation 없음)
MAI-Code-1-Flash코딩 모델, 50억 파라미터, SWE-Bench Pro 51%, VS Code 기본 모델로 롤아웃
MAI-Image-2.5이미지 편집
MAI-Transcribe-1.543개 언어 음성→텍스트
MAI-Voice-215개+ 언어 음성 생성

MAI-Code-1-Flash는 GitHub Copilot 토큰 기반 과금에서 Claude Haiku 4.5보다 저렴하게 책정되며 현재 개인 사용자의 약 10%에 롤아웃 시작됐습니다. Microsoft

MAI 모델들은 Fireworks AI, Baseten, Open Router에서도 사용 가능하며, 개발자가 직접 가중치를 튜닝할 수 있게 됩니다. Microsoft Blogs


2️⃣ Microsoft IQ — 에이전트의 "컨텍스트 엔진"

Microsoft IQ가 GitHub Copilot, Foundry, Copilot Studio 전반에 정식 출시(GA)됩니다. 이는 AI 에이전트에 실제 업무 지식을 공급하는 컨텍스트 레이어로, M365 신호 기반의 Work IQ, 구조적 비즈니스 데이터의 Fabric IQ, 실시간 웹 그라운딩의 Web IQ로 구성됩니다. Tom's Guide

Work IQ API는 6월 16일 개발자에게 공개되며, 이메일·문서·회의·조직 관계도를 에이전트가 활용할 수 있게 됩니다. Gizbot


3️⃣ Scout — M365의 상시 자율 에이전트

Scout는 OpenClaw 프레임워크 기반으로 구축된 상시 작동 에이전트입니다. 사용자가 직접 이름을 붙이고(예: Sebastian), 자동화할 업무에 대해 지속적으로 피드백을 주면 에이전트가 사용자 스타일에 맞게 적응합니다. TechCrunch

Scout는 Teams, Outlook, OneDrive, SharePoint 전반에 통합되어 백그라운드에서 지속 작동하며 이메일·캘린더·채팅·문서를 분석해 회의 준비, 일정 충돌 해결, 이메일 초안 작성 등을 자동으로 처리합니다. ETV Bharat

각 에이전트는 공유 서비스 계정이 아닌 개별 Entra ID를 갖고, 작업 범위에 맞게 스코프된 자격증명을 사용하며 감사 추적을 생성합니다. Microsoft


4️⃣ OpenClaw + MXC — Windows의 에이전트 보안 인프라

오픈소스 에이전트 런타임 OpenClaw가 이제 Windows에서 네이티브로 실행됩니다. MXC(Microsoft Execution Containers) 기반의 하드웨어 격리로 보안을 보장하며, Windows 365 for Agents(에이전트용 클라우드 PC)도 정식 출시됩니다. Windows Developer Blog

OpenClaw 컨테이너의 CPU 오버헤드는 대부분의 워크로드에서 2% 미만이며, NVIDIA도 OpenShell을 통해 MXC를 통합합니다. Windows News


5️⃣ Project Solara — "에이전트 퍼스트 디바이스" 미래상

Project Solara는 에이전트 중심 디바이스 플랫폼으로, 앱 기반 모델을 대체해 에이전트가 백그라운드에서 워크플로를 조율합니다. 미리 설계된 고정 UI 대신 컨텍스트에 따라 인터페이스를 동적으로 생성하는 "just-in-time UI" 개념을 도입합니다. ETV Bharat

배지형 웨어러블과 데스크형 디스플레이 두 가지 컨셉 디바이스를 공개했으며, USB-C로 연결 시 Windows 365 클라이언트로도 활용 가능합니다. 이는 에코시스템 파트너를 위한 레퍼런스 디자인으로 제공될 예정입니다. Command Line


6️⃣ 개발자 도구 업데이트

GitHub Copilot 데스크탑 앱이 프리뷰로 출시되어 에디터 사이드바를 벗어난 네이티브 데스크탑 에이전틱 워크플로를 지원합니다. Project Rayfin은 에이전트 퍼스트 SDK로 Microsoft Fabric 위에서 백엔드-애즈-어-서비스를 제공합니다. Tom's Guide


📌 한 줄 총평

Build 2026의 핵심 메시지는 "AI가 소프트웨어의 부가기능이 아니라 OS·실리콘·클라우드 전 계층의 기반" 이라는 선언입니다. OpenAI 의존에서 벗어나 자체 MAI 모델 패밀리를 공개하고, Scout·OpenClaw·MXC로 에이전트 자율화를 위한 보안 인프라를 갖춘 것이 가장 큰 변화입니다. AI 교육·개발 관점에서는 MAI-Code-1-Flash의 저렴한 가격과 VS Code 기본 탑재, Work IQ API 개방(6/16)이 당장 눈여겨볼 포인트입니다.




https://news.microsoft.com/build-2026/#video-FFMm454fxNA


도안구 기자님이 정리한 내용도 좋네요. 

https://www.techsuda.com/microsoft-build-2026-unmetered-intelligence-full-stack-strategy/


루프 엔지니어링 - 에이전트를 프롬프트하는 시스템을 설계하기 - 링크 걸어둡니다.

  ▲ 루프 엔지니어링 - 에이전트를 프롬프트하는 시스템을 설계하기 (addyo.substack.com) 21 P by GN⁺ 1일전 | ★ favorite | 댓글 4개 코딩 에이전트에게 매 턴마다 직접 프롬프트하던 방식을 끝내고, 에이전트를...