[Interview] 택시비 아끼는 유일무이 막차 알림 서비스 : 앗차(ATCHA)

12 min readJun 26, 2025

안녕하세요! 디자이너와 프로그래머가 만났을 때, 디프만 17기 운영진입니다.
16기에서 최우수상과 인기상을 동시에 수상한, 많은 관심과 사랑을 받았던 서비스인 앗차를 소개하려 합니다! 서비스를 만들어 나갔던 과정을 더 자세히 들여다보기 위해 앗차의 제작자분들을 만나 다양한 비하인드 스토리를 들어보았어요.

안녕하세요! 먼저 간단한 자기소개를 부탁드려요:)

남X영(Design)
2~3년차 프로덕트 디자이너 남X영입니다. 앗차로 인기상과 최우수상을 수상할 수 있었는데, 좋은 프로젝트를 만들 수 있어서 뿌듯합니다.

신민석(Android)
안녕하세요. 16기 6팀에서 안드로이드 개발을 담당했던 신민석입니다.

최원준(Server)
안녕하세요. 16기에 앗차 6팀에서 서버 파트장으로 활동했던 최원준이라고 합니다.

Part 01. 앗차(ATCHA)가 궁금해요!

앗차(ATCHA)는 어떤 서비스인가요?

남X영(Design)
유일무이한 막차 알림 전용 서비스예요. 저희 팀에 경기도권에 거주하는 분들이 계셨는데, 막차를 놓치는 경우가 종종 있었거든요. 신나게 놀다가 막차 시간을 깜빡하고 결국 택시를 타야 했던 경험이 있어서, 이런 문제를 해결하기 위해 적시에 출발 알림을 주는 서비스로 기획했습니다.

최원준(Server)
앗차는 막차 알림 서비스로 술자리에서 즐겁게 시간을 보내면서도 중간중간 막차 시간을 찾고 언제 출발해야 하는지 확인해야 하는 불편함에서 시작된 프로젝트였어요. 본인의 집을 미리 설정해 두면 막차 시간을 미리 계산해서 언제 출발해야 하는지 알림을 주는 서비스입니다.

신민석(Android)
기존 지도 서비스를 이용하며 사용자가 번거롭게 느낄 수 있는 뎁스를 최소화하고, 막차 조회부터 알림 기능까지 한 번에 제공하는 서비스입니다.

이번 프로젝트 주제가 너무 재미있고 인상 깊었는데요,
막차 알림이라는 아이디어는 어떤 방식으로 기획되었나요?

남X영(Design)
팀원 모두가 공감할 수 있고, 문제를 뾰족하게 해결할 수 있는 서비스를 만들고자 했어요. 말씀드린 것처럼 팀 내에 경기도권에 거주하는 분들이 많아서 실제로 막차를 타는 데 어려움이 있었어요.
다양한 불편한 경험들이 공유하면서 자연스럽게 공감대가 형성되었고, 이를 해결할 수 있는 ‘막차 알림’이라는 서비스를 기획하게 되었어요. 주제를 정하는 데 많은 시간을 들였고, 기획 방향도 여러 차례 수정하며 쉽지 않았지만, 결과적으로는 잘한 선택이었다고 생각해요.

Part 02. 앗차(ATCHA)의 기술적 도전

프로젝트를 진행하면서 가장 기억에 남는 어려움이 있을까요? 있다면 어떤 방식으로 해결하셨나요?

신민석(Android)
개발자 입장에서 항상 기획된 기능이나 디자인을 최대한 구현해 드리고 싶거든요. 근데 기본적으로 안드로이드에서 기능 제공 자체를 안 하면 구현이 어려울 때가 있어요. 저희가 처음 구현하려고 했던 게 잠금화면 알림바로 막차를 타기 위해 출발해야 하는 시간이 얼마나 남았는지 사용자에게 전달하는 기능이었어요. 아이폰으로 따지면 배민 시켰을 때 도착까지 시간이 얼마나 남았는지 진행도가 표시되는 것처럼요. 그래서 해당 기능을 구현하려고 안드로이드 팀원들과 열심히 관련 문서를 찾아봤는데 안드로이드 자체에서 지원을 안 하는 형식이라, 최대한 사용자가 잠금을 열지 않아도 화면에 보이게 하려고 잠금화면 자체를 커스텀해서 남은 시간이 보이도록 구현했습니다.

