“딸깍” 코드가 생성된다. 테스트 코드도 함께 따라온다. 레거시 분석은 몇 분이면 끝난다. POC는 하루 만에 마무리되고, 위키 문서까지 자동으로 정리된다. 요즘 개발자들 사이에서 종종 듣는 말이다. IDE보다 채팅창을 더 오래 바라보는 날이 늘어나고, 최근에는 채팅창을 넘어 클로드 코드 같은 도구를 사용하며 터미널만 바라보는 시간이 많아졌다. 우리는 점점 코드를 덜 쓰는 방향으로 가고 있다. 시니어 개발자가 될수록 설계와 문서화 같은 더 높은 레벨의 일을 해야 한다는 이야기는 오래전부터 있었다.

하지만 이렇게 빠르게 “코드를 덜 쓰는 개발자의 삶”이 올 줄은 예상하지 못했다. 그래서 문득 이런 질문이 들었다. 이게 맞는 방향일까?

주니어는 앞으로 어떻게 성장해야 할까?
리드 엔지니어의 역할은 사라지는 걸까?
우리는 지금 무엇을 공부해야 할까?

그래서 40년 차 미국 빅테크 프린시펄 엔지니어부터 쿠팡, 네이버 개발자에게 같은 질문을 던져보았다.

“AI를 어떻게 받아들이고 있으며, 실제 업무에서는 어떻게 활용하고 있나요?”

“우리는 AI와 페어 프로그래밍을 하고 있다”

첫 번째 인터뷰: 40년 차 미국 빅테크 개발자
그는 세미나에서 만난 40년 차 개발자였다. 아마존을 포함한 여러 빅테크에서 시스템을 설계했고, 현재도 미국 빅테크에서 프린시펄 엔지니어로 일하고 있다.

Q. 요새 AI가 핫한데, 어떻게 느끼시나요?

내가 개발을 시작한 80년대에도 AI는 핫한 토픽이었어. Smalltalk 머신도 있었지. 다만 그때는 연산 능력과 데이터가 부족했을 뿐이야. 페어 프로그래밍(Pair Programming)에 대해 잘 알지? 내가 이렇게 연차가 쌓이고 나와 함께 페어 프로그래밍을 하겠다고 찾아오는 사람은 없는데, 지금은 AI와 페어 프로그래밍을 하는 것 같아. 다만 이제는 상대가 사람이 아니라 모델일 뿐이지.

그에게 AI는 처음 보는 토픽이 아니었다. 하지만 예전과 달리, 지금은 이론과 실험을 넘어 실용적인 도구로 실제 업무에 적극 활용된다는 점이 다르다고 했다.

AI는 정말 페어 프로그래머처럼 동작한다.

코드를 제안한다.
리팩토링을 제안한다.
테스트를 작성한다
구조를 정리해준다.
문서를 만든다.

하지만 그는 중요한 차이를 강조했다. “AI는 비판하지 않아. AI와 대화해 보면 알겠지만, 아직까지는 내가 질문한 의도대로 답변하는 경향이 있지. 그리고 이것이 사람과의 대화에서 가장 큰 차이점이라고 생각해.”

사람과 페어 프로그래밍을 하면 의견에 대한 반박이 오가고, 논리와 근거에 따라 때로는 내 의견이 받아들여지기도 하고, 상대방의 의견이 받아들여지기도 한다. 그리고 그 과정을 거쳐 코드가 완성된다. 나의 경우에도 페어 프로그래밍을 하다가 코드 컨벤션 문제로 크게 충돌했던 경험이 있었는데, 결국 그 사람과 팀이 달라지고 나서야 해결됐다. 지금 생각해 보면 아주 중요한 일은 아니었는데 말이다. 이렇듯 사람과의 페어 프로그래밍은 때로 강한 논쟁을 수반한다.

하지만 이와 달리 AI는 사람이 반박하면 대부분 수용적인 입장으로 바뀌고, 이를 최대한 답변에 녹여내려 한다. 최근에는 이런 점 때문에 코드 리뷰 에이전트에 ‘무조건 반대하는 입장에서 코드를 리뷰’하는 역할을 부여하기도 한다는 글이 종종 보인다.

Q. 우린 어떤 것을 준비해야할까요?

