AI 시대에 개발 블로그에 관한 고찰
기술 블로그를 쓰는 이유가 무엇일까? 나는 3년 동안 기술 블로그를 운영해 왔다. 그런데 최근 들어 글을 쓰는 일이 점점 뜸해졌다. AI가 다 해주는 "대 딸깍의 시대"에 기술 블로그가 여전히 의미가 있을까 하는 생각이 들었기 때문이다. 이런 생각이 반복되다 보니 자연스럽게 글을 쓸 동력도 줄어들었고 달에 한두 번 정도로 글을 쓰는 횟수가 줄었다.
그러던 중 우테코에서 향로(이동욱)님의 강연을 들을 기회가 있었다. 놀랍게도 향로님은 강연을 시작하며 나와 비슷한 고민을 하고 있었다고 말씀하셨다. 지난 10년 동안 블로그를 운영해 왔지만 AI가 많은 것을 대신해 주는 시대에 기술 블로그를 계속 쓰는 일이 어떤 의미를 가지는지 고민했다는 이야기였다.
강연이 끝난 뒤 용기 내어 1대 1로 질문을 드렸다. "저는 3년 동안 기술 블로그를 운영해 왔는데, 최근에는 AI가 다 해주는 시대에 블로그를 계속 쓰는 게 어떤 의미가 있을지 고민이 됩니다. 향로님은 이런 시대에도 블로그를 계속 쓰는 이유가 무엇인가요?"
향로께선 블로그를 쓰는 이유가 본인에게 가장 잘 맞는 학습 방법이었으며 오로지 자기 자신을 위해서라고 하셨다. 듣고 보니 머리가 띵해짐... 내가 블로그를 쓰는 이유 또한 향로가 말씀하신 이유와 같았다. 나 또한 블로그가 가장 나에게 잘 맞는 학습 방법이었고 올바른 내용을 작성하기 위해 더 깊이 공부하게 되는 계기가 되었다.
내 블로그의 타이틀이 "과거의 나를 통해 미래의 나를 성장시키자"인 이유 또한 훗날 성장한 미래의 나라고 해서 과거의 나보다 항상 모든 것을 잘 알지 못하기 때문에 과거의 발자취를 통해 성장하자라는 이유에서였다.
이미 나는 그 답을 알고 있었지만 기억 속에서 잊고 있었다. 최근 들어 AI 의존도가 높아지다 보니 이런 일들이 종종 발생하는 것 같다. 취준 하면서 기본기가 가장 중요하단 것을 알고 있었음에도 어느 순간 머릿속엔 AI를 더 공부해야 한다, 이제 이런거 공부해서 뭐 하지? AI가 다해주는데? 란 생각에 잠겨 기본적인 지식들을 멀리하기도 했다.
여담으로 향로는 본인이 직접 작성하신 글들을 마크다운으로 바꿔 AI의 지식베이스로 사용하신다고 한다(캬...)
앞으로는 글을 쓰는 방향을 자유롭게 바꿔보려 한다. AI로 인해 이제 블로그를 보는 사람도 줄어들었으니 철저히 개인 학습을 위한 공간으로 사용해야겠다.
그래서 AI Agent는 왜 만들게 되었는가?
나는 원래 GPT나 클로드 데스크탑 앱을 사용해 간단한 질문을 주고받거나 프로젝트에서 발생하는 문제를 해결하는 정도로만 사용해 왔다. 그러다 보니 남들이 열광하는 OpenClaw, Hermes 같은 것들이 뭔지도 모르고 사용해 볼 생각조차 못했다.
그러던 중 어느 날 카카오톡 오픈채팅방에서 AI Agent 스터디 모집글이 올라왔다. 모집글에서 말하는 LangGraph, LangChain이 뭐고 워크플로우 자동화는 또 뭔지 당최 아무것도 이해하지 못했지만 아주 작은 것 하나라도 얻어가고 싶다는 생각에 지원하게 됐다.
스터디 시작
AI에 대해 너무 무지했기 때문에 심지어는 AI 에이전트가 뭔지도 모름... 민폐가 되진 않을까 걱정이 많이 컸지만 첫 대면 스터디부터 정말 정말 많은 것들을 배울 수 있었다. 가장 크게 느낀 것은 Personal 한 AI 에이전트는 존재하지 않는다는 것이다.
라이브러리나 프레임워크는 특정한 기능을 하는데 특화돼 있어 그대로 사용할 수 있지만 AI 에이전트는 아무리 잘 만들더라도 사람마다 각자의 환경과 조건, 성향등 많은 것들이 다르기 때문에, 심지어 같은 프롬프트를 넣어도 사람마다 다른 결과가 나올 수 있기 때문에 남들이 만든 것을 그대로 사용하는 것이 불가능하다고 생각했다.
그래서 지금 하고 있는 사이드 프로젝트를 내가 직접 코드를 치지 않고 유지보수 할 수 있는 AI 에이전트를 만들기로 결정했다.
바퀴 재발명하기
앞서 말한 이유도 있지만 가장 큰 이유는 바퀴 재발명이었다. Oh my Claude Code 같은 이미 잘 만들어진 유명한 오픈 소스들을 사용하는 방법도 있겠지만 AI 무지성 거인인 나에겐 너무 화려한 옷이다.
그래서 AI 에이전트가 뭔데?
AI를 사용하다 보면 에이전트란 말을 굉장히 많이 쓴다. sub agent, multi agent 등등 여기저기 다 붙이던데... 여기저기서 쓰니 나도 이게 처음엔 굉장히 헷갈렸다. 뭐만 하면 다 에이전트래
그래서 그냥 쉽게 이해하려고 내가 아는 유일한 에이전트인 축구 에이전트에 비유해서 이해했다. 축구 에이전트는 선수가 경기 자체에 집중할 수 있도록 주변 일을 대신 처리해 주는 사람이다. 정해진 절차에 따라 구단과의 계약을 협상하고, 이적 가능성을 알아보고, 스폰서나 일정 같은 외부 업무를 조율한다.
AI 에이전트도 비슷하다. 우리가 AI에게 목표를 주면 AI 에이전트는 그 목표를 달성하기 위해 정해놓은 규칙에 따라 스스로 필요한 단계를 나누고 도구를 사용한다. 그럼 이 에이전트를 어떻게 만들어야 할까? 나는 이미 잘 만들어진 바퀴를 벤치마킹하기로 결정했다.
Oh My Claude Code 뜯어보기
Oh My Claude Code를 선택한 이유는 AI 에이전트 스터디를 함께 하시는 혜림님께서 Oh My Claude code의 내부 구조를 해주셔서 오픈소스 에이전트 분석에 필요한 리소스를 줄일 수 있었기 때문이다(혜림님 감사합니다!!).
Oh My Claude Code는 총 19개의 전문화된 sub agent로 구성되어 있으며 각 에이전트의 역할과 작업 난이도에 따라 서로 다른 모델을 사용하는 3 Tier 구조를 가진다.
- Tier 1 : `Haiku` 기반의 경량 탐색 계층으로, 빠른 코드 탐색과 초안 작성처럼 비용이 낮고 반복이 많은 작업 담당
- Tier 2 : `Sonnet` 기반의 표준 개발 계층으로, 대부분의 실제 구현과 검증 작업과 일반적인 개발 흐름의 중심 담당
- Tier 3 : `Opus` 기반의 고성능 판단 계층으로, 높은 추론 능력과 신중한 판단이 필요한 작업 담당
이 구조를 통해 단순 탐색은 저비용 모델로 빠르게 처리하고 일반 개발은 균형 잡힌 모델로 수행하며 중요한 설계와 리뷰는 고성능 모델에 맡겨 비용 효율성과 품질을 동시에 확보하며 사용자의 요청이 들어왔을 때 OMC 오케스트레이터를 사용해 적절한 에이전트에게 라우팅한다.
멀티 에이전트 만들기
나는 이 구조에서 아이디어를 착안해 `AGENTS.md` 파일을 오케스트레이터로 사용했는데, Codex가 작업 전에 반드시 읽는 파일이라는 특성을 이용해 모든 요청이 먼저 공통 정책과 라우팅 규칙을 통과하도록 만들었다.
사용자의 요청은 오케스트레이터에 의해 탐색, 분석, 계획, 테스트, 구현, 리뷰, Git 작업 중 어디에 해당하는지 분류되고 이후 해당 전문 에이전트에게 위임된다. 이를 통해 AI가 혼자 판단해 바로 코드를 수정하는 위험을 차단하고 워크플로우를 명확하게 관리할 수 있다.
이후 각 에이전트들에 적절한 역할을 부여하였으며 필요한 경우 Skill로 분리하여 반복되는 요구사항을 전달하였다. 예를 들어 구현을 담당하는 에이전트에겐 팀 코딩 컨벤션을, 커밋과 PR 생성을 담당하는 에이전트에겐 각각 커밋과 PR 컨벤션을 설정하였다.
개발 워크플로우 자동화
다음으로 평소 나의 개발 워크플로우를 AI가 그대로 재현하도록 구현해 봤다. 나는 다음과 같은 순서로 작업한다.
Github Issue 생성 -> 작업 브랜치 생성 -> 구현 -> 커밋 -> PR 생성
처음에는 이 과정을 하나의 에이전트에게 모두 맡기려고 했다. 하지만 그렇게 하면 AI가 작업 범위를 정하고 코드를 수정한 뒤 커밋과 PR까지 멋대로 만들어 버릴 수 있다. 아무리 자동화가 편해도 눈을 잠깐 감았다 떴더니 PR이 생성돼 있는 건 조금 무섭다... 그래서 각 단계를 전문 에이전트의 역할로 분리하고 중요한 작업 사이에는 내가 직접 확인하는 승인 단계를 두었다.
작업 준비
기존의 작업 순서대로 새로운 기능이나 규모가 큰 작업은 먼저 GitHub Issue를 생성하고 작업 브랜치를 만든다.
계획 수립
작업 시 계획 에이전트가 먼저 코드를 분석하고 구현 계획을 세운다. 어떤 파일을 수정해야 하는지, 기존 구조에 어떤 영향을 주는지, 어떤 테스트가 필요한지를 정리한 뒤 나에게 계획을 보여주고 내가 계획을 승인해야 다음 단계로 넘어간다.
실제로 코드를 구현하는 단계보다 이 단계가 가장 중요하다. 이 단계에서 사람이 직접 꼼꼼히 검수해야 이후 코드를 구현했을 때 AI가 잘못 건드리는 부분도 줄어들고 원하는 결과물이 나올 확률이 증가한다. 실제로 함께 스터디를 하는 분께서 AI가 만든 작업 계획서(?)를 검토하는데 시간을 정말 많이 쓴다고 하신다. 때문에 사용자가 정확한 입력한 프롬프트를 입력하는 것이 중요하다.
하지만 AI에게 매번 내 말 잘 이해했어 ? 라고 물어보는 것은 귀찮다. 따라서 AI가 프롬프트를 분석하고 모호한 부분을 분석해 다시 재질문하게 하는 소크라테스식 질문법을 적용한 오픈소스인 ouroboros 도입도 고려했으나 역으로 피로도가 상당해질 것 같아 반려했다.
💡 소크라테스식 질문법
AI에게 정답을 곧바로 요구하는 대신 AI가 반문과 질문을 통해 사용자의 사고를 확장하고 스스로 문제를 해결하도록 돕는 프롬프팅 기술 및 대화 방법론
테스트 먼저 작성하기
계획이 승인되면 테스트 코드 에이전트가 구현보다 먼저 테스트를 작성한다. 테스트를 먼저 작성한 이유는 AI에게 성공의 기준을 명확하게 알려주기 위해서다. "적당히 잘 구현해 줘"가 아니라 "이 테스트를 통과하는 상태를 만들어 줘"라고 요구하면 에이전트가 엉뚱한 방향으로 달려갈 가능성을 줄일 수 있다. 테스트 코드 에이전트가 기대하는 동작이나 기존 문제를 재현하는 테스트를 만들면 해당 내용을 구현 에이전트에게 전달한다.
구현과 검증
구현 에이전트는 승인된 계획과 테스트를 바탕으로 실제 코드를 수정하고 끝나면 관련 테스트와 코드 검사를 실행한다. 실패하면 원인을 확인하고 다시 수정하며 정해진 검증 기준을 통과할 때까지 이 과정을 반복한다. 현재 구현의 기본 흐름은 다음과 같다.
planner → 사용자 승인 → tester → implementer → 검증
이 구조에서 중요한 점은 에이전트가 혼자서 계획하고 구현하고 스스로 잘했다고 결론 내리지 않는다는 것이다. 계획과 테스트, 구현의 책임을 분리해 각 단계의 결과가 다음 에이전트의 입력이 되도록 만들었다.
LLM Wiki 자동 동기화
LLM Wiki는 간단히 말해 프로젝트의 지식 베이스를 저장하는 저장소다. 프로젝트의 구조, 도메인 용어, 코딩 규칙, 테스트 전략처럼 에이전트가 작업 전에 알아야 할 정보를 한 곳에 정리함으로써 일반적인 AI가 새로운 대화를 시작하면 이전 작업의 맥락을 알지 못한다는 문제점을 해결한다.
또한 매번 직접 위키에 직접 내용을 작성하는 것이 아닌 작업 과정에서 새로운 도메인 정책이나 "반복해서 사용할 규칙"이 생겼다면 `wiki-maintainer`가 이를 LLM Wiki에 반영하거나 코드와 기존 문서의 내용이 달라졌다면 실제 코드를 기준으로 문서를 함께 갱신한다.
이때 AI에게 "반복해서 사용할 규칙"이라고 전달하면 AI는 반복이란 말의 기준이 무엇일까? 하며 스스로 판단하에 작업한다. 이러한 문제를 해결하기 위해 캐시 히트처럼 히트 횟수를 기록해 2회 이상 반복될 경우 등재 후보에 오르게 되고 AI는 이에 대한 PR을 작성하고 사람이 직접 PR 리뷰를 통해 등재 여부를 관리한다.
이를 통해 AI가 코드를 작성하는 것에서 끝나는 것이 아니라 작업 중 얻은 지식을 다음 작업에서도 사용할 수 있도록 축적하는 구조를 만들었다.
커밋과 PR 생성
이후 커밋 에이전트는 변경된 파일을 분석한 뒤 커밋 메시지를 생성한다. 이후 PR 에이전트가 변경 내용과 테스트 결과를 바탕으로 PR 제목과 본문을 작성하고 내용을 확인한 뒤 승인해면 브랜치를 push 하고 PR을 생성한다.
마무리
이렇게 내가 설계한 AI 에이전트를 소개해봤다. AI Agent가 뭔지도 모르던 시절부터 에이전트를 직접 설계하며 더 나은 방식을 고민하며 다양한 개념들을 접했다. 최근에는 프롬프트를 매번 직접 작성하는 대신 AI가 목표를 달성할 때까지 작업과 검증을 반복하는 시스템을 설계하는 것을 루프 엔지니어링(Loop Engineering)"이 유행한다고 한다.
내 에이전트 역시 완전한 자동 루프는 아니지만 방향은 비슷하다. 사용자가 모든 과정을 일일이 지시하지 않아도 워크플로우가 정해진 규칙에 따라 이어지고 중요한 결정이 필요할 때만 사용자에게 승인을 요청한다. 결국 중요한 것은 좋은 프롬프트 하나를 작성하는 능력보다 AI가 어떤 순서로 일하고, 무엇을 기준으로 결과를 검증하며, 어느 순간 사람에게 판단을 넘겨야 하는지를 설계하는 일이라고 생각한다.
하네스 엔지니어링, 루프 엔지니어링 등등 수없이 빠르게 몰아치는 AI 파도에 휩쓸려 꼴까닥하는게 하는게 아닐까란 걱정이 들었는데 향로께서 이와 관련해 이마를 탁 치는 말씀을 해주셨다.
"스프링이나 코틀린 같은 것들이 버전 업데이트 될 때마다 그걸 다 따라가지도 않는데 굳이 AI라고 다 따라갈 필요가 있을까요?"
이 말을 들으니 굳이 그 파도에 휩쓸릴 필요는 없다고 느꼈다. 컨텍스트, 하네스, 루프 엔지니어링이란 단어들도 그냥 유명한 개발자들이 만들어낸 단어일 뿐 나에게 필요 없다면 굳이 그걸 따라갈 필요가 있을까?
중요한 것은 얼마나 많이 알고 있느냐가 아니라 그 기술을 통해 내가 무엇을 배우고 어떤 문제를 해결했느냐일 것이다. 돌이켜보면 블로그도 AI 에이전트도 결국 같은 역할을 하고 있었다.
블로그는 과거의 내가 남긴 지식을 미래의 내가 다시 사용할 수 있게 해 주고, AI 에이전트는 내가 일하는 방식과 판단 기준을 대신 기억해 준다. 둘 다 누군가에게 보여주기 위한 결과물이라기보다 나를 더 잘 이해하고 성장시키기 위한 도구였다. AI가 코드도 글도 대신 만들어 주는 시대지만 무엇을 배우고 무엇을 남길지는 여전히 내가 결정해야 한다.
앞으로도 모든 파도를 따라가지는 않겠지만 나에게 필요한 파도라면 직접 올라타 보고 그 과정은 글로 남겨보려 한다.
내가 만든 에이전트는 이 저장소에서 확인할 수 있다.
GitHub - chanho0908/Keepiluv-Agent: 저는 호모로맨스 안드레 카파시 코덱서 입니다.
저는 호모로맨스 안드레 카파시 코덱서 입니다. Contribute to chanho0908/Keepiluv-Agent development by creating an account on GitHub.
github.com
