INTERVIEW · SOFTWARE ENGINEERING · AI
코드를 짜는 사람에서, 팀이 일할 수 있게 만드는 사람으로
2010년부터 실리콘밸리에서 개발자로 일해온 미쿡엔지니어님에게 AI 이후 달라진 개발자의 역할, 실리콘밸리 팀의 문서화와 공유 문화, 주니어가 쌓아야 할 전문성에 관해 물었습니다.
요즘 주니어 개발자에게 “AI를 잘 써야 한다”는 말은 별 도움이 되지 않을지도 모릅니다. 이미 쓰고 있으니까요. 챗GPT에 오류를 묻고, 코딩 에이전트에게 구현을 맡기고, 결과를 다시 고쳐달라고 요청합니다. 그런데 도구가 일을 더 많이 해줄수록 다른 질문이 남습니다.
‘그럼 나는 무엇을 잘해야 하지?’
실리콘밸리 빅테크에서 시니어·스태프 엔지니어 역할을 해온 미쿡엔지니어님은 개발자의 일이 사라진다기보다 자리가 이동하고 있다고 말합니다. 구현의 한가운데에서 고객과 문제를 정의하는 앞단으로, 코드를 직접 입력하는 자리에서 AI와 팀이 일할 수 있는 맥락을 만드는 자리로요.
그 변화는 거창한 미래 전망보다 미쿡엔지니어님의 팀이 일하는 장면에서 더 또렷하게 보였습니다. 업무 지식을 위키로 만들고, 새로운 기술을 월요일과 금요일에 나누고, 발표가 끝난 뒤에는 서로 다른 전문성을 가진 동료의 피드백을 받아 최종 문서로 남기는 과정입니다.
인터뷰에서는 AI 대체론부터 주니어 채용, 개발자의 기본기, 팀 문화, 지식공유를 계속하는 이유까지 41분 동안 이야기를 나눴습니다.
처음에는 AI도 조금 더 빠른 참고서라고 생각했어요
Q. AI의 성능이 실제 업무를 바꿀 수 있겠다고 처음 느낀 순간을 기억하세요?

처음 챗GPT를 쓸 때는 질문을 한 번 던지고 답을 한 번 받는 식이었어요. 그때는 참고서를 조금 더 빨리 찾아보는 느낌에 가까웠죠.
그런데 어느 순간부터 달라졌어요. 제가 준 컨텍스트 전체를 AI가 이해하고, 한 번 답한 내용을 바탕으로 스스로 계속 고치는 모습을 보게 된 거예요. 그때 ‘이건 이전과 다르구나’ 싶었어요. 저희 팀도 그전까지는 참고 자료를 빠르게 받는 도구 정도로 생각했는데, 전체 맥락을 넣은 만큼 결과가 더 정확해지기 시작하면서 훨씬 진지하게 보기 시작했고요.
Q. 지금 실리콘밸리 개발팀에서는 AI를 어떻게 쓰고 있나요?
한국과 크게 다르지는 않은 것 같아요. 개발자가 직접 코딩하는 시간보다 전체 업무를 감독하고, 태스크를 지시하고, 계획을 세우는 비중이 커지고 있어요. AI를 최대한 많이 사용하되 사람이 전체 흐름을 보는 식이죠.
개발자는 결국 고객의 요구를 받아 구현하는 사람이잖아요. 그래서 이제는 코드를 작성하는 사람이라기보다, 고객이 무엇을 필요로 하는지 이해하고 그걸 구현 가능한 문제로 바꾸는 쪽으로 역할이 이동하고 있다고 봐요.
새 모델이 나왔다고 대기업이 바로 모든 방향을 틀지는 않아요. 조직이 크면 한 번 방향을 바꿀 때 흔들리는 범위도 크거든요. 여러 선택지를 비교하고, 실패했을 때 돌아갈 방법을 남겨두고, 검증된 범위부터 천천히 움직이는 편이에요.
AI는 역할 전체보다 태스크를 먼저 가져갔어요
Q. 그렇다면 AI가 개발자를 대체할 거라는 불안은 어떻게 보세요?

