AI 시대 현직 개발자의 자기 효능감에 관하여

오늘도 개발자가 안 된다고 말했다

개발이 개발자의 고유영역이던 시절, IT 서비스는 기획자, 디자이너, 개발자가 열심히 협업하여 만들어내는 결과물이었다. 하루아침에 뚝딱 모든 기능이 완성되면 좋겠는데, 개발자들은 그렇게 해줄 수 없었다. 당시 개발은 한땀 한땀 쌓아올리는 집짓기와 비슷했기 때문이다. 그래서 개발자들은 종종 안 된다고 말했다.

바이브 코딩이 흔해진 요즘은 AI로 순식간에 웹 사이트를 만들 수도 있고, 마음에 들지 않으면 다 갈아엎고 설계와 디자인을 바꿀 수도 있다. 사람들은 이제 개발자와 협업하지 않고도 각자 필요한 툴 정도는 직접 만들어서 사용할 수 있게 되었다. 게임 회사 플랫폼 부서에서 일하는 나는, 최근 무기력함과 불안감을 겪었다. 업무를 편하게 하려고 툴을 직접 만들어 쓰는 동료들을 보며, 앞으로 나는 무슨 일을 해야 할까 싶었기 때문이다.

사람마다 일하는 이유는 다르지만, 나를 움직이는 건 ‘꼭 필요한 일을 하고 있다’는 자기효능감이다. 동료들에게 도움이 되는 툴을 만드는 데에서 큰 보람을 느꼈고, 그렇기에 웬만하면 된다고 하는 개발자였다. 그런데 공동의 툴을 기획하는 대신 각자 필요한 것을 만들어내는 세상에서는 더 이상 나에게 새로운 툴을 요청하는 동료가 없을 것처럼 느껴져 불안했다. 하지만 막상 만들어지는 툴들을 지켜보다 보니 문득 여전히 중앙화된 툴이 필요하다는 생각이 들었다. 여러 사람이 비슷한 기능을 만들어 쓰고 있다면, 각자의 노하우를 모아 함께 쓰는 툴로 만들 가치가 있다고 느꼈다. 다만 예전처럼 꼭 화면이 있는 툴일 필요는 없었다.

그렇다면 나는 어떤 툴을 만들어야 할까.

우리 회사 동료들이 공통으로 겪는 문제는 무엇이고, 그걸 어떤 형태로 해결해주면 좋을까?

엑셀 diff 툴의 추구미는 무엇인가

게임 개발자에게 엑셀은 애증의 툴이다. 대량의 데이터를 관리하기에 최적의 툴이지만, 변경이력을 추적하기가 어렵기 때문이다. 요즘 바이브 코딩을 즐기는 사람이 많아지면서, Git 버전관리를 쓰는 사람도 늘어났다. Git을 써본 사람이라면 변경이력 관리가 얼마나 편리한지 알 것이다. Git에서는 내가 원하는 변경사항들을 하나의 작업 단위인 커밋으로 묶어 기록할 수 있다. 누가 언제 어디를 바꿨는지뿐 아니라, 한 작업에서 어떤 파일들을 어떻게 고쳤는지도 함께 확인할 수 있다.

엑셀 파일도 Git으로 버전을 관리할 수는 있지만, 소스 코드처럼 커밋별로 변경 내용을 바로 읽기는 어렵다. 엑셀 내장 기능을 통해 두 파일을 비교하거나 셀 단위 변경을 추적하는 건 가능하지만, 내가 원한 것은 한 커밋에 묶인 코드와 엑셀의 변경사항을 함께 검토하는 것이었다. 특정 커밋에서 어느 시트의 어떤 값을 바꿨는지, 코드 리뷰 화면에서 바로 확인하고 싶었다.

실제로 개발 프로젝트에 엑셀 파일을 넣었을 때, 내가 본 화면은 이러했다. 파일이 바뀌었다는 건 알겠는데 어느 셀을 어떻게 고쳤는지는 볼 수 없었다.

처음 이 화면을 마주했을 때 나는 크게 절망했다. 그리고 정확한 변경사항을 확인할 수 없다는 사실에 몹시 불안했다. 물론 우회하는 방법은 있다. 엑셀 데이터를 JSON 파일로 변환하고, 코드에서는 JSON만 읽도록 하는 것이다. JSON은 줄 단위로 변경 내용을 볼 수 있으니, 이를 통해 원본 엑셀에서 무엇이 바뀌었는지 짐작할 수 있다.