다들 느끼겠지만, AI의 결과의 퀄리티는 질문과 설계의 퀄리티에 달려있어. 그리고 이 말은 내가 개발을 시작했던 40년 전에도 똑같이 들었던 이야기야. 물론 AI의 결과가 아닌 사람의 결과라는 차이점이 있지만 말이지. 따라서 내가 어떤 문제를 풀고자 하는지를 정확히 아는지 중요해, 이전에 주니어 레벨은 주어진 것만 완벽히 그리고 빠른 시간내에 구현하는 것이 최고였지. 그런데 이제는 AI가 더 빠르고 더 완벽해, 물론 질문이 완벽하다는 전제가 필요하지만. 아무튼 이젠 질문하는 법을 배워야해 다른 것은 그 다음에 챙겨도 돼.

생각해 보면 이런 류의 작업은 전통적으로 주니어를 넘어 시니어의 일이었다. 어떤 문제인지 정의하고, 어떤 방법으로 해결할지를 설계하고, 또 일을 분배하는 작업을 말한다.

이 문제의 이해관계자는 누구인가?
언제까지 이 문제를 해결해야 하는가?
어떤 제약 사항이 있는가?
성공적인 문제 해결의 기준과 측정 방법은 무엇인가?

그는 또 하나의 우려를 덧붙였다. “나는 주니어가 초기에 겪어야 할 고통이 없다는 게 두렵다고 봐.그러니 그 경험을 준비하라고 말해주고 싶지.”

버그를 추적하며 스택을 따라 내려가는 경험, 잘못된 설계로 장애를 내보고 복구하는 경험, 이런 감각은 자동으로 생기지 않는다고 그는 말했다. 그리고 이런 경험을 바탕으로 시스템을 설계하면서, 시스템의 가용성, 회복성 등 여러 가지를 고려하는 능력이 자연스럽게 길러진다고 덧붙였다.

“그렇다고 AI를 쓰지 말라는게 아니야. AI와 함께 버그를 추적하며 설계를 해보면 돼.”

Q. 최근 업무에서 AI를 활용한 경험에 대해 알려주세요.

크게 두 가지가 있어. 원래 나는 간단한 사이트를 만들 시간이 없어. 그래서 대부분 주니어 개발자에게 위임하곤 했지. 그런데 이번에는 AI와 함께 주말 동안 만들어봤어. 피그마 디자인과 함께 말이지. 그다음으로는 특정 DB 버그의 stack trace 전문을 읽게 했더니, 한 번에 오류를 찾아냈어. 그 방법론과 접근법은 내가 생각한 것과 매우 유사했고, 결과도 내가 예상했던 이슈와 정확히 일치했지.

그가 사용했던 방법은 우리가 사용하던 것과 크게 다르지 않았다. 다만 이전에는 시간이 없어 하지 못했던 일, 그리고 본인이 생각했던 검증을 누구보다 빠르게 실행해 주는 도구로 AI를 활용하고 있었다.

그리고 덧붙여 말했다. “AI는 도구야. 장인은 도구를 탓하지 않는다던데, 실력도 좋은데 도구까지 좋으면 더 빨리, 더 멀리 갈 수 있지 않겠나?”

이 말을 듣고, AI에 매몰되지 말자고 스스로 다짐했던 생각이 다시 떠올랐다. 40년 차인 그에게 AI는 본인의 일을 빼앗는 경쟁자가 아니라, 만능 도구에 불과했다는 점이 아이러니하게 느껴졌다.

스킬을 만드는 스킬을 만들어요

두 번째 인터뷰: 쿠팡 9년 차 프론트엔드 개발자
여러 스타트업을 거쳐 쿠팡에 들어간 9년 차 개발자인 그는 개발을 시작할 때부터 프론트엔드만 집요하게 파고들었다. 그런 그를 이전 회사 동료로서 인터뷰해 보았다.

Q. 요새 AI가 핫한데, 어떻게 느끼시나요?

핫하기도 하고, 회사에서도 AI를 업무에 많이 녹이려고 노력하고 있어요. 그리고 매니저와 1대1 미팅을 할 때도 요새 AI를 업무에 어떻게 사용하고 있느냐는 질문을 꼭 받아요. 제가 여기 들어온 지 이제 반년인데, 입사할 때부터 계속 같은 질문을 하시더라고요. 재작년까지만 해도 AI는 딱 제 연차에 엄청난 기회를 준다고 했어요. 절대적인 코딩 시간이 부족한 시니어 개발자에게 주니어 개발자를 여럿 붙여준다는 의미였지요. 그런데 지금 생각하면 아니에요. 모든 개발자에게 엄청난 기회를 주고 있다고 느껴요. 물론 AI가 여기서 더 발전하면, 그때는 어떻게 될지 모르겠네요.

