급류 속에서
인터넷 이곳저곳을 둘러봅니다. AI 뉴스는 홍수처럼 쏟아집니다. 쌓여만 가는 북마크는 더 이상 소화하기도 어렵습니다. 시대가 빠르게 변하는 것을 느끼지만, 모든 정보를 다 흡수할 수도 없고, 그럴 필요도 없다는 사실을 깨닫습니다. 혹은 그렇게 스스로를 안심시킵니다. 이제 인간이 병목이라는 말도 나옵니다. 회사는 더 빠르게 만들기를 원하고, 개발자도 자신의 직업 생명을 단축(?)시키기 위한 노력을 하고 있습니다. 개발자 수명은 얼마나 남았을까요? 특히 프론트엔드는? 단언하긴 어렵겠지만 긍정하기도 어렵습니다. 개발자가 사라질 것 같지는 않습니다. 요즘 LLM이 위세를 떨치고 앞으로도 더욱더 그럴 테지만, 여전히 개발자와 일반인의 간극은 생각보다 넓습니다. 그 거리를 좁히는 것도 개발자의 역할이 되었습니다. 최근 FDE, AX와 같은 키워드를 갖는 직무의 채용 공고를 쉽게 찾아볼 수 있습니다. 이처럼 다른 모양으로 분화되거나 통합될 것으로 보입니다. 변화는 더 빨라질 것 같습니다. 개인이 큰 변화의 물결에 맞서는 것은 어려워 보입니다. 맞서기보다는 그 흐름을 이용하는 노자의 지혜가 필요할지도 모르겠습니다.
제가 느낀 변화에 대해 정리해보고 싶었습니다
개발자로 일하게 된 첫해인 2022년만 하더라도, 실무에서 AI의 존재감은 미약했습니다. 주니어인 저로서는 공식 문서와 스택오버플로우를 참고하는 것이 일상이던 시기입니다. 그다음 해인 2023년 즈음이 되어서야, 깃헙 코파일럿을 업무에 도입했고 부족한 점이 많았던 기억이 납니다. 정규 표현식, 리눅스 명령 같은 오래된 지식에 대해서는 꽤 도움을 받았지만, 프론트엔드 구현은 정말 엉망이었습니다. 당시엔 AI가 사용할 수 있는 도구도 제한적이었고 최신 정보에는 취약했습니다. 리액트 라우터에 대한 최근 지식이 없어서 자주 실망했던 기억이 납니다.
2024년 상반기 정도부터는 기대감이 커졌습니다. Cursor, Windsurf 등과 같은 AI IDE가 등장했고 주목을 받았습니다. 당시 저는 Neovim 커스터마이징에 빠져 있었는데 Code Companion 등 여러 AI 도구를 통합하고 저만의 개발 환경을 구축하는 것에 큰 관심을 두었습니다. 이후 Claude Code가 처음 등장했을 때만 하더라도 딱히 매력을 느끼진 못했습니다. 당시 LLM의 성능이 지금처럼 좋지 않기도 했고 ACP를 통해 내가 원하는 모델을 내 필요에 따라 사용하기를 기대했습니다. 여전히 Neovim에서 코딩할 나날이 꽤 많이 남았다고 생각했습니다.
하지만 저의 예상은 크게 빗나갔습니다. 모델의 성능이 눈에 띄게 좋아졌고 그들의 일 처리 능력을 극대화시킬 수 있는 MCP, Skill 등 각종 수단이 등장했습니다. 작년에 작성했던 저의 글은 벌써 오래된 지식이 되었습니다. 제 예상보다 속도가 빨랐습니다.
제가 일하는 환경이 얼마나 변했는지 남겨보고 싶습니다. 앞으로도 많은 변화가 있을 텐데요. 나중에 돌아볼 수 있는 지점이 되길 기대합니다.
최근에는
코드를 직접 작성하는 일이 크게 줄었습니다. AI 도입 초창기만 하더라도 IDE 중심으로 코딩을 했습니다. 사이드 패널을 열고 LLM에게 질문하거나 무언가를 요청했습니다. 코드는 선택적으로 반영하거나 LLM의 응답을 참고하여 직접 작성합니다. 하지만 지금은 코드 작성을 전부 위임하고 사전 계획을 세우는 것에 많은 시간을 들입니다. 요구사항을 구체화하고, 구현 방향을 함께 모색합니다. 계획 단계에는 grill-me 스킬을 활용하여 제게 질문을 던지도록 합니다. 아주 단순한 요구사항이라면 계획을 건너뛰기도 합니다. 보통 완성된 계획은 문서로 남깁니다. 문서는 모델의 컨텍스트 한계를 보완합니다. 코드는 직접 작성하지 않고 그 결과를 검토합니다.
코드 리뷰를 하는 시간이 더 많아졌습니다. 코드를 편집하는 것보다 diff를 보는 시간이 압도적으로 많아졌습니다. 동료의 코드가 아닌 AI의 코드를 보는 시간입니다. diff를 볼 때는 hunk를 씁니다. LLM은 hunk 세션에 접근할 수 있고 제가 남긴 코멘트를 읽을 수 있습니다. hunk를 통해 질문하고, 코드 수정을 요청합니다. 하지만 저의 리뷰는 마지막 관문일 때가 많습니다. 에이전트는 작업을 진행하고 정적 검사를 돌립니다. 그리고 다른 에이전트에게 리뷰를 요청합니다. 서브 에이전트 또는 아예 다른 코딩 에이전트에게 말이죠. herdr 또는 orca와 같은 도구를 쓴다면 서로 다른 에이전트에게 요청시키기에 좋습니다. 주요 관심사에 따라 페르소나를 부여하여 리뷰를 독립적으로 수행하도록 합니다. 또한 HTML로 작성된 리뷰 보고서를 제가 보기 좋게 작성합니다.
인지 부하가 점점 더 가중됩니다. 이해가 새로운 병목이다라는 글에 공감이 가는 요즘입니다. 코드를 고민하고 작성하는 과정에서 자연스럽게 이해를 하던 시절이 지났습니다. 지금은 merge되어야 하는 코드가 빠른 속도로 쌓입니다. LLM의 리뷰를 거치긴 하지만 결국 책임은 담당자인 저의 몫이라 중요도에 따라 저의 리뷰는 필수적입니다. 중요도를 판단하는 것 또한 저의 몫이기도 합니다.
회사 또는 제가 기대하는 속도를 지켜내기엔 사람의 이해는 병목처럼 느껴집니다. herdr와 같은 에이전트 중심 도구도 나날이 발전하고 있지만, 병렬 작업도 인지 부하를 가중시키는 데 한몫합니다. 결국 merge되는 코드가 초래할 수 있는 결과에 따라 경중을 따지고 완급 조절이 필요하다는 생각을 합니다. 적어도 리뷰를 완벽하게 수행하진 못하더라도 요구사항 검증과 코드를 이해하는 것은 중요합니다. 스스로 코드를 이해하는 것을 돕기 위해 '이해가 새로운 병목이다'에서 소개된 explain-diff 스킬에 영감을 받은 스킬을 만들어 사용하고 있습니다. 이 스킬은 코드 변경, 구현, 기술 개념에 대한 한 편의 아티클, 그리고 퀴즈를 제공합니다.
제품 코드를 작성하는 것보다 하네스를 구축하는 데 더 많은 시간을 씁니다. AI가 작성한 코드를 이해하고 검토하는 것만큼 많은 시간을 들이는 테마는 하네스 구축입니다. 현재 진행하는 프로젝트에서 웹, 앱의 프론트엔드를 혼자 맡게 되면서, 제품 코드를 단일한 모노레포로 전환했습니다. 그리고 프로젝트 위키를 구축했습니다.
앞으로 혼자 하려면 AI에게 많이 의지해야 할 테니 제품의 모든 히스토리, 구현에 필요한 지식을 효과적으로 전달하기 위한 수단이 필요하다고 생각했습니다. 이는 LLM Wiki에서 영감을 받았습니다. 이는 온보딩 또는 인수인계를 위한 자료이기도 합니다. 위키의 구조는 대략 아래와 같습니다.
project/
...
docs/
contract/ # 여긴 cross-app 계약
architecture/
convention/
decision/
history/
backlog/
troubleshooting/
apps/
a-app/
docs/
architecture/
convention/
decision/
history/
backlog/
troubleshooting/
b-app/
# ...
wiki/ # 모든 문서를 하나의 위키 앱으로 배포
AGENTS.md에는 기본적인 지침과 참조를 두고 최대한 얇게 유지합니다. 에이전트는 필요한 문서를 탐색하고 필요에 따라 문서를 작성합니다. 문서를 작성할 때 필요한 지침도 문서로 남겨져야 합니다. 문서를 참조하는 얇은 스킬도 하나 만들어 둡니다. 문서를 작성할 때마다 그 스킬을 사용하도록 말이죠.
커스텀 스킬을 직접 만들 때는 문서를 SSOT(Single Source of Truth)로 삼아 해당 문서를 참조하는 스킬을 얇게 만드는 편입니다. 위키의 위력은 문서가 쌓일수록 커집니다. 앞서 언급한 리뷰 에이전트의 관심사와 그 기준 또한 문서화되어 있습니다. 코딩을 할 때 보아야 할 기준도 문서로 남겨져 있습니다. 반복적으로 서술하고 전달해야 하는 문서와 프롬프트를 줄이는 것은 효율을 올려 줍니다. 중복된 프롬프트를 인지했을 때 이를 명문화하는 것은 아주 중요합니다. 한 곳으로 모으는 행위는 모순을 줄이는 데도 도움이 됩니다.
자는 시간에도 일을 시킵니다. 처음에는 AI 출력을 기다리다 퇴근이 늦어지는 것이 싫어 tailscale을 사용했습니다. herdr, tailscale 그리고 herdr의 플러그인인 collie의 조합으로 휴대폰에서 작업의 진행 상황을 봅니다. 퇴근길 지하철에서 일을 마무리하거나 추가 작업을 시킵니다. 회사 맥북은 잠금 상태로 켜둡니다.
최근 Companion이라는 로컬 유지보수 앱을 하나 만들었습니다. 어차피 회사 PC는 항상 켜져 있으니 로컬 데몬 앱을 하나 띄어 둡니다. 이 앱은 상시로 켜져 있다가 정해진 시간이 되면 정해진 에이전트에게 일을 지시합니다. 아래의 페르소나를 부여한 8개의 에이전트를 돌립니다.
- backlog: 위키에 쌓인 백로그 처리
- docs: 문서 내용 감사 및 수정
- sentry: 센트리 로그 관찰 및 중요도에 따라 처리
- quality: 코드 품질 감사 및 수정
- qa: QA 제보 처리
- storybook: 스토리북 개선 및 추가
- radar: 특정 뉴스레터 구독, 기술 아티클 요약, 프로젝트 개선 제안
- security: 보안 결함 검토 및 수정
모든 에이전트는 정해진 시각에 각자의 기준에 따라 일을 수행합니다. 아직은 초기 단계라 제한적인 범위 안에서 일을 시키며 테스트를 해보고 있습니다. 작업을 모두 마치면 그날에 대한 보고서를 제출합니다. 작업 시간과 무관하게 PR의 추가 요청이나 질문에 대응하기도 합니다. 앞으로 미뤄 두었던 자잘한 업무는 이 녀석이 잘 처리해 주기를 기대합니다. 이젠 혼자 일하는 느낌이 덜 들게 될까요..?
최근 탄탄한 검증 레이어의 필요성을 느끼고 있습니다. E2E 자동화를 구축하고 컴패니언에게 이를 맡기려고 합니다. 크로스플랫폼을 따져야 하기에 고민되는 지점이 많아 엄두를 못 내고 있지만요.
모르겠습니다
최근 빠르게 변화하는 추세 속에서 어떻게 일하고 있는지 생각나는 대로 적어 봤어요. 잘 모르겠습니다. 나름대로 작업 환경을 효율적으로 개선하고 있습니다. 무엇보다 제가 편하게 일할 수 있는 환경을 만들어 보고자 합니다. 하지만 과거 직접 코딩을 하던 시절에 비해 학습과 배움의 질이 떨어지고 있다는 느낌을 받습니다.
그래서일까요? 일에서 재미를 느끼는 지점이 줄어든 것 같아요. 예전보다 개발 속도가 빨라졌으니까 시간이 더 많이 남을 테고, 그러면 저 자신에게 투자할 수 있는 시간도 잘 확보될 것도 같지만 실상은 더 빠른 속도를 요구하는 상황인 것 같아요. 체감상 더 여유가 없다고 느낍니다. 업무 시간 외에도 원격으로 에이전트에게 일을 시키거나 감시하고 있는 현실입니다. 메타 인지를 챙기는 노력을 게을리하면 미트 프록시가 되기 십상인 요즘인 것 같습니다.
앞서 현재 개발자는 각기 다른 모양으로 분화되고 통합될 것 같다고 했습니다. 적어도 현재의 모습으로 일하게 될 것 같지는 않습니다. 일의 보람이라는 측면에서는 단순히 요구사항을 만드는 구현자로서의 역할에는 만족하기 어려운 시대인 것 같습니다. 변화의 시기 속에서 하네스를 구축하는 것도 나름의 재미가 있지만 보람을 느낄 정도까지는 아닌 것 같아요. 코딩의 즐거움마저 뺏겼으니 제품에서 그 만족을 찾아야 하나 싶습니다.
회사에서도 저 나름의 의견을 내고 제안을 하기도 하지만, 역할상 많은 시간을 개발에 씁니다. 경험의 질적인 측면에서 제게 이로운 것인지 잘 모르겠습니다. 내가 혼자서 제품을 기획하고 개발하든, 동료들과 함께하든 간에 문제를 주도적으로 정의하고 해결하는 경험이 필요한 시대가 도래했다는 생각이 듭니다.