최원준(Server)
저희 팀원 분이 막차 로직을 직접 구현해 주셨는데, 공공 데이터 API를 쓰다 보니 완벽하지가 않았어요. 정부 기관에서 만들다 보니까 데이터를 제대로 주지 않는 부분도 있고, 지하철 노선도 같은 경우는 상행/하행의 개념이 각각 노선마다 다 다르기 때문에, 어떻게 하면 최적의 경로를 유저에게 제공할 수 있을 지가 굉장히 어려웠어요. 네이버나 카카오 같은 좋은 서비스 API를 사용하면 해결할 수 있지만, 비용적인 문제가 있어서 저희는 공공 데이터 API를 활용했었는데 이런 부분에서 매끄럽지 않게 계산되는 부분이 많았어요. 그래서 직접 하나하나 경로들을 확인해 보면서 엣지 케이스를 찾고 이 데이터를 DB에 넣어주는 작업을 진행했어요.
개인적으로 어려웠던 점은 푸시 알림 구현 부분이었어요. 저희 서비스는 FCM 토큰을 통해 FCM 서버로 푸시 알림을 전송하는 구조인데, 스케줄러가 특정 시간에 지속적으로 동작하면서 알림 발송 여부를 판단하고 전송하는 방식으로 구현되어 있었습니다. 그런데 서버가 멀티 서버로 구축되어 있다 보니, 두 개의 서버에서 동시에 스케줄러가 실행되면서 푸시 알림이 중복 전송되는 문제가 발생했습니다. 이 문제를 해결하기 위해 많이 고민했고, 최종적으로 레디스 분산락을 활용하여 락을 걸어서 처리하는 방식으로 해결했습니다. 이 과정에서 와치독이라는 새로운 데몬 스레드를 직접 구축했던 경험이 가장 인상 깊게 남아있습니다.

다양한 어려움이 있었던 것 같네요! 기술적인 어려움 외에 일정이 밀리는 등의 어려움은 없었나요?

남X영(Design)
일정상 어려웠던 것들이 있었는데, 기획 쪽에서는 어렵지 않았고, 그 후에 작업을 진행할 때 스펙이 커서 일정상 힘들었던 것 같습니다.

신민석(Android)
안드로이드가 배포를 하기 위한 정책이 바뀌어서 초기 일정을 빡빡하게 잡았더니 다들 열심히 했지만 수정사항도 조금씩 있고 살짝씩 밀리긴 했었어요. 런칭데이에 플레이스토어에 올라와 있는 게 저희 팀 목표였기 때문에 일단 최소한의 MVP를 완성해서 심사를 맡기고, 추후 바뀌거나 추가되는 부분은 수정해서 업데이트를 하는 방식으로 일정을 유동적으로 조율했던 것 같습니다. 지금은 이렇게 편안하게 말하는데 정책이 바뀌고 처음 출시해 보는 거라서 그 당시에는 얼마나 걸릴지 불안했고, 한 번에 통과가 안됐으면 어땠을지 아찔하네요.

Part 03. 앗차팀의 성장과 경험

이번 프로젝트를 진행하면서 가장 많은 성장을 한 부분이 어떤 부분이라고 생각하시나요?

최원준(Server)
디프만에서 다른 직군과 협업하면서 얻은 경험인 것 같아요. 개발자끼리 기술적인 고민이나 어려운 부분을 공유할 때는 개발 용어를 사용하면 되어서 비교적 소통이 쉬운 편이거든요. 그런데 디자이너와 협업을 하다 보니, 특정 기능이 구현되지 않을 때 그 이유를 설명하는 게 생각보다 어려웠어요. 기술 용어로는 디자이너분들이 이해하기 어려우니까, 개발자가 아니어도 이해할 수 있도록 어떻게 설명해야 할지 정말 많이 고민했어요. 이런 과정을 통해 다른 직군과의 협업 능력을 기를 수 있었던 게 저에게는 큰 성장 경험이었다고 생각해요.
또, 기술적으로는 새롭게 도전한 게 많았어요. 인프라도 GCP, NCP도 처음 해봤고, 레디스도 처음 해봤어요. 분산락도 해봤고요.

