달라진 것들

1. 직접 작성하는 코드의 감소

현재 기준으로 제 이름으로 Commit 되는 코드 중에 제가 직접 작성하는 코드의 비율은 5% 미만입니다. 이것을 정밀하게 측정해본 것은 아닙니다. 다만, 제가 직접 작성하는 코드의 양과 그 비중이 점점 줄어들고 있고 체감상 5% 미만이라고 느끼고 있습니다.

AI가 작성한 코드에 문제가 있거나 아니면 아예 누락된 부분에 대해서만 제가 코드를 작성하고 있습니다. 중요한 것은 아직도 이 비중을 줄여나갈 여지가 충분히 있다는 것입니다.

2. 나만의 Workflow를 만들어야 할 필요성

소프트웨어 개발자로서, 그리고 그 이전의 한 명의 직업인으로서 각자 본인만의 일 하는 방식이 있을 것입니다. 이것은 회사에 따라서도 다르고 내가 속한 팀, 내 직군 그리고 나의 개인적인 성향에 따라서 달라질 수 있습니다.

또는 같이 일 하는 사람에게 영향을 받고 내가 신입이었을 시절의 선배 개발자로부터 배운 것들이 아직도 일부분 남아있을 수 있습니다. 기획 문서를 전달받아 분석하고 설계하고 코드를 작성하고 디버깅하는 일련의 과정은 사람마다 약간의 차이가 있을 수 있다는 것입니다.

이러한 일 하는 방식은 한 번 정해지면 그것을 바꾸는 게 쉽지 않습니다. 내가 수년간에 걸쳐 체득한 최적의 방식이기 때문입니다. 예전에 개인적으로 TDD(Test Driven Development) 방식으로 개발하는 방식을 바꿔보려고 의식적으로 노력했던 기억이 있습니다. 책도 많이 읽어보고 실제로 회사의 몇몇 프로젝트에 TDD를 도입하여 처음부터 테스트 코드를 작성하는 방식으로 진행했었습니다. 이 때 상당히 많은 시행착오를 겪었지만 이때의 경험이 아직도 제가 일 하는 방식에 녹아있습니다.

AI Agent와 같이 소프트웨어를 만드는 지금도 나만의 일 하는 방식을 정립하는 것은 매우 중요합니다. 이것이 특히 더 중요한 이유는 이 방식에 따라 생산성의 차이가 매우 크게 나타날 수 있기 때문입니다. 이전에 사람이 모든 것을 할 때의 개인간 생산성 차이와 지금 AI와 같이 일 하는 상황에서의 생산성 차이는 그 크기와 양상이 매우 다를 수밖에 없습니다.

단순히 Claude code를 실행시키고 코드 파일을 몇개 읽게 한 다음에 "여기 버그가 있으니 수정해" 라고 하는 아주 간단한 방식부터 시작할 수 있습니다. 그러나 여기에 그치지 않고 소프트웨어 개발의 전체 life cycle을 시스템으로 만들어서 AI에게 많은 부분을 위임하는 방식으로 일 하는 것은 생각보다 간단치 않습니다.

그렇기 때문에 단순히 코딩을 잘 하는 것으로는 부족하고 SDLC 전반에 걸친 풍부한 경험을 그대로 시스템으로 전환할 수 있는 능력이 필요해졌습니다. 우리가 하려는 것은 기존의 100을 120, 130으로 만드는 것이 아니라 100을 400, 1000으로 만드는 것이기 때문입니다.

좋아진 것들

1. 제품 개발의 즐거움

소프트웨어 개발자에서 Product engineer로 전환되는 것을 느끼고 있습니다.

예전에 제품을 만드는 전체 과정의 일부분(Back-end)만 담당했던 것에서 지금은 '제품'을 만드는 전 과정에 제가 개입하고 기여하고 있습니다. 이것은 이전과 전혀 다른 차원의 즐거움을 느끼게 합니다.

그 전에는 PM이 작성한 스펙 문서 기반으로 Back-end system을 설계하고 DB 구조를 설계하고 API를 구현하는 것이 저의 주요 업무였습니다. 그리고 Front-end engineer와 API의 구조와 호출 시점에 대해 논의해야 했습니다. 그런데 지금은 달라졌습니다. 저는 AI Product Engineer로서 PM, Full-stack engineer, 일부 QA engineer의 역할을 전부 수행합니다.

고객이 겪고 있는 문제를 식별하고 그것을 어떻게 소프트웨어로 해결할 수 있을지 아이디어를 생각하는 과정부터 시작해서 고객의 목소리를 구체적인 해결책으로 구성한 스펙 문서를 작성하는 것, 그리고 이것을 토대로 프로그램을 만들고 이것을 검증하는 과정 전반에 걸쳐서 제가 직접 개입하고 기여하고 있습니다.

이것은 AI Agent 기반의 코딩 툴로 인해 소스 코드 작성에 사람이 개입하는 비중이 줄어들고 이에 따라 소스 코드 작성 비용이 크게 줄었기 때문에 가능한 일입니다. 예전처럼 사람이 직접 모든 것을 만들어야 했다면 1인 팀으로 움직이는 지금의 방식은 시도할 수조차 없었을 것입니다.

