AI 활용, 속도와 병목 사이 - 사내 발표 후기

발표를 준비하던 중 인스타그램 bearlycodinglab.kor에서 이런 글을 봤다.

“우리는 그저 클로드와 팀장 사이의 API일 뿐이다.”

읽고 나니 조금 뜨끔했다. 평소 코드를 살펴보거나 문서를 정리할 때 AI를 자주 쓰는 만큼, 잘못하면 정말 내 이야기가 될 수도 있겠다 싶었다. 팀장님의 요청을 AI에 옮겨 적고, AI의 답을 다시 전달하는 일만 한다면 그 사이에서 나는 어떤 판단을 하고 있는 걸까.

실제 업무에서는 AI가 만든 초안을 읽고, 빠진 요구사항을 찾고, 숫자와 근거를 확인하는 일이 계속 필요했다. AI 덕분에 작업은 빨라졌지만, 그 결과를 업무에 쓸 수 있는지 판단하는 일은 여전히 내 몫이었다.

속도가 빨라진 뒤의 변화도 설명할 필요가 있었다. 회사에서 이런 질문을 받았기 때문이다.

AI로 구현이 빨라졌다면, 줄어든 시간은 어디로 갔나?

구현은 빨라졌지만 리뷰와 승인, 다른 부서와의 조율에는 여전히 시간이 걸렸다. 아낀 시간을 코드 구조나 성능을 개선하는 데 쓰기도 했지만, 이런 변화는 화면만 봐서는 알기 어려웠다. 무엇이 빨라졌고, 그 시간에 무엇을 했으며, 어디에서 여전히 막히는지를 함께 설명해야 했다.

이런 경험과 고민을 정리해 다른 팀 개발 팀장님들 앞에서 이야기할 기회를 얻었다. 삼성SDS 써밋에 다녀와 우리 팀에 공유했던 내용을 팀장님께서 좋게 봐주신 덕분이었다.

발표 제목은 「AI 활용, 속도와 병목 사이」로 잡았다. 이 글에는 발표에서 소개한 실제 활용 방법과 그 과정에서 느낀 점을 남겨본다.

AI를 쓰는 범위가 넓어지고 있다

AI를 처음 쓸 때는 질문을 어떻게 적을지가 가장 중요했다. 역할을 주고, 조건을 붙이고, 출력 형식을 정한다. 같은 질문이라도 어떻게 설명하느냐에 따라 답이 달라지니 프롬프트에 신경을 쓰게 된다.

업무에 적용하다 보니 그다음 문제가 보였다. AI가 우리 업무와 코드를 얼마나 알고 있는지, 그리고 필요한 자료를 직접 확인할 수 있는지가 중요해졌다.

발표에서는 삼성SDS 신창민 상무의 「기업 AX를 위한 SW 개발 전략」에서 소개한 구분을 참고했다. Prompt, Context, Harness, Loop, Graph Engineering으로 이어지는 관점이다.

관점	정해야 할 것
Prompt	AI에게 무엇을 지시할 것인가
Context	AI가 어떤 정보를 알고 판단할 것인가
Harness	어떤 도구와 권한, 실행 환경을 제공할 것인가
Loop	수행과 검증을 어떻게 반복할 것인가
Graph	여러 에이전트를 어떻게 연결하고 조율할 것인가

이 중 내가 특히 중요하게 보는 것은 Harness Engineering, 즉 도구와 권한, 실행 환경을 어떻게 제공할지 정하는 부분이다. AI가 실제 자료를 읽고 작업하려면 무엇을 사용할 수 있는지 정해야 하고, 결과를 확인할 방법도 필요하다.

AI에게 많은 권한을 주면 작업 범위가 넓어지지만, 실수의 영향도 커질 수 있다. 반대로 권한을 지나치게 제한하면 실제 업무에 활용하기 어렵다. 그래서 어떤 작업은 바로 맡기고, 어떤 작업은 사람이 확인할지 기준을 정해야 한다. 발표에서는 이 기준에 따라 내가 실제로 도구와 권한을 어떻게 구성했는지 소개했다.

구현이 빨라진 뒤에 남는 병목

AI로 구현 시간을 줄였다고 프로젝트 일정이 같은 비율로 줄어들지는 않는다.

