끝났다고 생각한 자리에서
좋은 앱과 더 좋은 앱의 차이는 어디서 올까요? 처음 만들 때일까요, 아니면 만든 다음일까요? 여러분이 매일 쓰는 앱은 — 어제보다 오늘 조금 더 빨라졌을까요?
지난 두 글에서 코드를 통째로 갈아엎은 2.5주의 마이그레이션 이야기를 풀었습니다. 옛 코드 0줄. 자동 검증 통과. 화면 정상. 마이그가 끝났습니다. 보통은 여기서 한 호흡 돌리고, 다음 새 기능으로 넘어갑니다.
그런데 이번엔 조금 다르게 가보기로 했습니다. 끝났다고 생각한 그 자리에서 멈추지 않고, 앱을 더 가볍고 빠르게 다듬는 데 한동안 시간을 썼습니다. 이 글은 그 마이그 그 다음의 기록입니다. 그리고 — 솔직히 말하면 — 그 길 끝에서 만난 반가운 발견 하나에 대한 이야기이기도 합니다.
더 가볍게 — 짐 보따리를 145분의 1로
앱이 처음 켜질 때, 사용자의 기기는 보이지 않는 짐 보따리를 하나 내려받습니다. 화면을 그리는 데 필요한 코드 꾸러미지요. 이 보따리가 클수록 처음 켤 때 하얀 화면을 보는 시간이 길어집니다.
마이그 후 이 보따리를 들여다보다가, 한 부분이 유독 무겁다는 걸 발견했습니다. 화면 곳곳의 작은 아이콘들을 그리는 꾸러미였는데, 정작 쓰는 아이콘은 몇십 개인데 1,748개 전부를 통째로 싣고 다니고 있었습니다. 필요한 것만 골라 싣도록 짐 싸는 방식을 바꿨습니다.
결과: 그 꾸러미가 660KB에서 4.5KB로 줄었습니다. 약 145분의 1. 앱 세 개를 합치면 전체 짐이 45%가량 가벼워졌습니다. 사용자분들이 체감하는 건 딱 하나입니다 — 앱이 더 빨리 뜬다. 코드 안쪽에서 일어난 일은 보이지 않지만, 처음 켜지는 그 1~2초는 누구에게나 보입니다.
더 빠르게 — 첫 글자가 나오기까지
코치 앱의 핵심은 대화입니다. 그런데 마이그 이후, 코치가 답을 시작하기까지의 시간이 마음에 걸렸습니다. 질문을 보내고 답이 통째로 완성될 때까지 빈 화면을 바라보는 몇 초 — 그 침묵이 길게 느껴졌거든요.
그래서 코치가 생각하는 대로 글자가 흘러나오게 바꿨습니다. 사람이 말할 때 문장이 끝나야 입을 떼는 게 아니라 말하면서 생각하듯, 코치도 첫 글자를 1~2초 안에 내보내고 나머지를 이어 쓰도록요. 답의 총량은 같지만, 기다림의 체감은 전혀 달라집니다.
여기에 더해, 답을 보내는 길목에 끼어 있던 불필요한 멈춤들을 걷어냈습니다. 매 대화마다 기록을 남기느라 100~300밀리초씩 답이 늦어지고 있었는데, 그 기록을 답을 보낸 뒤에 따로 처리하도록 순서를 바꿨습니다. 사용자는 기다릴 필요가 없어졌지요.
그러다 측정 도구 자체를 의심했습니다
여기서 좀 멋쩍은 이야기를 하나 해야겠습니다.
응답 속도를 더 줄여보려고 측정부터 했습니다. 어디서 시간이 새는지 알아야 하니까요. 그런데 숫자를 들여다볼수록 이상했습니다. 분명 빨라졌어야 할 곳이 그대로였거든요. 한참을 헤매다, 문득 다른 각도의 질문이 떠올랐습니다. 혹시… 측정하는 행위 자체가 시간을 잡아먹고 있는 건 아닐까?
…
범인은 측정 코드 자신이었습니다. 속도를 재려고 넣어둔 그 기록 코드가, 매 응답마다 100~300밀리초씩 답을 늦추고 있었습니다. 빨라지게 하려고 넣은 것이 느려지게 하고 있었던 거죠. 곧바로 걷어냈습니다.
조금 우습기도 하고 부끄럽기도 한 일입니다. 다만 이 일에서 한 가지는 분명히 배웠습니다 — 눈금자조차 의심해야 할 때가 있다는 것. 100밀리초를 줄이겠다고 측정 인프라까지 다시 들여다보는 건, 어찌 보면 과한 일입니다. 그런데 보이지 않는 그 작은 단위가 쌓여 결국 사용자의 하루를 만든다는 걸 알고 나면, 그 과함이 과하지 않게 됩니다.
보이지 않는 곳까지 들여다보기
살아있는 제품에는 항상 다듬을 곳이 있습니다. 처음부터 완벽한 제품은 없고, 잘 도는 제품도 안쪽엔 아직 보이지 않는 작은 어긋남들을 품고 있습니다. 중요한 건 그게 있느냐 없느냐가 아니라 — 누가, 얼마나 깊이, 사용자가 겪기 전에 먼저 찾아내느냐입니다.
저희(저, 그리고 AI)에겐 자동으로 코드를 점검하는 다섯 겹의 검사가 있습니다. 그런데 마이그 이후, 그 다섯 겹을 전부 통과하고도 사람이 직접 코드를 읽어야만 보이는 종류의 어긋남이 있다는 걸 알게 됐습니다. 기계적인 검사로는 잡히지 않는, 의미의 결에 가까운 것들이지요.
앱이 멈추거나 화면이 깨지는 심각한 오류는 아닙니다. 오히려 그 반대라 더 까다롭습니다 — 화면도 멀쩡하고 자동 검사도 다 통과하는데, 어떤 조건이 겹칠 때만 사용자가 받는 도움이 한 뼘 모자라지는, 그런 눈에 잘 안 띄는 디테일들이거든요. 코드를 한 줄씩 다시 읽다가 그런 자리를 몇 군데 찾아, 사용자가 마주치기 전에 다듬었습니다. 그리고 같은 결의 어긋남이 또 없는지 같은 자리 전부를 훑었고요.
자랑하려고 꺼낸 이야기는 아닙니다. 다만 빠르게 만들 수 있는 시대일수록, 화면 너머의 보이지 않는 한 줄을 들여다보는 일은 더 사람의 몫으로 남는다는 걸 — 이 시기에 자주 느꼈습니다.
그러다 알게 된 것 — 혼자만의 고민이 아니었습니다
이쯤 되니 궁금해졌습니다. 나만 이런 걸로 끙끙대나? 어디까지 AI를 믿고, 어디서부터 직접 들여다봐야 하는가 — 매일 부딪히던 이 질문이 나만의 것인지, 한번 찾아봤습니다.
제가 이 일에 발을 들인 건 vibe coding 이라는 말을 듣고 나서였습니다. AI에게 원하는 걸 말로 던지면 코드가 나오는 방식 — 아마 요즘은 누구나 한 번쯤 들어보셨을 겁니다. 저 역시 그 말에 이끌려 시작했고요.
그런데 찾아보다 알게 된 건, 그 vibe coding이 가만히 멈춰 있지 않더라는 점이었습니다. 수많은 사람들이 그냥 다 맡기면 되는 걸까를 두고 계속 고민하면서, 그 흐름이 조금씩 다른 모양으로 자라고 있었습니다. AI에게 무엇을 어떻게 떠먹여 줄지, 어디에 검증의 그물을 칠지 — 제가 마이그와 최적화 내내 붙들고 있던 바로 그 질문들이, 그 흐름 한가운데에서도 똑같이 다뤄지고 있더군요.
저는 그 흐름을 정확히 이해했다고는 못 하겠습니다. 솔직히 공부할 게 한참 더 많습니다. 다만 한 가지는 분명히 반가웠습니다. 제가 더듬더듬 끌어안고 있던 고민의 방향이, 저 멀리 훨씬 똑똑한 사람들이 함께 밀고 있는 흐름과 맞닿아 있었다는 것. 그냥 흐름을 따라가는 것과, 내 고민이 그 흐름과 맥을 같이하고 있다는 걸 아는 것은 — 전혀 다른 기쁨이더군요.
마치며 — 혼자가 아니었습니다
맨 처음 글에서, 제가 코치 앱을 만든 이유를 적었습니다. 혼자 싸우는 사람에게 옆자리 하나를 만들어주고 싶었다고요. 코치가 없던 시절의 저 같은 사람에게.
그런데 그 옆자리를 만드는 일을 하다가, 제가 혼자가 아니었다는 걸 알게 됐습니다. 번들을 145분의 1로 줄이고, 첫 글자를 1초 빠르게 하고, 측정 도구까지 의심하고, 보이지 않는 한 줄을 들여다보던 그 시간들이 — 어딘가 큰 흐름과 닿아 있었다는 것. 그걸 알게 된 게, 이 마이그 그 다음 시기가 제게 남긴 가장 큰 선물이었습니다.
최적화에는 끝이 없습니다. 살아있는 제품은 계속 자랍니다. 그리고 그걸 키우는 사람도, 그 곁에서 조금씩 같이 자라는 것 같습니다.
여러분이 매일 손에 쥔 도구는 — 보이지 않는 곳에서도 자라고 있나요? 그리고 여러분의 고민은, 정말 혼자만의 것일까요?
함께 이 앱을 키워주시겠어요? 저희 앱들이 여러분에게 더 많은 쓰임이 되기를, 그리고 여러분의 의견을 받아 더 크게 자라기를 — 기대해 봅니다.