이전까지는 쏘카존 장애를 처리하고, 업무 흐름을 정리하고, 대시보드로 현황을 보는 일이 중심이었다면 지역사업팀에서는 차량의 공급을 담당했습니다. 차량을 필요한 곳에 배치하고, 상황에 따라 다시 옮기고, 주차비를 관리했습니다. 차량 한 대가 어느 쏘카존에 있느냐가 이용 가능 차량 수와 매출, 비용에 영향을 줄 수 있었습니다. 업무가 달라지면서 숫자를 보는 방식도 달라졌습니다. 신차를 어느 팀에 보낼까 가장 먼저 마주한 일은 신차 배치였습니다. 새 차량이 들어오면 어느 지역과 쏘카존에 몇 대를 보낼지 정해야 했습니다. 모든 지역에 같은 수요가 있는 것도 아니고, 차량을 배치할 수 있는 공간이 무한한 것도 아니었습니다. 기존 차량의 이용 상황과 쏘카존의 특성, 지역별 수요를 함께 봐야 했습니다. 단순히 빈자리가 있는 곳에 보내는 일이 아니라, 차량이 실제로 사용될 가능성과 운영 비용을 같이 생각해야 했습니다. 수익이 부족한 곳의 차량을 다시 옮기다 차량을 한 번 배치했다고 끝나는 것도 아니었습니다. 기존 쏘카존의 수익이 부족하거나 차량 이용이 기대보다 낮으면, 다른 쏘카존으로 차량을 재배치해야 했습니다. 반대로 특정 지역의 수요가 높아 차량이 부족한 경우에는 추가 공급을 고민해야 했습니다. 이 과정에서 차량을 옮기는 것 자체에도 비용과 시간이 들었습니다. 차량을 이동시키면 다른 곳의 공급 상태가 달라질 수 있었기 때문에 한 지역만 보고 판단할 수 없었습니다. 차량을 어디에서 빼고 어디에 넣을지, 이동 후에는 어떤 결과가 생겼는지를 계속 확인해야 했습니다. 작은 배치 변경이 지역 운영 전체에 영향을 줄 수 있다는 점을 배웠습니다. 강남·서초·송파·관악을 운영하다 서울권역사업팀에서는 서울과 인천 차량의 공급을 담당한 뒤, 강남·서초·송파·관악 지역 운영도 맡았습니다. 지역을 맡는다는 것은 한 가지 지표만 관리하는 일이 아니었습니다. 매출과 손익을 확인하고, 차량을 재배치하고, 쏘카존 주차비가 과하게 나가지 않도록 관리했습니다. 매출이 높아 보여도 주차비가 많이 나가면 실제 손익은 달라질 수 있었습니다. 차량을 많이 두면 이용 기회는 늘 수 있지만, 수요가 충분하지 않으면 유휴 차량과 비용이 함께 늘어날 수도 있었습니다. 그래서 지역 운영을 하면서는 매출과 비용을 따로 보기보다 함께 봐야 했습니다. 숫자 하나를 개선하는 것이 아니라 지역의 수익 구조를 이해해야 했습니다. 조직 개편 이후 데이터와 기획을 만나다 조직 개편 이후 지역사업팀에서는 대시보드 제작과 데이터 분석을 담당했습니다. 사업 기획, 제휴 제안과 관련된 일을 함께 경험했습니다. 현장 운영을 하며 어떤 숫자가 필요한지 어느 정도 알게 된 뒤라서, 대시보드를 만들 때도 단순히 지표를 나열하기보다 실제 의사결정에 필요한 정보를 먼저 생각하게 됐습니다. 누가 이 화면을 보는지, 이 숫자를 보고 어떤 행동을 해야 하는지, 기간과 지역을 어떻게 비교해야 하는지 고민했습니다. 데이터를 보는 일과 사업을 운영하는 일이 점점 가까워졌습니다. 차량의 위치를 바꾸면 질문도 달라졌다 차량 공급 업무는 차량 숫자를 맞추는 일처럼 보일 수 있습니다. 하지만 실제로는 지역의 수요와 공간, 매출과 비용, 운영 가능성을 함께 판단하는 일이었습니다. 개발자로 일할 때는 센서와 데이터가 어떻게 연결되는지 궁금했습니다. 쏘카에서 차량을 운영할 때는 데이터가 실제 배치와 비용 조정으로 어떻게 이어지는지 보게 됐습니다. 다음 글에서는 다시 사업운영팀으로 이동해 차량 공급을 더 넓은 관점에서 맡았던 이야기를 적어보겠습니다. 신차 구매와 사업모델 변경에 따른 차량 배분, 그리고 재배치 실적을 보기 위한 새로운 기준을 만들었던 경험입니다. 차량 한 대의 위치를 고민하면서, 사업을 움직이는 숫자는 현장과 떨어져 있지 않다는 것을 배웠습니다.
사업을 직접 해본 뒤, 회사의 사업 구조가 궁금해졌습니다. 스마트스토어와 유튜브를 운영할 때는 상품과 콘텐츠를 직접 고르고 결과를 확인했습니다. 규모는 작았지만 매출과 비용, 고객의 반응이 서로 연결돼 있다는 점은 분명히 보였습니다. 그렇다면 더 큰 회사는 어떻게 일할까. 차량을 여러 지역에 배치하고, 이용자에게 서비스를 제공하고, 그 과정에서 생기는 비용과 매출을 어떻게 관리할까. 이 질문을 품고 쏘카에 입사했습니다. 사업이 돌아가는 현장부터 보게 됐다 처음 배치된 곳은 지역사업팀이었습니다. 제가 맡은 일은 쏘카존 장애를 처리하고, 현장 실사를 요청하고, 차량 탁송을 등록하고 모니터링하는 일이었습니다. 화면 속 숫자만 보는 업무가 아니라, 실제 쏘카존과 차량의 상태가 서비스에 어떤 영향을 주는지 확인하는 일이었습니다. 차량이 있어야 할 곳에 있는지, 쏘카존에 문제가 생기지는 않았는지, 필요한 조치가 제때 진행됐는지를 계속 확인했습니다. 한 가지 업무처럼 보여도 요청과 확인, 처리와 공유가 이어지는 여러 단계가 있었습니다. 반복되는 일을 흐름으로 정리하다 업무를 하다 보니 비슷한 문제가 반복됐습니다. 장애가 접수되고, 담당자가 확인하고, 조치가 진행되고, 결과가 공유되는 과정이 매번 조금씩 달랐습니다. 처음에는 주어진 일을 처리하는 데 집중했습니다. 하지만 같은 내용을 여러 번 확인하고, 진행 상황을 다시 물어보는 일이 이어지면서 프로세스를 정리할 필요가 보였습니다. 쏘카존 장애처리 업무를 하면서 요청부터 완료까지의 흐름을 살펴봤습니다. 어떤 정보가 처음부터 필요한지, 어느 단계에서 처리가 멈추는지, 완료 여부를 무엇으로 판단할지 정리했습니다. 이때부터 운영 업무를 단순히 많이 처리하는 것보다, 일이 흐르는 구조를 만드는 데 관심이 생겼습니다. 한 번의 문제를 해결하는 것도 중요하지만, 다음 사람이 같은 문제를 더 쉽게 처리할 수 있게 만드는 일도 중요했습니다. 대시보드로 보이지 않던 것을 보이게 만들다 이후 사업운영팀으로 이동했습니다. 이곳에서도 쏘카존 장애처리 업무를 맡았고, 장애처리 현황을 한눈에 볼 수 있는 대시보드를 만들었습니다. 대시보드를 만들기 전에는 각각의 건을 따로 확인해야 했습니다. 어떤 장애가 열려 있는지, 얼마나 오래 처리되지 않았는지, 어느 지역에 요청이 몰려 있는지 한 번에 파악하기 어려웠습니다. 업무에 필요한 항목을 정리하고, 상태와 기간을 구분하고, 팀이 함께 볼 수 있는 화면으로 만들었습니다. 화면 하나가 모든 문제를 해결해주지는 않았지만, 어디부터 확인해야 하는지 판단하는 데 도움을 주었습니다. 운영팀에서 고지서 회수 프로세스를 정리한 일도 기억에 남습니다. 회수되지 않은 고지서를 찾고 처리하는 과정을 정리하면서 비용을 줄이는 데도 연결됐습니다. 저는 이때 데이터가 멋진 분석 결과로만 쓰이는 것이 아니라는 점을 배웠습니다. 지금 처리해야 할 일을 찾고, 누락된 건을 발견하고, 팀이 같은 기준으로 상황을 보는 데에도 데이터가 쓰였습니다. 업무를 하면서 관심의 방향이 바뀌었다 처음 쏘카에 들어왔을 때만 해도 사업운영 업무를 하게 될 것이라고 구체적으로 생각하지 않았습니다. 사업이 어떻게 돌아가는지 궁금해서 들어왔고, 현장 업무를 맡으며 하나씩 알아갔습니다. 그 과정에서 데이터와 대시보드를 자주 만났습니다. 어떤 숫자를 볼지 정하고, 어떤 상태를 구분할지 정하고, 팀이 실제로 사용할 수 있는 화면으로 만드는 일이 재미있었습니다. 개발을 배울 때는 장치에서 데이터를 가져와 소프트웨어로 처리했습니다. 쏘카에서는 사업 현장에서 발생하는 업무 데이터를 정리해 운영에 활용했습니다. 기술은 달랐지만, 흩어진 정보를 구조화하고 다음 행동으로 연결한다는 점은 닮아 있었습니다. 사업운영팀에서 지역사업팀 차량 공급 관리로 쏘카에서의 업무가 쌓이면서 지역 사업 공급 및 관리를 경험해보고 싶어졌습니다. 이후 지역사업팀으로 이동했습니다. 다음 글에서는 지역 사업팀의 차량 공급을 담당하며 차량을 어디에 배치할지 고민했던 이야기를 적어보겠습니다. 신차 배치부터 차량 재배치, 주차비 관리와 지역 운영까지, 차량 한 대의 위치가 사업 숫자와 어떻게 연결되는지 경험한 시간이었습니다. 돌아보면 쏘카에서 처음 배운 것은 거창한 사업 전략이 아니었습니다. 현장의 문제를 발견하고, 반복되는 일을 정리하고, 필요한 정보를 함께 보는 일이었습니다. 그 경험이 다음 역할을 맡을 수 있는 바탕이 됐습니다.
Most knowledge still lives in PDFs, spreadsheets and scanned files — formats that break when you try to feed them into an LLM or RAG pipeline. Tables collapse, formulas get mangled, and reading order is lost. Markdown has become the de-facto input format for AI workflows: it is compact, keeps heading hierarchy, and preserves table structure. The hard part is getting reliable conversion. What a good converter needs Layout-aware extraction — multi-column PDFs must keep the right reading order Table preservation — real Markdown tables, not flattened text OCR for scans — scanned documents need layout-aware OCR, not raw text dumps Formula & image handling — math should survive as LaTeX, images as references Tool we use Markovo converts PDFs, Excel, scanned documents, audio and video into clean Markdown ready for LLM and RAG workflows. You can upload a file or paste a public URL — no signup needed to try. For teams building knowledge bases or RAG pipelines, solid document-to-Markdown conversion removes one of the biggest data-quality bottlenecks. Clean input → better embeddings → better answers.
첫 회사에서 오래 일한 뒤 퇴사한 것은 아니었습니다. IoT 소프트웨어 개발자로 약 5~6개월 정도 일했을 때, 대학 동기와 함께 사업을 시작했습니다. 지금 돌아보면 꽤 갑작스러운 선택이었습니다. 개발자로 첫발을 뗀 지 얼마 되지 않았고, 그렇다고 사업을 잘 알고 있던 것도 아니었으니까요. 그래도 그때는 직접 해보고 싶은 마음이 있었습니다. 회사 안에서 소프트웨어를 만드는 일과, 내가 고른 상품이나 콘텐츠를 세상에 내놓는 일은 어떻게 다른지 궁금했습니다. 개발자를 시작한 지 얼마 되지 않았을 때 첫 회사에서의 시간은 짧았지만, 새로운 일을 시작하기에는 충분히 많은 생각을 하게 만든 시간이었습니다. 교육에서 배운 내용을 실제 업무로 연결해보며 개발자의 생활을 경험했습니다. 한편으로는 소프트웨어를 만드는 일 바깥에서 어떤 일이 벌어지는지도 궁금했습니다. 누가 이 제품을 필요로 하는지, 사람들은 무엇을 보고 구매하는지, 매출이 생기면 비용은 어디에서 빠져나가는지 같은 질문이 생겼습니다. 당시에는 이 질문을 사업관리나 비즈니스 분석이라는 말로 부르지 않았습니다. 그냥 직접 확인해보고 싶었습니다. 마침 대학 동기와 비슷한 생각을 나눌 기회가 있었고, 함께 작은 사업을 시작해보기로 했습니다. 데이터를 보고 상품을 골라보기 처음 시작한 일은 스마트스토어였습니다. 상품을 그냥 감으로 고르기보다, 데이터를 통해 판매할 아이템을 찾아보려고 했습니다. 어떤 상품이 관심을 받고 있는지, 비슷한 상품은 어떻게 판매되고 있는지, 사람들이 어떤 표현으로 검색하는지 살펴봤습니다. 지금 생각하면 거창한 분석은 아니었습니다. 그래도 데이터를 보고 아이템을 고르고, 실제로 등록하고, 반응을 확인하는 과정을 직접 경험했습니다. 개발을 배울 때는 입력값을 넣고 결과를 확인하는 과정이 익숙했습니다. 스마트스토어에서는 상품을 올리고 고객의 반응과 판매 결과를 확인했습니다. 대상은 달랐지만, 가설을 세우고 결과를 확인한다는 점은 비슷하게 느껴졌습니다. 물론 숫자만 보면 되는 일은 아니었습니다. 상품 설명을 어떻게 쓰는지, 사진을 어떻게 보여주는지, 가격과 배송 조건을 어떻게 정하는지에 따라 결과가 달라졌습니다. 데이터는 방향을 잡는 데 도움을 줬지만, 실제 운영에는 여러 판단이 함께 필요했습니다. 흥미로운 기사를 영상으로 만들어보기 스마트스토어와 함께 유튜브 채널도 운영했습니다. 흥미로운 기사나 소식을 주제로 정하고, 내용을 정리해 영상으로 만들었습니다. 직접 영상을 편집하고 업로드하면서 어떤 이야기를 사람들이 보고 싶어 하는지도 고민했습니다. 개발 업무에서는 코드와 장치가 중심이었다면, 유튜브에서는 주제와 전달 방식이 중심이었습니다. 같은 내용도 어떤 순서로 보여주고 어떤 제목을 붙이느냐에 따라 다르게 받아들여졌습니다. 처음부터 능숙했던 것은 아닙니다. 영상을 만들고 올린 뒤 조회수나 반응을 확인하면서 조금씩 수정했습니다. 무엇을 만들지 정하고, 만들어서 내놓고, 결과를 보고 다음 선택을 바꾸는 과정이 반복됐습니다. 사업을 정리하며 남은 질문 사업을 오래 이어가지는 못했습니다. 스마트스토어와 유튜브 채널을 정리하면서, 직접 사업을 시작하고 운영해본 시간도 마무리됐습니다. 결과만 보면 짧은 경험일 수 있습니다. 하지만 그 기간 동안 돈이 들어오고 나가는 과정을 직접 보았고, 사람들이 어떤 상품과 콘텐츠에 반응하는지도 가까이서 확인했습니다. 무엇보다 회사 밖의 숫자가 궁금해졌습니다. 기업은 어떤 방식으로 돈을 벌고, 비용을 어디에 쓰고, 여러 팀의 활동을 어떤 기준으로 판단할까. 작은 사업을 해본 뒤에는 이 질문이 더 구체적으로 느껴졌습니다. 그때부터 사업이 돌아가는 방식을 가까이에서 보고 싶다는 생각이 생겼습니다. 개발자로서 기술을 만드는 일과, 사업 안에서 우선순위를 정하고 자원을 배분하는 일 사이에는 어떤 연결이 있는지도 궁금했습니다. 다음에는 쏘카로 갑니다 돌아보면 이 시기의 사업 경험은 성공한 창업 이야기라기보다, 제가 무엇을 궁금해하는지 알게 된 시간에 가깝습니다. 상품을 고를 때 데이터를 봤고, 영상을 만들 때 사람들의 반응을 봤습니다. 직접 운영해보니 매출과 비용, 고객의 반응과 실행 과정이 따로 떨어져 있지 않았습니다. 하나를 바꾸면 다른 부분도 함께 움직였습니다. 사업을 정리한 뒤에는 쏘카의 업무 방식과 사업 구조가 궁금해졌습니다. 쏘카는 어떻게 돈을 벌고, 차량과 주차비 같은 비용을 어떻게 관리할까. 그래서 쏘카에 입사하게 됐습니다. 다음 글에서는 쏘카에서 처음 맡았던 업무와, 반복되는 운영 업무를 프로세스와 대시보드로 정리하게 된 이야기를 적어보겠습니다.