쿠팡에서는 대부분의 팀이 AI 도구를 활용하고 있다고 한다. 그리고 전사적으로 할당된 AI 툴을 선점하기 위해 오픈런이 가끔씩 벌어지기도 한다고 한다.

“agent.md 문서를 계속 업데이트해요. AI가 일관된 방향으로 작업하도록 규칙을 정리하고, 또 계속 추가하죠. 그리고 AI가 리뷰를 해주는데, 코멘트나 컨벤션에 어긋나는 부분이 있으면 바로 규칙에 반영해요. 제가 작성하는 PR 중 10%는 오로지 AI를 위한 수정 사항이에요.”

그러면서 간단한 예시를 몇 개 말해줬다.

“테스트 코드는 XXXX 이런 식으로 작성해야 해요. jest 규칙에 언급되어 있죠. 하지만 AI가 그것을 누락했으니 규칙을 추가해야 하죠. CSS의 design token은 YYYY에 있는 파일에서 가져다 써야 해요. 그런데 기존 코드베이스에서는 이게 섞여 있어서 잘못된 방식으로 읽어오고 있으니, 여기도 규칙을 추가해야 해요.”

옆에서 보는 그의 모습은 마치 AI에게 코드 리뷰를 하고 있는 듯했다. 그리고 그는 이렇게 말했다.

“실은 지금 말했던 예시들은 제가 초반에 입사하고 나서 받았던 코드 리뷰 내용이에요. 처음에는 하나의 PR에 대충 30개의 리뷰가 달렸었어요. 그중에는 간단하지만 반복되는 리뷰들도 있었죠. 그래서 중간에는 자체적으로 ‘pr-check’라는 스킬을 만들어, 코드 리뷰에서 반복적으로 나오는 코멘트를 먼저 수정하는 과정을 거쳤었죠. 그리고 최근에는 AI 리뷰가 자동으로 도입되면서, 이런 스킬들을 바탕으로 agent rule을 만들어 계속 추가하고 있네요.”

Q. 최근 업무에서 AI를 활용한 경험에 대해 알려주세요.

쿠팡은 아니고, 이전 회사에서 CMS(Content Management System)를 자체적으로 구현해야 했어요. 콘텐츠가 정적인 텍스트로만 이뤄지면 참 좋겠지만, 실제로는 다양한 미디어 파일과 인터랙션을 포함한 데모형 콘텐츠가 많았죠. 그래서 ‘puck editor’라는 오픈소스를 가져와 구현했어요. 이 라이브러리는 제가 사전에 구현해 둔 컴포넌트를 바탕으로, 사용자가 drag & drop으로 컴포넌트를 가져와 콘텐츠를 수정할 수 있어요.

그리고 저는 여기에서 사용되는 컴포넌트들을 AI를 이용해 대부분 만들었어요. 예전 같으면 해당 컴포넌트를 만드는 데 컴포넌트 하나당 며칠씩은 걸렸을 거예요. 그런데 AI를 이용해 회사에서 쓰는 디자인 시스템을 바탕으로 puck editor에 필요한 컴포넌트로 포팅하는 작업을 전체 3일 만에 끝냈어요. 기본적인 레이아웃용 컴포넌트와 데모용 컴포넌트까지 포함하면 대략 30개 정도를 지원했던 것 같은데, 이전에는 상상도 못 할 속도예요. 그리고 저는 이 시스템을 만들어보면서 AI가 수평 확장에 정말 강력하다는 걸 깨달았어요.

같은 구조를 여러 곳에 적용해야 할 때, AI는 압도적으로 빠르다. 그러면서 그는 말을 덧붙였다.

“그렇다면 개발자가 할 일은 수평 확장이 가능하도록, 수직 확장의 토대를 마련하는 것이죠.”

AI는 지시된 방향 안에서 훌륭하다. 하지만 방향을 설정하고, 수직 확장이 가능하도록 토대를 만드는 일은 여전히 인간, 곧 개발자의 몫이다.

Q. 요새 어떤 것을 공부하고 계시나요?

방금 말한 것처럼, 수직 확장을 위해 조금 더 깊은 내용을 공부하고 있어요. 최근에 읽은 책으로는 <멀티패러다임 프로그래밍(유인동 저)>을 포함해, 테스트 코드를 위한 책들을 중점적으로 보고 있습니다.

