요즘 나는 AI를 어떻게 활용하고 있는가
2026년 5월 14일날이 가면 갈수록 개발하며 AI를 사용하는 비중이 커지고 있다.
예전처럼 모르는 것을 물어보고 공부하는 용도나, 국소적인 부분에 한해 코드 일부를 완성하는 것에서 나아가, 요즘은 작업 방식 자체가 바뀌고 있다.
이제는 AI를 코드 자동완성 도구라기보다는, 작업 단위로 일을 넘길 수 있는 도구에 가깝게 쓰고 있다. 내가 직접 한 줄 한 줄 코드를 치기보다는, 먼저 이슈에 맥락을 정리하고, 관련 조건을 적어두고, AI가 그걸 읽고 작업할 수 있게 만드는 쪽에 더 신경 쓰게 됐다.
그러다 보니 자연스럽게 내가 하는 일도 조금 바뀌었다. 코드를 직접 쓰는 시간은 줄었고, 대신 “어떤 일을 시킬지”, “어떤 맥락을 줘야 할지”, “결과물을 어떻게 검토할지”에 시간을 더 쓰게 됐다.
예전에는 AI를 잘 쓰는 게 프롬프트를 잘 쓰는 거라고 생각했는데, 요즘은 조금 다르게 느낀다. AI를 잘 쓰려면 결국 일을 잘게 나누고, 맥락을 잘 정리하고, 결과물을 검토할 수 있어야 한다.
그러니까 그냥 개발을 안 하게 됐다기보다는, 개발의 모양이 조금 바뀐 느낌이다.
요즘 쓰는 AI들
요즘 가장 많이 쓰는 조합은 Claude Code와 Codex다.
둘 중 하나만 쓰는 건 아니고, 둘 다 쓰고 있다. 어느 하나가 압도적으로 모든 걸 잘한다기보다는, 각자 잘 하는 게 있어서 섞어서 쓰고 있다.
대충 역할을 나누면 Claude Code는 실제 작업을 시킬 때 많이 쓰고, Codex는 코드 리뷰나 다른 관점에서 검토할 때 많이 쓴다.
Claude Code한테 이슈 하나 던져주고 작업하게 한 다음, Codex한테 다시 코드 리뷰를 시킨다든가. 반대로 omc code reviewer를 돌려서 한 번 더 보게 한다든가. 사람이 개발할 때도 작성자와 리뷰어를 나누는 것처럼, AI도 구현자와 리뷰어를 나눠 쓰는 쪽이 더 안정적인 것 같다.
물론 그렇다고 AI 리뷰를 그대로 믿는 건 아닌데, AI가 잡는 것도 있고, 못 잡는 것도 있고, 괜히 트집 잡는 것도 있다. 가끔은 맥락을 잘못 이해하고 이상한 소리를 하기도 한다.
그래도 내가 처음부터 모든 코드를 다 뜯어보기 전에, 위험해 보이는 부분을 한 번 걸러주는 용도로는 꽤 쓸만하다. 혼자 봤으면 놓쳤을 만한 부분을 잡아주는 경우도 있고, 반대로 “이건 AI가 괜히 지적한 거네” 하면서 내 판단을 정리하는 데 도움이 되기도 한다.
나보다 잘 하는 사람이 너무 많다
Claude Code는 스킬을 직접 만들어 쓰기보다는, 이미 잘 만들어진 스킬을 가져다 쓰는 쪽으로 가고 있다. 주로 omc, omx 선에서 다 해결되더라.
처음에는 직접 내 입맛대로 이것저것 만들면 좋지 않을까 싶었다.
근데 막상 생각해보면 스킬을 잘 만드는 것도 일이다. 잘 설계해야 하고, 계속 관리해야 하고, 바뀐 작업 방식에 맞게 업데이트도 해야 한다.
이러다 보면 배보다 배꼽이 커진다.
그래서 지금은 직접 다 만들기보다는, 이미 잘 만들어진 것들을 가져와서 쓰는 쪽이 더 낫다고 느끼고 있다. 필요한 부분만 조금씩 맞춰서 쓰면 충분한 경우가 많았다.
자주 쓰는 건 대충 이런 것들이다.
/omc-plan --consensus --interactive
/deep-interview
omc code-reviewer/omc-plan --consensus --interactive는 바로 구현시키기 전에 자주 쓴다.
AI한테 냅다 “이거 해줘” 하고 맡기면 편하긴 한데, 조금만 작업이 커져도 얘가 무슨 생각으로 뭘 하려는지 먼저 봐야 한다.
안 그러면 나중에 결과물을 보고 “아니 이게 아닌데…” 하면서 다시 돌려야 하는 경우가 생긴다. 그래서 일단 계획을 세우게 하고, 그 계획을 보고 방향이 맞는지 확인한 다음 작업을 시키는 편이다.
/deep-interview는 내가 머리가 안 돌아갈 때 자주 쓴다.
뭔가 정리해야 하는데 내가 처음부터 깔끔하게 명세를 못 쓰겠으면, 그냥 AI가 질문하게 두고 거기에 답하면서 생각을 정리한다. 뇌를 조금 빼고 싶을 때 쓴다.
omc code-reviewer는 구현 후 1차 리뷰용으로 자주 쓴다. 완벽하진 않지만, 그래도 한 번 돌려놓으면 자잘한 실수나 놓친 포인트를 잡아주는 경우가 있다.
ralph는... 토큰이 모자라서 잘 안 쓰게 되더라.
MCP는 필요한 것만
MCP는 GitHub, Linear, Slack, 가끔 Figma 정도만 붙여서 쓰고 있다.
처음에는 이것저것 다 붙여놓고, 뭔가 많이 연결해두면 엄청난 자동화 환경이 생길 것 같고, 모든 게 유기적으로 돌아갈 것 같고, 그런 헛된 기대를 품고 이것저것 찾아봤는데, 결국 자주 쓰는 건 정해져 있더라.
코드는 GitHub에 있고, 이슈는 Linear에 있고, 커뮤니케이션은 Slack에 있고, 디자인 맥락은 Figma에 있고... 실무에서 AI가 진짜로 참고해야 하는 맥락도 대부분 여기에 있다.
그리고 많이 붙이면 붙일수록 Context Window를 계속 붙잡아두고 있기 때문에... 딱 쓸 것만 빼고 정리했다. 지금은 저 정도만 붙여도 충분하다고 느끼고 있는데, 계속 써보면서 조금씩 조정해봐야 할 것 같다. 지금 느끼는 바로는 괜히 이것저것 다 붙여놓는다고 생산성이 올라간다기보다는, 실제 작업 흐름에 들어오는 도구를 제대로 연결하는 게 더 중요한 것 같다.
VSCode(Cursor)를 버렸다
예전에는 Cursor를 꽤 많이 썼다.
VSCode 기반이라 익숙했고, 자동완성도 좋았고, 채팅으로 코드 수정하기도 편했다. 한동안은 그냥 메인 에디터처럼 썼다.
근데 요즘은 아예 안 쓴다.
Cursor가 갑자기 별로가 됐다기보다는, 내 작업 방식이 바뀌어서 굳이굳이 싶어졌다. 예전에는 내가 직접 코드를 많이 썼으니까, Extension도 중요하고, 자동완성도 중요했다. 한 줄 치면 다음 줄 예측해주고, 함수 뼈대 만들어주고, 반복 코드 채워주고. 이게 꽤 유용했다.
근데 요즘은 간단한 수정이나 반복적인 구현을 Claude Code에 작업 단위로 맡기는 경우가 많다. 그러다 보니 에디터 안에서 한 줄씩 자동완성을 받는 경험의 중요도가 많이 낮아졌다.
이렇게 되니까 에디터에 기대하는 것도 달라졌다. Extension 몇십개씩 주렁주렁 달고, AI 기능이 빵빵한 무거운 IDE보다, 그냥 빠르고 가벼운 에디터가 더 편해졌다. 그래서 요즘은 VSCode도 Cursor도 안 쓰고, Zed를 메인으로 쓰고 있다.
Zed
다들 써보세요 정말 좋아요
일단 가볍다. 요즘은 코드를 직접 오래 붙잡고 치는 일이 줄어서 그런지, 에디터가 빠릿빠릿한 게 생각보다 크게 느껴진다. Cursor나 VSCode가 못 쓸 정도로 느리다는 건 아닌데, Zed를 쓰다 보면 확실히 가벼운 쪽이 주는 쾌적함이 있다.
아직 베타 느낌이 좀 있어서, 업데이트도 자주 되고, 기능도 계속 생긴다. 얼마 전에는 Git branch tree view도 생겼는데, 이게 들어온 뒤로는 훨씬 좋아졌다. 그전에는 Git 쪽이 좀 아쉬웠는데, 이제는 일상적인 작업에서는 크게 불편하지 않다.
물론 다 좋은 건 아니다.
Extension이 아직 많이 아쉽다. 몇 개 없어서 엄청난 기능을 기대할 수는 없지만... 그래도 나름 쓸만한 건 다 있어서 그럭저럭 괜찮은 편이다.
그리고 업데이트가 잦다. 잦은만큼, 여기 있던게 저기로 옮겨가기도 하고, 아무도 안 쓸 것 같은 기능이 갑자기 메인으로 생기기도 하고. 그래도 대부분은 커스텀해서 없애버리거나, 다듬을 수 있어서 그건 만족스럽다.
다만, tab 자동완성은 아직 확실히 많이 아쉽다. 가끔 Cursor가 그리워지는 포인트다. Zed 쪽 자동완성은 쓰레기같아서... 그냥 꺼두고 쓰고 있다. 근데 뭐 요즘은 자동완성 자체를 그렇게 많이 안 쓰니까... 크게 문제는 안 되더라.
Linear issue body를 plan 파일처럼
회사에서는 이슈 관리를 Linear로 하고 있다.
그리고 요즘은 Linear issue body에 꽤 공을 들이고 있다. 이게 그냥 “이슈 설명을 친절하게 쓴다” 정도가 아니라, AI가 읽고 작업할 수 있는 컨텍스트 저장소처럼 쓰는 느낌에 가깝다.
간단한 수정은 Claude Code가 잘하긴 하는데, 잘 하게 하려면 context가 충분해야 한다.
무엇을 바꿔야 하는지, 왜 바꿔야 하는지, 기존에는 어떤 문제가 있었는지, 어떤 파일을 보면 되는지, 주의해야 할 제약은 뭔지. 이런 것들이 없으면 AI가 알아서 코드베이스를 뒤지긴 하는데, 이상한 방향으로 가거나 불필요하게 범위를 넓히는 경우가 생긴다.
그래서 요즘은 이슈 본문에 최대한 context를 넣어두려고 한다.
느낌상 plan 파일을 따로 만드는 대신, Linear issue body를 plan 파일처럼 쓰는 것에 가깝다.
물론 모든 이슈를 엄청 자세하게 쓰는 건 어렵다. 그렇게 하면 이슈 하나 쓰다가 하루가 간다. 그건 또 그것대로 이상하니까...
그래서 Linear MCP를 붙여서 알아서 코드베이스 분석하고 이슈까지 작성해서 등록하도록 시킨다. 나중에 Linear 들어가서 슥 훑어보고 슬쩍슬쩍 손만 보면 되니까 이슈 관리 비용이 많이 줄었다.
이렇게 해두면 나중에 Claude Code에게 이슈 링크만 던져도 어느 정도 작업이 가능하다. 내가 직접 작업하는 이슈의 작업성도 좋아졌다.
예전에는 머릿속에 맥락을 들고 바로 코드부터 수정하는 경우도 많았다. 근데 AI에게 일을 맡기려면 그 머릿속 맥락을 밖으로 꺼내야 한다. 이 과정이 귀찮긴 한데, 막상 해두면 이슈 품질도 좋아지고, 나중에 다시 볼 때도 편하다.
그러니까 AI를 쓰려고 문서를 잘 쓰기 시작했는데, 결과적으로 사람에게도 좋은 문서가 되는 셈이다.
간단한 이슈 작업 흐름
요즘 간단한 이슈는 대충 이런 식으로 처리한다.
- 내가 작업할 이슈를 고른다.
- Claude Code에게 Linear 이슈 링크를 던진다.
- Claude가 이슈 내용을 읽고 관련 파일을 확인한다.
- 이슈 번호를 포함해서 브랜치명, 커밋, PR 컨벤션을 맞춘다.
- 구현한다.
- omc code-reviewer를 돌린다.
- 나온 지적사항을 다시 수정한다.
- PR까지 올린다.
- 내가 최종 확인하고 수정하거나 머지한다.
글로 쓰면 좀 거창해 보이는데, 실제로는 그냥 “이 이슈 작업해줘”에 가깝다. 대신 이슈 본문이 어느 정도 잘 작성되어 있어야 한다.
물론 항상 잘 되는 건 아니다.
UI가 많이 들어가거나, 제품 판단이 필요하거나, 기존 구조를 크게 바꿔야 하는 작업은 아직 내가 많이 봐야 한다. AI가 혼자 적당히 해버리면 안 되는 영역이 있다.
그래도 명확한 기능 수정, API 연동, 기존 패턴을 따르는 반복 작업, 단순 리팩터링 같은 건 꽤 잘한다. 특히 내가 이슈 본문에 “이 파일을 참고해라”, “이 패턴을 따라라”, “이 케이스는 건드리지 마라” 같은 식으로 잘 적어두면 성공률이 꽤 올라간다.
결국 중요한 건 “AI가 똑똑한가?”도 있지만, “AI가 볼 수 있는 맥락이 충분한가?”인 것 같다.
기술 부채를 발견했을 때도 방식이 바뀌었다
작업하다 보면 마음에 안 드는 코드가 계속 보인다.
이건 어쩔 수 없다. 기능 하나 고치려고 들어갔는데, 옆에 이상한 추상화가 보이고, 더 들어가면 중복 코드가 보이고, 또 들어가면 예전에 급하게 처리한 흔적이 보인다.
예전에는 이럴 때 둘 중 하나였다.
바로 고치거나, 아니면 나중에 고쳐야지하고 까먹든가...
근데 바로 고치면 현재 작업 범위가 터진다. 분명 작은 이슈 하나 처리하려고 시작했는데, 갑자기 리팩터링이 끼어들고... PR 범위가 넓어지고... 리뷰하기 어려워지고.... 욕도 먹고... '이거 누구 마음대로 같이 바꿔?' 소리 듣기 딱 좋기도 하고..
반대로 머릿속에만 남겨두면? 높은 확률로 까먹는다. 나중에 같은 코드를 보고 '아 이거 전에 고치려고 했는데' 하고 다시 깨닫는다. 그리고 또 까먹는다. (청년치매 아님)
요즘은 이런 걸 발견하면 바로 고치기보다는, Claude Code에게 관련 코드베이스를 분석시키고 Linear 이슈를 만들게 한다.
대충 이런 식이다.
이 부분 구조가 (이러이러해서) 마음에 안 드는데, 관련 코드베아스 분석해서 어떤 문제가 있는지 파악하고, 수정 방향 간단하게 잡아서 Linear에 백로그 잡아줘. Linear 이슈 템플릿은 @issue_template_refactor.md 사용해줘.
그러면 AI가 현재 구조, 문제점, 개선 방향, 관련 파일 등을 정리해서 이슈를 만들어준다. 물론 그대로 두면 너무 장황하거나 애매할 때도 있어서 내가 조금 다듬긴 한다.
그래도 이렇게 해두면 최소한 기억속으로 사라지지는 않는다. 그리고 나중에 실제로 작업할 때, 이미 문제의식과 맥락이 이슈에 남아 있어서 진입하기가 훨씬 편하다.
아직까지는 이 방식이 꽤 마음에 든다. 당장 고치지 않으면서도 기술 부채를 그냥 흘려보내지 않을 수 있다. 현재 작업 범위를 지키면서, 나중에 처리할 수 있는 형태로 남겨두는 것이라고 보면 되지 않을까.
Cycle 회고
매 Cycle이 끝나면, Codex한테 Linear MCP 붙여서 사이클 분석을 돌려보고 있다. 단순한 통계가 아니라, LLM만이 할 수 있는 것들 위주로 시키면 아주 볼만한 자료가 나오더라. 예를 들어, tag sanity 체크라든가, 이슈 overdue 현황이라든가, 왜 이랬을까라든가, 단순히 이슈 몇 퍼센트 쳐냈어요가 아니라, 각 팀원별로 어떤 식으로 태스크를 쳐냈는지 꽤나 그럴싸하게 분석해준다. 내부 공유용으로 몇 번 뿌려봤는데 반응이 나쁘지 않더라.
아직 AI에게 맡기기 어려운 것들
그렇다고 모든 걸 AI에게 맡길 수 있는 건 아니다.
아직까지는 사람이 봐야 하는 부분이 꽤 많다. 특히 아키텍처를 어떻게 가져갈지, 어떤 trade-off를 감수할지, 요구사항을 어떻게 해석할지는 내가 직접 판단해야 하는 경우가 많다. 왜냐? 내가 책임져야 하거든...
예를 들어 어떤 feature 하나를 구현한다고 했을 때, 그냥 빨리 붙이는 게 맞을 수도 있고, 이번 기회에 구조를 정리하는 게 맞을 수도 있다. 혹은 지금은 일부러 적당히 타협하고, 다음 사이클에 제대로 가져가는 게 맞을 수도 있다.
이건 코드만 보고 결정할 수 없다. 일정, 팀 상황, 디자인 진행 상태, 백엔드 준비 여부, 앞으로의 변경 가능성 등 팀 내 상황 같은 것들이 다 맞물려서 들어간다.
AI에게 이런 맥락을 최대한 적어줄 수는 있지만... 근데 그럼에도 최종 판단은 사람이 하는 게 맞지 안나 싶다. 적어도 아직은?
UI는 아직 잘 못 다루는 것 같다
특히 UI는 아직 많이 아쉽다.
기능성 코드는 꽤 잘 붙인다. API 연결하고, 상태 관리 붙이고, 기존 훅 패턴 따라가고, 타입 맞추고, 반복적인 컴포넌트 수정하고. 이런 건 꽤 잘한다.
근데 UI는 좀 다르다. 화면 밀도, 여백, 텍스트 위계, 인터랙션, 디자인 시스템과의 일관성 같은 부분은 아직 사람이 보는 게 훨씬 낫다고 느껴진다.
Figma MCP 붙여서 “디자인에 맞게 구현해줘”라고 해도, 실제로는 꽤 많이 봐야 한다. 그래서 나는 UI 코드는 아직 직접 짜는 편이다. 적어도 화면의 골격이나 중요한 컴포넌트는 내가 잡고, AI는 그 뒤에 기능을 붙이거나 반복적인 수정, API 연동, 리팩터링을 하는 쪽으로 쓰는 경우가 많다.
AI를 잘 쓰려면 '무엇을 맡길 수 있는지'만큼 '무엇을 맡기면 안 되는지'도 알아야 하는 것 같다.
학교에서
학교에서도 AI를 꽤 쓰고 있다.
이번 시험 기간에는 원탁님이 만든 tutor-skills를 사용해서 공부해봤다. 컴네 강의자료 모아다 때려넣고, 개념 공부하고, 만들어준 퀴즈 풀어보면서 딱 하루 공부하고 봤는데 94점이 나왔다. 감사합니다!
물론 AI가 공부를 대신 해준다는 뜻은 아니다. 그래도 시험 범위가 넓을 때, 자료를 빠르게 훑고 중요한 개념을 압축해서 보고, 내가 뭘 모르는지 찾아내는 데는 확실히 도움이 된다. 특히, 멍청한 질문을 해도 잘 받아준다는 게 좋고, 눈치 안 보고 질문해도 된다는 점이 좋다.
과제나 프로젝트 과목에서도 쫌쫌따리 쓰고 있다. 요즘 프로젝트 과목이 많아서 그런지, 코드 짜는 것 말고도 할 일이 많은데, 천상 공돌이라 글재주가 별로 없어서, 보고서 써야 하고, 발표 준비해야 하고, 회의록 정리해야 하고, 요구사항 정리해야 할 때 큰 도움이 되주고 있다.
AI를 많이 쓸수록 컨텍스트 관리가 중요해진다
요즘 느끼는 건, AI를 잘 쓰는 핵심이 단순히 프롬프트를 잘 쓰는 건 아니라는 점이다.
아니 프롬프트도 중요하긴 하지, 근데 그보다 더 중요한 건 컨텍스트를 어디에, 어떤 형태로 쌓아둘지가 더 중요하지 않나는 생각이 점점 커지고 있다.
회사에서는 Linear issue body가 그 역할을 꽤 해주고 있다. 이슈에 배경, 요구사항, 제약, 관련 파일, 주의사항을 적어두면 AI가 그걸 읽고 작업할 수 있다. 그리고 그 기록은 AI뿐만 아니라 나중의 나와 팀원에게도 도움이 된다.
이게 생각보다 중요하다.
AI에게 일을 맡기려면 내가 먼저 일을 이해하고 있어야 한다. 내가 뭘 원하는지 모르면 AI도 제대로 못 한다. 내가 제약을 모르면 AI도 제약을 어긴다. 내가 결과를 검토할 수 없으면 AI가 만든 결과가 맞는지도 모른다.
결국 AI를 많이 쓴다고 해서 개발자가 할 일이 없어지는 건 아닌... 것 같다? 대신 해야 하는 일이 조금 (많이) 바뀐 것 같다.
직접 코드를 덜 칠 수는 있다. 하지만 문제를 더 명확하게 설명해야 하고, 작업을 더 잘게 나눠야 하고, 결과물을 더 잘 검토해야 한다.
마치며
요즘 내 AI 활용 방식은 예전과 꽤 달라졌다.
예전에는 AI를 코드 자동완성 도구로 봤다. Cursor 안에서 자동완성 받고, 모르는 걸 물어보고, 귀찮은 코드 생성을 조금 맡기는 정도였다.
하지만 지금은 조금 더 작업을 위임하는 식으로 사용해보고 있다.
Linear 이슈에 맥락을 정리해두고, Claude Code에게 작업을 맡기고, Codex나 code reviewer로 다시 검토하고, 내가 최종 판단한다. 기술 부채를 발견하면 바로 고치기보다 이슈로 남기고, 반복적인 구현은 AI에게 넘긴다.
그렇다고 AI가 모든 걸 해결해주는 건 아니다. 책임은 쓰는 사람이 져야하거든... AI가 잘하는 영역과 못하는 영역도 꽤 분명하다.
그래도 반복적인 구현, 리뷰, 문서화, 이슈 정리의 부담은 확실히 줄어들었다. 대신 컨텍스트를 잘 정리하는 일이 더 중요해졌다.
요즘은 그래서 이런 생각을 자주 한다.
AI를 잘 쓰는 능력은 코드를 덜 쓰는 능력이 아니라, 일을 더 잘 설명하는 능력에 가까운 것 아닐까?
결국 사람이든 에이전트든, 일을 잘 시키려면 먼저 내가 그 일을 잘 이해하고 있는게 우선이 아닐까. 그 점은 AI를 쓰기 전이나 지금이나 별로 달라지지 않은 것 같기도 하고...