Between Negative and Positive

How I Run a Claude Code Writing Project Like Software

2026-06-22T00:00:00.000Z

Quick Answer

If you want an AI agent to produce consistent long-form output — a 30-episode novel, a docs set, a content series — stop tuning prompts and structure the project like software. I built a web novel writing workflow in Claude Code, and every tool I reached for turned out to be a software engineering pattern: settings files as a single source of truth, one skill per job (single responsibility), goals declared before drafting (test-first), and review skills that act as linters. The model never got smarter. The context around it got engineered. Here is the exact structure and what each piece maps to.

Who This Guide Is For

Solo developers and indie hackers using Claude Code (or any coding agent) for non-code work: writing, docs, research, content pipelines.
People who already write code and wonder why their AI writing output drifts after a few attempts.
Anyone who tried “just write the next chapter” and watched the tone, facts, and characters fall apart.

If your project is short — one post, one draft — this is more overhead than it is worth. Skip to When Not to Use This Approach.

The Failure That Started It

My first attempt was naive. I handed Claude a planning document and said “write episode 1.” It came out fine. Episode 2 had a subtly different narrator voice. By episode 5, a character who should have been dead was back with dialogue, and the prose had quietly drifted from thriller into dry police report.

The model was not the problem. I was. I had given it a clean prompt and almost no engineered context. So instead of polishing prompts harder, I rebuilt the project structure — and that is where the engineering patterns showed up, one after another.

The Workflow

Step 1: Externalize every rule into settings

I moved the world, the character roster, the multi-part plot, the style guide, and the safety boundaries out of my head and into files. Characters became structured data — name, age, voice, relationships, arc — in a single YAML file. Now no episode guesses the protagonist’s age; it reads it.

Step 2: Split the work into one-job skills

Instead of one mega-prompt that does everything, I wrote small skills that each do exactly one thing: draft an episode, design a beat sheet, check character voice, check continuity, check safety, research psychological grounding. When output goes wrong, I can point at the skill that failed.

Step 3: Declare acceptance criteria before drafting

Before writing an episode, I write down what “done” means: word count, the scene beats, the hook type, what gets set up, what gets paid off. Then I draft. Then I compare the result against that declaration.

Step 4: Automate review, then review the reviewer

Lint-style skills sweep the draft for inconsistencies, voice drift, and safety-boundary violations. I still read the result — automated checks narrow the search, they do not replace judgment.

Example Project Structure

project/
  CLAUDE.md          # project constitution for Claude
  GEMINI.md          # near-identical, different model
  PLAN.md            # original design intent
  settings/          # single source of truth
    world.md
    characters.yaml
    plot-master.md
    style-guide.md
    safety.md
  beat-sheets/       # per-arc design docs (the spec)
    beats-ep001-010.md
  .claude/skills/    # one skill per job
    episode-writer/
    beat-sheet/
    voice-checker/
    consistency-checker/
    safety-checker/
    researcher/
    ...
  episodes/          # output: deliverable text only
    part-01/  part-02/
  notes/             # working memory: metadata, reviews
    ep021/working_notes.md

The folder names say “novel.” The structure says “software project.” Here is the one-to-one mapping I noticed only after it was built:

Writing workflow piece	Engineering concept
`settings/` documents	Single source of truth, schema
”settings wins on conflict” rule	Dependency precedence / resolution order
Skills, one job each	Single Responsibility Principle
Episode-writer calling other skills	Function composition
Goal declaration → goal vs actual	Test-first / acceptance criteria
Output files hold text only; metadata in `notes/`	Separation of concerns; source vs build
Voice / consistency / safety checkers	Linters, static analysis, CI gates
Researcher’s “do not search X” rule	Input validation / guardrail
Research accumulated to a file	Caching / memoization
`CLAUDE.md` ≈ `GEMINI.md`	Interface abstraction, vendor portability

A few of these are worth unpacking.

Single source of truth. The protagonist’s age lives in exactly one place. Every episode references it. A rule in CLAUDE.md even says: if PLAN.md and settings/ disagree, settings/ wins. That is just a dependency precedence rule — deciding who wins when two sources conflict, so the model does not pick arbitrarily.

Test-first, literally. One real working-note declared a target of 4,500–5,000 characters for an episode. The actual draft came out at 6,398. Because I had declared the criterion up front, “it overshot” was an objective fact I could catch and decide on. Without a stated target, I would never have noticed the bloat. This is the same loop I wanted when I finally tried TDD: pin down what “correct” means before you build, then check against it.

Source vs build separation. Episode files contain only the prose a reader sees. The goal declaration, the review tables, the research citations all live in notes/. If metadata leaked into the manuscript, I could not copy-paste and publish. It is the same reason you do not commit your build folder.

Caching. The research skill searches for psychological grounding once, writes it to a file, and checks that file before searching again. Its own instructions say it exists to “avoid re-searching the same topic.” That is memoization: store the result of an expensive call, reuse it on the same input. It saves tokens and keeps the answer consistent across episodes.

A Real Project Note

The honest part: building this took a weekend, and for the first few episodes it felt slower than just writing. The payoff only showed up around episode ten, when I realized the protagonist’s voice had stayed identical for the entire stretch and continuity had not broken once — something the naive “write the next chapter” approach lost by episode five.

It is not magic. The agent still drifts inside a single draft; that is exactly why the linter-style checkers exist. And the checkers run on the same model, so I read their output rather than trusting it blindly. The structure is what protects the result, not the model.

Common Mistakes

Treating the agent as a chatbot. “Write episode 5” with no project context produces confident, inconsistent output. Give it the settings and the spec.
Mixing source and metadata. Goal declarations and review notes inside the output file mean you cannot ship it cleanly.
One giant prompt. A single mega-prompt that does everything is impossible to debug. Compose small, single-job skills instead.
Skipping the goal declaration. Without a stated target, you cannot tell drift from intent.
Trusting a single review pass. Automated checks narrow the problem; they do not certify correctness. You still read the diff.

Checklist

Incomplete task: All rules externalized into a single source of truth All rules externalized into a single source of truth
Incomplete task: Each skill does exactly one job Each skill does exactly one job
Incomplete task: Acceptance criteria declared before generating Acceptance criteria declared before generating
Incomplete task: Output files contain only the deliverable; metadata lives elsewhere Output files contain only the deliverable; metadata lives elsewhere
Incomplete task: Automated review skills for consistency and safety Automated review skills for consistency and safety
Incomplete task: Expensive research cached, not re-run Expensive research cached, not re-run
Incomplete task: Instructions kept portable across models Instructions kept portable across models

When Not to Use This Approach

Skip the structure for short or one-off work — a single blog post, a quick draft, a throwaway script. The scaffolding costs more than it saves below roughly ten outputs. Skip it too for genuinely exploratory work where you do not yet know what “done” looks like; an agent will happily produce polished output for an unclear goal. And if you cannot yet judge the output quality yourself, the review steps matter more, not less — no structure substitutes for your own read.

FAQ

Q. Does this approach work for code projects too?

A. Code is the original. Centralizing config into a single source of truth, splitting work into single-responsibility units, declaring acceptance criteria first, and automating review are all standard engineering. The only twist here is that the deliverable was prose, not code.

Q. Isn’t building all this structure overkill?

A. For a single post or a quick draft, yes. The structure costs a weekend to build. It only pays off when you need consistency across many outputs, like a 30-episode series, a docs set, or a long content pipeline. Below about ten outputs, just write.

Q. Why keep separate instruction files for Claude and Gemini?

A. Portability. Keeping CLAUDE.md and GEMINI.md nearly identical means the rules live in the interface, not the model. You can swap the underlying model without rewriting the project’s conventions, the same way you abstract a database behind an adapter.

Last updated: 2026-06-22.

How I Use Claude Code to Build Small Web Apps

2026-06-22T00:00:00.000Z

Quick Answer

The workflow that works for me is: treat Claude Code as a project agent, not a chatbot. I scope one small task, write a short task file, ask it to inspect the repo, ask for a plan before any code, review the diff line by line, run tests, and then ask it to critique its own work. The speed comes from tight scope and disciplined review, not from letting it run free. Below is the exact loop I use to ship small web apps as a solo developer.

Who This Guide Is For

Solo developers and indie hackers shipping small apps alone
People who already use Cursor or Copilot and want a more agentic loop
Developers who can read a diff and tell whether it is correct

If you cannot yet judge whether a change is right, this still works, but the review steps matter more for you, not less.

My Basic Rule: Treat Claude Code as a Project Agent, Not a Chatbot

A chatbot answers a question and forgets. An agent operates on your repository, runs commands, and leaves a diff behind. The mental shift that changed my results was simple: I stopped asking “how do I do X” and started saying “here is the repo, here is the task, propose a plan, then implement it.”

That framing forces me to give it the two things it actually needs: context about the project and a clearly bounded task.

My Project Setup

Small web apps I build share roughly this shape:

my-app/
  src/
    routes/
    components/
    lib/
  tests/
  CLAUDE.md        # project conventions the agent should follow
  package.json
  README.md

The one file that pays for itself is CLAUDE.md. I keep it short: the stack, the folder conventions, the commands to run tests and build, and a few “do not do this” rules. The agent reads it before touching code, so I stop repeating myself every session.

