> ## Content Index
> Fetch the complete content index at: https://blog.jikji.ai/llms.txt
> Use this file to discover other available public pages before exploring further.

# AI 시대, 개발자는 뭘 준비해야 할까
- URL: https://blog.jikji.ai/posts/ai-sidae-gaebaljaneun-mweol-junbihaeya-halgga/
- Published: 2026-09-21T06:58:11.000Z
- Updated: 2026-09-21T06:58:11.000Z
- Author: jeongzu
- Tags: Blog

요즘 개발 이야기를 나누다 보면 결국 AI 이야기로 이어집니다. 어떤 도구가 코드를 잘 만드는지, 어디까지 맡겨봤는지, 써보니 뭐가 좋고 뭐가 답답한지.

편해진 건 분명히 있습니다. 막막하던 초안을 빨리 잡기도 하고, 반복 작업을 덜기도 합니다. 그러다 문득 이런 생각도 듭니다.

‘그럼 나는 앞으로 뭘 더 잘해야 하지?’

새로운 도구를 계속 익혀야 할 것 같고, 기본기를 더 공부해야 할 것 같기도 합니다. 둘 다 필요한 일이겠죠. 여기에 하나를 더 보태고 싶습니다.

**내가 만든 걸 쓰는 사람의 일을 이해하는 것.**

말로 하면 당연합니다. 그런데 막상 개발하다 보면 놓치기 쉽습니다. 이번 주 안에 끝내야 할 기능이 있고, 리뷰가 쌓여 있고, 갑자기 들어온 버그도 있으니까요. 사용자가 이 기능으로 무슨 일을 하려는지보다 일단 제대로 동작하게 만드는 데 집중하게 됩니다.

그렇게 배포까지 마쳤는데, 정작 사용자는 예전 방식으로 일하고 있다면 어떨까요.

## “그냥 엑셀로 하는 게 더 빨라요”

만든 사람 입장에서는 힘이 빠지는 말입니다.

필요하다고 해서 만들었고, 요청받은 기능도 넣었습니다. 그런데 사용자는 여전히 엑셀을 켜고, 메신저로 파일을 보내고, 옆자리 동료에게 물어봅니다.

이럴 때는 사용자가 일을 처리하는 과정을 처음부터 한 번 볼 필요가 있습니다. 우리가 만든 기능의 앞뒤에 어떤 일이 붙어 있는지까지요.

예를 들어 고객이 “사내 문서를 검색하는 AI 챗봇이 필요해요”라고 했다고 가정해보겠습니다.

개발자는 바로 여러 가지를 고민하게 됩니다. 모델은 뭘 쓸지, 검색은 어떻게 할지, 문서를 어떻게 나눌지. 개발자에게는 익숙하고 재미있는 문제입니다.

그런데 담당자 옆에서 실제 업무를 보면 다른 부분이 눈에 들어올 수 있습니다. 문서를 찾은 뒤 계약 조건을 비교하고, 금액이 맞는지 확인하고, 근거를 캡처해서 승인자에게 보내고 있습니다. 답변 하나를 얻은 뒤에도 일이 한참 남아 있는 겁니다.

이 사람에게는 매끄러운 대화보다 ‘이 금액이 어느 문서 몇 페이지에 있는지’가 더 중요할 수 있습니다. 답변을 다시 보고서에 옮겨야 한다면 그 작업이 더 번거로울 수도 있고요.

이걸 알게 되면 무엇부터 만들어야 할지가 달라집니다.

그래서 기능 이야기를 시작할 때 이런 부탁을 한 번 해보면 좋겠습니다.

> “최근에 하신 작업 하나만 보여주실 수 있을까요? 어떻게 처리하시는지 보고 싶어요.”

회의를 한 번 더 하는 것보다, 실제 작업을 같이 보는 짧은 시간이 더 많은 걸 알려줄 때가 있습니다.

## 만들기 전에 서로 같은 문제를 보고 있는지 확인하기

