AI 덕분에 개발이 쉬워졌고, 재미는 없어졌다.

회고

목록 보기

5/5

열심히 성장하던 시절

개발을 처음 시작했을 무렵부터 지금까지 훌륭한 개발자가 되기 위해 열심히 공부했었다. 물론 나보다 더 열심히 사는 개발자들도 많지만, 나도 내 위치에서 나름의 노력을 했었고, 벨로그에도 200개가 넘는 글을 작성하기도 했다. 그 만큼 개발에 진심이었고 재밌었다.

회사에서는 구현하기 복잡하거나 어려운 주제를 담당하는 것을 좋아했고, 동료 개발자가 하고 싶은게 아니라면 내가 가져왔다. 그 문제를 잘 풀어나가면 성장하는 느낌을 많이 받았기 때문이다.

그리고 팀 내에서 아무도 해보지 않은 도전 과제가 등장하면, 나는 항상 그런 프로젝트에 투입되고 싶어했다. 물론 많은 삽질이 필요하고, 다양한 개념들을 학습하기 위해서는 여러 노력이 필요하다. 그래도 프로젝트의 DX가 개선된다던가, 다른 직무와 협업에 있어 편리해진다거나, 서비스의 유지보수 측면에서 안정성이 올라가면 뿌듯했다. 게다가 견문이 넓어지는 느낌이 들때마다 ‘성장하고 있구나’를 느꼈다.

그렇게 진행했던 것들이 MFA(Micro Frontend) / 디자인 토큰 기반 디자인 시스템 / Vue만 사용하던 회사에서 Next 도입과 같은 굵직한 것부터 탠스택 쿼리 / 스토리북 / MSW 도입과 같은 부가적인 도전들이 있었다.

그런데 요즘에는 AI 때문에 개발하는 것에 대해 재미는 감소했다.

AI라는 친구의 등장

기술 블로그나 링크드인 같은 곳에서 AI의 찬양들이 쏟아져 나오기 시작할 무렵에, 나도 코드 어시스턴트들을 사용해보고 있었다. 코파일럿은 편하기는 했지만, 사실 그렇게 확 와닿지는 않았다. 근데 커서를 사용하고 나서는 큰 충격을 받았다. 생각했던것 보다 일을 잘했고, 특히 물리적으로 시간을 많이 잡아먹는 귀찮은 일들을 순식간에 해주었다.

이 무렵에 회사에서는 재미나이를 지원해주고 있었다. 하지만 코드 어시스턴트에 대한 지원은 없었다. 그래서 나는 커서를 사용해본 경험을 팀 내에 공유하며, 프론트 리더에게 이와 같은 AI를 지원해주기를 요청했었다. 그 요구가 통했는지 아니면 원래부터 회사에서 지원해주려고 준비중이었는지는 모르겠지만, 두 달 정도 뒤에 Claude / AWS Kiro (Q) 를 지원해주었다.

커서를 처음 사용해본 이후로, 고작 두 달이라는 시간밖에 지나지 않았었다. 이 짧은 시간동안 업그레이드 된 클로드는 더욱 훌륭한 일들을 하기 시작했다. 이제는 단순한 일 뿐만이 아니라, 어느정도의 복잡도가 있는 것들도 잘 구현하기 시작했다. 그리고 MCP 같은 개념까지 결합되면서, 생산성이 엄청나게 올라갔다. 이제는 도구가 아닌 동료가 된 느낌이었다.

회사 내에는 부정적인 의견도 존재했다. AI가 못하는 부분들이 많기에, 아직 맹신하기는 어렵다는 것이었다. 나는 이 의견에 매우 동의한다. 하지만 이 문제는 '지금의 상황'일 뿐이고, 빠른 속도로 해결될 일이라고 생각했다.

클로드를 개발하는 사람들도 자신들이 만든 클로드에 추가 개발을 진행할 때, AI를 이용한다고 언급할 정도니까 말이다. 실제로 클로드도 한 두달에 한 번 이루어지던 업데이트가 이제는 1주일만에도 새로운 버전이 등장하고 있다. 이미 새로운 시대는 시작된 것이다.

개발에 대한 의심

AI와 함께 개발을 하다가 문득 '개발 공부하는게 의미가 있을까?' 라는 생각이 들었다. AI가 빠른 속도로 반전하면서, 내가 경험해보지 못한 부분에 대해서는 AI가 일을 더 잘한다. 그리고 나보다 비교할 수 없을 정도로 빠른 속도로 업무를 처리한다.

