AI 코딩 도우미, 코드 품질 저하 우려? 오히려 '기술 부채' 해결사 될 수 있다!
요즘 개발 현장에서는 AI 코딩 도우미에 대한 기대감과 함께 걱정 어린 시선도 존재합니다. 'AI가 써준 코드가 품질이 떨어지면 어쩌지?', '빨리빨리 찍어내는 코드에 우리가 속고 있는 건 아닐까?' 하는 우려 말이죠. 하지만 사실 AI는 우리가 흔히 겪는 '기술 부채'를 해결하고 오히려 더 나은 코드를 생산하는 데 결정적인 역할을 할 수 있습니다. 코딩 AI가 단순히 빠른 코드를 넘어 '좋은 코드'를 만들도록 돕는 방법, 함께 알아볼까요?
'AI가 쓴 코드, 혹시나 저품질일까?' 걱정은 이제 그만
많은 개발자들은 AI에게 코드 작성을 맡기면 결과물의 품질이 떨어질까 염려합니다. 겉보기에는 그럴듯하지만, 실제로는 유지보수가 어렵거나 예상치 못한 문제를 일으키는 '나쁜 코드'가 양산될 수 있다는 것이죠. 만약 AI 도구를 도입했을 때 실제로 생산되는 코드의 품질이 눈에 띄게 떨어진다면, 이는 AI 때문이라기보다는 우리 개발 프로세스 자체의 문제점을 직접적으로 파고들어 해결해야 할 신호입니다. AI를 사용한다고 해서 꼭 저품질 코드를 만들어낼 이유는 없으며, 오히려 AI를 통해 더 나은 품질의 코드를 만드는 선택을 할 수 있습니다.
'기술 부채'는 어떻게 AI와 함께 줄여나갈 수 있을까?
소프트웨어 개발에서 '기술 부채'는 마치 금리가 붙는 대출과 같습니다. 당장 시간이 부족하거나 제약 때문에 '가장 좋은 방법' 대신 '빠르게 해결하는 방법'을 선택했을 때 발생하죠. 그리고 나중에 이 부채를 갚기 위해 시간을 투자해야 합니다. 하지만 프로젝트가 살아남아 시간을 벌어주지 못하면, 그 부채는 그대로 쌓여 나중에 더 큰 문제가 됩니다.
저는 이 기술 부채를 관리하는 가장 좋은 방법은 처음부터 기술 부채를 만들지 않는 것이라고 생각합니다. 그런데 경험상, 기술 부채를 해결하는 많은 경우들이 사실은 개념적으로는 단순하지만 시간은 오래 걸리는 작업들이었습니다. 예를 들어볼까요?
- 처음 API를 설계했을 때는 생각지 못했던 중요한 케이스가 나중에 발견되었을 때. 이를 해결하려면 수십 군데의 코드를 고쳐야 하는데, 시간이 없으니 조금 다른 새로운 API를 만들어 복제본으로 두는 선택을 하곤 합니다.
- 프로젝트 초기에 개념을 잘못 이름 지었던 경우 ('팀' 대신 '그룹' 같은). 모든 코드에서 그 명칭을 바꾸는 것은 너무 많은 작업이라, UI에서만 고치고 넘어가는 식이죠.
- 시간이 지나면서 시스템에 비슷하지만 약간 다른 기능들이 중복되어 쌓이고, 이를 합치고 리팩토링해야 할 때.
- 어떤 파일 하나가 수천 줄로 늘어나서, 이상적으로는 여러 모듈로 분리해야 하지만 당장 다른 급한 문제들 때문에 손대기 어려울 때.
이런 작업들은 모두 머리로는 간단하지만, 실제로 시간을 들여야 하는 일들이죠. 더 급한 문제가 쌓이다 보면 좀처럼 우선순위를 높이기가 어렵습니다. 바로 이런 지점들에서 코딩 AI가 빛을 발할 수 있습니다.
AI, 반복적이지만 중요한 '리팩토링' 작업을 대신해준다
앞서 말한 리팩토링 작업들은 코딩 AI에게 아주 이상적인 적용 사례입니다. AI에게 어떤 부분을 어떻게 바꾸라고 지시하고, 백그라운드에서 작업하도록 맡겨두는 것이죠. 저는 보통 Gemini Jules, OpenAI Codex web, 또는 Claude Code on the web과 같은 비동기 코딩 에이전트를 사용합니다. 이렇게 하면 노트북 흐름을 방해받지 않고 백그라운드에서 리팩토링 작업을 실행할 수 있거든요. 작업이 끝나면 Pull Request로 결과를 평가하고, 좋으면 바로 적용합니다. 만약 조금 부족하다면, AI에게 다시 한번 지시해서 보완하게 할 수도 있고요. 결과가 영 별로라면, 그냥 버리면 됩니다.
이렇게 코드 개선에 드는 비용이 극적으로 낮아졌기 때문에, 우리는 사소한 코드 스멜이나 불편함에 대해 '무관용' 태도를 가질 수 있게 되었습니다. 예전에는 시간과 노력이 많이 들어 망설였던 일들을 이제는 AI 덕분에 부담 없이 처리할 수 있게 된 셈이죠.
AI는 놓칠 수 있는 '새로운 아이디어'까지 제시한다
모든 소프트웨어 개발 작업에는 문제를 해결하기 위한 수많은 선택지가 있습니다. 그런데 때로는 계획 단계에서 잘못된 선택을 해서 기술 부채가 쌓이기도 합니다. 예를 들어, 너무 뻔해서 생각조차 하지 못했던 간단한 해결책을 놓치거나, 나중에 보니 우리 프로젝트에 완벽하게 맞지 않는 기술을 선택하는 경우죠.
LLM(거대 언어 모델)은 우리가 미처 생각지도 못했던, 레이더망에 걸리지 않았던 명백한 해결책들을 놓치지 않도록 도와줄 수 있습니다. 물론 AI가 제안하는 해결책은 학습 데이터에 기반하기 때문에, 종종 '지루하고 익숙한 기술(Boring Technology)'일 가능성이 높습니다. 하지만 아이러니하게도, 그런 기술일수록 성공 가능성이 높고 안정적인 경우가 많죠.
더 중요한 것은, 코딩 에이전트가 탐색적 프로토타이핑을 돕는다는 점입니다. 어떤 기술이 우리 프로젝트에 적합한지 가장 확실하게 판단하는 방법은, 프로토타입을 만들어 직접 성능을 증명해보는 것입니다. 예를 들어, 수천 명의 동시 사용자가 예상되는 웹사이트의 활동 피드에 Redis를 사용하는 것이 좋을까요? 가장 확실한 방법은 해당 시스템의 시뮬레이션을 만들고 부하 테스트를 실행해서 무엇이 깨지는지 확인하는 것입니다. 코딩 에이전트는 잘 만들어진 단일 프롬프트만으로도 이런 종류의 시뮬레이션을 구축할 수 있습니다. 이로써 이런 실험의 비용은 거의 '제로'에 가까워집니다. 그리고 비용이 저렴하기 때문에, 한 번에 여러 실험을 실행하며 여러 해결책을 테스트하고 가장 적합한 것을 선택할 수도 있습니다.
AI와 함께 '복리 효과'를 경험하라
에이전트들은 우리가 지시하는 대로 움직입니다. 우리는 이러한 지시를 시간이 지남에 따라 발전시키고, 이전에 배운 내용을 바탕으로 미래의 실행에서 더 나은 결과를 얻을 수 있도록 만들 수 있습니다. Every의 Dan Shipper와 Kieran Klaassen은 코딩 에이전트와 함께 일하는 회사의 접근 방식을 '복합 엔지니어링(Compound Engineering)'이라고 설명합니다. 그들이 완료하는 모든 코딩 프로젝트는 회고로 마무리되는데, 이것을 '복합 단계'라고 부르며 작동했던 내용을 기록하여 미래의 에이전트 실행을 위해 문서화합니다.
만약 우리가 에이전트로부터 최고의 결과를 얻고 싶다면, 시간이 지남에 따라 우리 코드베이스의 품질을 지속적으로 향상시키는 것을 목표로 해야 합니다. 예전에는 시간이 많이 걸렸던 품질 향상이 이제는 그 비용이 낮아져서, 투자하지 않을 이유가 없어졌습니다. 이런 작은 개선들이 복리처럼 쌓여 큰 변화를 만들어낼 수 있습니다.
결국, AI는 '코드 품질'을 위한 강력한 조력자
AI 코딩 도우미에 대한 막연한 불안감 때문에 그 잠재력을 외면할 이유는 없습니다. 오히려 AI를 현명하게 활용한다면, 우리는 과거에는 엄두도 내지 못했던 코드베이스 개선 작업을 훨씬 쉽게 수행할 수 있습니다. 사소한 기술 부채를 방치하지 않고 바로잡으며, 새로운 아이디어를 탐색하는 데 드는 비용을 최소화할 수 있습니다.
결론적으로, AI는 우리가 더 나은 코드를 생산하도록 돕는 강력한 도구가 될 수 있습니다. 중요한 것은 AI를 어떻게 '사용'하느냐에 달려 있습니다. 단순히 빨리 코드를 뽑아내는 도구가 아니라, 우리 팀이 더 높은 품질의 코드를 유지하고 발전시킬 수 있도록 돕는 '파트너'로서 AI를 활용한다면, 앞으로의 소프트웨어 개발은 더욱 효율적이고 안정적으로 나아갈 것입니다. AI와 함께라면, '기술 부채'는 더 이상 우리 발목을 잡는 장애물이 아닌, 오히려 개선의 기회가 될 수 있다는 사실을 기억하세요!
원문 참고: https://simonwillison.net/guides/agentic-engineering-patterns/better-code/
댓글 쓰기