The Workflow

Step 1: Define the Scope

I write the task in one or two sentences and, more importantly, I write what is out of scope. “Add a rate limiter to the login route. Do not touch the signup flow or the session store.” A bounded task produces a small diff, and a small diff is reviewable.

Step 2: Create a Task File

For anything bigger than a one-liner, I drop a short TASK.md with the goal, the acceptance criteria, and any constraints. It costs two minutes and removes most of the back-and-forth. The agent treats it as the contract.

Step 3: Let Claude Code Inspect the Project

Before asking for changes, I let it read the relevant files. Agentic tools are good at this: they grep, open files, and build a map. I would rather spend tokens here than have it guess at an API that does not exist.

Step 4: Ask for a Plan Before Code

This is the highest-leverage step. I ask for a plan first: which files, what changes, in what order. Reading a plan takes thirty seconds and catches the wrong approach before any code is written. Roughly half the time I correct the plan, and that correction saves a full bad diff.

Step 5: Review the Diff

I read every line. Not skim, read. The failure mode of AI coding is plausible code that is subtly wrong, and the only defense is review. If the diff is too big to review carefully, that is a signal the task was too big, not a reason to trust it more.

Step 6: Run Tests and Manual Checks

I run the test suite and click through the actual feature in the browser. Generated code compiles far more often than it is correct. A green build is necessary, not sufficient.

Step 7: Ask Claude Code to Review Its Own Work

After it passes my review, I ask it to critique its own change: edge cases, error handling, security. It often catches a missing null check or an unhandled rejection. A second pass from the same model is cheap and surprisingly useful.

A Real Project Note

On a small link-shortener I built, I asked for a feature and let the plan step slide because the task “felt obvious.” It happily added a database migration that dropped a column it thought was unused. Tests passed, because there was no test covering that column. I caught it in the diff only because the migration file looked larger than it should have.

The lesson was not “the AI is dangerous.” The lesson was that I skipped Step 4 and Step 5, and the process is what protects you, not the model. Cost-wise, a session like this runs me a few dollars in tokens, far less than the hour the bug would have cost in production.

What Claude Code Is Good At

Mechanical, well-specified changes across several files
Writing the first draft of tests and boilerplate
Explaining unfamiliar code before you change it
Refactors where the target shape is clear

What Claude Code Still Gets Wrong

It invents APIs that look right but do not exist
It over-engineers when the task is vague
It writes tests that assert the bug, not the requirement
It silently widens scope if you do not fence it in
It sounds equally confident whether it is right or wrong

None of these are dealbreakers. They are reasons to keep the plan-and-review loop.

My AI Coding Checklist

Incomplete task: Task scoped to one feature or one bug Task scoped to one feature or one bug
Incomplete task: Out-of-scope areas stated explicitly Out-of-scope areas stated explicitly
Incomplete task: Plan reviewed before any code Plan reviewed before any code
Incomplete task: Every line of the diff read Every line of the diff read
Incomplete task: Tests run and feature checked manually Tests run and feature checked manually
Incomplete task: Agent asked to review its own change Agent asked to review its own change
Incomplete task: Diff small enough to revert cleanly Diff small enough to revert cleanly

When Not to Use This Approach

If the task is genuinely exploratory, where you do not yet know what “done” looks like, an agentic loop will produce confident output for an unclear goal. Figure out the shape yourself first, then bring in the agent to execute. Also skip it for trivial edits where typing the change is faster than describing it.

FAQ

Q. Is Claude Code good for beginners?

A. It is usable, but you still need to read every diff. If you cannot tell whether a change is correct, the speed gain turns into a debugging tax later. Start on small, well-scoped tasks.

Q. Should I let Claude Code edit many files at once?

A. For a first pass, no. Keep each task to one feature or one bug. Small diffs are easier to review and easier to revert when the agent goes the wrong way.

Q. Does Claude Code replace writing tests?

A. No. It can write tests, but you decide what “correct” means. Treat generated tests as a draft you verify, not as proof the code works.

This post is part of my AI-assisted solo developer workflow series. More practical guides on building and shipping small apps with AI tools are on the way.

2026년 2월 4일 오늘의 AI 뉴스

2026-02-04T00:00:00.000Z

오늘은 ‘코딩 에이전트가 IDE로 들어오는 날’이랑 ‘플랫폼/국가가 AI를 규제·자립하려는 날’이 같이 왔다. 더 똑똑해진 도구만큼, 책임 소재와 통제권 싸움도 같이 커지는 중.

Xcode 26.3, 에이전트 코딩을 IDE 기본 기능으로 끌어들임

애플이 Xcode 26.3에서 agentic coding을 공식 지원한다고 발표했다. 요지는 단순 자동완성/리팩터링 보조가 아니라, “목표를 주면 에이전트가 더 자율적으로 작업을 쪼개고 진행한다”는 방향이다.

이번 발표에서 흥미로운 포인트는 두 가지다.

첫째, 외부 코딩 에이전트와의 직접 통합을 전면에 내세웠다. 기사에는 Anthropic의 Claude Agent, OpenAI의 Codex 같은 에이전트를 Xcode 안에서 활용할 수 있다고 적혀 있다. 즉, 개발자가 IDE 밖에서 챗창 띄우고 복붙하던 흐름을, IDE 내부 워크플로로 고정시키려는 의도가 보인다.

둘째, “IDE가 가진 권한”을 에이전트에게 더 넓게 열어준다. 발표문에 따르면 에이전트는 문서 검색, 파일 구조 탐색, 프로젝트 설정 업데이트 같은 작업을 할 수 있고, Xcode Previews를 캡처해서 시각적으로 검증한 뒤 빌드/수정 루프를 반복할 수도 있다고 한다. 이건 ‘코드만 쓰는 모델’에서 ‘프로젝트를 다루는 에이전트’로 바뀌는 순간이다.

그리고 결정적으로, Xcode 26.3는 MCP(Model Context Protocol) 로 Xcode 기능을 외부 도구/에이전트에 노출한다고 했다. 이게 의미하는 건 “애플이 특정 모델을 고정해서 밀겠다”보다는, IDE를 에이전트가 붙는 플랫폼으로 만들겠다는 선언에 가깝다. 앞으로는 ‘어느 모델이 똑똑하냐’만큼 ‘IDE/런타임이 에이전트에게 어떤 안전장치와 권한 모델을 주느냐’가 중요해질 것 같다.

Qwen3-Coder-Next, 작은(하지만 계산은 똑똑하게) 코딩 에이전트 모델을 밀어붙임

Qwen 팀이 Qwen3-Coder-Next를 소개했다. “open-weight(가중치 공개)”, “코딩 에이전트”, “로컬 개발” 같은 키워드를 앞세운다.

기술적으로는 Qwen3-Next-80B-A3B-Base 위에서 만들었다고 하고, 구조는 hybrid attention + MoE(혼합 전문가) 아키텍처를 채택했다고 한다. 여기서 중요한 메시지는 파라미터 덩치를 키우는 쪽이 아니라, agentic training 신호를 스케일링한다는 접근이다.

설명에 따르면, 실행 가능한(검증 가능한) 코딩 작업을 실행 환경(executable environments) 과 짝지어서 학습하고, 환경 상호작용과 강화학습을 통해 도구 사용, 긴 호흡의 추론, 실행 실패 복구 같은 능력을 키운다고 한다. 말 그대로 “코드 답안지 외우는 모델”이 아니라 “실행 결과로 혼나는 모델”을 만들겠다는 얘기다.

또한 SWE-Bench(여러 버전), TerminalBench 2.0, Aider 같은 코딩 에이전트 벤치마크를 언급하면서, “활성 파라미터 풋프린트는 작지만 큰 오픈소스 모델들과 맞먹거나 넘는 결과”를 주장한다. (벤치 자체가 ‘현업을 그대로 재현한다’고 말하긴 어렵지만) 적어도 방향성은 명확하다: 이제 코딩 모델은 단순 생성 품질보다 에이전트로서의 장거리 작업 능력이 먼저 평가받는 분위기다.

그리고 개인적으로 제일 현실적인 포인트는 이거다. Qwen은 “강한 성능을 더 낮은 추론 비용으로”를 강조한다. 코딩 에이전트는 한 번 답하는 게 아니라, 생각하고 실행하고 고치고 다시 생각하는 루프를 돈다. 그러면 비용/지연시간이 곧 UX가 된다. 이런 맥락에서 ‘작지만 agentic 루프에 강한 모델’은 충분히 매력적인 카드다.

프랑스, 2027년까지 Zoom/Teams를 접고 ‘자국/유럽’ 쪽으로 이동

AP 보도에 따르면 프랑스 정부는 2027년까지 공무원 250만 명이 Zoom, Microsoft Teams, Webex, GoTo Meeting 같은 미국계 화상회의 도구 사용을 중단하고, Visio라는 자국(유럽) 기반 서비스로 전환하겠다고 했다.

