데이터 정제와 번역 지옥: 클로드 과장도 두 손 두 발 다 든 레시피 앱 개발 잔혹사
지옥의 문은 언제나 원대한 포부와 함께 열리는 법입니다. 초반에 제가 기획안을 쓰고 작업 시간을 시뮬레이션했을 때 6개월은 걸린다는 클로드 과장님의 예상과는 다르게, 우리의 환상적인 티키타카 덕분에 앱의 기본 뼈대를 뚝딱 만들어냈을 때만 해도 저는 제가 천재 개발자인 줄 알았습니다. 좋아 마마, 이 기세로 고퀄리티 글로벌 식단 관리 레시피 앱을 만드는 거야! 가자! 가자!!라며 기고만장했죠. 하지만 1인 앱 개발 전선에서 진짜 무서운 건 코딩 에러가 아니라, 내 통제를 벗어난 ‘현실의 데이터’와 ‘코딩을 잘 몰랐기에 생기는 비효율적 작업 순서’라는 걸 그때는 미처 알지 못했습니다. 이번 글에서는 제 멘탈을 가루로 만들었던 지옥의 레시피 정제 작업과 눈물 없인 볼 수 없는 번역 삽질기를 탈탈 털어보겠습니다.
포부는 칼로리 분석, 현실은 “데이터가 왜 이래?”
처음 앱을 기획할 때 제 포부는 아주 대단했습니다. 무료로 제공되는 레시피 API를 활용해 기본 레시피를 구한 뒤, 사용자가 원하는 칼로리와 영양가 있는 음식을 식단에 쏙쏙 넣을 수 있게 만들고 싶었어요. 욕심이 더해져 식단 관리 앱 개발 단계에서 더 나아가 한 달이 지나면 본인이 섭취한 영양 정보와 칼로리 통계 분석 리포트까지 짜잔! 하고 제공하는 완벽한 헬스케어 시스템을 꿈꿨죠.
하지만 실제 다운로드한 레시피 데이터의 민낯을 마주한 순간, 제 환상은 산산조각이 났습니다. 데이터가 상상을 초월할 정도로 너무 더러웠기 때문이죠. 클로드 과장에게 API로 긁어온 텍스트를 파싱하는 파이썬 코드를 받아 실행하고 나서 보게 된 실제 데이터는 충격 그 자체였습니다.
- 조리 순서가 중간에 뚝뚝 끊겨 있거나 심한 오타가 있는 것은 기본
- 분명 동일한 API 내에 있는 레시피들인데도 어떤 건 계량이 그람(g)이고, 어떤 건 큰술이라 포맷이 다 제각각
- 닭가슴살이 어떤 레시피에는 ‘닭가슴살’, 영양정보나 칼로리 정보 데이터에는 ‘닭 살코기’로 되어 있어 매핑 불가
Markdown
[초보 개발자의 멘붕 모먼트]
"과장님, 데이터 구조가 다 꼬여서 칼로리 영양소 매핑이 아예 안 돼요... 우리 기본 데이터 먼저 SQL 코드로 수정하죠.."
(클로드 과장의 답변: "맞아요. 이 상태의 데이터로는 정확한 분석이 불가능합니다. 재료명이 이상한것 부터 체크하겠습니다.")
결국 저와 과장님은 장장 일주일 내내 밤을 새우며 데이터 클리닝 작업에만 매달렸습니다. 플러터 독학을 하면서 앱만드는 코드 치는 시간보다 계속해서 이상한 재료명, 단위, 용령이나 조리 순서가 이상한것, 식단마다 매핑된 음식 카테고리 등을 끊임없이 과장님이 짜주는 SQL 코드로 supabase에서 찾아서 수정하는 작업을 했습니다.
그럼에도 불구하고 2,000개가 넘어가는 레시피를 하나하나 다 검수하는 건 불가능에 가까웠죠… 게다가 제가 세상 모든 음식을 다 만들어본 요리 장인도 아니니, 레시피 설명이 약간 이상해도 이게 맞는 건지 판단하기가 너무 애매하더라고요. 원래는 재료와 조리방법등을 제대로 다 파싱해서 칼로리와 영양분 데이터 베이스의 정보와 매핑해서 요리에 맞게 자동 계산을 해주겠다는 제 포부는 현실적으로 불가능하다는 판단이 섰습니다. 즉, 레시피 데이터, 칼로리 정보 데이터, 영양분 정보 데이터의 재료 명 등이 너무나 달라서 매핑이 현실적으로 어렵더라구요.
결국 결단을 내려야 했습니다. 칼로리 분석 기능은 분명 ‘있으면 좋은 기능’이 맞지만, 제 앱의 본질이자 가장 핵심적인 핵심 기능은 아니었거든요. 과감하게 칼로리와 영양 기능을 포기하고, 대신 눈앞의 레시피 데이터 퀄리티를 깨끗하게 만드는 ‘클리닝’ 작업에 모든 포커스를 맞추기로 했습니다. 1인 개발자는 자원이 한정되어 있으니 버릴 건 빨리 버려야 살길이 열리더군요.
📌 영어 번역? 동시에 안 만들고 나중에 합체하려다 터진 대참사
데이터 정제와 씨름하는 와중에 또 하나의 거대한 장벽이 가로막았습니다. 바로 ‘글로벌 번역’이었습니다. 한글과 영문이 모두 제공되는 다국어 지원 앱을 만들어서 전 세계 사람들이 국경 없이 쓸 수 있게 하겠다는 목표가 있었거든요.
처음 클로드 과장님께 물어봤을 땐 “일단 한글 버전 먼저 완벽하게 만들고, 나중에 영어 버전 씌우면 돼~”라는 말을 믿었습니다. 하지만 실전은 생각보다 작업량이 어마어마했습니다. 그 말을 믿은 과거의 제 자신을 한 대 때리고 싶을 정도로 엄청난 비효율의 극치였습니다. 소용없지만 과장님께 피드백도 강하게 드렸죠. 왜 제게 그렇게 말씀하셨나요! 그냥 처음부터 한글과 영어 다국어 설정을 동시에 진행하면서 빌드했어야 했습니다.
이미 완성된 수많은 앱 파일에 영어 번역 버전을 뒤늦게 집어넣으려니, 기존 코드를 전부 들쑤시며 다국어 지원 코드로 대공사를 해야 했습니다. 게다가 이미 끝내놓은 수많은 기능 테스트를 영어 버전 화면에서 다시 처음부터 다 진행해야 하더군요. 이 번역 시스템을 뜯어고치고 적용하는 데만 꼬박 일주일이 다 날아갔습니다. 이럴 줄 알았으면 초반 기획 때 AI 코딩 설계도를 짤 때부터 다국어 구조를 넣어달라고 할 걸 그랬다는 후회를 얼마나 했던지 모릅니다.
게다가 가장 큰 문제는 ‘음식 이름 and 식재료의 번역 퀄리티’였습니다. 요리 레시피 특성상 직역을 하면 의미가 완전히 왜곡되기 때문에 번역 퀄리티가 생명이었습니다. 만약 처음에 제대로 된 식단 관리 앱 개발 방향성을 잡고 다국어 설계를 동시에 했다면 이런 삽질은 줄었을 텐데 말이죠.
처음에는 번역계의 명품이라는 DeepL API를 연동해서 썼어요. 성능은 참 좋았는데, 레시피 2,000개를 통째로 다 밀어 넣고 번역을 돌리다 보니 순식간에 제 평생 무료 크레딧을 전부 탕진해 버렸습니다! 예상을 아득히 뛰어넘는 데이터양에 숨이 턱 막혔죠. 추가 비용을 무작정 지출할 수 없어서, 결국 다시 클로드 과장의 힘을 빌려 Claude API로 번역 파이프라인을 교체했습니다.
그런데 AI 번역도 완벽할 수는 없었습니다. 중간중간 검수를 하다가 번역이 요상하게 되는 걸 발견했거든요. 예를 들어서 한국의 깊은 맛을 내는 ‘참치액’을 자꾸 ‘멸치액젓(Anchovy fish sauce)’으로 번역해 놓는가 하면, 미림을 영어로 번역 후 다시 한글로 앱 내 설정을 바꾸면 갑자기 일어로 미림을 써준다던가 하는 등 치명적인 오류들이 튀어나오더라고요. 결국 저는 번역봇이 된 것처럼 중간중간 데이터 퀄리티를 수동으로 체크하고 수정하는 기묘한 노가다 작업을 끊임없이 반복해야만 했습니다.
땀과 눈물로 정제한 데이터, 그리고 드디어 출시된 ‘담음(Damem)’
이처럼 일주일은 더러운 데이터와 싸우고, 또 일주일은 꼬여버린 번역 코드 및 멸치액젓(?) 에러와 싸우며 영혼을 갈아 넣었습니다. 코딩보다 데이터 정제가 훨씬 힘들다는 선배 개발자들의 말이 뼈저리게 와닿는 순간이었죠. 플러터 독학을 시작할 때만 해도 이런 복병이 숨어있을 줄은 꿈에도 몰랐습니다.
이런 눈물겨운 대공사를 거친 끝에, 마침내 제 소중한 레시피 다이어리 앱 ‘담음(Damem)’이 앱스토어에 정식으로 출시될 수 있었습니다! 고생 끝에 낙이 온다는 말은 이럴 때 쓰는 건가 봅니다.
👉 우여곡절 끝에 탄생한 ‘담음(Damem)’ 앱스토어 구경가기
아직 완벽하진 않고 중간중간 다듬어야 할 데이터들이 보이지만, 클로드 과장과 밤새 에러 로그를 주고받으며 전 세계 독자들을 위해 완성한 식단 관리 레시피 앱 화면을 보고 있으면 자식 실물을 마주한 것처럼 가슴이 벅차오릅니다. 추가적인 앱 개발 비용을 들이지 않고 오직 끈기와 AI 서포트만으로 이 단계까지 온 것이 스스로도 믿기지 않네요.
하지만 앱 개발의 최종 보스는 따로 있었습니다. 코딩도 끝냈고, 데이터도 닦았고, 번역도 입혔으니 이제 스토어에 올리기만 하면 끝일 줄 알았죠? 하지만 제 앞에는 애플과 구글이라는 거대한 양대 산맥의 ‘앱 심사 거절 지옥’이 기다리고 있었습니다. 아이패드가 없어서 발생한 크래시 에러부터 지인 12명을 모으다 파탄 날 뻔한 구글 비공개 테스트의 눈물겨운 비하인드 스토리와 최종 비용 정산은 다음 마지막 시리즈에서 들려드리겠습니다!
- 1인 개발의 시작과 기획 단계가 궁금하다면? [이전 시리즈(2편) 보러 가기]