혼자 작업할 때는 목표를 정하고, 구현하고, 확인하는 과정을 빠르게 반복할 수 있다. 프로젝트에서는 다른 사람의 검토와 결정이 들어간다. 내 작업을 끝내도 다음 단계로 바로 넘어갈 수 없는 경우가 있다.

예를 들어 AI와 함께 코드를 빠르게 수정했더라도 요구사항이 모호했다면 결과를 보고 다시 논의해야 한다. 리뷰할 사람이 다른 업무로 바쁘면 PR은 검토를 기다려야 한다. 기획이나 디자인에서 결정해야 할 내용이 남아 있다면 구현 속도만으로 해결하기 어렵다.

발표에서 짚은 병목은 이런 것들이었다.

요구사항이 모호해 다시 만드는 시간
흩어진 요구사항과 문서, 코드를 맞춰보는 시간
리뷰와 승인을 기다리는 시간
다른 부서와 방향을 조율하는 시간

코드가 빨리 쌓이면 검토해야 할 양도 늘어난다. 확인할 수 있는 시간은 그대로인데 변경안만 많아지면 리뷰 대기열이 길어질 수 있다. 급하다는 이유로 검토를 건너뛰면 잘못된 변경을 놓칠 가능성도 커진다.

그래서 AI 활용의 효과를 보려면 어떤 작업이 빨라졌는지와 지금 어디에서 막히는지를 함께 봐야 한다고 생각한다.

DORA의 2025년 보고서도 AI가 조직이 이미 가진 강점과 약점을 증폭한다고 설명한다. 이 관점을 개발 업무에 적용해보면, AI를 도입하는 것과 함께 요구사항을 정리하고 결과를 검토하는 방식도 다듬어야 한다는 생각이 든다.

화면에 보이지 않는 개선도 있다

절약한 시간의 쓰임을 설명하려면 이런 질문에도 답해야 했다.

AI로 아낀 시간에 개발자는 무엇을 했나?

화면이나 기능이 그대로라면 달라진 게 없는 것처럼 보일 수 있다. 하지만 내가 개발·운영하는 서비스에서는 절약한 시간을 서비스 내부를 개선하는 데에도 썼다.

같은 화면 아래에 쌓이는 응답 속도와 코드 구조 유지보수 개선 — 눈에 보이는 화면 아래에 성능과 코드 구조의 개선이 쌓인다.

같은 화면이어도 응답 속도는 빨라질 수 있다. 기존 기능을 유지하면서 중복 코드를 정리하거나, 수정하기 어려웠던 구조를 개선할 수도 있다. 당장 필요한 기능에 밀려 미뤄뒀던 작업에 손을 댈 여유가 생긴 것이다.

기존 코드를 살펴보고 수정 방향을 비교하는 부담이 줄어드니, 이전에는 엄두를 내기 어려웠던 개선도 시도할 수 있었다.

이런 일은 새 화면처럼 바로 드러나지는 않는다. 대신 이후 코드를 수정할 때 부담이 줄고, 다음 기능을 개발할 때 도움이 된다. 고치기 쉬운 코드와 빠르고 안정적인 서비스도 회사에 필요한 결과다.

다만 이 가치를 설명하는 일은 개발자가 챙겨야 한다. 성능이 좋아졌다면 전후 응답 시간을 보여주고, 구조를 정리했다면 이후 수정이 어떻게 쉬워졌는지 설명해야 한다. AI로 시간이 줄었다는 이야기와 함께 그 시간을 어디에 썼는지도 전달할 필요가 있다.

내가 실제로 AI를 활용하는 방법

절약한 시간을 다른 개선에 쓰려면, AI가 만든 결과가 실제 업무에 사용할 수 있는 수준인지 먼저 확인해야 한다. 발표에서는 쇼핑몰 연동 문서 세 편을 작성했던 경험을 중심으로 내가 AI를 활용하고 검증하는 방법을 소개했다.

먼저 결과부터 이야기하면, 문서 세 편을 아홉 차례 수정했다. 한 번에 끝난 문서는 한 편도 없었다. AI를 쓰면 한 번에 완성될 것 같지만, 실제로는 결과를 읽고 기준을 다시 맞추는 과정이 계속 필요했다.

내가 사용하는 흐름은 다음과 같다.

요건 정리 프롬프트 설계 스킬과 MCP 도구 검증 사람의 판단을 거쳐 다시 수정하는 다섯 단계 — **기준을 정하고 결과를 검증한 뒤**, 필요한 부분을 다시 수정한다.

