Tap to restart

# Situation 상황- 로봇 관제 플랫폼 내에 자율주행 로봇의 전역 경로 생성의 바탕이 되는 지도를 스마트폰을 활용해서 실제 로봇을 움직여 가면서 만들 수 있는 기능 개발을 담당했다.- 구현 뒤에 테스트를 위해서는 실제 로봇을 끌고 테스트 장소에 갔다 왔다 하는데만 2시간이 걸렸다. 매번 실제 로봇으로 테스트를 할 수가 없다보니 버그가 뒤늦게 QA 때 발견되었다.- 버그를 수정하면 QA 담당자가 다시 로봇을 끌고 나가서 테스트하는 것이 반복되었다. QA를 모두 통과하는데 보통 3~4일이 걸렸다. # Task 과제- 실제 로봇을 끌고 밖에 나가지 않고도 손쉽게 테스트할 수 있어야 했다.  # Action 행동- 주말에 시간을 내서 가상 로봇 이동을 구현하기로 마음먹었다.- 로봇이 가상으로 이동하면 되..

# Situation 상황- 자율주행 이동 로봇은 전역 경로 계획Global Path Planning(우리가 지도앱으로 출발지와 도착지를 입력했을 때 나오는 경로를 생각하면 된다)을 바탕으로 자율 주행을 한다.- 기존 전역 경로 계획은 타팀에서 만든 패키지를 활용해 OSM(Open Street Map) 파일을 바탕으로 경로 계획을 했다.- 대규모 지역에서 서비스를 하게 되면서 OSM 파일이 기존 다른 서비스 지역과 비교해 10배 이상으로 커졌다. 전역 경로 계획 시 OSM 파일을 읽어서 그래프 형태로 메모리에 올리는 전처리 과정이 오래 걸리게 되어서 첫 경로 계획은 3초 이상 소요되었다. - 더 큰 지도 파일을 사용할 경우 당연히 전처리 과정이 더 오래 걸려서 첫 경로 계획은 더 오랜 시간이 필요했다.-..

# Situation 상황- 입사 뒤 보니 테스트 코드를 작성하지만 테스트 자동화가 되어 있지 않았다.- PR(Pull Request) 리뷰 때 테스트가 모두 통과되는지 살펴보려면 매번 브랜치를 변경해서 테스트를 돌려야 했다.- 테스트를 실행하는 과정이 번거로워서 지나치게 되었고, 기존 테스트가 실패하는 코드가 통합 개발 브랜치(develop)에 병합되는 일이 발생했다. # Task 과제- PR 오픈 시에 리뷰 전에 미리 기존 테스트와 새로 추가된 테스트가 모두 통과하는지 자동화가 필요했다. # Action 행동- 깃허브 액션을 활용해서 PR 오픈 시 테스트를 자동화했다. # Result 결과- 매번 일일이 브랜치 변경해서 테스트를 돌릴 필요가 없게 되었다.- PR 리뷰 전에 테스트가 실패할 경우 PR ..

# Situation 상황- QA 시작일 전날 오후에 staging 서버에 해당 스프린트 작업분 코드를 반영해서 배포했다.- QA 시작 첫날 많은 버그가 나왔다.- 개발자와 PO, PD, QA 등 담당자들이 서로 다르게 기획을 이해해서 뒤늦게 이슈가 되는 경우가 있었다.  # Task 과제- 버그를 줄일 필요가 있었다.- 서로 같게 개발 스토리를 이해하고 있는지 확인하는 단계가 필요했다.  # Action 행동- 전 회사에서 개발자 프리뷰란 이름으로 QA 시작일에 개발자가 직접 기능을 소개하는 시간을 가졌던 것이 떠올랐다.- 동료 팀원과 함께 팀 내에 개발자 시연을 제안했다.- 스프린트 프로세스에 개발자 시연이 추가되어, 가능하면 QA 전에 늦어도 QA 시작일에는 시연을 진행하게 되었다.- 시연 방법은 ..

