AI가 코드를 대신 짜주는 시대, 엔지니어는 더 편해졌을까요?
점심시간에 모여 각자의 AI 활용기를 나누는 마키나락스 문화, AI Lunch Talk(이하 ALT)에 나선 엔지니어들의 대답은 조금 달랐습니다. 코드를 만드는 속도는 빨라졌지만, 그 코드를 이해하고 검증하는 일은 오히려 더 어려워졌다는 것이죠.
“요즘 ‘쓸모없는 인간’이라는 생각이 들어요.”
“하면 할수록 제 기억력이 점점 짧아진다는 생각이 들더라고요.”
가벼운 고민인 것 같지만, 이날 발표한 네 명의 엔지니어는 같은 문제를 짚었습니다. 바로 ‘인지부채(Cognitive Debt)’입니다. AI가 만든 결과물을 사람이 이해하지 못한 채 쌓아두면, 그 이해의 공백이 빚처럼 불어난다는 뜻이죠. 당장은 일이 빨리 끝난 것 같아도, 나중에 코드를 고치거나 설명해야 할 때 이자까지 붙어 돌아옵니다.
빚을 체감하는 순간은 이 밖에도 다양했습니다. 쏟아지는 PR 앞에서 한 줄도 읽지 않고 승인 버튼을 누르고 싶어지는 순간, AI로 작성해 올린 내 PR에 동료가 “이건 왜 이렇게 된 거예요?”라고 물었는데 답하지 못하는 순간처럼요.
1편에서는 마케팅팀과 P&C팀, 비개발 직군 마키나원들의 AI 활용기를 전해드렸습니다. 2편에서는 마키나락스 엔지니어 네 명이 각자의 자리에서 이 문제를 어떻게 풀고 있는지 이어서 소개합니다.
01 인지부채를 줄이기 위한 AI 협업 방식: PR 리뷰를 중심으로
양유진 | Forward Deployed Engineer(FDE)
첫 번째로 소개할 FD Agent팀 양유진 님은 시작부터 양해를 구했습니다. 오늘 발표 자료도 AI로 ‘딸깍’ 만들어 왔으니, 이런 자료를 던지는 것 자체가 듣는 사람에게는 부담일 수 있다고요. 유진 님의 발표 주제는 바로 그 ‘부담’, 앞서 말한 인지부채였습니다.
AI는 빨라졌는데, 왜 나는 더 바쁜 걸까
AI가 코드를 아무리 잘 짜도 병목은 결국 사람의 인지 능력입니다. 팀원들이 AI로 쏟아낸 결과물을 검증 없이 넘기면, 리뷰하는 사람은 그 양에 압도됩니다. 유진 님은 여기서 한 걸음 더 나아갑니다. 변경 사항을 따라가지 못해 쌓인 인지부채는 ‘무엇을 왜 만들었는지’ 놓치는 의도부채로, 다시 기술부채로 번진다는 것이죠. 이런 부담이 커지면 결국 한 줄도 읽지 않은 채 ‘LGTM(Looks Good To Me)’을 누르게 되죠.
“코드 한 줄 안 보고도 PR 리뷰가 가능해야 한다”
유진 님의 도발적인 제안입니다. 코드를 보지 말자는 게 아닙니다. AI가 작성하는 코드를 라인 바이 라인으로 다 읽을 수 없으니, 대신 무엇으로 품질을 지킬지 팀이 합의하자는 것이죠. 유진 님이 꼽은 과제는 두 가지입니다. 의도를 제대로 전달하는 것, 그리고 그것을 검증하는 것.
의도는 AI가 캐묻게 해서 끌어낸다
“해줘”라고만 하면 AI는 원하는 것보다 과한 결과물을 내놓기 일쑤입니다. 내가 알고 있는 것뿐 아니라, 미처 생각하지 못한 부분까지 전달해야 하기 때문이죠. 그래서 유진 님은 AI가 질문을 집요하게 던지는 ‘그릴링(grilling)’ 방식을 씁니다. 웹사이트를 만들어달라고 하면 “브랜드 아이덴티티는요? 폰트는요?”라고 되묻는 식입니다. 그제야 ‘아, 이걸 말 안 했네’ 하고 의도를 온전히 전할 수 있습니다.
검증은 루프로 만든다
그릴링으로 주고받은 대화는 곧 계획이 됩니다. 이를 스펙 문서로 정리하고, 티켓으로 쪼개고, 테스트 주도 개발(TDD) 방식으로 구현합니다. 익숙한 개발 방식에 AI 협업을 녹여낸 흐름이라, AI에게 훨씬 믿고 맡길 수 있습니다. 여기에 프로젝트 용어를 정리한 컨텍스트 문서와, 결정의 이유를 남기는 ADR(Architecture Decision Record)을 더합니다. AI에게 그냥 ‘Runway’라고 하면 동영상 툴로 알아들을 수도 있지만, AI가 참고하는 CONTEXT.md 문서에 “Runway는 마키나락스의 AI OS”라고 적어두면 매번 설명할 필요가 없습니다. “왜 B보다 A를 먼저 했죠?”를 슬랙에서 뒤지지 않아도, AI가 코드베이스 안에서 ADR을 통해 알아서 파악하고요.
다만 유진 님은 이런 도구는 결국 취향이라고 덧붙였습니다. 정말 필요한 건 원칙에 대한 합의입니다. 사람과 AI는 각각 무엇을 맡을지, PR 리뷰의 목적은 정말 버그를 찾는 것인지. 도구보다 원칙을 먼저 이야기하자는 제안으로 발표를 마쳤습니다.
02 개발 자율주행 차량 탑승자가 복잡한 머릿속을 정리하는 방법
김인호 | Backend Engineer
두 번째로 소개할 플랫폼팀 김인호 님의 첫마디는 이랬습니다. “요즘 ‘쓸모없는 인간’이라는 생각이 들어요.” AI 계정을 여러 개 돌리는데, AI가 일을 너무 많이 해서 정작 본인은 뭘 해야 할지 모르겠다는 솔직한 고백이었습니다.
몸은 편해졌는데, 머릿속은 복잡해졌다
인호 님은 최근 Runway 플랫폼에서 개발 프로세스를 위한 결재 기능을 개발했습니다. AI가 많은 일을 해주지만, 무슨 일이 돌아가는지 모르니 주인의식이 사라지는 느낌이었다고요. 인호 님의 진단은 “개발은 쉬워졌지만, AI가 무엇을 하는지 이해하지 못하면 운영하고 개선할 수 없다”는 것이었습니다. 발표에서는 그 과정에서 부딪힌 세 가지 문제와 삽질(?)의 기록을 공유했습니다.
복잡한 비즈니스 로직은 체크리스트로
플랫폼 기능은 데이터 하나를 저장하는 데에도 수많은 조건이 붙습니다. 관리자는 수정할 수 있지만 뷰어는 조회만 가능한 식이죠. 그래서 정책의 뼈대는 사람이 정하고, 대안·예외 흐름은 AI와의 인터뷰로 채웁니다. 결과는 사람이 읽기 쉬운 HTML 체크리스트로 만들어, QA 담당자와 AI가 함께 채워가며 검증합니다. 역할별 가상 사용자로 시나리오를 병렬로 돌리는 시뮬레이터도 직접 만들었습니다.
블랙박스 코드는 시각화로
문제는 그다음이었습니다. 테스트와 PR 작성까지 AI가 다 해주니, 내가 모르는 코드가 PR로 올라가고 팀원들은 그 코드를 이해하느라 고생합니다. 인호 님의 해법은 코드를 시각화한 HTML 문서입니다. 코드 구조를 한눈에 보여주거나 변경의 의도를 다이어그램으로 설명하는 문서를 만들어 팀과 공유합니다. 별도 도구 없이 프롬프트 몇 줄로도 충분하다는 팁도 덧붙였습니다.
쌓여가는 문서는 검색 포털로
그러자 HTML 문서가 컴퓨터 여기저기에 쌓이면서, 어디에 저장했는지 까먹고 같은 문서를 다시 만드는 일이 생겼습니다. 인호 님은 아예 AI에게 검색 포털을 만들어달라고 했습니다. 키워드로 문서를 연결하는 지식 그래프에 모바일 열람까지 더해, 출퇴근길 지하철에서도 문서를 확인합니다.
이렇게 개발한 Runway 결재 기능은 실제 프로젝트에 적용됐고, 사용자들에게 “지금까지 별다른 문제 없이 잘 돌아간다”는 피드백을 받았습니다. 인터뷰로 체크리스트를 만들고, 시뮬레이터로 검증하고, 쏟아지는 문서는 잘 관리하라. 인호 님이 전한 takeaway입니다.
03 이해를 돕는 AI 활용: DrawX 백엔드팀이 해본 것과 느낀 점
백종규 | Backend Engineer
세 번째로 소개할 DrawX TF팀 백종규 님은 앞 발표와 겹치는 내용을 빼느라 즉석에서 자료를 고쳐가며 발표했습니다. 하고 싶은 말은 한 문장이었습니다. “에이전트에게 코드를 짜게 하되, 그 코드가 만드는 건 제품이 아니라 이해다.”
Best practice가 아닌 ‘우리의 practice’
DrawX 백엔드팀은 AI 사용 규칙도 코드처럼 관리합니다. AI가 참고하는 공통 규칙 파일을 팀이 함께 관리하고, 추가하고 싶은 내용이 있으면 누구든 PR로 제안합니다. 새로운 방식은 각자 직접 써보고, 데일리 스크럼에서 좋았던 것만 공유합니다. 남들이 좋다는 방법도 우리 상황에서 직접 써보기 전까지는 모른다는 이유에서입니다.
AI가 만드는 건 제품이 아니라 이해
종규 님이 가장 자주 쓰는 건 ‘이해’를 돕는 스킬들입니다. 간단한 질문에도 논문 같은 답을 내놓는 AI에게는 한두 문장으로만 답하게 하고, 짧게 묻고 답하며 내 수준에 맞게 이해해 나갑니다. 동료와 주고받는 문서는 AI 특유의 말투를 자연스러운 한국어로 바꿔주는 스킬을 팀에 맞게 직접 만들어 씁니다.
계기는 동료의 질문 하나였습니다. AI로 작성해 올린 본인의 PR을 두고 “이건 왜 이렇게 된 거예요?”라는 질문을 받았는데, 대답을 못 한 겁니다. 그 뒤로 PR의 배경과 변경 전후를 다이어그램으로 풀어주고, 마지막에 난이도별 퀴즈 5문제까지 내주는 스킬을 만들어 쓰고 있습니다. “주니어가 오면 만점 받기 전엔 PR 못 올리게 하자”는 농담도 나왔는데, 아쉽게도(?) 아직 주니어가 오지 않았다고 합니다.
아직 10배는 아니지만
종규 님은 나올 만한 질문에도 미리 답했습니다. 인터넷에서 말하는 ’10배 생산성’은 아직 아닙니다. 실수할 때마다 규칙을 추가하고 다시 확인하게 해봐도, 틀린 답은 여전히 나오니까요. 하지만 버그의 원인을 찾거나 취약점을 예상하는 일, 그리고 코드를 이해하는 일만큼은 확실히 10배라고 합니다. 바쁜 와중에도 AI 공부를 놓지 않는 이유는 주택담보대출에 빗댔습니다. 당장 내일 할 일(이자)만 갚다 보면 빚은 줄지 않으니, 원금(AI 활용법 공부)도 조금씩 갚아야 한다는 겁니다. “AI 회사 엔지니어가 AI를 잘 못 다루면 역설적이잖아요.”
종규 님은 AI 활용을 세 단계로 나눴습니다. 모르는 것을 물어보는 단계, 사람이 이해하며 함께 돌리는 단계, 그리고 에이전트를 믿고 맡기는 단계. 지금 팀은 두 번째 단계에 있고, 세 번째 단계는 한순간에 오지 않는다고 말합니다. 작은 시도가 하나둘 모여 팀 전체의 생산성을 조금씩 끌어올린다면 머지않아 마지막 단계를 마주할 것이라고요.
04 AI에게 효율적으로 일을 시키는 방법
정창해 | Machine Learning Engineer
네 번째로 소개할 Cognition팀 정창해 님은 도면 AI 엔진 개발을 비롯해 여러 프로젝트를 동시에 맡고 있습니다. “하면 할수록 제 기억력이 점점 짧아진다는 생각이 들더라고요.” 일이 늘수록 고민도 커졌습니다.
어제 한 일도 기억이 안 날 때
AI 덕분에 작업량이 많아지면서 요즘은 어제 한 작업들도 가물가물합니다. 특히 끝난 프로젝트를 다시 손볼 때는 당시 왜 그렇게 결정했는지 기억나지 않고, ‘나중에 해야지’ 하고 미뤄둔 엣지 케이스들을 잊어버릴 때도 많습니다. 창해 님은 이 문제를 네 가지 작업 방식으로 풀었습니다. 기록을 쌓고, 기준을 세우고, 작업을 병렬로 돌리고, 충돌을 막는 것입니다.
기억은 기록에게 맡긴다
출발점은 기록입니다. 프로젝트의 레포와 날짜 단위로 작업 로그를 쌓고, 진행 중인지 끝났는지 상태를 함께 남깁니다. 과거 프로젝트의 결정 사항과 규칙은 별도의 지식 문서로 모아둡니다. 에이전트는 작업을 시작하기 전에 이 기록부터 훑습니다. 기억이 안 날 때는 AI에게 “내가 왜 이렇게 했지?”라고 묻습니다. 문서를 모바일과 연동해 두니 이동 중에도 확인할 수 있습니다.
구현보다 기준이 먼저
LLM은 돌릴 때마다 결과가 조금씩 달라질 수 있습니다. 앞 단계의 결과가 흔들리면 뒤 단계의 로직까지 무너지죠. 또한, 각 단계의 정답을 눈으로 항상 확인해야 하죠. 그래서 창해 님은 구현 전에 라벨부터 만듭니다. AI로 라벨링 페이지를 만들어 10~20개 정도 직접 라벨링한 뒤, 그 규칙으로 나머지를 자동 라벨링합니다. 이렇게 만든 라벨이 의도된 결과가 반복해서 동일하게 나오는지 평가하는 기준이 됩니다.
동시에, 그러나 꼬이지 않게
여러 작업은 병렬로 돌립니다. 작업마다 독립된 공간을 만들고 이름을 붙여, 어떤 작업이 어디서 돌아가는지 한눈에 봅니다. 진행 상황은 모바일로 확인하고 지시도 내립니다. 이전 맥락을 이어받고, 요청 사항을 기록하고, AI가 캐묻는 그릴링으로 요구 사항을 정리한 뒤, 계획을 세우고 나서야 코드를 실행합니다. 병렬로 작업한 규칙 하나가 어긋나 전체 결과가 망가지는, 하나의 수정이 나비효과를 일으키는 일을 막기 위해서입니다.
AI를 많이 쓰다 보니 늘 부족한 토큰을 20~50%까지 아껴주는 도구를 쓰는 팁도 덧붙였습니다. 발표를 마치며 창해 님은 Cognition팀도 PR을 템플릿화해 서로 보기 편하게 만드는 등 코드 협업을 고민하고 있다며, 이날 들은 내용을 팀 안에서 발전시켜 다시 발표하는 날을 기대한다고 전했습니다.
각자 다른 일을 하는데, 같은 곳에 도착했다
이날 가장 재미있었던 건 발표들이 서로 이어졌다는 점입니다. 유진 님이 소개한 그릴링을 인호 님과 창해 님이 다시 꺼냈고, 종규 님은 겹치는 내용을 빼느라 자료를 고쳤죠. 각자 다른 일을 하면서도, 비슷한 고민 끝에 비슷한 답에 닿아 있었던 겁니다. AI가 빨라질수록 사람이 이해하고 판단할 수 있는 구조를 만들어야 한다는 것이요.
종규 님 발표 자료에는 이런 문장이 있었습니다. “Best practice가 아니라 우리의 Practice” 남들이 좋다는 방법도 우리 상황에서 직접 써보기 전까진 모른다는 뜻인데요. 각자 써보고, 좋았던 걸 나누는 자리. ALT가 우리에게 더욱 유익했던 이유이기도 합니다.
지금까지 두 편에 걸쳐 마키나락스의 ALT 현장을 전해드렸습니다. ALT에서 나눈 이야기들이 저희에게 너무나 유익했기에, 이 중 엔지니어 세션들을 외부에 공개 가능한 정보로 재구성해 영상으로도 준비했습니다. AI 활용을 고민하는 많은 분들께 저희의 고민이 유의미한 실마리가 될 수 있길 바랍니다.