남X영(Design)
성장했다고 생각한 부분은… 성장했다기보단 회사 다니면서 특별하게 ‘내가 성장했구나’라고 생각할 수 있는 계기가 없었는데, 디프만에서 MVP를 만들면서 디자인적인 디테일을 만드는 역량이 늘었다는 걸 체감하게 되었던 것 같아요.

팀의 유일한 현직자 디자이너셨는데요,
팀을 위해 적극적으로 참여한 부분이 있을까요?

남X영(Design)
디자인 시스템을 주도해서 구축했어요. 디자인 시스템이 있어야 팀원들이 빨리 화면을 구현하는 게 가능할 것 같아서 필요한 부분을 먼저 체크해서 만들었습니다. 어떻게 구현되는지에 대해서는 경험이 있기 때문에 그런 부분에 있어서 개발자들과의 커뮤니케이션을 하려고 노력했어요.
백/프론트가 어떻게 일하는지 알기 때문에 데이터를 어디서 가져오는지 현직자가 아니면 이해가 어려운 부분인 것 같아서 데이터가 어떻게 표기되는지, UI에는 어떻게 반영되는지 확인했던 것 같습니다.

현직자이셨다면, 시간관리도 까다로웠을 것 같습니다.
직장과 병행하면서 힘든 점은 없었나요? 본인만의 시간 분배 팁이 있을까요?

남X영(Design)
그냥 개인 시간을 모조리 버리면 됩니다. 현직자가 아니고 저희 모든 디자이너분들이 개인 시간을 프로젝트에 투자하셨기 때문에… 현직자라 더 개인시간을 투자한 건 아닌 거 같아요. 하는 내내 너무 힘들었습니다….ㅎㅎㅎ
하지만!! 상을 받고 나니 너무 행복하더라고요. 치유가 되었어요. 좋은 결과로 보상을 받았기 때문에 굉장히 좋은 경험이었습니다.

확실히 4개월이라는 기간 동안 하나의 서비스를 런칭하려면 많은 시간이 필요한 게 맞는것 같습니다..ㅎㅎㅎ
그렇다면, 개발자분들께선프로젝트를 완료한 후 특정 테크스택 등 새롭게 공부해 보고 싶었던 것들이 있었나요?

신민석(Android)
일단 지금은 개인적인 공부보다 배포해 놓고 발견되었던 버그 사항을 수정하는 것이 먼저인 것 같고, 더 나중에 버그가 좀 잡혀서 오류가 잘 안 난다! 해서 여유가 좀 생기면 가까운 미래는 현재 코드에 멀티 모듈을 적용해 보고 싶습니다. 멀티 모듈이라는 건 디자이너 분들도 이해하기 쉽게 말하자면 앱을 큰 덩어리 하나로 만드는 게 아니라 기능별로 작은 부품처럼 나눠서 만드는 방식이에요!
그리고 이번에 안드로이드 One UI 7.0 버전이 업데이트되면서 대선 기간에 대선 실시간 현황을 표시해 주고 그러더라고요? 저희가 처음에 구현하려다 실패한 게 지금 나왔다고 하니까 호기심이 안 생길 수가 없더라고요. 어떻게 구현하는지 아직은 잘 모르지만, 꼭 구현해 보고 싶어요.

Part 04. 팀워크와 네트워킹

6팀은 디프만 활동 종료 이후 다 같이 MT를 다녀왔다고 들었어요! 마음이 맞는 동료를 찾은 것 같은데 비결이 궁금해요!