요새 AI가 테스트 코드를 잘 만들어주잖아요. 그런데 그게 테스트 개수만 늘리는 건지, 테스트 커버리지만 채우는 건지 제가 잘 모르겠더라고요. 그래서 이번 기회에 테스트 코드에 대해 깊이 있게 학습해보려고, 우선 5권을 구매해서 보고 있어요. 지금은 4권째 읽고 있습니다. 여기에서 읽은 지식과 학습한 내용을 바탕으로, 테스트 코드를 위한 agent.md 파일을 작성하는 것을 목표로 삼고 있어요.

현재 제가 주로 일하는 서비스는 AI가 본격적으로 도입되면서 테스트 코드가 3배가량 증가했어요. 제 목표는 이것들을 더 이상 늘리지 않고, 유의미한 개수로 유지하는 거예요. 테스트가 많아질수록 CI/CD 시간이 오래 걸리고, 불필요한 테스트는 오히려 리팩토링 프로세스에도 좋지 않은 영향을 주니까요.

Q. 왜 이렇게 테스트 코드에 진심이세요?

요즘 일부에서는 ‘코드를 안 보고 배포한다’는 말도 나오는데, 저는 AI를 신뢰하는 것과 판단을 위임하는 것은 다르다고 생각해요. 만약 제가 혼자 일하고 모든 책임도 혼자 진다면, 코드를 안 보고 배포할 수도 있겠죠. 하지만 실제 제품은 혼자 힘으로 동작하지 않아요. 따라서 안 보고 배포한다는 말은, 나는 책임질 수 없으니 너희가 책임지라는 의미처럼 들려요.

그렇지만 또 AI가 생성하는 코드를 안 쓸 수는 없죠. 저는 AI가 생성한 코드의 책임을 테스트 코드에서 찾아보고 있어요. 요새는 ‘테스트를 통과하면 제대로 된 기능이다’라는 말도 유행하고 있어요. 이게 맞는 명제인지는 모르겠지만, 현실적인 타협안이라고 생각하고 있습니다.

9년 차 개발자는 책임을 질 수 있는 수준으로 AI를 활용하고 있었고, 그 책임을 위해 여러 가지 자신만의 규칙과 환경을 만들어가며 깊이 공부하고 있었다. 그렇다면 규칙은 어떻게 세우고 있는지 물어봤다.

“요새 많이 하는 것 중 하나는 ‘이때까지 대화 중에 스킬이나 룰로 만들 수 있는 것이 있으면 만들어줘’라는 명령어예요. 그리고 이를 바탕으로, 위에서 말한 스킬을 만드는 스킬(/create-skills)을 커스텀해서 만들고 있어요.”

스킬을 만들기 위한 스킬이라니, 처음 재귀 함수를 봤을 때처럼 오묘하고 신기했다.

나는 직접 코드를 안 쓴 지 두 달째다

세 번째 인터뷰: 네이버 12년 차 백엔드 개발자
그는 프론트엔드로 시작해 백엔드를 거쳐, 현재는 풀스택으로 일하고 있다. 그리고 이제 막 매니저 역할을 시작한 초보 매니저이기도 하다.

Q. 요새 AI가 핫한데, 어떻게 느끼시나요?

갑자기 생각난 건데, 올해(인터뷰 날짜 기준 3월 초)에는 IDE를 안 켜본 것 같아요. 갑자기 소름이 끼치네요. AI가 핫한 만큼 저도, 그리고 조직도 AI에 발 빠르게 적응하려고 준비하고 있어요.

IDE를 안 켠다고 해서 개발을 안 하고 있는 것은 아닙니다. 오히려 PR 양은 이전보다 더 늘어났어요. 저는 주로 클로드 코드를 사용하고 있는데요. 문서와 지라 티켓에 상세하게 작성된 PRD(Product Requirements Document, 제품 요구사항 정의서의 약자로 서비스나 기능의 목표, 타깃 고객, 핵심 기능, 성공 지표 등을 명확히 정의해 개발팀, 디자인팀 등 이해관계자와 공유하는 문서)를 클로드 코드가 알아서 가져와 백엔드 코드를 작성해줘요.

물론 제가 하는 일이 단순히 API를 만드는 것뿐만 아니라 다양하게 있지만, 그래도 그중에서 가장 많은 시간을 잡아먹는 것은 단연 API를 만드는 부분이죠.

그는 최근 IDE를 사용하는 시간이 눈에 띄게 줄었다고 말했다. 그렇다면 개발 시간은 과연 줄어들었을까?