처음부터 역할 전체를 대체한다고 생각하지는 않았어요. 먼저 대체되는 건 역할 안에 들어 있던 개별 태스크라고 봤거든요.
사람을 줄인다고 해서 AI가 그 사람이 갖고 있던 컨텍스트까지 바로 가져가지는 못해요. 예상하지 못한 문제가 생겼을 때 AI가 제대로 대응했는지 확인할 기준도 필요하고요. 에이전트가 처리하지 못하는 상황을 어디에서 사람이 맡을지, 전체 역할을 어떻게 나눌지를 정하는 것도 결국 사람의 일이었어요.
물론 그 경계도 계속 바뀌고 있습니다. 지금은 사람이 맡고 있는 예외 처리와 감독 중에서 무엇을 더 자동화할 수 있을지 다시 개발하고 있으니까요. 그래서 ‘사람은 안전하다’거나 ‘곧 전부 대체된다’고 단정하기보다, 어떤 태스크가 AI로 넘어가고 그다음 사람에게 어떤 판단이 남는지를 보는 편이 더 정확하다고 생각해요.
2010년의 빅데이터도 결국 개발자가 쓰는 도구가 됐어요
Q. 발전 속도가 너무 빨라서 개인적으로 두렵지는 않았나요?
그런 감정은 늘 있었던 것 같아요. 제가 2010년에 커리어를 시작했는데, 당시에는 빅데이터가 정말 큰 화두였어요. 그 기술을 따라잡지 못하면 도태될 것 같다는 생각도 했죠.
그런데 시간이 지나 돌아보니 빅데이터도 결국 개발자가 사용하는 도구더라고요. AI도 언젠가 돌아보면 개발자가 쓰는 도구 중 하나가 되어 있을 거라고 생각해요.
그래서 새로운 도구가 나올 때마다 모든 것을 처음부터 다시 시작한다고 느끼기보다, 도구가 바뀌어도 남는 기반을 쌓아두는 게 중요합니다. 기본기가 있으면 새로운 기술이 들어와도 훨씬 빠르게 따라갈 수 있으니까요.
Q. 그런데 ‘기본기’라는 말은 조금 추상적이잖아요. 지금 시대의 기본기는 무엇인가요?
가장 먼저 고객이 있어야 해요. 고객이 원하는 것을 풀어가는 게 개발자의 일이니까요. 문제를 정확히 정의하고, 어떤 구조로 풀지 정하는 것이 가장 중요한 기본기라고 생각합니다.
그 문제와 맥락을 잘 정리해두면 AI가 받아서 일할 수 있어요. 사람은 AI가 만든 결과를 전체 환경에 놓고 봐야 하고요. 문제가 생기면 어디에서 시작됐는지, 시스템에 어떤 영향을 주는지 판단할 수 있어야 합니다.
예전에는 언어의 문법과 툴 사용법을 아는 비중이 컸다면, 지금은 AI가 그런 부분을 더 잘 처리해요. 대신 사람은 AI에 무엇을 물어야 하는지, 일을 어떻게 나눠 맡길지, 결과를 어떻게 검증할지를 배워야 합니다.
CS 지식도 여전히 유효해요. 메모리가 어떻게 쓰이는지, 네트워크 패킷이 무엇인지 정도는 알아야 문제가 생겼을 때 고칠 수 있어요. AI가 만든 문제를 다시 AI에게만 맡기다 보면 상황이 더 나빠질 수도 있거든요. 최소한 내가 직접 할 수 있는 일을 AI에게 위임했다는 판단이 가능할 만큼은 펀더멘탈을 알고 있어야 합니다.
팀에서는 코드를 고치는 일보다 문제를 잘 만드는 데 시간을 써요
Q. 실제 팀에서는 AI와 사람이 일을 어떻게 나누나요?
저희는 업무에 필요한 지식을 위키로 만들어뒀어요. 질문이 들어오면 AI가 먼저 위키를 보고 레퍼런스를 찾은 뒤 처리할 수 있게 해둔 거죠.
문제를 받았을 때 어느 코드를 확인하고 고쳐야 하는지도 AI가 찾아갈 수 있도록 구조를 만들어놨어요. 그러다 보니 사람은 문제 자체가 제대로 작성됐는지, AI가 이해할 수 있게 구조화됐는지를 확인하는 데 더 많은 시간을 씁니다.
문서화의 목표는 문서를 많이 쓰는 데 있지 않아요. 내가 없더라도 동료나 AI가 그 문서를 보고 일을 이어갈 수 있게 만드는 거예요. 사람이 감독자로 남아 문제를 판단하되, 반복해서 처리할 수 있는 일은 충분한 컨텍스트와 함께 AI에 맡기는 구조에 가깝습니다.
Q. 그러면 문서는 사람을 위한 기록이면서 AI를 위한 컨텍스트이기도 하네요.
맞아요. 모든 회사가 사람이 반복하던 일을 자동화해왔잖아요. 그렇다고 사람을 없애는 것이 목표라기보다, 사람은 전체를 보고 문제가 생겼을 때 개입하고 반복 작업은 시스템이 처리하도록 만드는 거예요.
그 과정에서 컨텍스트가 없으면 자동화가 작동하지 않아요. 그래서 AI를 많이 사용할수록 문서화가 오히려 더 중요해진다고 생각합니다.
같이 일하고 싶은 사람은 티켓 너머의 고객을 보는 사람이에요.
Q. 시니어 엔지니어로서 어떤 개발자와 같이 일하고 싶나요?