신민석(Android)
다른 팀도 그랬겠지만 저희 일을 진짜 열심히 했거든요. 다른 프로젝트나 동아리 할 때는 노는 비율도 어느 정도 있었는데 아무래도 직장 다니는 분들도 계시고 취준하는 분들도 계셔서 놀 거 다 놀면서 하면 절대 다 못 만들 것 같아서 다들 진짜 열심히 했던 것 같아요. 그래서 다 같이 열심히 일한 만큼 재밌게 놀자! 해서 엠티 계획을 잡았고 최종 발표 때 상까지 받으니까 더 뿌듯한 마음으로 놀고 온 것 같습니다.
사실 팀원 중 일부만 진심이었다면 잘 참여 안 하려고 하고 활동기간 끝나면 딱 끝! 이런 느낌이었을 것 같은데 뭔가 다 같이 열심히 했다는 게 중요한 것 같아요. 다 같이 진심이니까 끝나고 같이 놀러도 가고, 이렇게 될 수 있었던 건 오글거리는 말이지만 서로 이해하고 배려해서 아닐까요? 나만 바쁘게 하는 거 같고 얼른 끝났으면 좋겠고 이런 마음가짐이었다면 하기 싫어졌을 것 같은데 각자 상황을 이해해 주고 최대한 맞춰가면서 해서 활동 기간이 끝나고 프로젝트나 MT도 진행될 수 있었다고 생각합니다.

최원준(Server)
디프만 활동을 시작할 때 운영진분들이 임의로 팀을 만들어 주는데, 케미가 잘 맞는 사람들이 많아서 좋았어요. 프로젝트에 대해 같이 고민하고 오프라인으로 만나다 보니 온라인보다 많이 친밀감을 얻을 수 있었고 그게 기반이 되어서 좋은 결과를 얻었던 것 같아요.

Part 05. 예비 디퍼들에게 한마디

인터뷰의 마지막 코너입니다! 다음 기수의 디퍼들을 위해 한마디를 하는 코너에요:)
다음 기수의 디퍼들이 새로운 프로덕트를 만들며 고려하면 좋을 것들이 어떤 것들이 있을까요?

남X영(Design)
MVP를 만들어서 배포하는 게 흔치 않은 경험이고, 마음 맞는 팀원을 만날 수 있는 기회니 주저 말고 지원하셨으면 좋겠고, 솔직히 저도 붙을 줄 몰랐는데 붙어서 놀랐습니다. 혹시나 내가 실력이 부족한가? 의심하지 마시고 일단 떨어지더라도 넣어보고, 넣었다는 경험 자체가 중요하니까 용기 내서 지원하시면 좋겠습니다.

신민석(Android)
저는 지금까지 다른 사이드 프로젝트도 몇 개 해봤지만, 이번에 앗차를 개발하면서 가장 좋았던 점 중 하나는 제가 직접 사용할 수 있는 서비스였다는 점이에요. 학교 전공과목에서 진행했던 팀 프로젝트 과목은 주제가 완전히 자유롭지 않기도 했고, 나중에 회사를 가더라도 이미 만들어져 있는 서비스를 담당하게 될 확률이 더 크다고 생각해요.
그에 비해 16기 활동을 진행하는 동안 기획자가 없었기 때문에 다 같이 기획에 참여하고 아이디어를 냈던 만큼 서비스에 공감이 많이 됐어요. 저희 팀에 iOS 개발자분들이 합류했는데 아이폰 어플로 나온다면 제가 실제로 쓸 것 같아서 이런 부분들이 좋았던 것 같아요. 그래서 다음 기수에 디퍼들이 새로운 프로덕트를 만든다면, 개발이랑 디자인은 다들 너무 잘하실 거니까 본인들이 가장 공감되고 해결하고 싶은 문제가 확실한 서비스를 만드셨으면 좋겠습니다!

최원준(Server)
조바심을 안 가졌으면 좋을 것 같다는 생각이 드네요. 이게… 저희 팀도 프로젝트를 진짜 많이 갈아엎었거든요. 세 번 넘게 갈아엎었던 것 같아요. 그래서 설문조사도 두 번이나 받았거든요. 뭔가 시간에 쫓겨서 서로 마음에 안 드는데 프로덕트를 선정하는 것보다는 계속 치열하게 고민을 하고 한계점을 계속 같이 나눠본 다음에 선택하는 프로덕트가 좋은 결과로 이어질 수 있는 것 같다고 많이 느꼈어요. 그래서 조바심을 갖지 않고 진심으로 프로덕트를 어떻게 더 잘 만들 수 있을지 치열하게 논의하는 게 좋지 않을까 생각합니다.