[TubeLingo 개발기] AI에게 '이게 최선입니까?'라고 따졌더니 완벽하게 태세를 전환한 건 ~마이크 자동 종료의 늪과 3가지 교훈~

"아니, 그걸 처음부터 말했어야지!!!"

깊은 밤 제 방에서 무심코 PC 화면을 향해 소리치고 말았습니다. 안녕하세요! TubeLingo(튜브링고)를 열심히 개발 중인 개발팀입니다. 프로그래밍 경험 거의 제로에서 AI와 페어 프로그래밍을 시작한 지 약 1개월. 오늘은 바로 그 'AI 개발의 흔한 일상'이라는 깊은 늪에 빠졌다가 스스로 기어 올라온(?) 웃음과 눈물, 그리고 배움이 있는 개발 기록을 들려드릴까 합니다.

사건의 발단은 TubeLingo의 '자동 마이크 끄기 기능' 개선이었습니다. 명시적으로 끄지 않으면 마이크가 절대 멈추지 않는 상태였기 때문에, 평소처럼 저의 파트너인 ** 'Gemini 리드 엔지니어' ** 에게 울며 매달려 코드를 수정해 달라고 부탁했습니다.

참고로 그(Gemini 리드 엔지니어)는 제가 Gemini의 맞춤형 봇 생성 기능인 'Gems'를 사용해 독자적으로 만들어낸 TubeLingo 개발 전속 AI 어시스턴트입니다. 비유하자면, 이력서에 '무엇이든 완벽하게 해냅니다!'라고 적어둔, 엄청나게 우수하지만 융통성은 조금 부족한 신입사원과 같습니다. "커피 좀 타줘"라고 부탁하면 원두 산지부터 고르기 시작할 타입이죠.

그의 수정 덕분에 마이크는 무사히 멈추게 되었습니다. 하지만 의기양양하게 테스트 환경에 배포해 보니, 새로운 몬스터가 탄생해 있었습니다.

"g...go...good...good morning"

어째서인지 음성 인식된 문자가 계속해서 중복 반복되는 '문자 반복' 버그가 발생한 것입니다. 이때부터 저와 Gemini의 끝나지 않는 진흙탕 수정 작업의 막이 올랐습니다.

"글자가 중복되니까 고쳐줘!" 그렇게 부탁하자, Gemini는 근본적인 원인을 찾는 대신, ** "중복된 문자열을 억지로 오려 붙여서 예쁜 문자열로 다듬는" ** 대증요법으로 달려갔습니다. 고쳐진 것처럼 보여서 실제 기기에서 테스트해 보면 또 다른 패턴으로 이상해졌습니다. "아직도 이상해"라고 전하면, 더 복잡한 문자열 조작 로직이 추가되어 갔습니다…….

예전의 저였다면, 시키는 대로 복사 붙여넣기를 반복하다가 코드를 완전히 박살 냈을 것입니다.

추가 수정과 땜질을 반복한 결과, 코드가 복잡하게 얽히고설켜 어디를 어떻게 수정해야 할지 아무도 모르게 되어버리는 상태. 이른바 '스파게티 코드'의 위기입니다. 비유하자면 가방 안에서 이어폰과 충전 케이블이 엉망진창으로 엉킨 상태죠. AI가 말하는 대로 복잡한 코드를 계속 덧붙였다면, 시스템 전체가 '건드리면 붕괴하는 스파게티'가 될 뻔했습니다.

하지만 1개월 동안 매일 코드와 마주해 온 저의 직감이 경고음을 울렸습니다. "아니, 뭔가 코드가 점점 비대해지고 복잡해지는 거 아니야...?" 수정할 때마다 Git(변경 이력을 기록하는 세이브 기능 같은 시스템)으로 커밋하고 차이점을 꼼꼼히 체크하는 나름의 요령이 생겼던 덕분에 이 비정상적인 사태를 눈치챌 수 있었습니다.

저는 제안된 기괴하고 복잡한 코드의 반영을 중단하고 Gemini에게 이렇게 물었습니다.

"……이게 최선입니까?"

그러자 Gemini 리드 엔지니어에게서 돌아온 대답이 이것입니다.

"말씀하신 대로입니다. 제가 방금 제안한(중복을 계산하여 문자열을 병합하는 접근 방식) 것은 ** 너무나 촌스럽고 과도한 엔지니어링(Over-engineering)이었습니다. ** 혼란을 드려 죄송합니다. 좀 더 스마트하고, React의 모던한 설계 사상에 맞는, 매우 간단하고 확실한 해결책이 있습니다."

