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