개발자가 AI를 활용하는 방법
코드는 이제 명세를 주면 AI가 뚝딱 구현해주는 시대가 되었어요.
생산성이 올라간 만큼 같은 시간 동안 생성되는 코드의 양도 압도적으로 많아졌어요.
이 글은 이런 시대에 생산성을 올리면서도 주도권을 잃지 않는 밸런스에 관한 고민으로 시작되었어요.
1. 빠른 건 이제 디폴트다
AI와 일하면서 생산성이 비약적으로 오른 건 확실해요. 새 기능 하나에 며칠씩 걸리던 게 몇 시간으로 줄었어요. 이 블로그를 만들 때도 처음 적용한 기술이 손가락으로 세지 못할 정도인데 큰 병목 없이 빠르게 구현해서 배포할 수 있었어요.
문제는 나중에 그 코드를 다시 건드려야 할 때예요. 낯선 영역을 AI가 빠르게 만들어주고 잘 동작하면 그걸 내 거라고 할 수 있을까요? 이건 외주에 가까워요.
그리고 이 속도는 이제 누구나 낼 수 있어요. '코드를 빨리 짜는 능력'은 이제 큰 변별력을 발휘하지 못해요. 그러면 뭐가 남을까… 이게 가장 고민이 되는 질문이에요.
2. 설계에 더 공을 들여요
설계를 먼저 잡는 건 원래도 하던 일이지만 달라진 건 거기에 쓰는 비중이에요. 구현이 빨라지면서 결과를 가르는 무게가 코드보다 설계로 옮겨갔어요. AI는 명세를 주면 빠르게 만들어주지만 구조가 모호하면 결국에는 그 결과를 나중에 갈아엎어야 할 수 있어요. 그래서 구현에 들어가기 전에 설계를 더 단단하게 잡으려고 해요.
다듬는 방식도 달라졌어요. 큰 그림은 제가 잡되 세부적인 내용은 AI와 주고받으며 수정해요. 책임을 어디에 둘지, 이 경우엔 어떻게 흘러야 할지 등을 티키타카하다 보면 혼자 볼 때보다 빈약한 부분이 빨리 드러나요. 디테일까지 합의가 되면 구현 계획을 세우고 구현에 들어가요.
설계에서 제일 신경 쓰는 건 어떻게 간결하고 유지보수하기 쉬운 구조를 짤 것인가예요. AI는 오버 엔지니어링하려는 경향이 강해요. 간단한 로직에도 만약을 대비한 분기를 넣고 예외 처리를 겹겹이 쌓아요. 무엇이 필요 없는지는 우리 프로젝트를 아는 사람만 알아요. 그래서 빼는 결정의 주도권은 꼭 사람이 가져가야 한다고 생각해요.
플랜을 검토받는 과정도 따로 둬요. 코드를 짜기 전에 플랜 단계에서 한 번 리뷰를 받아요. 구조가 현재 수준에서 적정한지, 놓친 유즈케이스는 없는지 등을 구현 전에 체크하면 호미로 막을 것을 가래로 막지 않아도 돼요.
3. 맥락을 문서로 남겨요
AI한테는 묘한 비대칭이 있어요. 세상의 코드는 거의 다 봤으면서도 정작 우리 프로젝트는 처음 봐요. 맥락을 안 주면 우리 컨벤션이 아니라 모든 코드의 평균값으로 답해요.
그래서 컨텍스트를 문서로 고정했어요. AGENTS.md나 CONVENTION.md 같은 공식 문서에 팀이 합의한 코드 컨벤션과 디자인 패턴 등을 적어두고 기능을 만들기 전에 Tech Spec을 먼저 썼어요. 머릿속에만 있던 규칙을 글로 내려두면 사람한테 설명할 때도 AI한테 시킬 때도 같은 기준이 돼요. 단순 반복 작업을 에이전트에 맡겨도 결과가 들쭉날쭉하지 않고요.
문서로 남기는 게 코드 규칙만은 아니에요. 도메인 지식도 함께 적어둬요. AI는 코드는 잘 짜도 우리 서비스가 왜 이렇게 동작하는지는 몰라요. 예약을 며칠 전까지 취소할 수 있는지, 어떤 용어가 우리 도메인에서 무슨 뜻인지 같은 건 코드만 봐서는 안 나오거든요. 회의에서 정해지고 사람 머릿속에만 있던 규칙을 글로 내려두면 AI도 그 맥락 위에서 판단해요.
개인 프로젝트도 비슷해요. 이 블로그에는 CLAUDE.md를 두고 "같은 코드가 세 번 넘게 반복될 때만 추상화한다" 같은 규칙을 적어놨어요. 회사 문서가 여럿이 같은 출발선에 서기 위한 거라면 이건 혼자라도 며칠 뒤의 나와 AI가 헤매지 않게 하려는 거예요.
명시적으로 적어두면 검사도 자동화할 수 있어요. 반복해서 지적하던 컨벤션은 린트 룰로 만들어두면 사람이 매번 볼 필요가 없어져요. 규칙이 글로 있어야 기계한테 맡길 수도 있더라고요.
4. 환경을 프로그래밍해요
코드를 직접 짜는 시간이 줄면서 프로그래밍하는 대상 자체가 바뀌고 있어요. 요즘 제가 짜는 건 기능보다 AI가 일을 잘하게 만드는 환경일 때가 많아요.
하나는 하네스예요. AI가 엉뚱한 판단을 하지 않도록 필요한 맥락을 미리 갖춰주는 코드예요. 이 블로그의 챗봇을 만들 때 글과 실제 코드가 어긋나는 문제가 있었어요. 글에는 "SEO는 나중에"라고 써놨는데 코드에는 이미 다 들어가 있었거든요. 챗봇은 글만 보고 아직 안 했다고 답했고요. 그래서 빌드할 때마다 코드베이스 현황을 코드에서 직접 뽑아 챗봇한테 이걸 먼저 보라고 했어요. 이렇게 AI가 정확히 판단할 토대를 마련해두는 게 하네스예요.
또 하나는 AI에게 일할 도구를 연결해주는 일이에요. MCP로는 AI가 우리 시스템이나 데이터에 직접 접근할 수 있게 해요. 스킬로는 자주 하는 작업의 프로세스를 미리 정의해두고요. 이렇게 해두면 단순하고 반복적인 일은 통째로 맡길 수 있어요. 이런 에이전트 환경을 잘 갖춰두어야 비로소 사람이 판단이 필요한 일에 더 집중할 수 있어요.
참고로 이 블로그의 챗봇과 검색을 어떻게 만들었는지는 따로 적어둔 글이 있어요.
5. 빠르게 만들어서 보여줘요
아이디어가 떠올랐을 때 예전엔 문서로 정리하거나 회의에서 말로 설명했어요. 지금은 그 시간에 일단 만들어요. 구현이 빨라지면서 설명하는 것보다 직접 만들어 보여주는 게 빠를 때가 많아졌거든요.
떠오른 걸 빠르게 동작하는 형태로 옮기고 프리뷰로 띄워요. 작업하던 걸 바로 배포해서 링크 하나로 열어볼 수 있게요. 머릿속 설명은 사람마다 다르게 받아들이는데 화면은 그렇지 않아요. 동작하는 걸 같이 보면 이 방향이 맞는지 한눈에 알 수 있어요.
띄워놓고 직접 테스트하면서 발전시켜요. 글로 볼 때 안 보이던 게 화면에선 더 와닿아요. 여기 흐름이 어색하다거나 이 단계는 빼도 되겠다는 판단이 빨리 나와요.
6. 마지막 판단은 사람이 해요
속도가 빨라지고 위임이 늘수록 마지막에 사람이 보는 일이 더 중요해져요. 어디까지 AI에 맡기고 어디서 멈출지 그 경계를 정하는 일이 AI와 협업에서 가장 모호했어요.
코드 리뷰가 좋은 예예요. 네이밍이나 접근성 같은 반복적인 지적은 LLM한테 1차로 맡겨요. 사람이 매번 똑같은 걸 짚는 데 시간을 쓸 필요가 없거든요. 대신 사람은 AI가 짠 이 코드가 정말 의도와 맞는지를 봐요. AI 코드는 겉으로는 말끔해 보여서 더 위험해요. 그럴듯한데 미묘하게 틀린 걸 잡으려면 우리 흐름을 아는 사람이 의심하며 읽어야 해요.
AI한테 일을 시키는 것과 결과의 책임까지 넘기는 건 달라요. 시키는 건 얼마든지 하되 마지막에 책임지는 자리에는 사람이 있어야 해요. 그렇지 않으면 외주와 다를 바 없어요.
마무리
돌아보면 제가 하는 일은 이미 코드를 짜는 쪽에서 멀어졌어요. 대신 설계를 잡고 맥락과 환경을 챙기고 어디까지 맡길지 정하는 쪽으로 옮겨갔어요. AI가 빠르고 똑똑해질수록 오히려 틀린 답도 그럴듯하게 내놓을 수 있어서 이 자리가 더 중요해지더라고요.
그래서 새 작업을 받으면 코드부터 열지 않아요. 무엇을 만들지 정하고 AI한테 뭘 줄지 어디까지 맡길지부터 정리해요. AI를 잘 쓴다는 건 많이 맡기는 게 아니라 어디까지 맡길지를 아는 거라고 생각해요.