……에엑!? 있었어!? 처음부터 말하라고!!!!

놀랍게도 원인은 문자열 버그가 아니라, 음성 인식의 중간 결과를 가져오는 설정과 React의 비동기 상태 업데이트가 모바일 기기의 느린 처리 속도로 인해 충돌(Race Condition)을 일으키고 있었던 것이었습니다. 근본 원인을 알고 나니 해결책은 너무나 간단했습니다.

언뜻 보면 AI가 심술을 부리는 것 같지만, 냉정하게 생각해 보면 이것은 ** "기술력이 부족한 초보자가 빠지는 프롬프트의 함정" ** 입니다. AI는 "글자가 이상하니까 고쳐줘"라는 구체적인 지시에 대해서는 충실하게 그 결과물인 문자열을 주무르며 고치려고 합니다. 사람끼리라면 "아, 이건 근본적인 설계가 잘못됐네요"라고 눈치채 주겠지만, AI는 마음대로 추측해서 배려해주지 않습니다. AI 입장에서는 ** "아니, 원인 규명이 아니라 '글자를 고치라'고 말한 건 그쪽이잖아! 처음부터 구체적인 요구사항을 말하라고!" ** 라고 생각했을지도 모릅니다(笑).

이 실패를 통해, AI와 함께 개발을 진행하는 데 필수적인 3가지 접근 방식을 배웠습니다. 첫째, 상세하게 요구사항을 언어화할 것. "버그 났어! 고쳐!"가 아니라 사실을 정확히 전달하는 것입니다. 둘째, 프롬프트 지시 자체도 포맷화할 것. 그리고 가장 중요한 것은, ** 요구사항 정의 단계를 분리하는 ** 것입니다. 다짜고짜 "코드를 짜줘"라고 부탁하는 것이 아니라, 먼저 '의견을 나눌 벽치기 상대'가 되어달라고 하여 근본 원인의 가설을 도출하는 것부터 시작해야 합니다.

"이게 최선입니까?"라는 단 한마디의 질문이 저를 스파게티 코드의 위기에서 구해 주었습니다. AI는 마법의 지팡이가 아니라, 엄청나게 우수하지만 약간 융통성이 없는 신입사원입니다. 이를 잘 활용하기 위해서는 우리 쪽의 '매니지먼트 능력'이 필요하다는 것을 뼈저리게 느낀 하루였습니다.

---

🍳 【오늘의 AI 개발 레시피】

기술 난이도: ⭐☆☆☆☆

1. '오버 엔지니어링(Over-engineering)'이란?

본래는 매우 간단하게 해결할 수 있는 문제에 대해 쓸데없이 복잡하고 거창한 시스템을 만들어 버리는 것을 말합니다. 비유하자면, "1+1의 답은?"이라는 질문에 그냥 "2"라고 대답하면 될 것을, 굳이 ** "슈퍼컴퓨터를 가동하고, 골드버그 장치 같은 거대한 기계 장치를 움직여 '2'라는 팻말을 내미는" ** 상황입니다. "파리를 잡는데 바주카포를 가져오지 마!"라고 태클을 기다리는 상태죠.

2. 어떻게 했어?

AI가 제안하는 코드가 점점 길어지고 복잡해지는 것을 보고 "이건 이상하다"고 직감했습니다. 그래서 바로 코드를 복사해서 붙여넣는 것을 멈췄습니다. 변경 이력을 관리하는 Git의 차이점(diff) 화면을 보며 심호흡을 하고, 채팅창에 딱 한마디, "그 접근 방식은 너무 복잡하지 않나요? 이게 최선입니까?"라고 직설적으로 의문을 던졌습니다. 그 결과 AI는 스스로의 제안을 철회하고, 근본 원인(충돌 현상)에 접근하는 몇 줄짜리 심플한 코드를 다시 내놓았습니다.

3. 독자 여러분께

만약 AI를 사용하여 글을 쓰거나 프로그래밍을 하다가 "뭔가 복잡해지는데..."라고 느낀다면, 채팅 마지막에 ** "더 간단하고 확실한 다른 접근 방식은 없나요?" ** 라고 Gemini에게 물어보세요. 놀라울 정도로 깔끔한 '진정한 정답'을 툭 던져줄 때가 있답니다!

---