물론 모든 것을 AI에게 맡기는 것은 아직까진 이상적인 이야기이다. AI가 작성해준 코드에 버그가 있거나, 아니면 AI가 만들었던 기능에 더 많은 기능들이 복합적으로 추가되면서 사이드 이펙트를 발생시켰을 때, AI가 문제를 해결하지 못하면 결국 개발자가 파악해야 하기 때문이다.

이와 같은 상황에서 개발자의 역량이 부족하다면, AI가 작성한 코드나 플로우들을 이해하기 힘들 것이고, 그 만큼 문제를 해결하는데 있어 많은 시간을 소요하게 된다. 하지만 나중에 AI가 못하는 부분이 사라진다면, 정말 자연어만으로 충분히 모든게 가능하다면 개발 지식들이 중요한걸까?

청소기 안에 탑재되어 있는 부품들을 모두 이해하면서 청소기를 사용하지는 않는다. 이처럼, 머지 않은 미래에는 개발 언어를 이해하지 않고 AI에게 구현 / 테스트 / 검증을 맡기게 되는거 아닐까? 이것은 추상화의 개념이랑도 비슷한 것 같다.

그리고 가끔은 그런 생각도 한다. 사람이 이해하기 쉽게 만들어진 지금의 컴퓨팅 언어들은 사라지고, 컴퓨터만 이해할 수 있는(01010101.. 같은 ㅋㅋ) 대신에 엄청난 속도를 자랑하는 무언가가 나오는건 아닐까 하는 생각 말이다.

지금 AI의 수준은 청소기가 고장나는 경우, 문제가 있는 부품들을 만들어서 교체해주는 정도까지 온 것 같다. 부품들끼리의 복잡한 연결로가 고장난 경우에는, 아직까지는 완벽하게 고쳐주지는 못하지만, 이 부분들도 빠르게 진화하고 있다.

이런 생각들은 개발에 대한 재미를 떨어뜨렸다. 개발 공부에 대한 의심이 싹트기 시작했기 때문이다. 과거에는 복잡한 문제를 해결하기 위해 여러 지식들을 습득하고, 꼬리에 꼬리를 무는 개념들을 타고 들어가면서 학습해왔다. 이런것들이 모이다가 어느 순간 깨달음을 얻으면, 그게 바로 개발의 재미이며 묘미였다.

하지만 지금은 대부분을 AI에게 맡긴다. 개념을 몰라도 해결해달라고 하면 몇 분 만에 해결해준다. 해결 과정을 보면서 나라면 어떻게 해결했을까 상상하며 비교도 해보지만, 이런 과정들도 의미가 있는건지 의문이 생긴 것이다.

AI가 만든 코드를 테스트하고 검증하는데 시간을 쏟아야 하는건 맞지만, 코드를 이해하는데 시간을 투자하는게 맞는건지에 대해서도 의심이 간다. 나중에는 결국 AI에게 명령만 하고 코드는 안보게 되는 것은 아닐까? 검증에서 실패한 경우에도 다시 AI에게 수정을 요청해서 해결하고, 그러다가 정 안되면 그제서야 코드를 보는 세상이 오지 않을까? 처음에는 엄청난 혁신으로 다가와, 나에게 두근거림은 선사했던 AI가, 이제는 개발의 재미를 뺏어가고 있는 상황이다.

그렇다고 AI를 안쓸거냐? 그건 정말 미련한 선택일 것이다. 과거부터 지금까지 개발자라는 사람들은 기능을 완벽하게 구현하고 버그를 제거하며 안정적인 서비스를 운영하는 것도 있었지만, 어떻게 해야 생산성을 늘릴 수 있을지 고민하며 수 많은 아키텍처와 방법론들을 쏟아냈었다.

그런데 개발 생산성을 엄청나게 높일 수 있는 AI라는 도구이자 동료를 사용하지 않는것은 개발자로써의 모순이기도 하고 나 자신이 이 세상에 뒤쳐지는 일이 될 것이다.

1%의 디테일에 재미를 느끼자

