Bringing a navigation service in-house
For a large navigation service run by a telecom carrier, we took part in moving development that had leaned heavily on outside parties into the company's own engineering organization. The service guides routes with real-time traffic data and puts hazard alerts, public transit search, and estimated travel times to frequent destinations in one app. It has a very large user base, so even a small defect reaches the route guidance of many drivers. Our share was building and maintaining core features such as route guidance, the map screen, and the search-to-guidance flow, along with stabilization and verification, across several versions of cross-team code review and short, repeated development cycles.
Bringing in-house the development that had leaned on outside parties
Bringing navigation in-house means moving development areas that depended heavily on outside parties into the company's own engineering organization. Many drivers were already using the app every day, so the service had to keep running while the people responsible for its development changed. We took part in this work across several versions, handling core feature implementation and maintenance.
Core screens that run from search to route to guidance
We worked on the main features of a large navigation app: route guidance, the map screen, and the flow from search to guidance. A driver finds a destination, picks a route, and then follows the guidance, and those three steps run as one flow. Updates in the same period split the maps, streaming them for nearby places and public transit search while using maps stored on the device for route guidance, and put travel times to frequent destinations such as home and work on the first screen. With so many real users, stability and handling of exceptional cases were treated as seriously as the features themselves.
Cross-team code review and change-history management
In the in-house development, cross-team code review and change-history management (configuration management) were standard procedure. Code quality was owned by the team rather than by individuals, and collaboration was anchored on what changed and when. With an agile approach, work was split into short cycles, and through repeated issue tracking and schedule coordination the team worked out a process that fit it.
Stabilization by developers from two platforms working as one team
With too few developers for the navigation app, we worked as one team with developers who had been on the other platform. Differences between the platforms were shared openly, and problems were solved by bringing in each side's point of view. Because even a small defect reaches many drivers at once, stabilization and verification got as much care as feature development. When the project wrapped up, every member of the team received a commendation.
Highlights
Moving development of a large, live navigation service into the company's own process
Development and stabilization of route guidance, maps, and search
Cross-team code review, change-history management, and short iterative cycles
Insights
GA4 client_storage: 'none'은 정말 쿠키를 막을까?
두 달 전 이 블로그에 「GA4 쿠키 없이 쓰기」라는 글을 썼습니다. clientstorage: 'none' 으로 쿠키 저장을 끄고, 자체 분석이 쓰던 익명 ID 를 clientid 로 넘기면 쿠키 0개로 GA4 를 쓸 수 있다는 내…
GA4 Measurement Protocol: gtag.js 없이 서버에서 이벤트 보내기
랜딩 페이지의 전송량을 파일 단위로 쪼개 보다가, 가장 큰 파일이 우리 코드가 아니라는 것을 알았습니다. Google Analytics 의 gtag.js 였고, 방문 한 번에 176KB 를 받고 있었습니다. 페이지 전체가 1,094K…
중소 제조업 AI 도입 순서: DX를 먼저 끝내야 할까?
공장을 가진 중소·중견 제조기업 16만여 곳 가운데 스마트공장을 도입한 곳은 19.5%입니다. 회사가 작을수록 이 비율은 더 떨어집니다. 중소벤처기업부가 2025년 4월에 낸 제1차 스마트제조혁신 실태조사 결과입니다. 그림: 기업 규…
Next.js loading.tsx와 404: 버튼이 화면보다 먼저 살아나게 하기
관리 화면 왼쪽 위에 사이드바를 접고 펴는 ☰ 버튼이 있습니다. 폭 하나 바꾸는 버튼인데, 대시보드에서 누르면 2초 넘게 아무 반응이 없었습니다. 레이아웃만 바꾸는 일이 왜 이렇게 오래 걸리는지부터 들여다봤습니다. Next.js 16…