「AI에게 일자리를 빼앗긴다」가 아니라 「AI와 함께 생각한다」로 전환했더니, 일하는 방식이 근본적으로 변했다.

필자는 풀스택 엔지니어(Full-stack Engineer) 경력 20년 초과. 금융계 Web 서비스를 주 전장으로 삼아왔다.

Claude(Anthropic이 제공하는 AI)를 본격적으로 업무에 도입한 지 약 1년이 지난 지금,

무엇이 변했고, 무엇은 변하지 않았는가를 솔직하게 쓰고자 한다.

시니어 엔지니어(Senior Engineer)나 리드 엔지니어(Lead Engineer)라면 꼭 읽어보길 바라는 내용이다.

처음의 인식은 아마 많은 사람과 같았을 것이다.

「GitHub Copilot처럼 보완해 주는 편리한 도구겠지?」

그래서 처음에는 코드 생성에만 사용하고 있었다. 그리고 별로 감동하지 않았다.

생성되는 코드가 「작동은 하지만 읽고 싶지 않은 코드」였기 때문이다.

코드 리뷰(Code Review)에서 반려할 수준의 구현이 태연하게 나오고,

직접 쓰는 편이 더 빠른 상황도 많았다.

반년 정도 지나자 사용을 그만둘 뻔했다.

전환점은 복잡한 이관(Migration) 작업 설계에서 막혔을 때였다.

MySQL 5.7 → 8 과 Amazon Linux 2 → 2023을 동시에 진행하는 안건에서,

리스크를 어떻게 분산할지에 대한 정리가 잘 되지 않았다.

문서로 쓸 수 있을 만큼 구체화되지는 않았지만, 머릿속을 정리하고 싶다.

그런 상태일 때, 문득 Claude에게 「상담」을 해보았다.

현재 이런 상황에서 막혀 있습니다.
- AL2→AL2023 및 MySQL 5.7→8을 동시에 이관해야 함
- 운영 환경 전환 시의 리스크가 높다고 느끼고 있지만, 무엇이 두려운 것인지 정리가 되지 않음
...

돌아온 것은 「이관 절차서」가 아니었다.

「당신이 두렵다고 느끼는 것은 이런 것이 아닌가」라는 정리였다.

• 장애 발생 시 원인 분리(Troubleshooting)가 어려워짐 (두 시스템이 동시에 바뀌기 때문)
• 롤백(Rollback) 판단 기준이 모호한 채로 운영에 들어갈 리스크
• 양쪽의 지식이 한 명의 엔지니어에게 의존하고 있는 상태

내 안에서 막연했던 불안이 언어화된 순간이었다.

코드를 작성해 달라고 한 것이 아닌데도, 업무가 앞으로 나아갔다.

이 체험을 통해 사용법이 근본적으로 바뀌었다.

이전에는 기술 조사에 반나절이 걸리는 일이 있었다.

공식 문서(Official Documentation), Stack Overflow, Zenn, 직접 작성한 코드의 검증……

전부 스스로 하고 있었다.

지금은 Claude에게 「기점」을 만들어 달라고 한다.

OpenSSL 1.x → 3.x로 변경 시 앱에 영향이 나타나기 쉬운 포인트를 알려주세요.
특히 Java + Spring Boot에서의 주의점을 중심으로.

출력물은 「정답」이 아니라 「조사의 지도」다.

여기에 나열된 항목을 공식 문서에서 확인한다는 방식으로 사용하고 있다.

중요한 것은 고유명사·버전 번호는 반드시 스스로 검색해서 확인하는 것이다.

AI가 내놓는 정보를 맹신했다가 후회한 경험이 나에게는 있다. 이것은 반드시 지키고 있다.

조사 속도는 체감상 3~4배 빨라졌다.

시니어 엔지니어의 업무 중 코드 리뷰의 비중은 크다.

이전에는 자신의 경험과 직관으로 리뷰했지만,

지금은 작성한 코드를 Claude에게 보여주며 「놓친 부분이 없는지」 확인하도록 하고 있다.