이 세상에서 ‘완벽’이라는 말이 성립되는 것은 어렵다. 어렸을 때, 사탕 봉지 안에서 두 개의 사탕이 나온적이 있었다. 그 당시에는 마냥 기분이 좋았지만, 지금 생각해보면 반복 작업을 위해 만들어진 기계조차도 반복 작업에 완벽하지가 않다는 사실을 깨닫게 된다. 그런데 이게 만약 사탕이 아니라 의약품이라고 가정해보자. 특정 알약 한 알에 어떤 성분이 두 배로 들어가게 되었다. 이것은 누군가에게 매우 치명적일 수 있다. 개발로 치면 크리티컬한 버그인 것이다.

이처럼 AI도 크리티컬한 버그를 만들게 될 것이다. 계속 고치지 못하고 빙빙 도는 부분들도 있을 것이다. 완벽하지 않기 때문이다. 위에서 말했던 ‘미래에는 가능하다’는 99%의 일들을 말했던 것이다. 나중에도 분명 1%에 대해서는 AI도 실수를 할 것이라고 생각한다. 그래서 우리는 이 1%의 디테일을 채우기 위해, 여전히 개발 지식을 쌓고, 코딩 실력을 향상시켜야 한다. 개발에 대한 재미도 잃지 않게 되어 일석이조가 된다.

대부분의 일을 AI가 한다고해서 개발에 대한 태도를 의심하며, 벌써 부터 마음이 꺾일 필요가 없다. 달라질건 없고, 하던대로 하면 된다.

과거에 T 공부법이라는 개념을 본 적이 있다. 요약하자면 다양한 분야에 대해 넓게 알고, 그 중에서 한 분야에 대해 깊게 알기 위해 학습한다는 의미였다. 이제는 AI 덕분에 T의 가로선인 ㅡ 부분을 손 쉽게 넓힐 수 있고, 세로선도 빠른 속도로 그을 수 있게 되었다. (이제는 ㅠㅠㅠㅠㅠ 같은 모양이 되려나..)

이는 아예 새로운 직무의 일도 해볼 수 있게 된 것을 의미한다. 웹 프론트엔드 개발자는 더 빠른 속도로 앱이나 백엔드에 익숙해질 수 있으며, 실제로 업무에 투입되는 것도 무리는 아닐것이다. 이런 부분에서 재미를 찾아도 좋을 것 같다.

자동화에 재미를 느끼자

조금은 부끄러운 이야기이지만, 우리는 테스트 코드를 전혀 작성하지 않았다. 항상 헐떡이며 개발 할만큼 업무가 바빴기 때문이다. 그런데 개인적으로 AI가 등장하고 나서부터는 시간이 없다는 말은 핑계가 되었다고 생각한다. 그래서 나는 AI와 함께 테스트 코드를 작성하기로 결정한다. 하지만 테스트 코드에 대한 경험이 전무하다보니 가장 간단한 UI 라이브러리성의 공통 컴포넌트부터 테스트 범위로 잡았다.

먼저 'Button 컴포넌트에 대해 테스트 코드를 작성해줘'라고 요구해보았다. 일단 테스트 코드를 얼마나 잘 작성하는지 확인해본 것이다. 클로드가 어느 정도 작성해주기는 했지만 내가 만족할 정도는 아니었다. 그래서 나는 이어서 '버튼 컴포넌트를 완벽하게 파악하고 테스트 코드를 작성해줘' 라던가, '컴파운드 컴포넌트 패턴을 사용하고 있고, 디자인 토큰이 입혀져 있기 때문에 헤드리스는 아니야' 같은 정보들을 주기 시작했다.

이렇게 요구했던 것들을 기반으로 공통 컴포넌트를 위한 프롬프트 규칙 파일을 작성했다. 테스트 코드들도 일관성이 있어야 개발자가 파악하기 더 좋으므로, 이런 규칙들까지 정리했다. 그리고 이렇게 만들어진 md 파일 기준으로 모든 공통 컴포넌트들에 테스트 코드를 하나씩 생성하기 시작했다. 그 결과 순식간에 원하는 결과물을 얻을 수 있었다. 이제 공통 컴포넌트를 수정하더라도, 불안감을 안은채 하지 않아도 된다는 사실이 매우 기뻤다. 이후에는 비지니스 로직이 결합된 컴포넌트를 테스트 하기 위한 프롬프트를 작성했고, 앞으로는 E2E같은 더 다양한 관점에서의 테스트 코드도 AI 프롬프트 자동화를 통해 접근해볼 예정이다.