그럼에도 여전히 원본 엑셀에서 무엇이 바뀌었는지 직접 보고 싶은 경우가 있다. 가령, 엑셀에 비정상적인 입력값이 들어오면 JSON 파일이 갱신되지 않고 빌드 파이프라인이 실패하도록 검증단계를 두었다고 가정해보자.

JSON을 생성하기 전 검증 단계에서 실패하면, JSON 변경 내역이 없어 원인을 짐작하기 어렵고, 손수 엑셀을 열어 어느 시트가 잘못됐는지 확인해야 한다. 이때 만약 어떤 행이 바뀌었는지 diff를 볼 수 있다면, 엑셀 파일을 열기 전에 문제를 찾을 단서가 생긴다.

한동안 이 문제로 고민하면서 엑셀 diff를 보여주는 툴이 있는지 이리저리 찾아봤다. 그럴듯한 툴을 몇 개 찾기는 했지만, 안정성을 보장하기가 어려워 회사 업무에 적용하기에는 망설여졌다. 동료들과 대화를 해보니 많은 사람들이 비슷한 고민을 했고, 각자 방법을 찾아봤고, 비슷한 한계에 부딪힌 듯했다.

나는 거기서 멈췄지만, 한 걸음 더 나아간 동료가 있었다. 동료는 엑셀 diff UI를 지원해주는 툴을 직접 만들기 시작했다. 기존 코드 리뷰 화면에서는 확인하기 어려웠던 엑셀의 행과 셀 단위 변경 내역을 UI로 제공하는 툴이었다. 동료가 데모버전을 보여주었고, 어떤 행의 어떤 값이 어떻게 바뀌었는지, 코드 리뷰하듯 한눈에 확인할 수 있다는 점에서 정말 획기적이었다. 올해 초의 일이었다.

그런데 얼마 전 그 동료와 다시 이야기하다가, 이 툴을 계속 같은 방향으로 만들어도 될지 고민하고 있다는 말을 들었다.

“엑셀 데이터 수정을 이제 사람이 하지 않아요. 수정 결과도 에이전트한테 요약해달라고 시키고요. 각자의 엑셀 diff 툴이 있는 셈이라서, 어쩌면 이 툴이 필요하지 않을지도 모르겠어요.”

“이 툴의 강점은 diff UI잖아요. 사람이 직접 눈으로 차이를 확인하고 싶은 니즈는 없을까요?”

“변경사항이 아주 많은 경우에는 오히려 사람이 눈으로 확인하는 과정에서 놓치는 것들이 있잖아요. 그래서 부가 기능으로 고민하던 MCP를 오히려 메인 기능으로 개발해야 할 수도 있겠다는 생각이 들어요.”

그 말을 듣는 순간, 그동안은 사용자로서 MCP를 연결해 쓰기만 했지만 앞으로는 직접 구현하게 될 것 같다는 예감이 들었다. 그 예감은 머지않아 현실이 됐다. 툴과 API를 만들어 달라는 요구는 점차 줄고, MCP 서버를 구현해 달라는 요구가 늘기 시작했다.

이제는 에이전트도 툴을 쓴다

각자가 자기 툴을 만들 수 있는 세상에서도, 중앙화된 툴은 여전히 쓸모가 있다. 각자의 에이전트가 따로 처리하기보다 한곳에서 해두는 편이 나은 일도 있기 때문이다. 예를 들어 레포지토리 전체를 읽어야 하는 작업이 있다고 하자. 동료 수십 명의 에이전트가 각자 같은 레포를 처음부터 읽는 것보다, 중앙 툴이 한 번 읽어 인덱싱해두고 모두가 그걸 조회하는 편이 빠르고 싸다. 모두가 같은 시점의 코드를 기준으로 작업하니, 서로 다른 버전을 보고 이야기하는 혼선을 줄일 수 있다.

바이브 코딩과 함께 ‘에이전틱 코딩’이라는 말도 쓰인다. 이 글에서는 코딩을 넘어 AI 에이전트에게 업무를 위임하는 방식을 ‘에이전틱 워크플로우’라고 부르려 한다. 예전에는 동료들이 직접 쓸 웹 UI를 주로 만들었다면, 이제는 에이전트가 활용할 수 있는 형태도 고민하게 됐다. MCP로 기능을 제공하거나, 플러그인이나 스킬로 도구와 사용 방법을 묶어주는 식이다. 그중 MCP(Model Context Protocol)는 에이전트가 어떤 기능이 있는지 알아보고 호출할 수 있도록 연결하는 표준이다.