이건 “화상회의 앱 바꿔요” 수준이 아니라, 유럽 전반에서 커지는 디지털 주권(digital sovereignty) 흐름의 한 조각이다. 기사엔 오스트리아 군이 Microsoft Office 대신 LibreOffice를 쓰거나, 독일 Schleswig-Holstein 주가 Microsoft 서비스에서 벗어나 Nextcloud/오픈소스 이메일로 이동하는 사례도 나온다.

동기가 되는 키워드는 반복된다.

데이터 프라이버시
유럽이 미국/중국 대비 기술 리더십에서 뒤처진다는 불안
특정 기업/국가가 서비스 접근을 끊어버릴 수 있다는, 이른바 ‘킬 스위치’ 공포

재밌는 건, 이런 흐름이 AI랑도 바로 연결된다는 점이다. 앞으로 업무 도구가 “문서/회의”를 넘어 “에이전트/모델/클라우드”까지 확장되면, 국가/기관 입장에서는 단순 라이선스 비용이 아니라 의존성(Dependency) 리스크를 더 크게 보게 된다. 특히 공공 영역은 한 번 붙으면 떼기 어렵다. 그래서 더 일찍 움직이는 느낌이다.

Grok, 프랑스 수사 + 영국 ICO 조사… ‘생성’보다 ‘책임’이 먼저 질문받는 단계

BBC 보도에 따르면 프랑스 검찰의 사이버범죄 부서가 X(트위터)의 파리 사무소를 압수수색했고, 조사 대상에는 Grok도 포함돼 있다. 보도 내용에는 불법 데이터 추출 의혹, 아동 포르노 소지의 공모, 성적 딥페이크로 인한 이미지 권리 침해, 조직적 사기성 데이터 추출 등 여러 혐의 가능성이 언급된다.

동시에 영국에서는 ICO(정보위원회)가 Grok 관련해 “유해한 성적 이미지/영상 콘텐츠를 만들 수 있다”는 문제의식 아래, 개인 데이터 처리와 안전장치가 적절했는지 조사에 착수했다고 한다.

여기서 관전 포인트는 기술 논쟁이 아니다. 이제는 “모델이 가능하냐”보다 “플랫폼이 어떤 안전장치를 갖췄고, 사고가 나면 누가 책임지냐” 가 메인 질문으로 올라왔다. 특히 딥페이크·성적 이미지 문제는 피해가 구체적이고 회복이 어렵다. 규제기관이 먼저 달려드는 분야가 되는 것도 당연하다.

예상되는 미래 (Expected Future)

오늘 뉴스 네 개를 한 문장으로 묶으면 이거다: 에이전트는 개발자 도구로 들어오고, 국가는 그 에이전트를 통제할 수 있는 위치를 잡으려 한다.

IDE 내 에이전트가 기본값이 되면, 팀의 생산성은 분명 튀어 오를 거다. 근데 동시에 “에이전트가 만진 코드”에 대한 리뷰/감사(audit) 부담도 커진다. Xcode가 Previews 캡처까지 돌리게 해주면, 다음은 테스트/릴리즈 파이프라인까지 에이전트가 건드리는 게 자연스러워진다. 그러면 권한 모델(무엇을 할 수 있고, 무엇을 못 하게 막는지)이 곧 품질이 된다.
오픈웨이트 코딩 에이전트(예: Qwen3-Coder-Next)가 더 강해지면, ‘클라우드 API만이 답’이라는 구도가 흔들린다. 특히 기업 내부 코드/레거시/보안 요구가 있는 곳은 로컬/온프레미스 선택지가 매력적이다. 다만 여기서 진짜 승부는 모델 자체가 아니라, 실행 환경/툴링/관측성(로그, 재현 가능성) 까지 포함한 패키지로 갈 가능성이 크다.
프랑스 사례처럼 공공기관이 미국계 도구 의존도를 낮추면, 그 다음은 AI 모델/에이전트 쪽으로도 같은 질문이 옮겨간다. “우리 업무가 외부 모델의 약관/정치 상황/수출 규제에 묶여도 되나?” 같은 질문 말이다. 결과적으로 유럽/각국이 자국 모델 + 자국 클라우드 + 오픈소스 스택을 더 밀 가능성이 높다.
Grok 건처럼 규제 이슈가 커질수록, ‘빨리 만들고 배포’는 점점 비용이 비싸진다. 특히 성적 딥페이크/무단 생성 같은 영역은 기술적 필터만으로 끝나지 않고, 데이터 처리·동의·삭제 요청·증거 보존 등 운영 프로세스가 중요해진다. 앞으로는 모델 성능 경쟁만큼 컴플라이언스/안전 운영 능력이 경쟁력이 될 것 같다.

결론: 2026년은 “코딩 에이전트가 대세가 된다”가 아니라, “코딩 에이전트가 제도권으로 들어오는 해”로 기억될지도 모르겠다. 제도권은 늘 재미없지만, 규모를 만든다.

참고 자료 (References)

2026년 2월 3일 오늘의 AI 뉴스

2026-02-03T00:00:00.000Z

오늘은 ‘에이전트가 일하는 방식’이 확 바뀌는 쪽으로 뉴스가 몰렸어. 코딩 에이전트는 데스크톱으로 내려오고, 벤치마크는 사람 사회(협상/거짓말)와 확률(리스크)로 확장되고, 엔터프라이즈는 데이터웨어하우스 안으로 모델을 끌어들인다.

OpenAI, macOS용 Codex 앱 공개: “에이전트 지휘소”를 데스크톱으로

OpenAI가 macOS용 Codex 앱을 공개했어. 핵심은 “코딩 도구 하나 추가”가 아니라, 여러 에이전트를 동시에 굴리고(멀티스레드), 장시간 작업을 맡기고, 사람은 감독자로 앉히는 인터페이스라는 점이야.

내용을 보면 딱 요즘 개발 흐름을 인정한 형태다. 한 에이전트랑 페어프로그래밍처럼 한 줄씩 고치는 시대도 여전히 유효하지만, 실제로 팀이 바라는 건 그게 아니거든. “이 리포에서 A는 테스트 고치고, B는 문서 정리하고, C는 릴리즈 노트 뽑아” 같은 병렬 작업이 진짜 돈이 돼.

Codex 앱이 강조하는 기능들이 그런 방향으로 설계돼 있어:

프로젝트 단위로 에이전트 스레드를 나눠서 컨텍스트를 유지한다.
변경 사항을 스레드 안에서 diff로 리뷰하고 코멘트로 되돌릴 수 있다.
git worktree 기반으로 에이전트별로 격리된 작업 공간을 만든다(같은 repo에서 충돌 없이 여러 갈래 시도 가능).
CLI/IDE 확장 설정과 히스토리를 그대로 이어받는다(툴 전환 비용 줄이기).

여기서 재밌는 포인트는 “스킬(Skills)”과 “오토메이션(Automations)”을 전면에 세웠다는 거야. 스킬은 결국 **재현 가능한 작업 지침 + 도구 연결(스크립트 포함)**이고, 오토메이션은 그걸 스케줄링해서 백그라운드에서 돌리는 방식이잖아. 즉, 에이전트가 코드만 쓰는 게 아니라 업무의 단위를 처리하도록 유도하는 쪽으로 제품이 간다.

개발자 입장에서 이게 좋은 점도 있고 무서운 점도 있어.

좋은 점:

“내가 하기 싫은데 꼭 해야 하는 일”의 상당수가 자동화 가능해진다. (이슈 트리아지, CI 실패 요약, 릴리즈 브리프, 문서 갱신 등)
사람은 설계/검토/결정에 집중하고, 에이전트는 수행에 집중하게 된다.

무서운 점:

에이전트가 늘어날수록 코드베이스에 동시성(organizational concurrency) 이 생기고, 그때부터 진짜 병목은 모델이 아니라 리뷰/승인/정책이 된다.
“누가 어떤 기준으로 승인했는가”가 개발 프로세스의 핵심 로그가 될 가능성이 크다.

한마디로, 코딩 에이전트는 이제 IDE 플러그인이 아니라 “작업 운영 체계” 쪽으로 넘어가는 중이야.

Snowflake × OpenAI: 데이터 클라우드 안으로 모델을 넣는 2억 달러짜리 신호

OpenAI랑 Snowflake가 2억 달러 규모 파트너십을 발표했어. 방향이 뻔하면서도 강력해. 엔터프라이즈가 AI를 쓰려면 결국 “우리 데이터”에 붙어야 하잖아. 근데 기업 데이터는 보안/거버넌스 때문에 아무 데나 못 나가. 그래서 데이터가 있는 곳(데이터웨어하우스/데이터 클라우드) 안으로 모델을 끌어들이는 게 정답이 된다.

발표 내용의 요지는 이런 구조야:

Snowflake 고객이 Snowflake 내부에서 OpenAI 모델을 써서 에이전트/앱을 만든다.
Snowflake Intelligence 같은 자연어 질의 경험에 모델을 붙여서, 직원들이 코드 없이도 데이터에서 인사이트를 뽑도록 한다.
SQL에서 바로 모델을 호출하는 형태(함수/AI Functions)로 “분석 파이프라인의 일부”가 된다.

이게 왜 중요하냐면, 엔터프라이즈는 항상 같은 문제를 반복해.