# Situation 상황- 기존 어드민이 있었지만 기능이 제한적이었다.- 프런트 엔드 개발자가 부족해서 내부 구성원들을 위한 백오피스 기능 개발은 불가능한 상황이었다.- 타 팀에서 들어온 이슈를 백엔드 개발자가 운영 데이터베이스에 접속해서 변경 처리하는 경우가 많았다.- 백엔드 개발자들은 이슈를 처리하느라 기능 개발 시간이 부족해 추가 근무를 하게 되는 상황이 자주 발생했다.- 백엔드 개발자가 회의에 참여하거나 휴가를 쓰는 경우 이슈 처리가 지연되었다. # Task 과제- 백엔드 개발자가 아닌 누구나 이슈를 처리할 수 있는 백오피스 기능이 필요했다. # Action 행동- 백엔드 프레임워크로 장고 프레임워크를 사용하고 있었고 장고는 장고 어드민이란 기본적인 백오피스 기능을 제공했다. - 팀 내 장고 어..

# Situation 상황타 팀으로부터 요청이 여러 슬랙 채널에서 "살펴봐주세요", "이것 좀 해결해주세요." 등 짧은 메시지와 함께 @ 멘션 기능을 통해서 들어왔다. 그러다보니 다음과 같은 문제가 발생했다.- 공식 요청 채널이 없으니, 슬랙 DM을 통해서 요청이 오는 경우가 많았다.- 한명한테 요청이 몰리는 경우가 많았다.- 누가 어떤 요청을 받아서, 얼마나 처리하고 있는지 팀원 전체가 파악할 수 없었다.- 요청 내용을 파악하기 어려웠다. 요청을 파악하려면 슬랙 스레드 메시지 전체를 읽어야지만 알 수 있었다.- 요청에 중요도 긴급도 등 정보가 없었다. 따라서 모든 문제를 요청 받은 즉시 해결하게 되어 업무 흐름이 끊겼다. # Task 과제- 요청을 한 곳에 모은다.- 요청자는 요청 내용, 중요도, 긴급..

# Situation 상황예전에 로봇 플랫폼 서버와 로봇이 주행하게 될 전역 경로 생성 서버가 따로 있었다. 전역 경로 생성 서버가 따로 있는 것이 비효율적이라 로봇 플랫폼 서버와 전역 경로 생성 서버를 하나로 합치면서 코드도 한 저장소로 합치게 되었다. 전역 경로 생성 개발자는 다른 팀이었는데, 백엔드팀 코드 저장소에서 같이 개발하게 되었다. 하지만 전역 경로 생성 개발자는 장고에 대한 이해, 테스트 작성 등 백엔드 개발 관련 지식이 부족했다. 전역 경로 담당자는 예전보다 개발하는데 더 오래 걸리게 되었고, 나와 만날 때 다시 과거로 돌아가 서버 분리를 하면 좋겠다는 이야기를 자주했다. # Task 과제과거로 다시 돌아가 전역 경로 생성 서버를 따로 두는 것은 비효율적이었다. 로봇 플랫폼 서버가 전역 ..

# Situation 상황사내에서 DRF로 개발하고 있으며, Github Action과 AWS ECR, ECS를 활용해서 배포를 하고 있다. Github Action에서 배포 실행 버튼을 누르면 아래와 같은 순서로 배포가 진행되었다.1. 선택한 브랜치의 코드를 바탕으로 도커 이미지 생성해서 ECR로 이미지 업로드2. 1번에서 업로드한 ECR 이미지로 API 서버, 워커 서버 등 배포 진행 # Task 과제1번이 프로젝트가 커지고 외부 라이브러리나 팩키지 설치가 많아질수록 속도가 오래 걸렸다. 특히 PostGIS를 쓰게 됨에 따라 관련 해서 우분투에 libgdal-dev 팩키지 설치가 필요해졌는데 이 팩키지 설치만 몇 십초 씩 걸려 긴 시간이 소요되었다. 어떻게든 속도 개선 작업이 필요했다. # Actio..