다음 코드를 리뷰해 주세요.
특히 병렬 처리(Concurrency) 버그, N+1, 에러 핸들링(Error Handling) 누락을 중심으로 봐 주세요.
[코드 붙여넣기]

스스로는 깨닫지 못했던 관점을 지적받는 일이 정기적으로 있다.

「이것은 나의 맹점이었다」라고 생각되는 지적이 1~2건은 나온다.

경험이 길수록 선입견이 강해지기 때문에, 오히려 시니어에게 더 유효하다고 느낀다.

20년 동안 일하며 고립감을 느낄 때가 있었다.

팀에 기술적으로 대화할 사람이 없거나, 바빠서 상담할 수 없는 상황이다.

언제든 상담할 수 있는 「기술적인 대화 상대」가 항상 있는 상태가 되면서,

작은 의문점을 그대로 방치하지 않게 되었다.

「이건 최근의 설계 베스트 프랙티스(Best Practice)가 어떻게 바뀌었지?」

「이 구현, 5년 뒤에도 유지보수하기 쉬울까?」

「이 방침, 주니어에게 설명한다면 어떤 부분이 걸림돌이 될까?」

이런 질문을 언제든 던질 수 있게 되었다. 답이 「정답」인지는 별개로 하더라도,

생각을 정리하는 장소로서 기능하고 있다.

설계 문서, 장애 보고서, 인수인계 자료, 제안서……

엔지니어가 생각하는 것 이상으로 「글을 쓰는」 업무는 많다.

이전에는 백지 상태에서 시작하는 것이 부담스러웠다. 지금은 Claude에게 골격을 만들어 달라고 한다.

다음 내용으로 장애 보고서의 골격을 만들어 주세요:
- 발생 시각: 〇월 〇일 〇시
- 영향 범위: 〇〇 기능이 〇분간 응답 불능
...

골격에 사실을 덧붙이고, 자신의 언어로 고쳐 쓰기만 하면 된다.

최종적인 아웃풋(Output)의 질도 높아졌다. (골격이 있으면 구성을 고민할 필요가 없기 때문이다.)

이 부분이 중요하다.

Claude는 판단하지 않는다. 내가 판단한다.

"이 시스템을 운영 환경(Production)에 배포해도 되는가?"

"이 아키텍처(Architecture)를 선택해야 하는가?"

"이 리스크(Risk)를 수용할 것인가?"

이러한 판단은 경험과 문맥(Context), 그리고 책임감을 바탕으로 이루어진다.

AI가 내놓는 "권장 사항"은 참고 정보일 뿐, 판단의 대체재가 아니다.

오히려 20년의 경험이 축적되어 있는 만큼,

"Claude의 제안 중 어느 부분이 문맥에 맞지 않는지"를 꿰뚫어 볼 수 있다.

시니어 엔지니어일수록 AI를 올바르게 사용할 수 있는 이유는 필터링(Filtering) 능력이 있기 때문이다.

역설적으로 말하면, AI의 출력을 그대로 믿는 것이 위험한 쪽은 주니어보다 경험자일지도 모른다.

"뭔가 이상하다"라는 위화감을 느낄 수 있느냐가 AI 활용 능력을 가른다.

1년 동안 사용해 오며 가장 적절하다고 느낀 표현은 "사고의 외부화"다.

머릿속에 있는 정보, 불안, 아이디어를 언어화하고 정리하여,

"내가 보지 못하는 것"을 비추는 거울로서 기능한다.

단순히 코드를 작성해 주는 것만이 아니다.

시니어 엔지니어가 가진 "경험을 언어화하는 능력"과 결합되었을 때,
AI는 진정한 의미로 업무의 질을 높이는 도구가 된다.

"AI에게 일자리를 빼앗긴다"라는 이야기를 아직 하고 있는 사람이 있다면,

그 사람은 아직 AI를 "코드 생성 도구"로만 사용하고 있는 것이라고 생각한다.

상담 상대이자 사고의 외부화 도구로 사용하기 시작하면, 보이는 것이 달라진다.

본 기사는 필자의 개인적인 경험을 바탕으로 작성되었습니다. 업무의 상세 내용은 일부 추상화되었습니다.