예를 들어 엑셀이 어떻게 바뀌었는지 궁금하면 에이전트에게 “이 두 파일을 비교해서 요약해줘”라고 요청하는 식이다. 검증에 실패하면 원인을 찾아달라고 하고, 같은 시트를 수정해 충돌이 생기면 해결을 맡길 수도 있다. 이를 위해 비교·검증·수정에 필요한 기능을 MCP 도구로 제공하는 것이다.

결국 중앙화된 툴을 만드는 일은 여전히 유효했다. 다만 이제는 동료들이 직접 쓰는 화면과 함께, 그들의 에이전트가 호출할 기능도 만들어야 했다.

그밖에 구상하고 있는 MCP의 사례

게임 아이템과 상품 데이터를 관리하는 툴에서도 비슷한 고민이 있다. 현재 툴은 웹 클라이언트와 서버로 구성되어 있다. 보안상 수정은 툴 내부 UI에서만 가능하고, 사내 다른 툴에 제공하는 API는 읽기 전용으로 데이터 조회만 허용하고 있다. 그런데 동료들이 에이전트로 일하기 시작하면서, 이 데이터 수정도 AI에게 맡기고 싶다는 요구가 생겼다.

논의의 시작은 사내 다른 툴에서도 조회뿐 아니라 수정까지 할 수 있게 해달라는 요청이었다. 지금은 웹 UI에서만 수정할 수 있어서, 동료들의 에이전트도 브라우저를 띄워 화면을 조작해야 했다. 이 과정을 거치지 않고 수정 기능을 직접 호출하고 싶다는 요구가 계속 들어왔다. 마침 상품 관리 툴은 게임 초창기부터 만들어져 다소 낡은 툴이라 올해 개편을 진행했다. 올해 초 계획을 세웠고, 지금은 개발을 마치고 QA와 론칭을 앞두고 있다. 개편 작업은 툴의 주 사용자분들과 정기 회의를 하며 진행해 왔는데, 그 사이 에이전트 사용 환경에서 MCP가 보편화되면서 API 제공에 대한 요청과 논의도 자연스럽게 MCP 지원에 대한 요청과 논의로 이어졌다.

처음에는 수정 API를 추가하는 방향으로 생각했다. 그러다 MCP로 제공하면 어떨까 싶었다. 아직 최종 결정을 내린 단계는 아니고 검토 중이다. 다만 정기 회의에서 나온 요청의 흐름을 보면 지원하는 방향으로 갈 것 같다.

예를 들어 동료가 에이전트에게 “이 상품 가격을 1,000원으로 바꿔줘”라고 요청한다고 하자. 수정 API만 제공한다면, 동료는 API 문서를 에이전트에게 건네고 요청 주소와 입력 형식에 맞는 호출 스크립트를 만들게 할 수 있다. 인증 정보도 설정해야 한다. MCP로 제공하면, MCP를 지원하는 에이전트 앱에 서버를 연결하고 인증한 뒤 서버가 제공하는 도구의 설명과 입력 형식을 받아 사용할 수 있다. 같은 요청을 받았을 때 에이전트가 상품 가격 수정 도구를 골라 호출할 수 있는 것이다. 동료들이 각자 API 문서를 전달하고 호출 방법을 준비하는 수고를 줄일 수 있겠다고 생각했다.

물론 MCP라고 수정 권한을 제한 없이 주는 것은 아니다. 어떤 경로로 호출하든 요청한 사용자의 권한을 확인하고, 허용된 수정만 기존 상품 처리 로직으로 실행할 생각이다.

MCP 기능을 상품 관리 서버 안에 넣을지, 별도 서버로 만들어 상품 관리 서버를 호출하게 할지는 좀 고민이 됐다. 우선은 기존 서버 안에 함께 넣는 방향으로 정했다. 아직 MCP 기능이 얼마나 커질지 알 수 없는 단계에서 배포하고 운영할 서버를 하나 더 늘리기보다는, 기존 상품 처리 로직을 재사용하며 시작하는 편이 낫겠다고 생각했다.