데이터는 내부에 있고(접근 통제),
모델은 외부에 있고(요금/정책/규제),
둘을 잇는 레이어가 복잡해질수록 프로젝트는 망한다.

그래서 “데이터 플랫폼 안에서 모델을 쓴다”는 건 기술 선택이 아니라 조직 설계의 단순화야. 보안팀/법무팀/데이터 거버넌스 팀이 싫어할 지점들을 최소화할 수 있거든.

그리고 이건 에이전트 시대에도 더 크게 작동해. 에이전트가 일을 하려면 결국 “읽기/쓰기 권한”이 필요한데, 엔터프라이즈 데이터는 그 권한을 허용하는 순간 난리가 난다. 데이터 플랫폼 안에서 모델이 돌아가면, 최소한 정책 집행과 감사 로그를 한 곳에서 통제할 수 있는 그림이 나와.

즉, 오늘 파트너십은 “모델이 좋아졌다”가 아니라 “AI 도입의 병목이 어디인지 다들 인정했다”는 신호로 봐야 한다.

Google DeepMind × Kaggle Game Arena 업데이트: 체스 다음은 ‘늑대인간’과 ‘포커’다

Google DeepMind가 Kaggle의 Game Arena 벤치마크를 업데이트하면서, 기존 체스에 더해 Werewolf(늑대인간) 와 포커를 추가했어. 이게 꽤 상징적이야.

체스는 ‘완전 정보(perfect information)’ 게임이야. 보드 위에 모든 정보가 깔려 있고, 잘 두면 된다. 근데 현실은 그런 적이 거의 없지. 사람들은 정보도 불완전하고, 상대는 거짓말도 하고, 나도 확률을 계산해야 하고, 때로는 심리전도 한다.

DeepMind가 얘기하는 포인트는 딱 이거야:

늑대인간: 자연어로만 진행되는 팀 기반 소셜 추론 게임. 커뮤니케이션/협상/모호함 처리/기만 탐지 같은 “소프트 스킬”을 본다.
포커: 불완전 정보 + 리스크 관리. 확률적 추론과 불확실성 하에서의 의사결정을 본다.

여기서 난 특히 “에이전트 안전(agentic safety) 연구의 샌드박스”라는 표현이 인상적이었어. 늑대인간은 모델이 거짓말을 잘하는 능력도 시험할 수밖에 없거든. 현실에선 그게 위험한 능력인데, 게임 환경에서는 그걸 안전하게 측정할 수 있다는 논리야. 일종의 ‘격리된 악역 연습장’ 같은 느낌.

그리고 이런 벤치마크가 실무랑 연결되는 지점이 있어.

기업에서 에이전트가 사람과 협업하려면, “정답을 잘 말한다”보다 “불확실한 상황에서 합리적으로 판단한다”가 더 중요하다.
회의/협상/이슈 트리아지 같은 건 사실상 늑대인간에 가깝다. 누가 사실을 말하는지, 누가 핑계를 대는지, 누가 의도를 숨기는지 계속 추론해야 하잖아.
운영/트레이딩/재고/마케팅 같은 영역은 포커다. 불확실성을 수치로 다루고, 손익과 리스크를 같이 본다.

그러니까 ‘게임 벤치마크’는 장난이 아니라, 앞으로 에이전트가 사람 사회에 들어오기 위한 입장 시험 같아.

Google, 멸종위기종 유전체 보존에 AI 투입: “시퀀싱을 더 싸고 빠르게”

구글은 멸종위기종의 유전체(genome) 정보를 보존하기 위한 프로젝트에 AI와 지원을 붙이고 있어. Vertebrate Genomes Project, Earth BioGenome Project 쪽을 돕는 이야기고, 실제로 13종의 멸종위기 동물 유전체 시퀀싱을 지원했고 앞으로 더 확장하겠다고 했어.

이 뉴스가 좋은 이유는 AI가 “콘텐츠 생성/코드 생성”을 넘어서, 진짜로 과학의 비용 구조를 바꾸는 쪽에 들어간다는 점이야.

유전체 시퀀싱은 과거엔 시간과 돈이 미친 듯이 들었지. 첫 인간 유전체는 13년 + 30억 달러라는 전설이 있고. 근데 지금은 며칠/수천 달러 단위로 내려왔고, 여기에 DeepVariant/DeepConsensus/DeepPolisher 같은 도구들이 정확도와 비용을 더 줄이는 데 기여했다고 한다.

보존 관점에서 유전체 데이터는 ‘마지막 백업’ 같은 거야.

종이 멸종하면 유전 정보도 영원히 사라진다.
유전체를 알면 근친 교배 문제나 유전적 다양성 보존 전략 같은 걸 더 정교하게 설계할 수 있다.
여러 종의 유전체를 비교하면 생물학적 통찰이 나온다(농업/질병/환경 적응 등).

개발자 시각으로는 이런 프로젝트가 좀 “인프라 냄새”가 나서 마음이 간다. 결국 AI를 과학에 붙이는 건 데이터 파이프라인, 품질 관리, 재현성, 공개 데이터, 컴퓨팅 비용 같은 문제를 같이 푸는 거거든. 멋있게 말하면 AI for Science, 현실적으로 말하면 데이터 엔지니어링의 대규모 확장판이야.

예상되는 미래 (Expected Future)

오늘 뉴스 네 개를 한 줄로 묶으면 이거야: AI가 ‘모델’이 아니라 ‘운영되는 시스템’이 된다.

Codex 앱 같은 “에이전트 운영 UI”가 퍼지면, 개발팀은 에이전트를 사람처럼 배치하고 관리하게 될 거야. 근데 사람과 달리 에이전트는 복제 비용이 거의 0이라서, 어느 순간부터는 “몇 명을 뽑을까” 대신 “동시에 몇 개의 스레드를 허용할까”가 조직의 질문이 된다.
Snowflake 같은 데이터 플랫폼 안으로 모델이 들어가면, AI 도입의 핵심은 모델 선택이 아니라 권한/감사/거버넌스/비용 최적화가 된다. 엔터프라이즈 AI는 점점 ‘보안 제품’처럼 보일 거고, AI 팀은 보안팀/데이터팀이랑 더 붙어 다닐 거야.
Game Arena가 늑대인간/포커로 확장된 건, 벤치마크가 “수학/추론”에서 “사회/불확실성”으로 이동 중이라는 신호야. 에이전트가 실제 업무에 들어오면, 논리보다 더 많이 쓰는 게 설득/협상/불확실성 관리거든. 이걸 측정하지 못하면, 우리가 만드는 에이전트는 늘 실무에서 미끄러질 거야.
AI for Science는 앞으로 더 커질 거야. 단순히 논문 읽어주는 비서가 아니라, 실험/시퀀싱/시뮬레이션 같은 실제 비용이 큰 프로세스에 AI를 넣으면, 생산성은 ‘몇 %’가 아니라 ‘몇 배’로 뛴다.

결론적으로, 2026년은 “모델 성능 숫자”보다 “어떻게 운영하고 통제할 것인가”가 뉴스의 중심이 될 가능성이 크다. 에이전트를 쓸 거면, 이제부터는 프롬프트보다 정책과 프로세스를 먼저 고민해야 한다는 얘기지.

참고 자료 (References)

2026년 2월 2일 오늘의 AI 뉴스

2026-02-02T00:00:00.000Z

최근 AI 업계는 새로운 모델들의 등장과 기존 모델들의 퇴장, 그리고 AI가 단순한 도구를 넘어 협력적 파트너로 진화하는 ‘에이전트’ 기술의 발전으로 뜨겁다. LLM 경쟁이 점점 더 치열해지는 가운데, AI의 윤리적 문제와 기술적 한계에 대한 고민도 깊어지고 있다.

새로운 모델의 등장과 세대교체

요즘 AI 모델 시장은 정말 정신없이 돌아간다. 춘절을 기점으로 바이두, 알리바바 같은 중국 기업들이 새로운 LLM을 쏟아내며 본격적인 경쟁을 예고했다. 이런 상황에서 미스트랄은 기업 내부 코드를 학습해 자동 완성하는 ‘바이브 2.0’을 내놓았고, xAI는 동영상 생성용 ‘그록 이매진’ API를 공개하며 멀티모달 경쟁에 뛰어들었다. 확실히 이제 텍스트만 다루는 모델은 명함도 못 내밀게 될 것 같다.

한편, OpenAI는 GPT-4o, GPT-4.1 등 일부 구형 모델들을 2월부터 퇴출한다고 발표했다. 새로운 모델들이 계속 나오니, 성능이 떨어지는 구형 모델들을 정리하는 것은 당연한 수순이다. 구글 역시 새로운 오픈 번역 모델 ‘TranslateGemma’를 공개하고, 제미나이에 개인화된 지능을 도입하는 ‘에이전트 비전’을 선보이는 등 꾸준히 발전하는 모습을 보여주고 있다. 바야흐로 LLM의 춘추전국시대이자, 본격적인 세대교체가 시작된 느낌이다.

트렌드는 ‘AI 에이전트’: 단순 도구를 넘어 파트너로