저는 앞으로 프로덕트 엔지니어링이 더 중요해질 거라고 생각해요.
개발자는 티켓에 적힌 요구사항을 보고 혼자 코딩하는 일이 많았어요. 그런데 이미 잘 정리된 태스크를 AI가 처리하기 시작하면, 사람은 그 이전 단계로 가야 합니다.
내 프로그램이나 기능을 실제로 사용하는 고객을 만나야 해요. 여기서 고객은 최종 사용자일 수도 있고, 내가 만든 시스템을 사용하는 사내 동료일 수도 있어요. 미팅을 열고 무엇을 원하는지 확인하고, 필요한 것을 자기 언어로 다시 정리해야 합니다.
그다음 문제를 정의하고 문서화해서 팀과 함께 검토하고 풀어가는 거죠. 단순히 티켓을 완료하는 사람이 아니라, 어떤 문제를 풀어야 하는지부터 찾아가는 사람이 필요해요.
또 자기가 배운 것을 공유하는 사람과 일하고 싶어요. 공유했을 때 피드백을 방어적으로 받아들이기보다, 그 내용을 바탕으로 결과를 다시 개선할 수 있는 사람이요. 코드를 혼자 잘 짜는 것과 팀의 결과를 더 좋게 만드는 것은 조금 다른 능력이거든요.
월요일과 금요일, 한 사람이 배운 것을 팀의 문서로 만들어요
Q. 공유가 중요하다고 하셨는데, 팀에서는 실제로 어떻게 하고 있나요?
저희는 일주일에 두 번 정도 공유하는 시간이 있어요. 월요일과 금요일에 새로운 아이디어나 기술이 나오면 한 사람이 공부해서 발표합니다. 발표가 끝나면 팀원들이 피드백을 주고받고요.
각자 배경과 전문 분야가 다르기 때문에 같은 기술을 보고도 보는 지점이 달라요. 누군가는 활용 가능성을 보고, 누군가는 시스템에서 생길 위험을 발견합니다. 여러 관점에서 긍정적인 효과가 있는지 확인한 다음에야 실제 업무에 적용해요.
최종적으로는 피드백을 반영한 문서를 다시 팀에 공유합니다. 한 사람이 먼저 알게 된 기술이 개인의 노하우로 끝나지 않고 팀 전체가 사용할 수 있는 기준으로 바뀌는 거죠.
이런 문화는 개인의 태도만으로 생기지는 않아요. 회사가 안정적으로 지식을 공유할 수 있는 환경을 만들어줘야 합니다. 서로 아는 것을 숨겨야 유리한 분위기라면 누구도 먼저 꺼내놓기 어렵잖아요.
Q. 조직은 구체적으로 무엇을 제공해야 할까요?
저는 무엇보다 시간이 중요하다고 생각해요.
새로운 기술을 익히고 실제 업무에 적용하는 데는 전환 시간이 필요합니다. 낮에는 원래 일을 다 하고, 야근하면서 새 기술을 공부하라고 하면 안 돼요. 학습과 실험도 업무의 일부로 인정하고 시간을 배정해야 합니다.
안전하게 실험할 수 있는 가드레일도 필요해요. 어떤 비밀 문서에는 접근하면 안 되는지, 어떤 정보를 외부에 보내면 안 되는지, 네트워크와 모델의 접근 권한은 어디까지인지 조직이 먼저 정해야 하죠.
경계가 명확하면 개발자는 매번 보안 문제를 추측하지 않고 허용된 범위에서 새로운 기술을 더 빠르게 적용할 수 있어요. 자유롭게 실험하는 문화와 안전장치는 반대가 아니라 같이 가야 하는 조건입니다.
주니어 시장이 어려워진 이유도 태스크가 먼저 사라졌기 때문이에요
Q. 지금 개발자로 커리어를 시작하는 주니어에게는 현실적으로 어떤 시기인가요?
한국도 미국도 개발자 시장이 좋다고 말하기는 어려운 것 같아요. 특히 주니어 시장은 확실히 더 어렵고요.
예전에는 시니어가 반복되는 일을 주니어에게 맡겼고, 주니어는 그 일을 해보면서 역량을 쌓았습니다. 그런데 그런 태스크가 먼저 AI에 배정되고 있어요. 주니어가 조직 안에서 처음 경험을 얻던 입구가 좁아진 셈이죠.
그렇다고 준비를 멈춰야 한다는 뜻은 아니에요. 오히려 단순 구현만 보여주는 것보다 AI를 활용해 문제를 풀고, 결과를 검증하고, 실제 세계의 맥락을 설명할 수 있는 개발자가 필요해질 거라고 봐요.
중요한 건 막연한 낙관보다 지금 경험을 쌓는 겁니다. 시장이 어렵더라도 개발자로 일할 기회를 만들고, 작은 문제라도 끝까지 다뤄본 경험을 남겨야 해요. 기회가 왔을 때 이미 준비된 맥락과 결과물이 있어야 하니까요.
모든 신기술을 쫓기보다 하나의 버티컬을 먼저 만드세요
Q. 새로운 기술이 너무 많이 나오다 보니 주니어는 포모를 느끼기 쉬워요. 무엇부터 봐야 할까요?
제가 경력이 15년 이상 되다 보니 알게 된 건, 아무리 새로운 기술이 와도 하루아침에 모든 게 바뀌지는 않는다는 거예요.
대기업도 새 기술이 나왔다고 바로 적용하지 않아요. 이미 운영 중인 인프라가 있고, 바꾸는 데 큰 비용이 들기 때문이죠. 어느 정도 지켜보다가 충분히 성숙한 기술을 선택합니다.
주니어도 비슷하게 생각하면 좋겠어요. 새로운 기술이 있다는 사실을 알고 흥미를 갖고 보는 건 필요해요. 하지만 그 기술이 내 생활과 직업을 내일 당장 전부 바꿀 거라고 생각할 필요는 없습니다.
한 분야는 확실히 알아야 해요. 직업과 연결되는 전문성, 그러니까 T자의 버티컬이 먼저 있어야 합니다. 그 전문성을 중심에 두고 AI의 도움으로 옆 영역을 넓혀가세요.
그리고 단순히 결과물을 한 번 만드는 데서 끝나면 안 됩니다. 실제로 구현했을 때 어떤 인시던트가 생길지, 문제가 생기면 어디부터 확인하고 해결할지까지 전체 플로우를 볼 수 있어야 해요. AI 시대에 더 중요해지는 전문성은 한 기능만 만드는 능력보다, 그 기능이 운영되는 전체 흐름을 책임질 수 있는 능력에 가깝습니다.
가르치려고 공부하면 머릿속에 구조가 생겨요
Q. 본업도 바쁜데 2022년부터 인프런에서 계속 강의를 만든 이유가 있나요?
처음에는 기저귀 값을 벌려고 시작했어요. (웃음)
그런데 강의를 만들려면 누군가를 가르치기 위해 제가 먼저 공부해야 하더라고요. 공부하다 보니 몰랐던 부분을 알게 되고, 다른 사람에게 설명하려면 머릿속에서 내용을 다시 구조화해야 했어요. 그 구조화가 끝나면 비로소 제 것이 되는 느낌이었고요.
강의에서 정리한 내용은 팀에도 나누게 됐어요. 2주에 한 번씩 새로운 기술을 팀원에게 공유할 수 있었고, 기초적인 주제를 계속 다루다 보니 다음에 어떤 트렌드를 공부해야 하는지도 더 잘 보이기 시작했어요.
어떤 기술이 유행하는지만 보는 게 아니라, 그중 무엇이 우리 팀과 다른 개발자에게 실제로 도움이 될지를 생각하게 된 거죠. 강의를 만드는 일이 제 실력을 높이고, 다시 팀의 학습으로 돌아오는 시스템이 됐습니다.
Q. 강의를 만들면서 가장 보람 있었던 순간은 언제였나요?
강의를 듣고 취업에 도움이 됐다는 이야기를 받을 때가 가장 좋아요. 해외에서 대학을 다니던 분이 취업했다는 메시지를 보내주신 적도 있고요.
회사 안에서 제 강의를 바탕으로 발표를 이어가다가 시니어로 승진했다는 분도 있었어요. 그런 리뷰를 받으면 제가 정리한 지식이 누군가의 성장에 실제로 도움이 됐다는 걸 느끼게 됩니다.
그래서 인프런 강의는 이제 제 학습 시스템 안에 들어온 것 같아요. 계속 배우고, 가르치고, 그 과정에서 제 실력도 다시 높이는 방식으로요.
꾸준히 쌓은 기본기는 기회가 왔을 때 설명할 수 있는 힘이 됩니다
Q. 마지막으로 취업과 성장 때문에 불안한 수강생에게 한마디 부탁드려요.
AI 시대라 취업이 어렵게 느껴질 수 있어요. 그래도 꾸준히 공부하면 기초가 쌓입니다. 기초가 쌓이면 개발 능력이 자기 안에서 구조화되고요.
그 상태에서 취업의 문을 여러 번 두드리다 보면 내가 준비한 것과 기회가 맞는 순간이 올 수 있다고 생각해요. 언제라고 약속할 수는 없지만, 그때까지 공부를 멈추지 않았으면 합니다.
미쿡엔지니어님이 인터뷰 내내 반복한 말은 새로운 도구를 무조건 빨리 따라가라는 것이 아니었습니다. 고객의 문제를 먼저 보고, AI가 일할 수 있도록 맥락을 만들고, 배운 것을 동료와 나누며, 한 분야의 전문성을 오래 쌓으라는 이야기였습니다.
처음에는 기저귀 값을 벌기 위해 시작했던 강의가 자신의 공부를 구조화하고 팀에 새로운 기술을 나누는 시스템이 됐다는 이야기처럼요. AI 시대의 개발자에게 남는 능력도 어쩌면 비슷할지 모릅니다. 혼자 알고 끝내는 것이 아니라, 내가 없어도 다른 사람과 시스템이 이어갈 수 있는 형태로 지식을 남기는 것.
미쿡엔지니어님은 앞으로도 인프런에서 계속 배우고 가르칠 예정이라고 했습니다. 다음 기술이 무엇이든, 먼저 공부해 구조를 만들고 다시 나누는 일을 계속하면서요.
미쿡엔지니어님의 데이터 엔지니어 노하우를 알고 싶다면?
댓글 0
댓글을 작성해보세요.