1. 작업 범위와 기준을 먼저 적는다

시작하기 전에 범위, 기준, 항목, 형식을 정리한다.

어디까지 다룰 것인지, 어떤 자료를 근거로 삼을 것인지, 반드시 들어가야 할 내용은 무엇인지 적는다. 누가 읽을 문서인지도 함께 정한다. 개발자가 구현에 참고할 문서와 의사결정에 사용할 문서는 필요한 설명이 다르기 때문이다.

이 기준을 먼저 적어두면 결과를 받고 수정할 때도 판단하기 쉽다. 빠진 내용인지, 애초에 이번 작업 범위에 들어가지 않는 내용인지 구분할 수 있다.

2. 프롬프트 초안도 AI와 함께 만든다

정리한 요건을 바탕으로 AI에게 작업용 프롬프트를 만들어보게 한다. 흔히 메타프롬프팅이라고 부르는 방식이다.

내가 빠뜨린 조건이나 확인 항목을 찾는 데 도움이 된다. 다만 만들어진 프롬프트는 직접 읽고 우리 환경에 맞게 고친다. 사용할 수 없는 자료를 요구하고 있거나, 작업 범위가 불필요하게 커졌다면 수정한다.

프롬프트를 만드는 과정에서도 사람이 업무 맥락을 알고 있어야 한다.

3. 반복하는 절차는 스킬로 남기고 도구를 연결한다

반복하는 작업의 절차와 주의사항은 스킬로 저장해둔다. 매번 처음부터 설명하던 기준을 다음 작업에서도 사용할 수 있게 남기는 것이다.

직접 자료를 확인해야 하는 작업에는 MCP(Model Context Protocol)를 통해 DB나 메일 같은 도구를 연결한다. 내가 자료를 하나씩 복사해 전달하는 과정이 줄고, AI가 필요한 정보를 조회하며 작업할 수 있다.

이전에 정리한 쇼핑몰 API 변경 검토 자동화도 비슷한 방식이다. 공지를 수집하고 연동 코드와 대조하는 절차를 스킬로 만들고, 실제로 확인하면서 알게 된 몰별 주의사항을 추가했다.

우리 환경에서 확인한 기준이 쌓일수록 다음 작업에도 도움이 된다.

4. 숫자는 직접 확인할 수 있는 도구로 다시 검증한다

이 문서 작업에서 가장 기억에 남는 사례는 인터페이스 건수였다.

AI는 32개라고 정리했다. 문장도 자연스럽고 숫자도 자신 있게 제시했다. 그런데 스크립트로 다시 확인해보니 실제로는 42개였다.

단순히 개수를 세는 일에서도 틀릴 수 있다는 것을 다시 확인했다. 그래서 이런 항목은 검색 명령이나 스크립트로 검증한다. 이관 대상 규모도 MCP를 통해 DB에서 직접 조회하도록 했다.

직접 조회한 결과도 무엇을 어떤 조건으로 셌는지 확인해야 한다. 조회 대상이 다르면 정확하게 센 숫자라도 우리가 필요한 결과와는 달라진다.

숫자와 함께 확인 방법이 있어야 검토할 수 있다.

5. 사람이 읽고 무엇을 고칠지 판단한다

결과를 받으면 네 가지를 확인한다.

요청한 범위에 맞는가
설명을 뒷받침하는 근거가 있는가
숫자가 실제 자료와 일치하는가
이 문서의 독자가 이해하고 판단할 수 있는가

수정할 때는 어느 부분이 왜 잘못됐는지 구체적으로 전달한다. 빠진 항목이 있다면 대조할 원본을 알려주고, 설명이 맞지 않으면 독자에게 필요한 내용을 다시 적는다.

아홉 차례 수정한 문서도 이런 과정을 거쳤다. AI가 초안을 빨리 만들어주니 수정도 빠르게 반복할 수 있었다. 그 과정에서 기준을 세우고 잘못된 부분을 찾는 일은 계속 내가 해야 했다.

내가 발표에서 소개하고 싶었던 것도 이 과정이었다. 초안을 받아서 검토하고, 문제를 짚고, 다시 확인하면서 업무에 사용할 수 있는 결과로 만드는 방식이다.

도구를 연결할수록 권한도 정해야 한다

