#11. 기록

최근 신규 기능 하나를 추가했다. 처음에는 재밌겠다고 생각했는데 반응이 거의 없었다. 그런데 비회원까지 사용 범위를 넓히자 바로 반응이 붙었다. 작은 변화지만 실제로 사용이 어디에서 막히는지 다시 확인하는 계기가 됐다. 거창하게 UX라고 부를 것까지도 없다. 결국 정보의 배열, 구조, 진열 같은 기본적인 배치가 꽤 중요하다. 이런 감각을 계속 쌓아가는 게 필요하다는 생각이 든다.

요즘은 서비스 지표를 예전보다 훨씬 엄격하게 보고 있다. 가만히 들여다보면 아직 어떤 지표도 “서비스”라고 부를 수 있는 임계점을 넘지 못했다. 방향은 맞고 데이터도 조금씩 쌓이고 있으며 루프 설계도 형태를 갖추고 있지만, 아직 그 선을 넘지는 않았다. 그래서 당분간은 이렇다 저렇다 의미를 붙이기보다 조용히 쌓는 단계라고 보는 편이 맞겠다.

오늘은 다른 생각 기록.

한동안 직접 코딩을 하지 않았는데 깃허브에는 다시 녹색 불이 켜지고 있다. 사실 코드의 대부분은 AI가 작성한다. 설계부터 구현, 코드 리뷰, QA까지 거의 전부 AI에게 맡기고 있다. 예전에 리뷰할 때 “Looks good to me +1” 하던 버릇도 그대로라서, 요즘은 대충 이런 느낌이다. “오키, 인제 상용에 배포한다?” 네 배포하셔도 됩니다. 이러면 바로 올리고, 잘 돌아간다. “Looks work well in production +1.” 이 정도. 그래서, 개인적으로는 “AI 산출물 검토하는데 시간이 더 걸린다거나, 코딩 생산성은 더 이상 크게 올라가기 어렵고 인간이 필요하다”는 이야기도 내 경험상 조금 회의적이다.

이렇게 게으르지만 지금까지 발생한 장애는 두 번뿐이었다. 하나는 DB 연결 누수였는데, 초기에 로컬 LLM을 길들이면서 나온 코드였고 다른 하나는 인프라 설정에서 내가 실수한 경우였다 (요즘은 그놈 코딩 보다는 정말 중요한 여러 허드렛일 배치 작업 뺑뺑이 돌린다). 현재 하루 API 호출이 거대한 규모는 아니지만 그렇다고 소형 또는 실험 단계라고 부르기에도 애매한 숫자다. 여전히 대충 배포하고 라이브에서 바로 건드리는 스타일은 크게 달라지지 않았다. 다만 요즘은 뭔가 잘못되었을 때 “아이씨…” 하면서 식은땀이 올라오는 순간이 조금씩 생긴다. 등줄기가 살짝 쭈뼛해지는 느낌. 그래도 그 감각이 나쁘지 않다. 아, 이게 운영하는 맛이구나 싶다. ㅋ

속도 이야기도 조금 해보자.

“빨리 만들어서 검증한다”는 시대는 거의 저물었다고 생각한다. 이제는 MVP만으로는 뚫기 어렵다. 이미 대부분의 영역에는 데이터 층, 사용자 층, 그리고 네트워크가 쌓여 있다. 인터넷 거대 구조 내 이런저런 최적화 알고리즘도 새로운 출현자 뉴비가 뭘 하기 어렵게 만든다.

이런 구조를 무시한 채 단순한 MVP 하나로 시장을 관통하는 일은 점점 더 어려워지고 있다. 한때는 젊은 사람들 몇 명 모여서 Lean하게 시작해보자는 식의 로망이 있었다. 빠르게 만들고, 빠르게 실패하고, 그 과정에서 답을 찾는 방식. 하지만 지금은 아이디어도 싸고 실행도 싸진 시대다. 아마 이런 팀빌딩하고 있다면 빨리 그만두는게 좋을거다.

이제는 구시대적 스타트업 마인드도 버려야하고 질문도 조금 바뀌어야 한다고 생각한다. 무엇을 만들 것인가보다, 어떤 데이터 흐름 위에 서 있을 것인가. 이미 데이터가 있는 곳을 점유하든지, 아니면 최소한 그 흐름 안에 풍향계와 미터기를 설치할 수 있어야 한다.

그럼에도, AI가 만능이 아닌것이.

노가다가 여전히 필요한 곳, 그리고 CS 이야기

어떤 배달앱이 있다고 가정해보자. 유저 혜택이나 뱃지 같은 정책 하나를 정한다고 치면, 수정 요구사항이 한 곳에서 끝나지 않는다. 전시 영역이든 마이페이지든, 주문과 결제, 빌링까지 서비스 전반으로 퍼져나간다. 작업 자체가 어려운 것은 아니다. 대부분은 여기저기 조건을 추가하고 맞춰주는 일이다. 하지만 그 범위가 굉장히 넓다. 이런 종류의 작업은 AI가 알아서 전부 처리해주지 않는다.

주문 로직, 결제 조건, 쿠폰 적용, 사용자 혜택, 마이페이지 표시, 관리자 페이지, 정산과 빌링, 이벤트 배너, API 응답 스키마, 앱 UI까지. 이건 단순히 코드를 고치는 문제가 아니다. 서비스 전체에 정책이 어떻게 전파되는지를 다루는 문제다. 결국 코드가 아니라 서비스 구조를 이해해야 한다.

그래서 결국 필요한 것은 일을 잘게 쪼개고, 각각을 어디에 반영해야 하는지 판단하고, 결과물을 하나의 시스템으로 수렴시키는건 사람. 이런 정도의 업무 지식과 맥락 처리는 거대 인프라 굴린다고 싸지는게 아니고 사람이 더 효율적이다.

또, 직접 사업을 해보거나 CS를 해본 사람이라면 이게 얼마나 고달픈 일인지 안다. 그리고 이 작업이 결코 사소하지 않다는 것도 안다. 오히려 사업 리스크와 가장 가까운 영역이기도 하다.

통상 외부 용병 투입 C레벨 구조에서는 이런 현실적인 운영 문제보다 숫자와 보고서에 더 집중하는 경우가 많다. 그렇게 조직은 서서히 사업의 본질에서 멀어지고, 결국 내부부터 썩어가며 침몰하는 모습도 몇 번 봤지.

반대로 이런 경험 없이 바로 1인 서비스를 시작하면 또 다른 종류의 현실을 만나게 된다. 그 궤도에 올라가는 것 자체도 일단 어렵지만, 올라가고 나면 거쳐야할 관문들이다. 생각보다 훨씬 많은 운영 스트레스를 감당해야 한다는 것을 알게 된다.