“단순히 AI가 있어서 개발 시간이 10분의 1로 줄었나? 생산성이 10배, 100배가 되었나? 이런 느낌은 아니네요. 제가 하는 업무가 단순히 코딩이 전부가 아니고, 또 AI가 이렇게 발전하기 전에도 코딩 그 자체가 시간을 가장 많이 잡아먹는 일은 아니었거든요. 요즘도 그렇고 이전에도 코딩보다는 컨텍스트를 정리하고 문서화하는 시간이 더 길어요. 여러 가지 문서를 읽고 R&R(Role & Responsibilities의 약자로, 조직이나 프로젝트 내에서 각 구성원이 맡은 ‘역할과 책임’을 의미)를 정리하는 일이죠. 대신 한 가지 고무적인 점은, 제가 하는 컨텍스트 정리와 문서화 작업이 실제로 개발 속도를 끌어올린다는 점입니다.

제가 이 작업을 하는 이유는 개발자들(프론트엔드, 백엔드)에게 스펙을 정의하고 전달하기 위해서였어요. 때로는 기획자의 역할도 해야 하니, 이런 부분을 구체화하고 통일한 문서를 바탕으로 기능을 만들기 위해 시간을 들여 정성껏 작성하고 공유하는 것이었죠. 물론 이 작업이 개발자들의 일을 줄여주기도 합니다. 제대로 된 문서는 잘못된 개발 방향을 초반부터 걷어내고, 불필요한 의사소통 비용을 줄여주니까요. 하지만 이게 직접적으로 코딩 그 자체의 속도에 영향을 주지는 않았어요.

그런데 AI가 본격적으로 업무 프로세스에 녹아들면서 달라졌어요. 제가 만든 문서는 AI가 일을 한 번에, 그리고 제대로 하게 만드는 잘 정리된 Plan 문서로 동작합니다. 실제로 저는 업무를 정리하면서 해야 할 To-do list를 만드는데, 이것조차 AI를 잘 동작하게 하는 하나의 방법론으로 작동합니다.”

Q. 최근 업무에서 AI를 활용한 경험에 대해 알려주세요.

아마 많은 분들이 직접적인 개발 과정에서 AI를 활용한 경험을 말씀하실 텐데요. 저는 오히려 비개발적인 부분에서 AI를 활용하는 일이 생산성을 더 높여준다고 생각합니다. 예를 들어, 매니저인 저에게 지라 티켓이나 일정을 관리하는 일은 항상 어렵고 큰일이지만, 사실 하기 싫은 일이기도 하죠. 왜냐하면 그 많은 지라 티켓을 일일이 확인하면서 기능 개발이 어디까지 왔는지, 또 일정은 잘 진행되고 있는지 체크하는 건 너무 번거로운 일이기 때문이에요.

지라 대시보드나 여러 기능도 있지만, 많은 개발자분들이 경험적으로 느끼시겠지만 생각보다 지라 티켓이나 일정 관리를 꼼꼼히 하지 않아요. 주로 개발을 시작할 때 한 번, 그리고 개발이 전부 마무리돼 ‘완료’ 처리할 때 한 번, 이렇게 두 번 정도만 상태를 변경합니다. 이게 개발자 입장에서는 꽤 번거로운 일이거든요. 그래서 저는 이 프로세스의 상당 부분을 클로드 코드를 이용해 자동화하고 있습니다.

클로드 코드를 연결해 지라 티켓을 가져온 뒤, 어떤 작업을 시작할 거라고 하면 클로드 코드가 다음 작업을 진행해줍니다.

지라 티켓 status 변경
지라 티켓 번호를 포함한 브랜치 설정
해당 브랜치를 기반으로 GitHub draft 작성

이렇게 되니 ‘지라 대시보드와 GitHub pull request에서 누가 어떤 작업을 진행 중이구나’를 한눈에 볼 수 있더라고요. 그리고 하루에 한 번씩 일정 관리 크론잡도 돌고 있는데요. 지라 티켓과 GitHub 정보, 그리고 일정 정보를 바탕으로 일이 어느 정도 진행되고 있는지 알려주는 스크립트입니다. 저는 이것을 통해 매니저 역할을 해 나가고 있어요.

그러면서 그는 클로드 코드에서 해당 화면을 보여주었다. 그의 클로드 코드는 터미널 기반이지만, 한껏 커스텀되어 필자가 보기에도 깔끔한 하나의 매니저 도구처럼 보였다.

