AI에게 일을 맡길수록, 사람에게 남는 일
안녕하세요. 엑셈에서 MaxGauge의 Oracle 모니터링 에이전트를 C/C++로 개발하고 있는 DB개발본부 데몬1팀 김성규입니다.
"AI가 사람을 정말 대체할 수 있을까?"
요즘 자주 듣는 질문입니다. 저도 그게 정말인지 궁금했습니다. 남의 일자리로 확인해 볼 수는 없으니 제 일로 직접 실험해 보기로 했습니다.
방법은 단순합니다. 제가 하는 일 곳곳에 AI를 넣어 하나씩 갈아끼워 보는 겁니다. 기록도, 개발도, 검증도, 아이디어를 내는 일도요. 목표는 제가 가진 지식과 노하우를 AI가 대신하게 만드는 것입니다. 그러려면 AI의 결과를 믿을 수 있어야 하기에 신뢰도를 높이는 데 가장 많은 시간을 쓰고 있습니다.
실험한 영역은 4가지입니다. 영역마다 AI가 어디서 막혔고 그때마다 사람이 무엇을 채워 넣어야 했는지를 중간 보고서 형식으로 공유합니다. 실험에 사용한 도구는 Claude이고, 실험은 지금도 진행 중입니다.
결론부터 말하면 실험은 아직 실패입니다. 다만 실패한 지점을 따라가 보면 AI에게 일을 맡기기 위해 사람이 무엇을 준비해야 하는지가 보입니다.
1. 실험 결과 한눈에 보기
아직 저를 완전히 갈아끼우지는 못했습니다. 영역마다 AI가 막힌 지점이 있었고, 그때마다 제가 무언가를 채워 넣어야 했습니다.
위 이미지의 ‘막힌 지점’과 ‘사람이 채운 것’ 두 열이 이 글의 핵심입니다.
2. 기록: AI는 적히지 않은 내용을 지어낸다
가장 먼저 맡긴 일은 분기마다 작성하는 성과 정리였습니다. 저는 업무를 ClickUp 일감으로 관리하고 있어서 기간만 알려 주면 AI가 해당 기간의 일감을 찾아 읽고 정리해 줍니다.
문제는 AI가 추측으로 이야기를 만들어 낸다는 것이었습니다. 왜 그럴까 들여다보니 이유는 단순했습니다. 일감에 적혀 있지 않았기 때문입니다. 그 뒤로 기록 방식을 3단계에 걸쳐 바꿨습니다.
- 빈칸 줄이기: 평소에 일감을 꼼꼼히 적기 시작했습니다. 바쁜 날에는 여전히 자세히 적지 못하는 일감도 있지만 AI가 지어내는 일은 확실히 줄었습니다.
- 일감 연결하기: 서로 연관된 일감을 AI가 각각 별개의 일로 정리하는 문제가 보였습니다. 관련 일감끼리 링크를 걸자 AI도 이어지는 업무를 하나로 엮어 정리하기 시작했습니다.
- 팩트 남기기: "성능을 개선했다", "버그를 수정했다"로 끝나는 기록으로는 AI도 그 이상을 쓸 수 없습니다. 어떤 부분이 얼마나 개선됐는지, 어떤 버그를 어떻게 고쳤고 결과가 어땠는지를 일감에 구체적으로 남겼습니다.
지금도 통째로 맡기기에는 완벽하지 않지만 처음보다는 분명 좋아졌습니다. AI는 그대로였고 바뀐 건 제 기록 습관이었습니다.
3. 개발: 넓게 맡기면 AI는 우리 제품을 모른다
코드 작성은 이미 꽤 많이 AI로 갈아끼웠습니다. 저는 C/C++ 개발자지만 사내 도구는 한 번도 써 보지 않은 Go, Python, Rust로도 AI와 함께 만들고 있습니다. 처음에는 국소적인 부분만 맡겼는데 그 정도 범위는 상세하게 설명하지 않아도 품질이 괜찮았습니다.
AI가 발전하면서 더 넓은 범위를 맡겨 봤습니다. 그런데 결과물에는 다른 팀과의 접점이나 제품 전체 도메인 관점의 설계가 빠져 있었습니다. 고치면 되는 부분도 있었지만 어떤 것은 설계 자체의 문제라 프로그램을 다시 작성해야 했습니다.
결과를 일일이 검토하며 다시 시키니 품질은 올라왔습니다. 다만 그만큼 제가 AI에게 줘야 하는 피드백도 늘었습니다. 일은 AI가 하는데 저는 오히려 더 바빠졌으니 AI가 저를 대체하는 방향은 아니었습니다.
그래서 방법을 바꿔 봤습니다. 처음부터 제가 다른 모듈과 제품 도메인 지식을 녹여 설계하고, 그 설계를 바탕으로 개발을 맡기는 방식입니다.
그러자 맡기는 시점부터 AI의 질문이 쏟아졌습니다. 질문에 답하다 보니 기존 제품의 이력과 스펙, 다른 모듈과의 연계까지 더 넓게 생각해 볼 기회가 됐습니다. 그렇게 나온 결과물은 제가 직접 코드를 작성할 때보다 나았습니다.
대충 맡기고 꼼꼼히 검토하든 설계를 먼저 넘기든 품질은 올릴 수 있었습니다. 다만 어느 쪽이든 마지막에 남는 건 제품을 넓게 보는 시야였고, 이 부분은 아직 AI에게 넘기지 못했습니다.
4. 검증: AI는 시험 문제를 바꿔서 만점을 받는다
에이전트의 성능 개선을 AI에게 맡겼을 때 일입니다. AI가 "성능이 개선됐습니다"라고 보고했는데 들여다보니 데이터를 수집하는 횟수 자체를 줄여 놓은 것이었습니다. 일을 덜 하니 CPU를 덜 쓰는 건 당연합니다.
자동차로 치면 연비를 개선하라고 했더니 덜 달려서 기름을 아낀 것과 같습니다. 기름을 얼마나 썼는지만 보면 개선처럼 보이지만 1km에 얼마나 쓰는지를 보면 달라진 게 없습니다.
위 그림은 이 차이를 예시로 정리한 것입니다. 왼쪽은 AI가 본 기준인 'CPU를 총 얼마나 썼나'입니다. 수집 횟수가 줄었으니 사용량도 줄어 개선처럼 보입니다. 오른쪽은 '한 번 수집할 때 CPU를 얼마나 쓰나'라는 기준입니다. 이렇게 보면 개선 전과 후가 그대로입니다.
그래서 DB 성능 지표를 한 번 수집할 때 CPU를 얼마나 쓰는지 측정하는 profiler를 만들었습니다. 연비 계기판을 단 겁니다. 이제는 이 기준을 AI에게 주고 성능 개선을 맡깁니다. 기준이 생기자 AI도 더는 시험 문제를 바꾸지 못했습니다.
데이터 정합성 검증도 맡겨 봤지만 여기서는 다른 문제가 있었습니다. 에이전트는 여러 Oracle 버전과 패치에서 똑같이 동작해야 합니다. 테스트 환경을 만들 수는 있었지만 버전 하나를 구성하는 데 반나절, 오래된 버전은 며칠씩 걸렸고 서버 자원도 한정돼 있었습니다. 그러다 보니 한 번에 검증해 볼 수 있는 범위가 좁았고 AI의 검증 결과도 그만큼 부정확한 경우가 있었습니다.
이 문제는 Docker 기반으로 Oracle 테스트 환경을 만들어 구성 비용을 줄이는 방식으로 풀었습니다. 버전과 패치별 이미지를 만드는 스크립트는 AI가 작성했고, 지금은 Oracle 10g부터 26ai까지 51개 패치 레벨을 내려받아 바로 띄울 수 있습니다. 다만 어떤 환경이 왜 필요한지 정하고 이미지가 제대로 만들어졌는지 확인하는 검증 단계를 세우는 일은 제가 맡았습니다.
돌아보면 검증에서 제가 한 일은 두 가지였습니다. 무엇으로 판단할지 기준을 세우고 그 기준으로 시험해 볼 환경을 넉넉히 만드는 것입니다. 시험은 AI가 치를 수 있지만 시험지를 만드는 건 아직 사람의 몫이었습니다.
5. 아이디어 내기: "다 개선해 줘"는 쓸모가 없었다
아이디어를 내는 일도 맡겨 봤습니다. 처음에는 "이 서비스의 개선 포인트를 찾아서 전부 개선해 줘" 같은 식으로 요청했습니다. 결과는 그럴듯했지만 실제로 쓸모 있는 건 거의 없었습니다.
그래서 방법을 바꿨습니다. 제가 직접 써 보면서 불편한 부분을 먼저 찾고, 그 지점에 대해서만 의견을 묻는 방식입니다.
예를 들면 이런 식입니다.
- "이 부분이 너무 느려서 불편한데, 구조를 이렇게 바꾸거나 UX를 이렇게 바꾸면 어떨까?"
- "이 부분은 CPU 효율을 포기하더라도 이런 식으로 개선하는 게 좋을 것 같아."
- "이렇게 바꾸면 다른 모듈에 영향은 없을까?"
3가지 질문에는 각각 불편을 느낀 지점, 감수할 수 있는 trade-off, 확인하고 싶은 영향 범위가 담겨 있습니다. AI가 답을 찾을 범위를 사람이 먼저 좁혀 준 겁니다.
출발점을 주자 AI가 내놓는 아이디어가 확 달라졌습니다. 반대로 말하면 무엇이 불편한지는 아직 사람이 느껴야 합니다. 직접 써 보지 않은 AI는 불편함을 모르기 때문입니다.
6. 마치며: 갈아끼울수록 선명해지는 것
4가지 실험에서 AI가 막힌 지점에는 공통점이 있었습니다. AI는 기록되지 않은 맥락과 무엇이 좋은 결과인지에 대한 기준을 모릅니다. 그리고 하나 더, 자기가 낸 답이 옳은지도 모릅니다. 수학 문제나 쉬운 질문에는 워낙 정답을 잘 내다 보니 정답을 아는 것처럼 보이지만 실제로는 옳고 그름을 아는 게 아니라 그럴듯한 답을 내는 데 가깝습니다. 적히지 않은 내용을 지어낸 것도, 일을 덜 하고 "개선됐다"고 보고한 것도 그래서였습니다.
실험 내내 제가 한 일은 대부분 AI가 틀리지 않을 조건을 만드는 일이었습니다.
- 기록: 맥락과 팩트를 일감에 남기기
- 개발: 도메인 지식을 녹인 설계를 먼저 넘기기
- 검증: 측정 기준과 테스트 환경 만들기
- 아이디어: 직접 써 보고 불편함을 정의하기
그래서 지금 제 결론은 "아직은 완전한 대체가 불가능하다"입니다. 물론 지금까지의 실험으로 내린 제 생각일 뿐입니다.
재미있는 건, 저를 갈아끼우려고 하면 할수록 갈아끼워지지 않는 부분이 오히려 선명해졌다는 점입니다. 그리고 저를 AI로 대체하려고 애쓰는 동안 정작 제가 많이 성장했다고 생각합니다. 기록하는 습관도, 제품을 넓게 보는 시야도, 무엇으로 결과를 판단할지 정하는 눈도요.
요즘은 이런 가설을 세워 두고 있습니다.
자신을 AI로 대체하려는 사람이, 역설적으로 끝까지 대체되지 않는 게 아닐까.
다만 이 실험은 묘한 구조입니다. 실험이 실패하는 동안, 그러니까 제가 아직 대체되지 않은 동안에만 가설이 살아 있습니다. 그마저도 가설이 옳다는 증명은 되지 않습니다. "아직" 대체되지 않은 것일 수도 있으니까요.
반대로 실험이 성공해서 제가 완전히 갈아끼워지는 날 가설은 거짓이 됩니다. 그날이 오면 마지막 실험 보고서로 다시 찾아뵙겠습니다.
함께 보면 좋은 아티클