사용자의 이야기를 들었다고 바로 이해했다고 생각하면 또 엇갈릴 수 있습니다. 각자 익숙한 표현을 쓰다 보니 같은 말을 다르게 받아들이기도 하니까요.

이럴 때는 우리가 이해한 내용을 짧게 써서 돌려보면 됩니다.

“계약서를 찾고 내용을 확인하는 데 시간이 많이 들고 있네요. 이번에는 그 시간을 줄여보려고 합니다. 대신 금액과 계약 조건은 원문에서 확인할 수 있어야 하고요.”

이 정도면 대화를 이어갈 수 있습니다.

그러면 고객이 “맞아요. 그런데 사실 제일 오래 걸리는 건 승인 기다리는 시간이에요”라고 할 수도 있습니다. 중요한 이야기입니다. 검색을 아무리 개선해도 전체 업무 시간이 기대만큼 줄지 않을 수 있다는 걸 미리 알게 됐으니까요.

이미 구현한 뒤에 이런 이야기를 들으면 난감합니다. 시작할 때 알게 되면 범위를 조정하거나 기대치를 맞출 수 있습니다.

개발자가 모든 업무를 꿰뚫고 있을 필요는 없습니다. 다만 **내가 무엇을 이해했고, 무엇을 아직 모르는지 드러내는 습관**은 도움이 됩니다. 모르는 걸 빨리 물어볼수록 나중에 다시 만드는 일을 줄일 수 있습니다.

## 기술 공부도 여기에서 조금 달라진다

사용자의 일에 관심을 가지자는 이야기가 기술 공부를 덜 하자는 뜻은 아닙니다. 오히려 현장을 알면 더 공부해야 할 부분이 보입니다.

앞선 문서 검색 사례만 해도 그렇습니다.

오래된 계약서가 검색되면 어떻게 해야 할까요. 문서 두 개의 금액이 다르면 어느 쪽을 보여줘야 할까요. 다른 부서의 비공개 문서가 답변에 섞이면요. 답을 찾지 못했을 때는 어디까지 설명하고 사람에게 넘겨야 할까요.

처음에는 모델을 연결하면 될 것 같았는데, 데이터와 권한, 평가, 오류 처리까지 살펴야 합니다. 실제로 쓸 수 있는 시스템을 만들려면 이런 부분을 피하기 어렵습니다.

공부할 때도 이 질문들을 가져가면 좋겠습니다. 작은 프로젝트를 만들더라도 잘되는 질문 몇 개만 넣어보고 끝내지 말고, 자료가 없는 질문이나 애매한 질문도 넣어보는 겁니다. 틀린 답이 나오면 어디서부터 잘못됐는지 따라가보고요.

AI가 코드를 만들어줬을 때도 마찬가지입니다. 왜 이렇게 구현했는지 읽어보고, 어떤 입력에서 문제가 생길지 확인해야 합니다. 문제가 생겼을 때 고칠 수 있으려면 여전히 기본기가 필요합니다.

새 도구를 배우면서 이런 감각을 함께 쌓으면 좋겠습니다. 빨리 만드는 데서 얻은 시간을, 만든 것을 더 잘 이해하는 데 쓰는 겁니다.

## 배포 후에 한 번만 더 들여다보기

배포가 끝나면 다음 일이 기다리고 있습니다. 잠깐 숨을 돌리고 나면 새 기능을 맡거나 다른 문제를 해결하러 가야 합니다. 방금 만든 기능이 어떻게 쓰이는지 알아볼 틈이 없는 경우도 많습니다.

그래도 가능하다면 일정에 짧은 시간을 남겨두면 좋겠습니다. 담당자가 실제로 써본 뒤 이야기를 듣는 시간입니다.

“써보니 어떠세요?”라고만 물으면 “괜찮아요”로 끝날 수 있습니다. 실제 처리한 건을 같이 보면서 어디가 편했고 어디에서 막혔는지 물으면 좀 더 구체적인 이야기가 나옵니다.