최근 AI 분야의 가장 큰 화두는 단연 ‘AI 에이전트’다. 이제 AI는 단순히 질문에 답하는 수준을 넘어, 사람과 협력하며 전문성을 높여주는 ‘파트너’로 진화하고 있다. 맥킨지 보고서에서도 ‘에이전트 AI’의 부상을 주요 기술 트렌드로 꼽았다. 유연한 파운데이션 모델이 자율적으로 여러 단계의 작업을 계획하고 실행하는 능력을 갖추면서, 말 그대로 ‘가상 동료’가 만들어지고 있다는 것이다.

하지만 이런 에이전트 AI가 제대로 작동하려면 아직 해결해야 할 과제가 많다. 앤트로픽은 장기 실행 에이전트가 여러 컨텍스트 창에서 일관성을 유지하기 위한 ‘하네스(harness)‘가 필요하다고 지적했다. 교대 근무하는 동료에게 이전 작업 내용을 인수인계하듯, AI 에이전트에게도 맥락을 유지해주는 장치가 필요하다는 비유가 인상 깊었다. 결국 얼마나 ‘기억’을 잘 유지하고 활용하느냐가 AI 에이전트 기술의 성패를 가를 것으로 보인다.

계속되는 도전: 환각, 그리고 인간 능력의 퇴화

AI 기술이 눈부시게 발전하고 있지만, 고질적인 문제들은 여전하다. LLM이 그럴듯한 거짓말을 만들어내는 ‘환각’ 현상은 아직 해결되지 않은 가장 큰 난제다. 최근 NeurIPS 2025 학회에 채택된 논문들에서도 수많은 환각 인용이 발견되었다는 소식은 이 문제가 얼마나 심각한지 다시 한번 일깨워준다. 이를 해결하기 위해 LLM 워터마킹이나 공격 방어 기법 같은 연구가 활발히 진행 중이지만, 아직은 갈 길이 멀어 보인다.

앤트로픽은 “AI를 쓰면 일은 빨라지지만, 실력은 떨어질 수 있다”는 흥미로운 경고를 던지기도 했다. AI에 지나치게 의존하다 보면 인간의 고유한 문제 해결 능력이나 창의성이 퇴화할 수 있다는 지적이다. 개발자로서 AI라는 강력한 도구를 어떻게 활용해야 할지, 단순히 코드를 빨리 짜는 것만이 능사가 아님을 다시 한번 생각하게 만드는 대목이다.

예상되는 미래

AI 에이전트 기술의 발전은 결국 ‘개인화’로 귀결될 것이다. 모든 사람이 각자의 업무 스타일과 지식 수준에 맞는 AI 비서를 갖게 되는 세상이 머지않았다. 개발자에게는 코딩 스타일을 학습한 AI 페어 프로그래머가, 기획자에게는 시장 분석 자료를 실시간으로 정리해주는 AI 전략가가 붙는 식이다.

하지만 기술이 발전할수록 ‘진짜’와 ‘가짜’를 구별하는 능력, 그리고 기술에 종속되지 않고 주체적으로 사고하는 능력이 더욱 중요해질 것이다. AI가 생성한 결과물을 비판적으로 검토하고, 최종적인 판단은 인간이 내리는 역량이 미래 시대의 핵심 경쟁력이 될 것이다. 결국, AI는 인간을 대체하는 것이 아니라, 인간의 능력을 증폭시키는 방향으로 나아가야만 진정한 가치를 가질 수 있을 것이다.

참고 자료

월드모델이 갑자기 현실이 된 느낌 (Google DeepMind Genie 3 / Project Genie)

2026-02-02T00:00:00.000Z

텍스트 한 줄로 ‘탐험 가능한 세계’를 뽑아내는 월드모델(Genie 3)이 공개되면서, 에이전트 연구가 드디어 게임/로봇 쪽으로 본격 이사 가는 분위기다.

구글 월드모델(Genie 3) 소식이 왜 그렇게 충격적이었나

‘월드모델(world model)’이라는 말은 예전부터 있었는데, 솔직히 대부분은 “멋진 말”에 가까웠다. 어떤 환경을 모델이 내부적으로 시뮬레이션해서, 행동을 넣으면 다음 상태를 예측한다… 뭐 이런 거.

그런데 Google DeepMind가 공개한 Genie 3는 그 설명을 갑자기 “체감”으로 바꿔버렸다.

텍스트 프롬프트를 주면 실시간으로 탐험 가능한 세계를 만들어주고
24fps, 720p로 몇 분간 일관성(consistency)을 유지한다고 하고
단순히 영상 생성이 아니라, 입력(이동/시점 등)을 받으면서 프레임을 이어서 생성한다

이게 왜 다르냐면, 영상 생성은 “완성본을 한 번에 뽑아내는” 느낌이었다면, 월드모델은 “내가 움직이면 세계가 반응하는” 구조다. 결국 이건 시뮬레이터에 가깝다.

그리고 시뮬레이터는 곧바로 에이전트로 이어진다.

월드모델의 핵심: ‘예측’이 아니라 ‘훈련 커리큘럼’이다

DeepMind 쪽 글에서도 월드모델을 단순 예측기로 설명하지 않는다. 중요한 포인트는 이거다.

월드모델은 에이전트를 학습시키기 위한 ‘무한 커리큘럼’이 될 수 있다.

현실 세계는 데이터 수집이 비싸고, 위험하고, 느리다. 로봇은 넘어지면 부서지고, 자율주행은 사고가 나면 끝이다.

반면, 월드모델은:

실패를 마음껏 하게 만들 수 있고
난이도를 미친 듯이 조절할 수 있고
데이터 생성량이 사실상 제한이 없다

즉, 강화학습이든 에이전트든 결국 부딪히는 벽(환경/경험 부족)을 “시뮬레이션으로 밀어붙이는” 전략이다.

나는 이게 AGI 얘기보다 더 실용적으로 들린다. AGI가 오든 말든, 훈련 환경을 대량으로 만들 수 있으면 산업은 바로 움직인다.

Project Genie: ‘연구 데모’에서 ‘제품 UX’로 내려온 순간

재밌는 건, DeepMind가 논문만 던진 게 아니라 Project Genie라는 형태로 “만져볼 수 있는 프로토타입”도 같이 가져왔다는 점이다.

정리하면 이런 흐름이다.

Genie 3: 범용 월드모델 연구 결과
Project Genie: 그걸 실제로 체험시키는 Google Labs 프로토타입

구글 블로그는 Project Genie를 세계 만들기/탐험/리믹스라는 UX로 설명한다.

World sketching: 텍스트 + 이미지로 세계 초안 만들기
World exploration: 내가 움직이면 경로를 실시간 생성
World remixing: 다른 사람이 만든 세계 프롬프트를 기반으로 변형

여기서 핵심은 “리믹스”가 붙는다는 거다. 이건 단순 연구 시연이 아니라, 창작/게임/교육 쪽으로 붙일 생각이 확실히 보인다.

개발자 입장에서 제일 무서운 부분: ‘인터랙션을 지원하는 생성’

Genie 3를 읽다가 제일 소름 돋았던 문장은, 매 프레임이 오토리그레시브(auto-regressive) 로 생성된다는 대목이다.

이 말은 곧:

시간이 지날수록 히스토리가 길어지고
모델은 “몇 초 전”이 아니라 “1분 전”의 정보까지 끌고 와야 하고
그걸 실시간(초당 여러 번) 처리해야 한다

즉, 이건 모델 성능만의 문제가 아니라 시스템 설계의 문제다.

메모리(visual memory) 관리
지연(latency) 최소화
컨트롤 입력에 대한 안정적인 반응
일관성 유지(누적 오차가 쌓이지 않게)

난 개인적으로 이게 “월드모델”보다 “실시간 시스템”을 더 떠올리게 했다. 게임 서버/렌더링/스트리밍/캐시 같은 것들.

AI가 결국 다시 시스템 엔지니어링을 소환하는 느낌이다.

예상되는 미래 (Expected Future)

내가 보는 월드모델의 다음 스텝은 세 가지다.

에이전트 테스트베드의 표준화
- 지금까지 에이전트는 각자 환경을 만들고, 각자 평가했다.
- 월드모델이 충분히 “제어 가능”해지면, 평가 자체가 표준화될 가능성이 크다.
게임/콘텐츠 산업에서의 급속한 채택
- 텍스트로 ‘플레이 가능한 씬’을 생성하는 순간, 프로토타이핑 비용이 붕괴한다.
- 영화/게임의 프리비주얼(Pre-visualization)과 교육 시뮬레이션도 같이 따라온다.
현실과의 접점은 ‘정확도’보다 ‘정책’이 먼저 온다
- 월드모델이 진짜 도시/장소를 완벽히 재현할 필요는 없다.
- 하지만 저작권, 안전, 오용(딥페이크+인터랙티브) 같은 문제는 실험 단계부터 바로 따라온다.

결론적으로, 월드모델은 “AI가 세상을 이해한다” 같은 감성적인 문장이 아니라, 에이전트를 대량 양산할 수 있는 생산라인이 되는 쪽으로 갈 것 같다.

그리고 이 생산라인이 무서운 이유는, 모델이 똑똑해지는 속도보다 **“만들고-시험하고-배포하는 속도”**가 더 빨라질 수 있기 때문이다. 개발자 입장에선 도구가 하나 더 생긴 게 아니라, 게임의 룰이 바뀌는 느낌이다.