또 기억에 남는 것은 스웨거 문서 기반으로 API Path, Request / Response Model, 데이터 패칭 함수 등을 자동화한 것이다. 사실 이미 swagger-typescript-api라는 라이브러리를 통해 리퀘스트 및 리스폰스 모델정도는 스웨거 기반으로 뽑아오고 있었다. 하지만 데이터 패칭 함수나, API EndPoint Path같은 것들은 우리 프로젝트 스타일에 맞게 직접 작성했다. 이게 별거 아닌 것 같지만, 응근히 귀찮고 시간을 잡아먹었다.

export function fetchBlogDetailPage(
	requestModel: FetchBlogDetailPageRequestModel
): FetchModel<FetchBlogDetailPageReturn> {
	return serverFetch(apiPath.blog.detail, 'get'...)
}

먼저 스웨거 기반으로 모델은 그대로 뽑도록 했다. 그리고 이 라이브러리에서 데이터 패칭 함수도 만들어주는 기능이 있는데, 이것은 커스텀은 쉽지 않고 자신의 입맛대로 생성해버린다. 그래도 일단 데이터 패칭 함수도 만들도록 했다. 그리고 이 결과물들을 참고한 채로 Swagger MCP를 돌렸다. 우리 프로젝트의 성격에 맞게 데이터 패칭 함수나 API EndPoint Path를 추가하도록 했으며, 기존 API에 수정 사항이 있는 경우에도 잘 고칠 수 있도록 프롬프트를 구성했다. 그 결과 원하는 결과를 얻었고, 꽤 높은 생산성을 얻게 되었다고 생각한다.

이 외에도 컴포넌트에 대한 스토리북을 잘 작성할 수 있도록 프롬프트를 설계한다던가, GitHub에 PR이 올라오면 AI가 코드 리뷰를 할 수 있는 플로우를 구성하는 등의 자동화도 생각해볼 수 있다. 자동화 영역은 무궁무진 하므로, 다양한 시도를 해보면서 재미를 느껴보자.

AI 고도화에 재미를 느끼자

위에서 소개한 테스트 코드 프롬프트나 스웨거 기반으로 자동화를 진행할때 AI가 일을 잘 할 수 있도록 많은 시도들을 했었다. 어떻게 보면 AI는 불확실성을 가진 존재인데, 이것을 확실하게 처리하도록 핸들링하는 과정인 것 같았다. 이게 생각보다 쉽지 않다. 이제는 어떻게 하면 더 대답을 잘하게 할 수 있을지, 다른 사람들의 고도화된 프롬프트를 보면서 공부도 하고, 여러 방식을 시도해보면서 깨달아가는 과정이 필요하다고 생각했다.

AI를 조금 사용해보면 알겠지만, 한 번에 너무 많은 일을 시키거나 요구하면 원하는 결과를 얻기 힘들다. 목적에 맞는 요구들을 순차적으로 수행했을 때, 좋은 결과를 얻을 확률이 높아진다. 이거 어디서 많이 본거다. 개발에서 관심사의 분리이다. 그리고 AI도 코드를 작성하는 것 처럼, 논리적으로 명확한 규칙을 정해주면 더 잘한다. 결국 개발자의 사고 방식을 탑재해서 AI를 활용하면 더욱 효과적으로 사용할 수 있게 된다. 고도화 하는 과정은 개발을 하던 방식과 크게 다르지 않고, 재미를 느끼기에 충분하다고 생각한다.

마무리

나는 재밌어야 일을 더 잘하는 타입이다. AI가 나의 일자리 자체를 위협하는 것도 맞지만, 애초에 나부터 일이 재미가 없으면 효율이 떨어진다. 그래서 재미가 없어지는것에 대해 더 두려웠던거 같다. 하지만 다행스럽게도 개발에 대한 의심을 지우자는 결론을 내렸고, 또 다른 부분들에서 재미를 찾기도 했다. 변화하는 시대에 맞게 나도 진화하고 있다는 느낌을 받았다.

개발자들 중에 마음이 꺾이려는 사람이 있다면, 이 글을 보고 도움이 되면 좋겠다.

HyunHo Lee

함께 일하고 싶은 개발자가 되기 위해 달려나가고 있습니다.

이전 포스트