데이트래블 - DayTravel

모든 개발자가 떠난 서비스를 물려받다 내가 온리유에 합류했을 때 상황은 이랬다. 모든 개발자가 이미 퇴사한 상태. 개발을 모르는 대표가 혼자 버티고 있었다.인수인계? 그런 건 없었다. 도메인 호스팅 계정조차 찾는 데 이틀이 꼬박 걸렸다. 코드는 여러 개발자가 'MVP 빨리 만들기'라는 목표로 던져놓은 파편들뿐이었다.2명이서 서비스를 처음부터 다시 만들기로 했다. 다만 기존 고객은 유지해야 했기에, 레거시를 하나씩 분석하며 점진적으로 전환하는 방식을 택했다. 진짜 문제는 배포 자체가 수동이었다는 것 당시 배포 프로세스를 보고 놀란 건, 아니 프로세스라고 부르기도 뭐한 수준이었다.EC2에 SSH로 직접 접속git pullnpm buildpm2 restart끝이었다. 문서도 없고, 롤백 방법도 없었다. 그냥..

배포가 느려진 진짜 이유는, 코드 때문이 아니었다 요즘 들어 가장 많이 드는 고민은 이것이었다. “왜 이렇게 배포가 오래 걸릴까?” 매일같이 기능은 쌓여가고, 팀원들도 쉼 없이 개발하고 있는데막상 실제 서비스에 반영되는 속도는 점점 느려지고 있었다. 순수 개발보다 더 오래 걸리는 건 QA였다 우리가 이 문제를 뜯어보며 놀란 건,실제로 순수하게 ‘코드 짜는 시간’은 그렇게 오래 걸리지 않는다는 사실이었다. 정말 시간을 잡아먹는 건, 그 이후의 과정이었다. 개발 완료 → develop 배포기본 QA → 디자인 QA디자인 QA 반영 후 다시 QA버그 수정 후 QA마지막으로 프로덕션 배포 이 과정 속에서 “지금 어떤 QA가 어디까지 되었는지” 파악도 어렵고,한 단계를 넘기면 꼭 예기치 못한 에러가 다시 터지..

기능이 아닌 가치를 만드는 개발을 하고 있습니다 온리유 CTO, 개발자로서 기록을 시작합니다 저는 결혼정보회사 온리유의 CTO 개발자로 일하고 있습니다.사람을 연결하는 일은 생각보다 훨씬 복잡합니다.특히 온리유처럼 ‘가볍지 않은 만남’을 추구하는 브랜드에선,단순히 매칭 시스템을 구축하는 것 이상의 고민이 필요했습니다. 저는 그 고민의 기록을 남기기 위해 블로그를 시작합니다. 저는 왜 온리유를 만들었는지 돌아보고 있습니다 온리유는 기존 소개팅 시장에 대한 문제의식에서 시작했습니다.소개팅 앱은 너무 가볍고, 결혼정보회사는 너무 비싸고 형식적이었습니다.진지한 만남을 원하는 괜찮은 사람들이 “쓸 서비스가 없다”고 말할 때,저는 그 간극을 기술로 풀어낼 수 있을지 고민했습니다. 저는 ‘지인이 소개해주는 듯한 신..