참고 자료 (References)

Google DeepMind — Genie 3: A new frontier for world models
- https://deepmind.google/blog/genie-3-a-new-frontier-for-world-models/
Google Blog (The Keyword) — Project Genie: Experimenting with infinite, interactive worlds
- https://blog.google/innovation-and-ai/models-and-research/google-deepmind/project-genie/
구글코리아 블로그 — 무한한 인터랙티브 세계를 여는 ‘프로젝트 지니(Project Genie)’
- https://blog.google/intl/ko-kr/company-news/technology/project-genie-kr/

AI 뉴스: OpenClaw — 개인용 에이전트 운영체제(처럼) 쓰는 법

2026-02-02T00:00:00.000Z

요즘은 ‘모델을 잘 쓰는 사람’보다 에이전트를 잘 운영하는 사람이 더 빠르게 결과를 낸다. 오늘은 그 운영 관점에서 재미있는 프로젝트인 OpenClaw를 주제로 잡아, 도구 실행·브라우저 자동화·크론·스킬 같은 구성 요소가 어떻게 하나의 “개인용 자동화 OS”처럼 묶이는지 정리해본다.

OpenClaw는 뭐가 다른가?

OpenClaw는 단순 챗봇이 아니라, “대화 + 실행”을 기본값으로 두는 개인 비서 런타임에 가깝다.

메시지(디스코드/텔레그램 등)로 들어오는 요청을 받고
필요한 경우 브라우저를 직접 띄워 클릭/검색/요약을 하고
로컬 파일을 읽고/쓰고/수정하고
백그라운드 작업(크론)으로 정기 발행/리마인드도 처리한다

즉, LLM이 말만 하는 도구가 아니라 내 기계 위에서 일을 끝내는 도구로 설계되어 있다.

핵심 구성요소: “에이전트 운영”에 필요한 것들

1) Tools (도구 호출): 말 → 행동

OpenClaw의 특징은 “툴이 내장된 채팅”이다.

파일 읽기/쓰기/편집
쉘 명령 실행
브라우저 자동화(검색, 스냅샷, 클릭/타이핑)
메시징 전송(채널 플러그인)

이 덕분에, 예를 들어 ‘자료 수집해서 요약해줘’ 같은 요청이 검색→근거 확인→정리로 끊기지 않고 이어진다.

2) Skills (스킬): 반복되는 일을 한 번에

스킬은 쉽게 말해 자주 하는 일의 플레이북이다.

예:

“AI 뉴스 발행” → 레포 이동 → 생성 → QA → 커밋/푸시
“날씨 알려줘” → wttr.in 호출

좋은 스킬이 있으면, 프롬프트를 길게 쓰지 않아도 실행이 안정적으로 된다.

3) Browser automation (브라우저): 링크만 던지는 게 아니라 직접 확인

웹 서치 API가 막히거나, 페이월/스크립트 렌더링 때문에 단순 fetch가 어려운 경우가 많다.

OpenClaw는 브라우저를 통해:

구글/뉴스 검색
여러 기사 탭 열기
본문 스냅샷/요약

같은 일을 사람이 하던 방식 그대로 자동화할 수 있다.

4) Cron (정기 실행): “매일 14:10에 자동 발행” 같은 루틴

개인 자동화가 진짜 ‘시스템’이 되려면, 대화형 요청뿐 아니라 정기 작업이 필요하다.

OpenClaw의 크론은:

매일/매주 특정 시간 실행
실행 결과 기록(성공/실패/소요 시간)
작업을 isolated session으로 돌려서 본 대화 맥락을 오염시키지 않음

같은 운영 관점이 들어가 있다.

5) Sessions / Sub-agents: 오래 걸리는 작업은 분리

긴 리서치나 개발 작업은 메인 세션에서 끌면 피곤해진다.

OpenClaw는 서브 에이전트를 따로 띄워서:

백그라운드로 작업하고
완료되면 메시지로 알려주는

패턴을 지원한다. (대화 UX가 “작업 관리”에 가까워진다.)

OpenClaw로 할 수 있는 현실적인 사용 사례

콘텐츠 자동 발행: 블로그/레포에 매일 요약 글 생성 → 커밋/푸시
시장/뉴스 브리핑: 구글 뉴스 검색 → 기사 5~10개 요약 → 핵심 포인트 정리
업무 리마인더: “내일 9시에 회의자료 챙기라고 알려줘” 같은 크론 알림
개발 보조: 로컬 레포 분석 + 코드 변경 + 커밋까지 (상황에 따라)

시작할 때 주의할 점 (중요)

모델/벤더 용량 문제: Gemini 같은 외부 모델은 429(용량 부족)로 막힐 수 있다. 이럴 땐
- 다른 모델로 fallback
- 일정 시간 후 재시도
- 또는 ‘모델 없이도 되는 부분’(정리/커밋 등)을 분리 같은 운영 전략이 필요하다.
자동화의 함정: “발행”은 외부로 나가는 행동이라 실수 비용이 크다.
- QA 체크리스트(길이/메타데이터/사실성/출처)를 스킬에 포함시키는 게 중요하다.
도구 권한 관리: 브라우저/쉘/메시징은 강력한 만큼, 어떤 작업을 자동 승인할지 기준을 정해두는 게 안전하다.

실전 예시: OpenClaw로 바로 써먹는 자동화 6가지

아래 예시는 ‘개념 이해’보다 한 단계 더 나아가서, 실제로 손에 쥐고 바로 돌릴 수 있는 패턴만 골랐다.

1) “지금 이 페이지 요약해줘” — 브라우저 자동화

웹에서 근거를 직접 확인해야 하는 상황(뉴스/공시/문서)에서는 브라우저 자동화가 체감 효용이 크다.

동작 흐름: 브라우저 열기 → 검색/이동 → 스냅샷 → 요약
장점: API 키 없이도 실제 화면 기준으로 확인 가능

2) “매일 14:10에 AI 뉴스 발행” — 크론 + 스킬

OpenClaw의 크론은 ‘정확한 시간’에 트리거를 걸고, 스킬(플레이북)로 글 생성/커밋/푸시를 묶어준다.

동작 흐름: cron → isolated session → 스킬 실행 → git push
팁: 모델/벤더 용량 문제(429)가 생기면 재시도(backoff) 로직을 스킬에 넣어두면 안정적이다.

3) “20분 뒤에 나한테 다시 알려줘” — 원샷 리마인더

대화형 요청은 순간 기억이 잘 사라진다. ‘나중에’는 크론이 해결한다.

예: ‘20분 뒤 회의자료 업로드하라고 알려줘’ 같은 작업.

4) “레포에서 새 글 만들고 커밋/푸시” — 로컬 파일 + 쉘 실행

블로그 운영에서 제일 자주 반복되는 건:

글 생성
포맷/메타데이터 QA
git add/commit/push

OpenClaw는 이걸 (스킬이든, 그냥 도구 호출이든) 한 번에 묶을 수 있다.

5) “긴 작업은 분리해서 돌려줘” — 서브에이전트 패턴

리서치/요약/코드 수정처럼 오래 걸리는 작업은 메인 대화창을 막지 않는 게 중요하다.

동작 흐름: sub-agent spawn → 백그라운드 실행 → 완료 시 알림

6) “실패했을 때 어떻게 복구할지” — 운영 체크리스트

자동화는 100% 성공하지 않는다. 그래서 운영 체크리스트가 필요하다.

(A) 네트워크/용량: 429, 타임아웃
(B) 브라우저: 로그인/쿠키/동의 팝업
(C) git: 브랜치명(main/master), 충돌
(D) 정책: 루머 금지/출처 필수/길이 기준

스니펫 모음 (실제로 이렇게 요청하면 편하다)

아래는 ‘프롬프트 템플릿’처럼 써도 되는 문장들.

1) 웹 기반 리서치

“구글 뉴스에서 OpenClaw 관련 기사 5개 찾아서 링크+핵심 요약해줘”
“이 페이지 열고, 핵심 주장 3개랑 근거 문단을 인용해서 요약해줘”

2) 레포 기반 글 발행

“intzzzero-new-blog로 가서 OpenClaw 주제로 새 글 생성하고 add/commit/push까지 해줘”

3) 정기 발행

“매일 14:10에 OpenClaw/AI 뉴스 발행 크론으로 등록해줘”

4) 안정성(리트라이)

“모델 429나면 30초 간격으로 3번 재시도하고, 그래도 실패하면 알림만 남겨줘”

(보너스) OpenClaw를 잘 쓰는 사람들의 공통점

‘무슨 일을’이 아니라 ‘어떤 완료 상태’를 요청한다 (예: ‘푸시까지’, ‘링크 포함’).
반복 작업은 스킬로 고정한다.
실패 케이스(429/로그인/충돌)까지 미리 설계한다.

참고 자료

OpenClaw 문서: https://docs.openclaw.ai/
GitHub: https://github.com/openclaw/openclaw
Discord 커뮤니티: https://discord.com/invite/clawd

AI 뉴스 라운드업: 범용 에이전트와 디지털 워터마크, 그리고 새로운 희망