AI가 자료를 읽는 것에서 나아가 실제 도구를 사용하게 되면, 어디까지 맡길지도 정해야 한다.

실행 속도가 빨라진 만큼 잘못된 작업도 빠르게 진행될 수 있다. 특히 운영 시스템이나 외부 서비스에 연결할 때는 작업의 영향을 따져봐야 한다.

발표에서는 내가 사용하는 환경의 기준을 다음과 같이 소개했다.

구분	작업
허용	DB 조회, 스키마 확인, 실행계획 확인
사람의 확인 필요	메일 발송, 외부 연동 실행
금지	운영 데이터 변경과 삭제

조회와 분석은 정해진 범위 안에서 진행하게 하고, 외부에 영향을 주는 작업에는 사람이 확인하는 단계를 둔다. 운영 데이터를 바꾸거나 삭제할 수 있는 권한은 제한한다.

프롬프트에 이 기준을 적고, 실제 도구 권한에도 적용해야 한다. 코드 변경은 별도 브랜치에서 작업하고 PR로 검토하는 흐름을 사용한다.

사람이 모든 동작을 하나씩 확인하면 활용 효과가 줄어든다. 그래서 바로 진행할 수 있는 작업과 사람이 판단해야 할 작업을 미리 구분하는 것이 중요하다고 생각한다.

개발자가 더 일찍 고민해야 할 것

AI에게 맡길 범위를 정하는 일은 결국 개발자가 직접 판단할 몫을 정하는 일이기도 하다. 도입부에서 본 문장처럼 요청과 답을 전달하는 데 머무르지 않으려면, 요구사항을 이해하고 정리하는 일부터 챙겨야 한다고 느낀다.

받은 요구를 그대로 AI에 전달하면 그 안에 있던 모호함도 함께 전달된다. 결과물을 보고 나서야 예외 상황을 발견하면, 빠르게 만든 코드를 다시 수정해야 한다.

개발자가 맡는 문제 정의 요구사항 정리 방향 선택 결과 검증 — 개발자가 맡아야 할 문제 정의와 방향 선택, 결과 검증.

그래서 개발자가 기획 단계부터 참여해 예외 상황을 찾고, 구현할 수 있는 수준으로 요구사항을 정리해야 한다고 생각한다. 구현 중에는 결과가 의도한 방향에 맞는지도 살펴야 한다.

이때 비즈니스 맥락도 필요하다. 고객에게 어떤 문제가 중요한지, 이번 범위에서 무엇을 우선할지 알아야 AI가 만든 제안도 평가할 수 있다. 기획자나 디자이너, 의사결정권자와 이 기준을 맞추는 일도 개발 과정에 포함된다.

이전에 AI 실무 역량 평가 후기에서도 비슷한 생각을 했다. 코드를 수정하는 것과 그 수정이 왜 필요한지, 어떤 영향을 만드는지 설명하는 것은 각각 필요한 일이었다.

앞으로는 코드를 작성하는 능력과 함께 문제를 이해하고 요구사항을 정리하는 능력, 결과를 검증하고 설명하는 능력을 더 많이 쓰게 될 것 같다. AI를 쓰면서 나도 이 부분을 더 신경 쓰게 됐다.

마치며

이번 발표를 준비하면서 평소 AI를 어떻게 쓰고 있는지 다시 돌아볼 수 있었다. 자주 쓰고는 있었지만, 내가 어떤 기준으로 맡기고 어디에서 직접 판단하는지 정리해보는 것은 또 다른 일이었다.

개발 팀장님들과 이런 내용을 공유할 기회를 얻어 감사한 마음도 들었다.

AI 덕분에 빨라진 작업이 있고, 그 시간을 활용해 시도한 개선도 있다. 한편으로는 검토할 양이 늘고, 요구사항과 판단 기준을 더 명확하게 정해야 할 필요도 느끼고 있다.

앞으로도 실제 업무에 AI를 적용하면서 빨라진 구간과 여전히 막히는 구간을 함께 살펴보려고 한다. 우리 팀에서는 어떤 일이 병목인지, 어떤 결과를 받으면 다음 사람이 더 쉽게 검토할 수 있을지부터 고민해보고 싶다.

AI를 사용하는 방법도 계속 바뀔 테니, 직접 해보면서 얻은 경험은 앞으로도 글로 남겨볼 생각이다.

피드백은 언제나 환영입니다.

목차