시스템을 설계하고 코드를 작성하는 것은 물론 제품에 기여하는 일이지만 동시에 일부분이기도 합니다. back-end engineer로서 일할 때는 고객에게 직접적으로 impact를 주는 경험을 하기가 쉽지 않았습니다. 현재 1인 팀으로서 제가 느끼는 것은 고객에게 직접적으로 impact와 가치를 제공하고 있다는 것입니다.

2. 압도적인 생산성 향상

1년 전까지만 해도 저는 AI가 개발자의 생산성을 20 ~ 30% 정도 향상시킬 수 있을 것이라고 생각했습니다. 하지만 지금은 어쩌면 2배~3배 혹은 10배까지도 가능한 시대가 되었다고 말할 수밖에 없습니다.

현재 저는 BMAd Method라는 AI Agile framework을 통해 초기 brainstorming, prd 작성, architecture 설계까지 전부 AI와 진행하고 이것을 토대로 Ralph Loop 방식으로 AI가 전체 기능의 0에서부터 최소 90%를 구현하도록 하는 Workflow를 구축해놓은 상태입니다. Ralph Loop을 밤 시간대에 돌려서 토큰 리밋에 걸리지 않게 하고 아침에 출근하여 작업된 코드를 1~2시간 정도 검토하여 나머지 10%를 채워넣습니다. 그리고 커밋합니다. 예전에 1주일은 걸리던 작업을 이제는 하루에 할 수 있게 된 것입니다.

이제 PM과 논의할 때는 문서 기반으로 하는 게 아니라 실제로 작동하는 화면을 보면서 논의합니다. 스펙 문서가 만들어지고 어느정도 수준으로는 작동하는 프로토타입을 만드는데 반나절이면 충분하기 때문입니다.

나빠진 것들

1. 소스 코드 스킬의 퇴화

이것은 너무나 분명합니다. 2년 전, 1년 전의 저와 지금의 저는 소스 코드 작성 스킬에 엄청난 차이가 있을 것입니다. 2년 전까지만 해도 모든 코드를 직접 작성했던 반면에 지금은 글쎄요, 하루에 100줄도 코드 작성을 안 합니다.

감각이라고 해야 할까요. 이 상황에서 이 함수를 쓰고 저 상황에서는 여기에 맞는 문법을 사용해야 한다는 그런 감각이 무뎌지고 있다는 것을 여실히 느낍니다.

2. 코드 품질 관리 부담

AI가 작성한 코드의 품질을 관리하는 것은 생각보다 쉽지 않습니다. AI가 사람보다 코드를 잘 작성하다는 것은 어디까지나 요구사항을 만족하는 수준으로 작동하게끔 코드를 빠르게 작성한다는 의미입니다.(아직까지는!)

회사의 여러 도메인 각각의 개별적인 특성을 이해하고 레거시 시스템과의 유기적인 관계를 고려한 코드를 작성하기 위해서는 AI에게 고품질의 Context를 제공해야 합니다. 너무 많이 제공해서도 안 되고 누락된 것이 있어서도 안 됩니다. 적절한 Context는 언제나 중요합니다.

적절한 Context가 부여되지 않은 상태에서 요구사항만 AI에게 제시한다면 유지보수가 힘들고 어쩌면 기술 부채가 쌓일 수도 있습니다. 저의 경우 몇달 전에 React 기반의 Front-end 모듈 작업을 AI와 같이 한 적이 있습니다. 기능 자체는 잘 작동했고 제가 대략적으로 검토한 결과 나쁘지 않았습니다. 하지만 회사의 Front-end engineer는 이 작업 결과에 대해 Junior가 작성한 코드 같다면서 더 개선했으면 한다는 피드백을 저에게 준 적이 있습니다. 다시 확인해보니 상태 관리 측면이나 디자인 시스템을 적용하는 방식이 상당히 올드한 스타일이었습니다.

결론

코드 품질 관리 부담 측면에서 제가 받았던 피드백(Junior가 작성한 코드 같다)을 받아들이고 Workflow를 개선하여 AI가 작업을 담당할 때, State management, Design system, Styling 등등의 회사 내부적인 가이드라인을 Context에 첨부할 수 있도록 했습니다. 개선 이후에는 그전처럼 너무 올드한 스타일의 코드 작성이나 잘못된 디자인 시스템을 참조하는 문제가 확실히 줄어들었습니다.

앞으로도 이런 방식으로 꾸준히 발전시켜나갈 계획입니다. 모든 변화는 장단점이 있습니다. 장점은 더 발전시키고 단점은 보완하는 방식으로 AI 기반의 소프트웨어 개발 방식을 진화시켜야 합니다.

이렇게 AI 기반의 개발 방식을 잘 만들어놓으면 언젠가 내가 대체될 수도 있겠다는 생각도 동시에 하게 됩니다. 그리고 어쩌면 Software engineer 라는 직업이 사라지는 게 아니라 다른 방식(Product engineer)로 변화하는 과정일 수도 있지 않을까 하는 생각도 합니다.

이 변화는 피할 수 없기 때문에 받아들이고 즐겨야 한다고 생각합니다. 개인적으로 5년, 10년 후에 Software engineer 라는 직업이 어떻게 될지는 잘 모르겠습니다. 약간의 낙관적인 기대를 가지고 이 변화에 적응하면서 살다보면 나중에 잘 되지 않을까? 하는 막연한 기대를 가지고 있습니다.

Comments (0)

Checking login status...

No comments yet. Be the first to comment!

AI Agent 기반 소프트웨어 개발에 대한 소회

Comments (0)