기존 상품 처리 로직의 입력 검증을 그대로 적용하고, 다른 툴들이 쓰는 읽기 전용 API 조회 경로도 유지하려 한다. 다만 MCP 요청을 받는 부분은 상품 처리 로직과 분리해두려 한다. 나중에 MCP 기능이 커지거나 따로 운영할 필요가 생기면, 그 부분을 별도 서버로 옮기는 것도 검토할 수 있게 해두려는 것이다.

여전히 웹 UI가 필요한 경우

그렇다고 웹 UI가 전부 사라질 것 같지는 않다. 에이전트가 아무리 똑똑해져도 화면이 필요한 경우는 있다.

첫째, 사람이 최종 확인해야 하는 경우가 있다. 상품 가격을 바꾸는 작업을 에이전트에게 맡겼다고 하자. 에이전트는 “요청하신 상품 120개의 가격을 수정했습니다”라고 깔끔하게 보고한다. 그런데 그 말만 믿고 배포 버튼을 누를 수 있을까? 혹시 0이 하나 더 붙은 상품은 없는지, 이벤트 상품이 엉뚱하게 섞이지는 않았는지, 결국 사람은 변경 전후를 나란히 놓고 눈으로 훑어본 다음에야 마음이 놓인다. 에이전트에게 책임까지 위임할 수는 없기 때문이다. 그래서 중요한 변경일수록 무엇이 바뀌었는지 직접 볼 수 있는 화면이 필요하다고 생각한다. 동료가 만든 엑셀 diff 툴이 여전히 쓸모 있는 이유도 여기에 있다.

둘째, 공유와 커뮤니케이션의 편의도 고려해야 한다. 에이전트와의 대화는 각자의 컴퓨터에서 이루어진다. 동료들과 함께 이야기할 때는 같은 화면을 띄워놓는 편이 편리하다. 말로만 설명하면 서로 다르게 이해하는 부분이 생길 수 있다. 결국 에이전트가 아무리 설명을 잘 해주더라도, 여러 사람이 논의하는 자리에서는 여전히 UI가 유용하다.

셋째, 에이전트를 쓸 수 없는 환경을 고려해야 한다. 서버 개발에서 외부 인프라에 문제가 생겼을 때를 대비해 fallback 경로를 마련해두듯, 에이전트가 없어도 작업이 가능한 길을 열어두어야 한다. 에이전트 모델에 장애가 생겨서, 또는 토큰 한도를 초과해서 업무를 할 수 없게 되는 상황은 결코 바람직하지 않다. 웹 접근성을 이야기할 때처럼, 사용하는 환경이 달라도 일을 할 수 있어야 한다는 생각이 든다.

그래서 MCP 서버를 만들면서도 웹 UI를 완전히 걷어낼 생각은 없다. 에이전트에게 맡길 때도, 사람이 직접 확인하거나 작업해야 할 때도 같은 툴을 쓸 수 있으면 좋겠다.

개발자가 느끼는 자기효능감

동료들이 필요한 툴을 직접 만들어 쓰는 모습을 보며, 앞으로는 내가 해줄 일이 없어지는 게 아닐까 불안했다. 동료들에게 필요한 것을 만들어주는 데서 보람을 느껴왔으니, 그 일을 더 이상 부탁받지 않는다면 내가 느끼던 자기효능감도 사라질 것 같았다.

그런데 동료들이 일하는 모습을 좀 더 들여다보니 여전히 내가 할 일이 있었다. 각자 필요한 툴을 만들 수는 있어도, 그 툴이 회사의 기존 시스템에 접근해 데이터를 읽고 수정하려면 연결해주는 작업이 필요했다. 에이전트가 요청했다고 해서 아무 데이터나 바꾸게 할 수는 없으니, 요청한 사람에게 수정 권한이 있는지, 입력한 값에 문제가 없는지도 서버에서 확인해야 했다. 여러 동료가 비슷한 기능을 따로 만들고 있다면, 그 기능을 한곳에서 관리하고 각자의 툴이나 에이전트가 가져다 쓸 수 있게 해주는 일도 필요했다. 동료들이 직접 만드는 툴이 늘어나면서, 내가 도울 수 있는 부분도 조금씩 달라지고 있었다.

동료들이 일을 편하게 할 수 있도록 돕는 일은 계속 필요하다. 모두가 툴을 만들 수 있게 되었다고 해서, 내가 해줄 수 있는 일까지 없어지는 건 아니었다.

ⓒ요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.