최근들어 AI Agent를 사용하여 개발하는 방법에 대해 매우 고민중이다. 기존에는 그냥 코드 작성하다가 ChatGPT에게 문제가 발생하면 물어보고, 적절히 수정 후 내 스타일대로 개선하는 방식의 개발이 편했다. 내가 개발한 소프트웨어에 대한 신뢰도가 나름 높은편이라 그런거일수도 있지만, 사실 AI에 대한 불신이 잘 걷어지지 않는다. GPT도 3.5부터 사용하기 시작해서 이제는 5.2버전까지 왔다. 버전이 올라가면서 많이 좋아진것은 사실이다. 하지만 여러가지 이유로 AI를 그리 적극적으로 사용하지 않다가 최근들어 개발 방식을 바꿀정도로 생각이 바뀌어 정리된 나의 생각을 기록해보려 한다.
AI는 확실히 좋다
사용하고 있는 Agent AI는 두가지다(Github Copilot까지 하면 세갠가). OpenAI의 Codex CLI, Jetbrains AI를 사용중이다. Codex의 경우 이전에도 사용하다가 말았었는데, 당시에는 모델 성능 자체가 다소 아쉬운 모습을 보여줘서 굳이 사용하지는 않았었다. 그러다가 Cursor가 유행한다는 얘기를 듣고 써볼까 싶기도 했지만 Jetbrains의 개발에 너무 익숙해져 굳이 넘어가기에는 부담이 됐었다. 그때쯤 JetBrains에서도 AI를 출시했고 사용해보다가 나름 나쁘지 않다는 생각에 1년 결제를 해보았다.
확실히 코드 작성을 할때 편하긴 편했다. 아주 기본적으로 반복되는 코드들은 내장된 Github Copilot이 자동으로 만들어준다. 마음에 안들더라도 내손으로 수정하는게 inteiij에서 그리 큰 부담은 아닌지라 조금씩 수정한다. 특히, 반복적인 코드를작성하는 상황중 가장 대표적인게 테스트 코드이다. AAA패턴으로 TDD를 적용해나간지 반년이 지난 시점에서 AI는 상당한 무기다. Copilot만으로도 내가 테스트하려는 항목들에 대한 테스트코드를 정말 빠르게 작성할 수 있기 떄문에 기능 구현에서 폭발적인 효율을 보일 수 있었다. 이 방식을 TADD라고 부르는거 같은데 꽤나 만족하며 적용하고 있다.
리팩터링도 생각보다 만족스럽다. Intellij의 AI Assistant나 Junie를 사용하면 코드의 기능을 유지한 상태로 내가 제시하는 가이드라인에 따라 코드 가독성이나 확장 가능성을 위한 리팩토링을 꽤나 잘해준다. 리팩터링의 결과물이 지나치게 난해하거나 기능 요구사항을 충족하지 못하는 경우는 거의 없었던거 같다. 물론 간혹 기존 기능이 잘못 돌아가는 경우도 종종 있긴 하지만 앞서 말했듯이 TADD를 적용중이라 문제가 발생하면 빠르게 조치가 가능하다.
게다가 최근들어서는 본격적으로 Agent를 사용해보고 있는데 Intellij의 AI Assistant 돈낸게 무색하게도 OpenAI Codex CLI을 사용해 개발하는 시간이 정말 많이 늘었다(100$면 지금 환율로..). 그리고 글을 작성하는 시점을 기준으로 약 1일전 OpenAI에서 Codex CLI를 Jetbrains AI Assistant에서 사용 가능하도록 지원하게 되며 사용성 자체도 편해졌다. 또, 얼마전에는 Claude Code에만 있던 Skills라는 기능이 도입되면서 Agent를 좀더 안정적이고 정형화된 방식으로 사용할 수 있게 됐다. sub agent 기능도 도입된것으로 알고 있는데 병렬적으로 처리해도 될만한 작업이 한동안 없었어서 이것은 다음기회에 사용해보려 한다. 어쨌든 Codex를 통해 개인적인 개발 방식에 엄청나게 큰 변화가 있던건 사실이다.
AI에 대한 편견이 완전히 사라지지는 않았다
물론 AI를 그리 많이 사용하지 않은 편에 속할수도 있다. 단순 불신을 떠나서 코드를 작성하고 증명해나가는 행위 자체를 즐기는 나로써 AI가 싫어서 쓰지 않는다 보다도 그냥 코드 작성을 남에게 넘기기 싫어서 내가 코드를 짜는편이다. 그럼에도 생산성을 위해서 정말 많이 사용하고 있지만 항상 필요할때 말썽을 일으키는 상황이 너무 많다.
아래에 겪은 경험들을 통해 내가 Agent AI에 대해 아쉬워하는 부분에 대한 생각을 드러내보겠다.
새 버전에 대한 대응이 그리 좋지는 않다
최근에 Spring Boot가 4.0으로 넘어오면서 어떤것이 바뀌었는지 확인할겸 프로젝트를 4.0버전으로 사용하고있다. Spring Boot가 워낙 오래되고 견고한 생태계인지라 큰 변동이 없을것이라고 생각하고 개발을 이어갔다. 하지만 별거 아닌것으로 생각되지만 생각보다 큰 변화가 있었다. 바로 autoconfigure 모듈을 제대로된 구조로 바꾼것이다. 동일한 코드를 작성하더라고 autoconfigure 관련 클래스를 가져올때 import를 잘못된 경로로 작성하는 상황이 상당히 많이 연출되었다. 뿐만 아니라 Deprecated된 함수들이 대거 제거되면서 코드 작성 방식의 변화가 일부 있었는데 이것을 AI가 인지하지 못하고 사용해버리는 바람에 컴파일 오류가 발생하는 상황도 있었다. AI가 이러한 정보를 알 방법이 없었을까? 당연히 알려면 알 수 있다. search를 활성화하고 AI가 문제상황을 점검하고 대처하는것이 불가능하지는 않으니까. 하지만 AI는 이러한 대처방법을 대신에 아예 라이브러리에 문제가 있다고 판단하여 스스로 라이브러리를 대체할 기능을 구현하기 시작했다. 코드는 훨씬 더 장황해졌지만 그렇다고 기능이 정상적으로 동작한거도 아니다. 하도 AI가 고전하길래 문제가 최초에 발생했던 import를 확인해보니 이전 autoconfigure 경로를 사용하고 있길래 import문만 수정해줬더니 아주 간단하게 해결됐다. 새로운 버전에 대한 대처 방식이 일반적인 개발자였다면 그냥 해당 새 버전의 공식문서를 읽어봤겠지만 AI는 기존의 해결법에 문제가 있다는 의심을 하지 않았다.
설계를 단편적으로 한다
설계의 경우 시스템이 지속해서 확장될 것을 어느정도 염두하고 진행해야 한다. 당장의 코드 간결성이 나중에 얼마나 분리하기 어려울지를 상상해야 좋은 설계가 이루어질 수 있다. 하지만 AI에게 이런 내용을 전달하지 않으면 매번 지금 당장 요구사항을 만족하는 수준으로 기능을 개발한다. 물론 이것이 매번 잘못되었다는 얘기를 하려는게 아니다. 하지만 조금 더 괜찮은 개발자라면 “한스텝”정도는 더 생각하는것이 좋은 상황이 상당히 많이 있었고, 설계 과정은 이러한 좋은 상황중 하나라고 생각한다. 특히 Spring 안에서의 객체지향 프로그래밍은 개발자의 설계 능력에 따라 정말 말도 안되는 수준으로 효율을 달리할 수 있다(시스템의 효율만을 이야기하는 것이 아니라 개발 효율을 포함하는 효율이다).
직감(?)이 없다
꼭 이상한걸 고쳐요...
오류가 발생한 상황에서 에러 로그는 아주 큰 힌트가 된다. 하지만 어떤 로그에 집중하느냐에 따라 문제를 해결하는것이 아니라 헛수고의 무한굴레에 빠지는 계기가 될수도 있다. AI는 이런 부분에서 정말 취약하다. 에러 로그를 확인하고 그 문제가 발생했을때의 대처법을 본인이 아는선에서 해결하려 한다. 하지만 그보다 더 중요한건 코드베이스에서 문제의 원인을 찾아내고, 문제를 대처하기 위해서 경우에 따라서는 구현 방식을 바꾸기도 해야한다는 것이다. 하지만 경험상 AI는 기존의 흐름에 방해가 최소화된 방향을 선호한다. 뿐만 아니라 문제 포인트를 지나치게 low level(라이브러리 수준)에서 찾기도 한다. 라이브러리 코드를 수정하는것은 어떤 위험을 수반할지 모르기 때문에 가능한 문제를 제어 가능한 수준에서 해결할 수 밖에 없다. 하지만 AI는 문제 해결에 혈안된 나머지 해당 라이브러리를 코드베이스에서 제어하는 방법을 적용하기도 한다. 배보다 배꼽이 더 큰 방법으로 문제를 해결하는것은 나중을 생각하지 않는 사고방식이다.
정리해보자면 “AI는 큰 흐름에서의 문제 해결에는 아직도 식견이 좁다”는것이 나의 경험이다. 물론 나의 프롬프트의 문제일 가능성이 충분하다고 생각한다. 하지만 AI에게 주체성이라는 것이 존재할 수 없는데 어떻게 식견을 늘릴수가 있겠는가? 사람도 마찬가지다. 식견은 경험과 지식의 확장이 아니라 주체적으로 사고하며 주관이 자리잡으며 비로서 확장 할 수 있다. 명령 없이는 사고하지 않는 AI가 식견을 가진다는것은 나로써는 상상이 가질 않는다.
그래서?
그렇기에 개발자 대체된다라는 요즘 떠도는 이야기에 그리 동의하지 않는다. 다만, 대체될 개발자들이 대체된다는 의견에는 100% 동의한다. 생각하지 않는, 주관이 흐린 개발자가 AI보다 나은 구석은 지금 당장만 해도 없고, 아주 나중에는 더더욱 없을것이다. GPT 4.0이 나왔을때 한번 깊게 고민해본적이 있다. AI의 발전 속도는 앞으로 더 빨라질 것으로 생각되었고, “과연 컴퓨터와 가장 가까운놈이 개발자라는 자리를 가만히 냅둘까?”라는 생각이 나를 불안하게 만들기도 했었다. 하지만 마냥 감정적으로만 받아들일 것이 아니라 냉철하게 생각을 할 필요가 있었다. 나는 개발이 좋으니까 포기할 생각이 없으니까.
“지식 기반 개발자가 아닌 지혜 기반 개발자”
당시 내가 내린 결론이다. 개발자는 아니, 세상 모든 지식 기반 직업들은 붕괴될 것이다. AI랑 사람이랑 동일한 능력이라도 AI는 잠도 안자고 쉬지도 않고 밥도 안먹는다. 지식으로 이기려 드는것은 무모한 발상이다. 그보다는 AI가 못하는 부분을 공략해야 한다. 누군가는 사람을 이해하려 들것이고 누군가는 사회를, 자연을 이해하려 들것이다. 그것은 지식을 기반하지 않는 그저 ‘현상’일 뿐이기 때문이다. 하지만 안타깝게도 소프트웨어는 공학이다. 누군가가 만들어낸 거대한 산에 조약돌을 던져 올리는 일이다. 돌을 던져올리는건 AI에게 맡기자. 그보다는 돌을 어디에 얼마나 던질지, 어떻게 던질지, 아니 애초에 던져야 하는지를 고민하는 것이 개발자의 역할이 되어야한다. 문제를 해결하기 위해 쌓아 올리기만 하는것은 작게는 해결이 될지라도 크게는 더 큰 문제를 만들 뿐이다. 불안에 떨지 말고 내가 할 수 있는 일이 무엇인지, 내가 해야할 일이 무엇인지에 집중하는것이 지금과 같이 불안한 시대를 타파하는 최선의 방법이지 않을까 싶다.
Spring Boot 4.0 Migration Guide
Jetbrains AI Codex Support
TADD: AI를 활용한 새로운 TDD 방법론