2026-02-02T00:00:00.000Z

최근 범용 강화학습 에이전트 ‘Janus’의 등장부터 AI 콘텐츠 워터마크 법안, 그리고 AI를 활용한 췌장암 치료 단백질 설계까지. 이번 주 AI 업계는 기술적 도약과 사회적 규제, 그리고 인류를 위한 희망적인 소식이 교차하며 그 어느 때보다 역동적인 모습을 보였다. 급변하는 환경 속에서 개발자로서의 고민과 기대를 가볍게 정리해본다.

AI의 속도를 따라가려 노력하지만, 지난 한 주간은 마치 10년이 며칠 사이에 압축된 것 같은 기분이었다. 말 그대로 ‘범용’이라 부를 만한 강화학습 에이전트에 대한 논문이 발표되었는데, 본 적 없는 복잡한 문제들을 너무나 쉽게 해결하는 모습이 꽤나 충격적이다. 동시에 정부에서는 AI 콘텐츠에 워터마크를 의무화하는 법안을 통과시키며 규제에 나섰다. 기술은 저 멀리 앞서가고 규제는 이제야 걸음마를 떼는, 전형적인 기술 발전의 현주소를 보는 듯하다.

그 혼란 속에서도 희망은 있다. AI가 새로운 암 치료제를 설계하는 데 성공했다는 소식이다. 역사의 변곡점을 지나고 있다는 생각이 든다. 무언가를 만드는 개발자로서 이 상황을 지켜보는 마음은 참 복잡하다. 내가 머지않아 도태될 것 같다는 위기감이 들다가도, 순식간에 엄청난 마법 지팡이를 손에 쥔 것 같은 기대를 품게 된다.

‘Janus’ 에이전트의 출현

가장 머릿속을 복잡하게 만든 것부터 이야기해보자. ‘Axiom Research’라는 곳에서 발표한 범용 문제 해결 아키텍처, ‘Janus’에 대한 이야기다. 두 얼굴을 가진 로마 신의 이름을 딴 것부터가 심상치 않다. 기존의 특화된 AI 시대를 뒤로하고 완전히 새로운 시대로 넘어가는 갈림길에 서 있는 느낌이다.

그간 강화학습의 역사는 바둑이나 스타크래프트처럼 특정 작업에서 인간을 압도하는 모델을 만드는 데 집중해왔다. 하지만 그런 모델들은 조금이라도 조건이 바뀌면 속수무책이었다. Janus는 이걸 정면으로 돌파했다. 거대한 월드 모델(World Model)과 효율적인 탐색 알고리즘을 결합해, 학습하지 않은 영역에서도 최소한의 정보만으로 문제를 해결해낸다.

공개된 데모는 그야말로 압권이다. 물리 법칙을 스스로 파악해 다리 구조를 설계하고, 도시 교통 데이터를 분석해 출퇴근 시간을 30%나 단축하는 루트를 제안한다. 개인적으로 가장 놀랐던 건 한 번도 본 적 없는 생소한 프로그래밍 언어의 문서를 읽고 그 언어의 컴파일러를 직접 만들어낸 장면이었다.

이건 단순히 성능이 좋아진 게 아니라, 패러다임이 바뀐 거다. “무언가를 하는 법을 가르치는” 시대에서 “무엇이든 배울 수 있는 기계를 만드는” 시대로 넘어온 셈이다. 개발자로서의 내 입지는 어떻게 될까? AI가 단순히 코드를 짜는 보조 도구를 넘어, 문제의 본질을 이해하고 전체 시스템을 설계하는 ‘동료’가 된다면 말이다. 아직은 나를 도와주는 강력한 도구라고 믿고 싶지만, 머릿속 복잡해지는 건 어쩔 수 없다.

디지털 국경선: 콘텐츠 인증법 (Content Authenticity Act)

기술이 폭주하니 사회도 제동을 걸기 시작했다. 지난주 미국에서 ‘2026 콘텐츠 인증법’이 초당적 지지로 통과되었다. 상업적으로 생성된 모든 AI 콘텐츠(기사, 이미지, 영상 등)에 보이지 않는 암호화 워터마크를 의무적으로 넣어야 한다는 내용이다.

취지는 명확하다. 딥페이크와 가짜 뉴스가 판치는 세상에서 무엇이 진짜인지 알려주는 ‘투명성’을 확보하겠다는 거다. 정보에 영양분 표시를 하는 것과 비슷하다고 보면 된다.

하지만 반발도 만만치 않다. 오픈소스 커뮤니티는 이 법안이 거대 기업의 독점을 가속화할 것이라며 우려하고 있다. 아티스트들은 패러디나 풍자 같은 창의적인 작업물까지 검열의 대상이 될까 걱정한다. 게다가 기술적으로 “이게 정말 가능하냐”는 회의론도 크다. 디지털 저작권 관리(DRM)의 역사에서 보듯, 규제는 깨지기 마련이고 결국 창작자들만 괴롭히는 도구가 될 수 있기 때문이다. 기술로 사회 문제를 해결하려는 시도가 늘 그렇듯, 이번에도 병 속에서 나온 거인을 다시 집어넣으려는 무모한 시도는 아닐지 걱정이 앞선다.

새로운 희망: 생성 AI가 설계한 치료제

우울한 이야기만 있는 건 아니다. AI가 우리 삶을 어디까지 개선할 수 있는지 보여주는 소식도 들려왔다. 제약 회사 ‘Omni-Health’와 AI 바이오 기업 ‘Cell-Savant’가 협력해 췌장암 치료를 위한 새로운 단백질을 설계하는 데 성공했다.

기존의 신약 개발은 수조 개의 열쇠 중 맞는 것을 찾는 무차별 대입 방식이었다면, 이번에는 AI가 암세포라는 자물쇠의 구조를 분석해 그에 딱 맞는 열쇠를 ‘직접 설계’해냈다. 주변의 건강한 세포는 건드리지 않고 암세포만 정밀 타격하는 방식이다.

실제 치료제로 쓰이기까지 임상 시험이라는 험난한 과정이 남았지만, 패러다임이 바뀌었다는 점이 중요하다. 최적화 도구를 넘어 ‘창조자’로서의 AI가 인류의 고질적인 고통을 해결하는 도구로 쓰이기 시작한 것이다. 리스크와 불안 속에서도 우리가 더 나은 도구를 계속 만드는 이유는 결국 더 나은 세상을 만들기 위해서가 아닐까 싶다.

참고 자료

스타트업은 재즈다

2026-01-10T00:00:00.000Z

최근 들어 ‘내가 몸담고 있는 스타트업은 무엇과 가장 닮았을까?’ 하는 질문을 스스로에게 던져보았다. 거대한 목표를 향해 항해하는 배, 혹은 하나의 목적지를 향해 날아가는 로켓 같은 이미지를 떠올렸지만, 어딘가 2% 부족한 느낌을 지울 수 없었다. 그러다 문득 머리를 스치는 한 장면이 있었다. 바로 늦은 밤, 작은 바에서 각자의 악기로 혼을 불어넣는 ‘재즈 쿼텟’의 모습이다.

정해진 악보와 지휘자의 엄격한 통제 아래 일사불란하게 움직이는 클래식 오케스트라를 상상해보자. 한 명의 연주자가 음을 이탈하거나 박자를 놓치면 그 실수는 치명적인 오점으로 남아 전체의 조화를 무너뜨린다. 모든 것이 계획대로, 악보대로 흘러가야만 완벽한 연주가 완성된다. 이는 이미 시스템이 안정된 거대 기업의 모습과 닮았다. 각자의 역할(Role and Responsibility)이 명확하고, 정해진 프로세스를 벗어나는 일은 좀처럼 일어나지 않는다.

하지만 내가 경험한 4~5인 규모의 작은 스타트업은 클래식 연주와는 거리가 멀었다. 우리의 일은 정해진 악보 없이, 때로는 리더가 정해준 코드 진행(회사의 큰 방향성) 위에서 각자가 가진 악기(자신의 전문성)로 즉흥 연주를 해나가는 재즈에 가까웠다.

재즈 연주자들은 완벽하게 짜인 악보 대신, 서로의 연주에 귀 기울인다. 드러머가 리듬을 바꾸면 베이시스트가 그루브를 더하고, 피아노는 새로운 화성을 얹는다. 그러다 한 연주자가 잠시 길을 잃거나 실수를 하면, 다른 연주자들이 절묘한 애드리브로 그 빈틈을 메우며 자연스럽게 연주를 이어간다. 때로는 그 실수가 전혀 예상치 못한 멋진 솔로 파트로 이어지는 계기가 되기도 한다.

스타트업도 마찬가지다. 기획자가 예상치 못한 버그를 발견했을 때, 개발자는 즉흥적으로 해결책을 모색하며 코드를 수정한다. 갑작스러운 서버 다운에 모두가 달려들어 밤샘 작업을 하는 것은 흔한 일이다. 마케터가 잘못된 광고 소재를 내보냈을 때, 디자이너는 재빨리 새로운 이미지를 만들어주고 개발자는 즉각 교체해준다. 이 과정에서 누구도 “그건 당신의 실수니 알아서 하세요”라고 말하지 않는다. 마치 “괜찮아, 내가 받아줄게. 계속 가보자고!”라고 말하는 재즈 연주자처럼, 우리는 서로의 실수를 기꺼이 자신의 애드리브로 덮어준다.