검색은 빨라졌는데 결과를 옮겨 적는 일이 남아 있을 수도 있습니다. 기능은 잘 동작하지만 사용자가 존재 자체를 모를 수도 있습니다. 우리가 꽤 공들인 부분을 아무도 쓰지 않을 수도 있고요.

아쉬운 마음이 드는 건 자연스럽습니다. 그래도 다음에 무엇을 해야 하는지는 훨씬 선명해집니다. 새 기능을 더 넣기 전에 사용 방법을 안내하는 것만으로 도움이 될 수도 있으니까요.

고객을 직접 만나기 어려운 개발자도 많습니다. 그럴 때는 고객 문의를 같이 읽거나, PM과 지원 담당자에게 실제 사용 이야기를 들을 수 있습니다. 내가 만든 것에 대한 소식이 돌아오는 통로를 하나 마련해두는 겁니다.

물론 이 시간을 개발자 개인이 알아서 쪼개 쓰는 데에는 한계가 있습니다. 팀에서도 배포 이후를 살펴보는 일을 일정에 포함해줘야 합니다. 결과를 중요하게 본다면, 결과를 확인할 시간도 있어야 하겠죠.

## 한 번 고생한 일은 다음에 조금 덜 고생하도록

프로젝트를 끝내고 나면 아쉬움이 남습니다.

“권한부터 확인했어야 했는데.”  
“이 데이터는 처음부터 문제가 있었구나.”  
“다음에는 이 질문을 꼭 해봐야겠다.”

이런 경험이 머릿속에만 남으면 다른 동료가 똑같이 고생할 수 있습니다. 나 자신도 몇 달 뒤에 다시 헤맬 수 있고요.

거창한 문서가 아니어도 괜찮습니다. 시작 전에 확인할 항목 몇 개, 실제로 실패했던 질문, 자주 쓰는 연결 코드 정도만 남겨도 다음 작업에 도움이 됩니다.

여러 프로젝트에서 같은 문제가 반복된다면 그때 공통 도구나 제품 기능으로 옮겨볼 수 있습니다. 모든 고객 요구를 미리 일반화하려고 애쓰기보다는, 반복해서 부딪힌 부분부터 정리해가는 편이 현실적입니다.

이런 식으로 고객의 업무를 이해하고, 구현하고, 실제 사용을 살피고, 배운 것을 제품에 되돌리는 방식은 FDE(Forward Deployed Engineer)라는 역할과도 연결됩니다.

FDE라는 이름이 생소해도, 해왔던 일을 떠올려보면 익숙한 부분이 있을 겁니다. 사용자에게 한 번 더 물어보고, 배포 뒤에 문제를 확인하고, 다음에는 같은 고생을 하지 않도록 도구를 만드는 일. 그 경험을 조금 더 의식적으로 이어가보자는 이야기입니다.

## 다음에 맡은 기능 하나부터

앞으로 무엇을 준비해야 하느냐는 질문에 답하다 보면 자꾸 할 일이 늘어납니다. 새 기술도 배우고, 업무도 이해하고, 운영도 살펴야 한다고 하면 부담부터 들 수 있습니다.

당장 전부 바꾸려고 할 필요는 없겠습니다.

다음 기능을 맡았을 때 하나만 더 물어보면 어떨까요.

**“이걸 쓰는 분은 지금 어떻게 일하고 있나요?”**

그 이야기를 듣고 나면 구현할 때 한 가지를 다르게 선택할 수도 있습니다. 배포 뒤에 그 선택이 도움이 됐는지 궁금해질 수도 있고요. 그렇게 조금씩 자신의 개발 방식이 넓어지는 것 같습니다.

막혀 있던 코드를 해결했을 때도 기분이 좋지만, 사용자가 “이거 덕분에 일이 좀 줄었어요”라고 말해줄 때는 또 다른 보람이 있습니다.

AI 덕분에 구현 과정에서 여유가 생긴다면, 그중 일부는 우리가 만든 것을 쓰는 사람에게 써보면 좋겠습니다. 다음에 무엇을 배워야 할지도 그곳에서 찾을 수 있을 테니까요.