“그리고 하나의 작업이 더 있어요. 제가 오늘 하루 동안 작업한 내용을 바탕으로 성과 관리 문서를 생성합니다. 그리고 주간, 월간, 분기 단위로 제 성과 관리를 해가고 있어요. 아직 이 자동화를 시작한 지 반년이 안 돼서 연간 단위는 없지만, 지금 추세라면 연간 성과 관리도 잘할 수 있을 것이라 생각합니다.”

그가 자동화에 푹 빠져 클로드 코드에 대해 설명하던 그 순간은, IDE를 몇 달 동안 켜지 않았음에도 가장 개발자답게 보이는 순간이었다.

Q. 요새 어떤 것을 공부하고 계시나요?

“제가 학부생 때는 동기들끼리 마우스 없이 코딩하는 날 같은 것도 만들어서 했었어요. 그때는 vim으로 빠르게 코딩하는 게, 뭔가 동기들 사이에서 실력의 척도였어요. 초등학교 때 타자 수가 빠르면 컴퓨터를 잘하는 사람 취급받는 것처럼요. 생각해 보니 그때도 속도가 전부였네요. 아무튼 그때 저는 코딩을 잘하기 위해 도구 사용법을 따로 시간을 들여 공부했어요. 그리고 AI도 마찬가지라고 생각해요. 시간을 들여 익혀야 해요. 우리가 vim 수련을 한 것처럼요.

요새는 또 하네스 엔지니어링(인공지능 모델, 특히 LLM(거대 언어 모델)을 감싸서 그 능력을 실전에 안전하게 활용할 수 있도록 통제하고, 도구와 연결해 실제 행동을 수행하게 하는 외부 소프트웨어 프레임워크 또는 구조)이나 AI 오케스트레이션(거대 언어 모델(LLM), 이미지 모델, 데이터베이스 등 서로 다른 AI와 시스템을 하나의 워크플로 안에서 지휘자처럼 통합·관리해, 단일 모델로 해결하기 어려운 복잡한 문제를 풀고 효율을 높이는 기술) 같은 것들을 어떻게 활용할 수 있을지 고민해보고 있어요.

그리고 이런 것들은 때로 너무 빨리 변해서, 제가 공부하기도 전에 새로운 방법론과 패러다임의 변화가 일어나기도 합니다. 그래서 불안하기도 하죠. 그래도 어쩌겠습니까? 다들 AI라는 비행기를 타고 날아가고 있는데, 저만 뛰어갈 수는 없잖아요.

신이 나서 클로드 코드를 만지고 있는 그의 모습에서, 어쩌면 AI라는 비행기의 속도보다 하늘을 난다는 그 기술 자체에 매료된 한 사람을 본 것 같았다.

세 명의 개발자와의 인터뷰를 마치며

세 사람의 이야기를 듣고 나니 한 가지는 분명했다. AI가 등장했다고 해서 개발이라는 일이 완전히 다른 일이 된 것은 아니라는 점이다. 다만 우리가 시간을 쓰는 방식이 조금 바뀌고 있을 뿐이다. 코드를 직접 작성하는 시간은 줄어들고, 문제를 정리하고 맥락을 설명하고 방향을 잡는 시간은 늘어나고 있다.

40년 차 엔지니어는 좋은 결과는 여전히 좋은 질문에서 시작한다고 말했다. 쿠팡 개발자는 AI가 잘 일하도록 규칙을 계속 추가하고 있었고, 네이버 개발자는 문서와 맥락을 정리하는 일이 개발 속도를 높인다고 했다. 세 사람의 이야기를 듣다 보니 결국 같은 결론으로 이어졌다. AI는 일을 더 빠르게 만들어주는 도구지만, 무엇을 만들지 결정하고 책임지는 일은 여전히 사람의 몫이라는 것이다.

그래서 요즘의 개발자는 코드를 얼마나 많이 쓰느냐보다 어떤 문제를 풀려고 하는지, 어떤 맥락에서 이 일을 하는지, AI에게 무엇을 맡기고 무엇은 직접 판단할지를 조금 더 깊이 고민하게 되는 것 같다. 아직 정답은 없다. 지금은 모두가 조금씩 자기 방식으로 실험해보고 있는 시기인 듯하다. 그래서 인터뷰를 마치고 나서 남은 질문은 이것 하나였다. “나는 오늘 AI에게 무엇을 시켰는가”가 아니라, “나는 오늘 어떤 문제를 풀려고 했는가?”라는 것. 여러분은 어떻게 생각하시나요?