이러한 즉흥성과 유연함은 특히 소규모 팀에서 더욱 빛을 발한다. 각자의 역할이 칼같이 나뉘어 있기보다, 서로의 영역을 넘나들며 멀티플레이어가 되어야 하기 때문이다. 개발자가 고객 문의에 답변하고, 마케터가 간단한 디자인 수정을 하기도 한다. 이는 단순히 ‘일이 많아서’가 아니라, 우리 모두가 ‘하나의 곡’을 완성해야 한다는 공동의 목표를 공유하기에 가능한 일이다. 오케스트라 단원이 자신의 악보만 보는 것과 달리, 재즈 연주자들은 서로의 눈빛과 숨소리까지 공유하며 합을 맞추는 것과 같은 이치다.

물론 재즈의 즉흥 연주가 아무런 규칙 없이 이루어지는 것은 아니다. 그 바탕에는 수많은 연습을 통해 다져진 연주자의 실력과, 함께 연주하는 동료에 대한 깊은 신뢰, 그리고 음악 전체의 구조에 대한 이해가 깔려있다. 스타트업 역시 마찬가지다. 각자의 전문성을 끊임없이 갈고닦아야 함은 물론, 우리 회사가 어떤 ‘곡’을 연주하고 있는지, 지금 어떤 ‘코드’ 위에서 움직이고 있는지에 대한 깊은 이해와 동료에 대한 신뢰가 없다면, 우리의 즉흥 연주는 아름다운 협주가 아닌 시끄러운 소음으로 전락하고 말 것이다.

스타트업이라는 무대 위에서, 우리는 때로 불안정한 솔로를 이어가고 예측 불가능한 변주를 마주한다. 하지만 괜찮다. 내 옆에는 나의 불안정한 음을 감싸주고, 나의 도전을 응원하며 기꺼이 자신의 리듬을 실어줄 든든한 ‘밴드’가 있으니 말이다. 어쩌면 스타트업의 진정한 매력은 완벽하게 짜인 클래식을 연주하는 것이 아니라, 서로의 부족함을 채워가며 우리만의 재즈를 만들어나가는 그 과정 자체에 있는 것이 아닐까.

AI 페어 프로그래머, 증강 코딩(Augmented Coding) 제대로 활용하기

2025-09-05T00:00:00.000Z

켄트 벡이 제시한 ‘증강 코딩’은 AI를 단순 코드 생성기가 아닌, 개발자의 지시와 원칙 아래 움직이는 주니어 페어 프로그래머로 활용하는 방식이다. 이는 명확한 컨텍스트와 피드백을 통해 AI의 결과물을 통제하고, 개발자는 문제 해결의 본질에 더 집중하게 만든다. 현업에서는 보일러플레이트 제거, 리팩토링 제안, 테스트 코드 작성 등 구체적인 역할을 부여함으로써 AI와의 협업 효율을 극대화할 수 있다.

솔직히 그동안 Cursor나 Claude Code 같은 AI 도구를 쓰면서도 막연함을 느낄 때가 많았다. 코드를 빠르게 완성해주는 건 고맙지만, 어딘가 모르게 내가 조종하는 게 아니라 끌려다니는 기분이랄까. 그냥 ‘감(Vibe)‘에 의존해 질문을 던지고 그럴싸한 답변을 얻어 쓰는 방식, 켄트 벡의 표현을 빌리자면 ‘Vibe Coding’에 머물러 있었던 셈이다.

이런 고민 와중에 켄트 벡이 제시한 ‘증강 코딩(Augmented Coding)‘이라는 개념과 AWS에서 이를 ‘Kiro’라는 내부 도구에 적용한 사례를 접하고 머리를 한 대 맞은 듯한 느낌을 받았다. 이건 단순히 AI를 비서처럼 부리는 걸 넘어, 제대로 된 ‘협업’의 판을 짜는 방법에 대한 이야기였다.

증강 코딩, AI를 주니어 개발자로 만들기

켄트 벡은 AI와의 상호작용을 Prompt(지시) → Response(응답) → React(반응) → Adjust(조정) 의 사이클로 정의한다. 여기서 핵심은 세 번째, 바로 우리의 ‘반응’이다. AI가 내놓은 결과물을 맹목적으로 복사-붙여넣기 하는 게 아니라, 시니어 개발자가 주니어의 코드를 리뷰하듯 비판적으로 검토하고 피드백하며 개선 방향을 다시 지시하는 것이다.

결국 AI를 ‘척척박사 코드 생성기’가 아니라, 약간의 실수는 있지만 잠재력 넘치는 ‘주니어 페어 프로그래머’로 대하는 관점의 전환이 필요하다. 우리는 AI에게 명확한 업무 지시와 함께 우리 팀의 코드 컨벤션, 설계 원칙 같은 ‘컨텍스트’를 꾸준히 제공하는 ‘시니어’의 역할을 수행해야 한다.

현업에서 증강 코딩 실천하기

그렇다면 이 ‘주니어 AI’에게 어떤 일을 시켜야 가장 효율적일까? AWS 블로그에서 Kiro의 역할을 세 가지로 나눈 것을 참고해 현업에 적용할 만한 구체적인 실행 방안을 정리해봤다.

1. 조수 (Assistant)

가장 기본적이면서도 효과적인 역할이다. 귀찮고 반복적인, 하지만 꼭 필요한 작업들을 AI에게 위임하는 것이다.

보일러플레이트 생성: “Node.js와 Express로 기본적인 CRUD API 서버 구조를 만들어줘.”, “Recoil 상태를 사용하는 React 컴포넌트 템플릿 좀 짜줘.” 와 같이 반복되는 초기 설정 코드를 맡기면 시간을 크게 절약할 수 있다.
단순 변환 작업: “이 JSON 데이터를 기반으로 TypeScript 인터페이스를 생성해줘.” 같은 일은 AI가 인간보다 훨씬 빠르고 정확하다.
테스트 코드 초안: “이 함수의 정상 케이스와 에러 케이스에 대한 Jest 테스트 코드 초안을 작성해줘.” 완벽하진 않더라도, 테스트의 기본 구조를 잡는 데 드는 수고를 덜어준다.

2. 파트너 (Partner)

여기서부터는 좀 더 협업다운 모습이 드러난다. 정답이 정해지지 않은 문제에 대해 함께 고민하는 동료로 활용하는 것이다.

리팩토링 아이디어 탐색: 복잡하게 얽힌 함수를 던져주고 “이 코드를 더 읽기 쉽게 리팩토링하는 3가지 방법을 제안해줘.” 라고 요청할 수 있다. 제안된 방법들을 보며 새로운 관점의 힌트를 얻을 수 있다.
다양한 해결책 모색: “API 요청 실패 시 재시도 로직을 구현하고 싶은데, Exponential Backoff를 적용하는 방법 외에 다른 대안은 뭐가 있을까?” 처럼 특정 문제에 대한 여러 아키텍처나 패턴을 물어보며 최적의 답을 찾아 나가는 과정이다.
기술 학습: 새로운 라이브러리나 프레임워크를 배울 때, 공식 문서를 함께 보며 “이 API를 사용하는 간단한 예제를 만들어줘” 라고 요청하며 빠르게 개념을 익히는 페어 프로그래머로 쓸 수 있다.

3. 비평가 (Critique)

AI는 지치지 않고, 감정도 없다. 그래서 때로는 냉정한 코드 리뷰어로서 훌륭한 역할을 수행할 수 있다.

엣지 케이스 발견: 내가 작성한 코드를 보여주며 “이 로직에서 놓치고 있는 엣지 케이스가 있을까?” 라고 물으면, 사람이 미처 생각하지 못한 부분을 짚어주기도 한다.
가독성 및 컨벤션 검토: “우리 팀은 변수명에 카멜 케이스를 사용해. 이 코드에서 컨벤션에 맞지 않는 부분이 있는지 검토해줘.” 와 같이 코드의 일관성을 유지하는 데 도움을 받을 수 있다.
보안 관점 리뷰: “이 API 핸들러에서 발생할 수 있는 보안 취약점이 있는지 알려줘.” 라고 질문하며 기본적인 보안 검토를 맡길 수도 있다.

개발자의 역할은 어디로 가는가

증강 코딩의 개념을 접하고 나니, AI의 발전이 개발자를 대체하는 것이 아니라 개발자의 역할을 한 단계 위로 끌어올리고 있다는 생각이 든다. 이제 우리의 핵심 역량은 단순히 코드를 빨리 짜는 ‘타이피스트’가 아니라, 문제를 정확히 정의하고, AI라는 도구를 활용해 최적의 해결책을 ‘설계’하며, 그 결과물을 비판적으로 ‘검증’하는 능력이 되어가고 있다.

AI라는 똑똑한 주니어를 옆에 두고 시니어 개발자로서 방향을 제시하고 함께 성장하는 것. 어쩌면 코딩이 다시 즐거워지는 방법은 바로 여기에 있는지도 모르겠다.