대 AI의 시대, 저 역시 클로드 코드 유저로서 PR리뷰 자동화 SKILL과 PR생성 자동화 SKILL등을 만들어 챕터에 공유하는 등 최근에는 주로 번거로우면서도 반복되는 업무를 자동화하기 위해 활용하고 있습니다.
그러다보니 2년전까지만 해도 AI에 유독 박했던 제가 여기까지 온게 인상깊기도 하여,, 제 가치관의 변동을 회고해보려 합니다.
저에게 있어 AI의 인식에 대해 큰 분수령이 두차례 존재했는데요. 2024년 말과 2025년 말 즈음으로 되돌아가보면
1. ~ 2024년 말#
당시에는 AI 코딩 에이전트는 존재하지 않았던건지 개발시장에서 주류는 아니었고 LLM 위주로 사용하였는데, 그 중에서도 ChatGPT가 가장 메이저였습니다.
공식문서 링크를 걸어주고 단순한 설명을 시키는 용도로 사용하는 것은 무난했습니다.
예를 들어
tanstack query에서 캐시를 초기화할 수 있는 방법은 뭐야?
라고 질문을 하면 setQueryData, invalidateQueries 등이 있다면서 용도별로 잘 답변해주었지만
막상 실제로 개발을 하면서 닥치는 시나리오 기반으로 설명한다고 했을 때에는 맥락을 잘 이해하지 못하는 듯한 뉘앙스에 답변이 대부분이었어요.
예를 들면
tanstack query를 사용하여 피드 리스트를 인피니티 스크롤로 구성하고 있어. 피드 중 한 아이템에 좋아요를 누르면 관련 데이터를 캐시를 업데이트해야 되는데 리스트 전체를 새로 다시 요청하는 것은 비효율적일 것 같아. 좋아요를 누른 아이템만 업데이트하는 방법이 없을까?
라는 시나리오를 던지면 제가 원했던 한 아이템만을 갱신할 수 있는 setQueryData가 아닌 리스트 전체를 새로 요청하는 invalidateQueries를 답변하는 경우가 있었습니다.
그 외에도 제가 어떤 상황 기반의 질문이나 가설을 제시했을 때 잘못된 답변을 교묘하게 그럴듯한 근거를 들어 정답인 척하며, 의아한 부분이 있어 반론은 제시하면 그제서야 너 핵심을 찔렀어같은 식의 피드백으로 화를 돋구는 사용감이 대부분이었습니다...
위같은 상황을 겪었던 당시를 회상해보면 AI가 아직 사용할 수준은 아니구나/신뢰할 수 없구나라고 느낀 점을 3가지로 추려볼 수 있을 것 같아요.
- AI가 같이 컨펌해주었다는 안도감에 저도 모르게 맞다는 전제하에 진행할 수 있는 위험
- 제 말을 객관적으로 평가하지 않고 그저 어떻게든 맞다고 증명해주려고 애쓰는 듯한 느낌
- 너 핵심을 찔렀다고 하면서 말하는 답변조차 잘 포장된 거짓일 수 있겠다.
즉 제 답을 객관적으로 볼 수 있는 능력도 없고, 저 또한 이에 속아 큰 스노우볼이 굴러가 시간낭비, 더욱 심하면 서비스에 잘못된 코드가 심어질 수도 있겠다 싶었습니다.
따라서 저는 2024년 말까지는 AI가 창작하는 것을 배제하기 위해 공식문서같은 객관적인 답안지를 링크로 줄 수 있을 때 위주로만 사용하였습니다.
2. ~ 2025년 말#
제 기억상으론 새로운 AI 모델이 속속이 등장하던 시기였습니다.
이 시기쯤 유명 기업 채용공고에서는 AI 활용을 잘하는 분을 우대한다라는 말이 보이기도 시작하는 등 업계가 한층 더 AI를 중요하게 바라보고 있구나라는 생각이 들더군요.
공식문서 기반의 잦은 문답으로 신뢰를 회복해서 그런건지, 모델들의 퀄리티가 산업 전반적으로 향상되어서 그런건지 예전보다 타율이 꽤 좋아진 듯한 느낌을 받고 있었던 때입니다.
이 때쯤에는 주요 로직을 짤 때 제가 하면 복잡하지만 AI가 하면 잘할 것 같은 업무들을 LLM에게 맡겨보곤 했습니다. 공식문서 기반인 것은 여전하지만 그것을 기반으로 창작해야 하는 등 조금의 생각이 더 필요한 작업으로요.
다만 컨벤션을 준수하는 등 기존 코드베이스를 이해해야 되거나 개발 도메인을 설명할 필요없는 작업들 위주의 작업을 주로 시켰습니다.
예를 들면 캘린더 로직이 있었습니다. MDN의 Date 객체의 링크를 주고 타겟이 된 달에 며칠이 있는지 세어서 배열에 날짜를 담아두는 로직을 짜달라고 요청했는데 꽤나 좋은 퀄리티로 짜줬던 경험이 있었습니다.
3. ~ 지금까지#
1) AI 에이전트 등장#
2025년 중후반쯤 됐을 새로운 종류의 AI 도구가 등장했는데요.
LLM과 달리 내 컴퓨터에서 직접 돌아가는 AI 에이전트라는 신문물이었습니다.
LLM을 사용하여 개발을 할 때 위에서 말했듯 기존 코드베이스나 개발 도메인을 이해하지 않아도 되는 부분에 한정해서만 사용했던 이유는
- 이런 규칙들은 기본적으로 양이 매우 많아 컨텍스트가 알맹이보다 서론이 더 길어 답변이 멍청해지는 할루시네이션 현상
- 심지어 매 세션마다 일일이 설명해야 됨
같은 문제로 인해 효율이 안나와서였는데
AI 에이전트는 프로젝트의 코드베이스를 읽을 수 있으므로 컨벤션 및 개발 도메인을 이해하고 있다는 전제하에 소통이 이루어진다는 것이 엄청 큰 메리트로 다가오더군요.
물론 메모리 파일로 가이드를 잡아주기도 해야하고 설명해야 하는 내용이 길수록 토큰 소비량이 많아 발생하는 비용문제 등 새로운 관점의 문제가 발생했지만 ㅎㅎ 장족의 발전이지요.
프롬프트를 짤 때 알맹이에만 집중할 수 있게 되었고, 할루시네이션도 많이 개선되었습니다
2) 자동화 방안#
AI 에이전트를 활용한 작업으로 가장 보람을 느꼈던 것은 제가 직접하면 시간을 많이 잡아먹고 수고가 많이 들며 반복되는 작업의 자동화였습니다.
예를 들면 PR 올리기, 팀원 PR 리뷰하기가 있지요.
제가 한 작업에 대해서 일일이 PR 내용을 작성하는 것이 꽤 번거로웠습니다.
어떠한 기획의 일환으로 작업한건지, 주요 파일은 무엇인지, 예외 처리는 어떠한 이유에서 이루어졌는지 등등 팀원을 이해시키기 위한 작문의 양 자체가 길기도 하고 맥락을 고려해서 작성해야 하는데에 시간을 너무 많이 잡아먹는 문제가 있었고,
반대로 제가 팀원의 작업을 리뷰할 때 내용이 잘 적혀있지 않으면 맥락을 이해해야 하는데에 수고가 많이 들었습니다
따라서 AI를 통해 자동화하면 효율이 많이 좋아지겠다 싶은 생각이 들었습니다
리뷰나 템플릿에 따른 내용 생성처럼 일정한 기준으로 이루어져야하는 작업이야말로 인간보다 AI가 더 잘 할 수 있는 영역이니까요.
팀 컨벤션으로 두기도 좋은 내용이다보니 SKILL(클로드 코드 기준)로서 규칙만 잘 정의하여 하네스만 잘채워두면 팀원 모두가 행복할 수 있겠구나싶었습니다.
마침 또 당시 코드래빗 툴을 도입할지 말지에 대한 논의가 있었는데 비싼 리뷰 툴을 사용하는 것보다 경제적이면서도 니즈에 충족되는 방향이었습니다.
팀원들이 각자 다른 AI 에이전트를 쓰다보니 관점이 다양하다는 장점도 있었습니다.
실제로 PR 스킬 사용 2달차인 지금, 누락된 예외처리 부분에 대해 언급을 남기거나 문제 발생이 우려되는 부분을 짚어주는 부분에서 PR 리뷰가 운영에 미치는 영향력이 상승한 것을 볼 수 있었습니다.
월간 웹 버그 리포트
- 리뷰 자동화 도입 전인 2026년 1월: 7건
- 리뷰 자동화 도입 후인 2026년 4월: 2건
배포 횟수 차이 등 다른 요인도 작용했겠지만 제가 인지하지 못했던 nullable 케이스나 코드만 봤을 때에는 예상할 수 없었던 race condition으로 인한 버그를 사전에 짚어주는 등 분명 영향이 있었어요.
예를 들면 리스트 필터기능을 팝업으로 구현했을 때, 팝업의 노출 여부도 히스토리로 관리되고 있다보니 필터 적용 시 query string 변경과 팝업 닫힘 사이에 race condition이 발생할 수 있다는 점을 지적해준 적이 있었습니다.
4. 앞으로 개발자는 어떻게 될까요?#
최근 비즈니스 업무에서도 AI 에이전트를 적극 활용하면서 느낀 점은 앞으로 개발자에게도 기획자로서의 역량이 요구될 것 같다는 점이었습니다.
어떤 기능에 대한 TF가 시작된다면 기획자분으로부터 전체적인 기획서를 받게 될텐데요. 받은 기획을 한번에 AI에게 그대로 맡긴다면
- 컨텍스트가 길어져서 할루시네이션 현상이 발생한다던가
- 기획서상 세부 정책이 누락된 것을 그대로 구현할 위험이 있습니다.
따라서 저는 큰 기획을 적절한 기능 단위로 나눠서 그 각각을 AI에게 컨텍스트로 제공하기 위해 한번 정제합니다.
예를 들어 유저간 서비스 내 재화를 주고받을 수 있는 응원박스라고 하는 기능에 대해 기획서를 받으면
- 응원박스를 유저간 주고 받을 수 있는 방법
- 응원박스 전송이 노출되는 페이지
- 응원박스를 보낼 수 있는 유저 조건
- 응원박스와 다른 기능 간 플로우
- POST API 엔드포인트
- 전송 에러 시 UI 표출 방법
- 전송 간 애니메이션 노출 방법 및 이미지 에셋 경로
- 내가 받은 응원박스는 어디서 보는지
- 받은 응원박스가 노출되는 페이지
- 어떠한 형태로 노출할 것인지 - 리스트? 캘린더?
- GET API 엔드포인트
- 조회 시 UI 표출 방법
등등 에이전트가 작업을 수월하게 할 수 있도록 나누고 세부 정책을 작성합니다.
이 과정에서 기획서에 누락되어 있던 정책(ex 정지 유저는 응원박스를 보낼 수 있는가?)을 발견할 수도 있지요.
이렇게 시나리오나 플로우, 기능에 대한 요구사항을 잘 정리하는 것이 AI 에이전트 코딩 시대에서는 부각되는 능력인 것 같습니다. 코드를 짜던 사람에서 코드를 어떻게 짜야하는지 설명하는 사람으로 메타가 변하고 있기 때문이지요.
여러분들은 어떻게 생각하시나요?