2021 회고 / SPR (Self Performance Review)
둘이서 자율주행 킥보드를 만들어나가며 삽질한 것들, 배운 것들, 그리고 생각한 것들
Author : 이장후 / 자율주행팀
1. 예쁜 인프라 만들기
배경
•
딥러닝을 하기에 디어의 (인적, 금전적) 리소스와 인프라는 터무니없이 부족함. 이 개발속도와 이 인력이라면 10년을 쏟아도 안 될 것 같다는 확신이 있었음.
•
모델 하나 건드려 보려고 해도 모델작업 외에 너무 복잡하고 까다로운 과정들이 시간을 많이 소비함
•
2020년 11월부터 쌓여 있던 스파게티 코드들과 알 수 없는 방식으로 얽혀 돌아가는 패키지
•
SLAM 기반의 주행을 그만두고, Vision 중심 주행을 해야겠다고 결정됨. 나에게는 Jetson 보드 한 개 이외에 아무것도 주어진 것이 없는 상황
목표
•
비전 기반의 주행을 할 수 있도록 뼈대 만들기
•
적은 사람으로도 많은 일을 해결할 수 있도록 머신러닝 라이프사이클의 '문제정의, 모델학습, 모델 평가, 모델 배포' 큰 뼈대를 이해하고 따라하기
•
매우 적은 비용으로 학습 환경 만들기 : 500만원짜리 컴퓨터보다 더 빠르고 안정적인 환경 만들기
•
막무가내로 설치되어 있는 디어의 자율주행관련 프로그램/패키지 설치 과정을 문서화하기
기여 및 성과
•
비전시스템의 뼈대
◦
2020년 12월 : 딥러닝 기반 실질적으로 도움을 주는 로직 없음, 뎁스카메라 1개 사용
◦
2021년 12월 : 딥러닝 기반 Segmentation 모델 3개 (+Detection 모델 1개), 뎁스카메라 3개 사용
•
문서화
◦
환경문서 : OS 를 초기화한 다음, 현재 시스템까지 다시 구축하는 데 걸리는 시간 단축. 스스로도 노하우가 쌓였지만 문서와 함께한 시행착오가 큰 몫을 했다.
▪
(2020년 11월) 3달 → (현재) 1~3일
◦
환경문서 : 환경에 대해서 조금씩 알게 되는 내용이 생길 때마다 문서화, 공개할 수 있는 상태로 완성했다.
▪
용기를 내서 ROS 커뮤니티에 비슷한 문제로 고통받는 사람에게 1회 공유했다. :)
◦
코드문서 : 관리하는 모든 파일의 상단에 주석을 작성하는 것을 원칙으로 했다.
한글은 언제나 보기 좋다
•
표준화
◦
디어 비전시스템에서 모델 메타데이터 / 클래스 (레이블) 메타데이터를 다루는 방식을 표준화했다.
▪
과거 (2021년 8월까지) 에는 모델 훈련시, 검증시, 실제 실행 시 필요한 정보들이 혼재했었다. 사용하는 경로, 데이터 레이블, 레이블의 속성, 모델의 파라미터 등이 매우 혼잡하게 섞여 있었다.
before
before
▪
런타임 모델만 정확히 분리하고, 모델을 기준으로 자동으로 해당 모델에 맞는 파라미터와 클래스를 불러올 수 있도록 메타데이터와 파싱 기능을 재설계했다.
after
after
▪
json 형태로 존재하는 메타데이터터를 이용해 내가 실행시키고자 하는 모델이 훈련 당시 어떤 파라미터를 사용했는지, 어떤 데이터를 사용했는지, 어떤 augmentation 을 사용했는지 역추적할 수 있게 되었다.
◦
단일 프레임워크, 라이브러리 선택, 훈련은 클라우드와 노트북에서, 추론은 엣지에서 하도록 만들었다.
▪
google cloud 상에서 일어나는 다양한 기능들을 하나의 노트북으로 만들어 시스템을 최대한 단순하게 유지하도록 만들음. 포함하고 있는 기능들은 다음과 같다.
1.
모델 학습과정과 메트릭(metric) 시각화
2.
대용량 파일 압축 풀기
3.
Google Drive 에 학습 가능한 형태로 데이터 증강시켜 저장하기
4.
Google Drive 와 GCS 사이에서 대용량 데이터 주고받기
5.
모델 학습 결과 정성적으로 확인하기
▪
학습 파이프라인을 구동하는 데 준비하는 시간이 획기적으로 단축되었다.
•
2020년 11월~2021년 8월 : 3회 (백본1개, 아키텍처 1개, 데이터셋 변형 파이프라인 세트 없음)
•
2021년 8월~2021년 12월 : 52회 (백본5개, 아키텍처 3개, 데이터셋 변형 파이프라인 세트 15종)
◦
저렴하게 Google Notebook 에서 Google 의 TPU 를 사용할 수 있도록 만들었다.
▪
유연성 : 노트북에서 GPU 를 사용하는 경우와 TPU 를 사용하는 경우를 동적으로 선택할 수 있도록 만들었다.
▪
학습속도 : 사용하는 모델 (EfficientNet, Mobilenet) 기준 수백만원대 가격의 GPU 대비 학습속도를 4배 이상 빠르게 만들었다. (Colab Pro + 에서 제공하는 GPU 에 비해 batch size 를 2배 이상 높일 수 있게 되었다)
▪
저비용 : 3달간 8백만+ 파라미터 모델, 데이터 5만장, 150에폭 규모의 모델을 약 40번 이상 학습하고 실험해 보는 데 들어간 TPU 인프라 사용비용은 0원이었다. (Google COLAB 구독비용 약 5만원/월 제외)
◦
인지시스템의 경우 git 으로 세부기능을 명확히 분리할 수 있도록 만들었다.
◦
TensorFlow 1 / pytorch 기반의 코드들을 제거하거나 TensorFlow 2 기반 패키지, 코드스니펫으로 대체했다.
▪
학습된 모델을 다운로드받고 실행하는 과정 자체에서 소비되는 시간이 단축됐다.
•
2021년 2월~2021년 8월 : 테스팅한 모델 수 3개
•
2021년 8월~2021년 12월 : 테스팅한 모델 수 12개
배운 점과 회고
•
오픈소스는 인하우스의 인력을 아낄 수 있다는 점에서 매우 강력한 도구이지만, 요청사항이나 오류 등이 검토되기까지 매우 오랜 시간이 걸릴 가능성이 있다는 것을 알게 되었다. 오픈소스 내부를 이해하기까지는 시간이 오래 걸리기 때문에 해당 문제를 관리자가 해결하기 전까지 프로젝트가 중단될수도 있다는 위험성을 배울 수 있었다.
◦
지난 6월부터 총 4개의 issue 를 열었고 다양한 상황을 경험할 수 있었다.
▪
albumentations-team/albumentation 과 같이 활성화된 repo 에서의 이슈는 빠르게 해결되었다.
▪
IntelRealsSense/librealsense 도 활성화된 repo 로, 빠른 응답을 받았지만, 적절한 답변을 받지 못했다.
▪
kears/keras 에 올린 이슈는 검토되었지만 1달째 문제가 해결되지는 않고 있다.
▪
tensorflow/tensorflow 의 이슈가 2달째 확인과 답변을 받을 수 없었다.
◦
1개의 PR 이 merge 되었다. 매우 거대한 프레임워크의 일부 패키지에서 매우 사소한 문제였지만, 아무도 고치지 않았다는 것으로 보아 - 활성화된 프레임워크 내부에서도 빠르게 발전하는 부분이 있고, 느리게 개선되는 부분이 있다는 것을 알게 되었다.
▪
tensorflow/tensorflow 에 bugfix 가 받아졌다. 신난다!
•
그간 웹이나 앱을 다루는 사람들에 비해 프로그래밍 아키텍처에 대한 고민이 적었던 것 같다. 당장 “버전과 포맷이 지속적으로 바뀌는 메타데이터를 다룰 수 있도록 하자” 라는 목적만 가지고서도 '확장성 있는 클래스의 설계' 와 같은 맥락의 공부가 필요하다는 것을 알았고, 아름답고 확장성 있는 클래스 설계를 하는 일이 나와 완전히 동떨어진 것만은 아니라는 생각이 들었다.
•
현재 노트북환경에서 데이터가공, 모델구축, EDA, 학습, 실험, 평가를 모두 하고 있다. 처음에는 위 모든 과정을 단 두 개의 노트북으로 구축하였다. 하지만 이 파이프라인도 덩치가 점점 커져가며 더욱 작은 단위로 분해될 필요가 있다는 점을 깨달았다. 더욱 작은 단위의 노트북으로 분해하되, 이들이 하나의 노트북처럼 유기적으로 동작시킬 필요가 있다고 느꼈다. 세상에는 이런 과정과 모델의 라이프사이클을 체계적으로 만드는 데 도움을 주는 프레임워크들이 있고, 이를 통틀어 MLOps 라고 부른다는 사실을 알게 되었다. MLOps 라는 것을 주제로 공부하면 내가 처음부터 만드는 것보다 훨씬 더 훌륭한 시스템들이 많이 있을 것이기때문에, 현재 시스템 더 정교한 구현에 대한 고민은 잠시 미루고 해당 분야를 알아보아야겠다고 느꼈다. 체계적인 문제 설계 - 모델 훈련 - 검증 - 배포 - 지속적 업데이트로 대변되는 거대한 모델 개발 파이프라인이 없는 상황에서 어느 불편함이 있을 수 있는지, 각 단계에서 처리해야 작업은 무엇일지 머릿속에 희미하게나마 새겨졌다는 점에서 의미있는 시간이었다.
•
준서와 함께 일을 할 때, 서로의 워크플로우에 git 의 branch 를 포함한 다양한 기능들이 상당히 도움이 된다는 사실을 배웠다. 버전관리도구를 통해 내가 개발중인 기능이 준서가 마주하는 버전에 예상할 수 없는 영향을 주지 않도록 만들 수 있었다.
•
Google 의 TPU 는 사용하기 위한 방법이 상당히 까다롭다. 싸고 효율 좋은 인프라를 만들기 위해서 Google TPU 를 사용하기 위해 삽질을 많이 할 수 있었다. 그 덕분에 TPU 를 사용하기 위해 코드단에서 지켜야 하는 것에 대해서, TPU 를 사용했을 때 생길 수 있는 문제점들에 대해서 어느정도 배울 수 있었다.
◦
구글의 특정 TPU 가 점점 저렴해지는 상황에서, 로컬 시스템의 유지보수를 위한 높은 비용투입 없이도 디어가 상대적으로 저렴하게 딥러닝을 할 수 있게 만들수 있지 않을까? 하는 자신감을 얻을 수 있었다.
2. 점자블럭 로직 만들기
배경
•
GNSS, IMU 등의 센서를 100% 신뢰할 수 없기 때문에 추가적인 처리 로직이 필요함.
•
딥러닝 방식으로 해결하기 위한 비전 데이터가 없음.
•
마일스톤을 달성하기 위해서는 아주 간단하면서도, 자명하고, 획기적이고 참신한 방법을 찾아야 할 수 밖에 없음.
목표
•
일부 상황에서 (점자블럭이 존재하고, 점자블럭이 잘 보이고, 직진 점자블럭인 경우) 킥보드의 heading 을 보정할 수 있도록 만들기
•
딥러닝을 사용하지 않고, 영상의 유의미한 특징을 추출하여 주행에 사용할 수 있도록 만들기
기여 및 성과
•
문제를 조건 - 상황 - 상황관리 로 분해해 생각하고, 특정 상황임을 의미하는 조건들을 쉽게 추가할 수 있는 클래스를 설계했다.
•
점자블럭에 대해서 조사하고, 점자블럭의 특징과 생김새에서 영감을 받아 ‘어떤 상황이 점자블럭이 잘 보이고 직진하는 상황인가’ 를 정의했다.
◦
위 그림과 같이 점자블럭의 방향이 킥보드가 직진으로 진행해야 하는 방향과 동일한 상황에서, 점자블럭 방향으로부터 킥보드의 핸들이 얼마나 회전해 있는지에 대한 각도정보를 반환하는 기능을 제작했다.
▪
회고노트를 제출하기까지 밖에 나가서 확인을 해보지 못할것같아 구체적인 주행성능에 대한 기여내용을 적기는 어려울 것 같다.
배운 점과 회고
•
딥러닝을 사용하지 않고, 우리가 알고 있는 정보만으로도 약간의 문제를 해결할 수 있을 때도 있다. 이렇게 인간의 경험에 의한 로직 설계를 ‘휴리스틱한 로직’ 이라고 말한다. 휴리스틱과 Autonomy 2.0 에 대해서 더욱 깊게 생각해보는 계기가 되었다.
◦
모든 상황을 딥러닝으로 해결할 수 있는 미래 자율주행 시스템은 굉장히 이상적이다. 하지만 그럴 필요가 없거나, 데이터를 구하기 여의치 못한 상황에서 사용할 수 있는 작은 칼은 있어야 한다고 느꼈다.
◦
당장 perception 엔지니어가 급한 것이 아니다. 딥러닝으로 대응이 가능하도록 데이터 수집 파이프라인을 구체화하는 것이 더 중요하겠다는 생각이 들었다.
◦
고전적인 컴퓨터비전 방법론(가령 허프변환, 카메라변환, 소실점, 사영기하 등...) 들에 대해서도 조금씩 내공을 쌓아나가야겠다는 생각이 들었다.
•
이와 별개로, 점자블럭이라는 것은 시각장애인들에게 굉장히 유일하게 의존할 수 있는 교통 표지판이라는 것을 알게 되었다. 색상이 노란색인 것 그 자체만으로도 의미가 있었고, 인도에 새겨진 모양들에도 의미가 담겨 있었다.
◦
자율주차 기술을 통해 점자블럭 위의 킥보드라는 장애물을 걷어내야겠다는 생각이 들었다.
◦
디어의 기술이 긍정적으로 사용될 방법이 없을까 고민하게 되었다 (4. 에서 추가적으로 설명한다).
3. 자율주행을 위한 딥러닝모델 성능 올리기
배경
•
디어가 사용하는 딥러닝 기반의 모델의 성능이 우수하지 못해 마일스톤을 달성하는 데 장애가 되는 것 같다는 문제의식
목표
•
딥러닝 모델 추론속도 높이기
•
딥러닝 모델 추론성능 높이기
기여 및 성과
•
앞서 언급했던 다양한 모델 파라미터들에 대한 실험을 통해, 모델이 충분히 안정적이고 믿을만한 상황이라면 모델 개선보다 데이터와 전처리가 더 중요할 수 있겠다는 결론을 얻었다.
•
삽질을 통해 신경망 최적화 도구 (TensorRT) 를 어떤 방식으로 사용해야 할지에 대한 그림을 그릴 수 있게 되었다.
배운점과 회고
•
생각보다 모델의 파라미터와 모델 아키텍처를 바꿔보면서 얻을 수 있는 성능이득은 크지 않았다. 이는 자율주행 개발의 방향성에 대한 생각을 더욱 뒷받침해 주었다.
◦
딥러닝 모델의 성능에는 데이터가 가장 큰 영향을 미칠지도 모른다. 데이터 증강 기법이나 데이터 수집 방법처럼 ‘모델’ 이라는 키워드가 아닌 ‘데이터’ 라는 키워드에 대한 고민이 더 중요하다.
◦
모델의 아키텍처를 변경함으로써 얻을 수 있는 이익은 데이터를 정제하거나 해상도를 조절 또는 카메라의 배치 각도를 조절하는 것과 같이 우리가 사용하고자 하는 환경(real-world) 에 맞는 양질(e.g. consistency) 의 데이터를 사용하도록 만들면서 얻을 수 있는 성능이익폭보다 훨씬 더 적고 비효율적이다.
▪
양질의 데이터라고 함은 다음과 같은 요소들을 포함할 수 있다. 하지만 우리가 프로토타이핑에 사용한 공개데이터셋은 아래 조건들을 만족시키지 못했다. 이 문제를 해결하기 위해서 4. 에서는 데이터 수집 방법을 제안할 수 있었다.
•
Andrej Ng 교수님이 강조했듯, 일관성 있는 데이터여야 한다 (consistency).
•
사람이 보기에도 시맨틱 정보가 충분히 보존되어 있어야 한다.
◦
사람이 보기에도 사진에 담긴 특정 영역이, 우레탄 재질의 인도인가? 우레탄 재질의 자전거도로인가? 아니면 페인트칠을 한 아스팔트 도로인가? 를 헷갈려해서는 안 된다.
•
데이터셋이 수집된 환경의 카메라와 다른 카메라를 사용할 수 있도록, camera intrinsic 같은 메타데이터를 제공해야 한다.
•
우리의 기구상 카메라 장착 extrinsic 과 크게 벗어나는 영상 데이터는 별로 쓸모가 없다. 우리와 비슷한 상황에서 촬영한 영상데이터여야 한다.
◦
단일 extrinsic 이 아닌 공개 데이터셋은 extrinsic 과 depth 를 함께 제공해서 perspective transform 을 할 수 있어야 한다.
•
우리의 입맛에 맞게 클래스의 기준을 변경할 수 있어야 한다.
◦
보행로 위에 사람이 서 있다고 가정했을 때, 사람이 가린 부분 뒤에는 분명히 보행로가 있을텐데, 이 사람이 가리고 있는 영역 또한 보행로의 일부라고 학습시킬 수도 있고 - 그렇지 않다고 학습시킬수도 있도록 레이블이 매겨져 있어야 한다.
•
영상 정보만으로는 부족하고. 비디오 클립으로 데이터를 가지고 있을 수 있어야 한다는 생각을 하게 되었다.
◦
비디오클립을 가지고 있을 때야 비로소 제대로 추론할 수 있다는 생각을 구체화할 수 있었다.
▪
단일 프레임만 가지고 학습하고 추론하는 구조라면 아주 간단한 예를 들어서 어떤 사람이 움직이고 있는지 멈춰 있는지 알 방법이 없게 된다. 움직이는 차량인지 주차된 차량인지 알 수 없게 된다. 움직이는 장애물이 보행영역을 가리면, 킥보드는 무작정 멈춰서 버릴 수밖에 없다.
▪
비디오클립은 높은 Co-visible 영역을 가진다. t 번째 프레임에서 잘 보이지 않는 영역이, t-5 번째 프레임에서는 너무나도 잘 보이는 영역이었을지도 모른다. 단일 프레임 추론이었다면 아무리 t-5 번째 프레임에서 segmentation 모델이 정확한 추론을 해냈다고 하더라도 t 번째 프레임을 추론해내는 모델 입장에서는 과거에 자신이 잘 했던 것을 복기해낼 수 없게 되는 것이다.
▪
따라서 딥러닝 모델을 발전시키는 방향은, 단순히 ‘성능을 높이겠다’ 는 것이 되어서는 안 된다는 사실을 배웠다. 오히려 다음과 같은 요소들이 더 중요할지도 모른다는 점들을 배웠다.
•
어떤 브랜치에 어떤 정보를 담아서 흘려줄 것인가?
•
어떻게 시간적인 특징들을 보존할 수 있도록 만들어줄 것인가?
•
어떤 데이터로 멀티태스크 모델을 만들고, 훈련시키고, 유지보수할 것인가?
•
TensorRT
◦
속도를 높이기 위해서는 기본적으로 TensorRT 라는 도구를 사용한다는 사실을 알게 되었다. TensorRT 로 뉴럴네트워크를 최적화시키는 방법은 두 가지 있다는 사실을 배웠다. 삽질 끝에 한 가지 방법은 암묵적으로 지원이 중단됐을 정도로 잘 동작하지 않는다는 사실 또한 알게 되었다 (상단에서 언급한 issue 중 아직도 답변이 달리지 않은 것들 중 하나이다.).
◦
이 또한 대부분의 삽질 과정이 문서로 남겨져 있다.
•
엣지 디바이스에서 여러 개의 독립된 모델을 돌리는 것은 상당히 컴퓨팅 리소스를 많이 잡아먹는 작업이라, 현재 상태에서 추가로 모델을 올려야 한다면 멀티태스크 모델을 만들어야겠다는 생각이 들었다.
•
2021년 12월 현재, object detection 모델은 당장의 마일스톤을 달성하는 데 큰 필요가 없다는 결론 하에, 실제 주행 시 사용하지 않고 있다.
4. 자율주행 기술, 전략, 사업적 고민
배경
•
디어의 자율주행이 빠르게 발전하지 못해 모두가 답답해하는 상황
•
이 자율주행이 만들 미래에 대해서 모두가 서로 다른 생각을 하고 있는 상황
•
마일스톤을 달성해야만 하는 이유와, 마일스톤 이후 기술적 방향성에 대한 목적 상실
목표
•
자율주행팀이 추구하는 바가 전사적 비전과 얼라인되도록 요구하기
•
자율주행팀이 전사적으로 더욱 많은 지원을 받을 수 있도록 컨센서스 만들기
•
디어의 자율주행팀이 어떻게 기술적으로 발전해야 할지 전략을 수립하기
•
사내 시니어 없이도 정말 창의적이고 획기적으로 많은 문제를 해결할 수 있도록 만들기
기여 및 성과
•
기술적 미래에 대한 고민과 제안
◦
디어 자율주행킥보드 루돌프의 인지시스템을 개발하며
▪
디어의 인지시스템을 한차원 더 높은 존재로 만들지 못하는 이유는 ‘데이터가 존재하지 않아서’ 라는 점을 지적했다.
▪
데이터를 대량으로 쌓을 수 있는 시스템을 구축할 수 있는 방법을 제안했다.
•
적은 노력으로 가장 많은 일을 할 수 있도록, 2차원에서(width,height) 벗어나 4차원에서(width,height,depth,time) 데이터를 똑똑하게 수집해야 한다는 점을 강조했다.
◦
‘이 작업을 우리가 직접 해야 한다’ 는 가설 검증 시도들
▪
6개의 B2B 데이터수집업 업체 (솔트룩스, 테스트웍스, 딥브레인, 셀렉트스타, 크라우드웍스, + 슈퍼브에이아이) 와 컨택하여 팩트를 수집했다.
▪
Tesla ai day, 현대차 hmg conference, 42dot umos day, 배달의민족 등 자율주행 기업들의 공개행사와 공개자료들을 최대한 참고하여 팩트를 수집했다.
▪
3D Reconstruction 과 3D Computer vision 과 관련해서 공부한 대학원생 2명에게 자문을 구해 팩트를 수집했다.
◦
사업적으로 보았을 때 디어 자율주행이 조금이라도 더 빨리 고객들을 만나기 위해서는, 기술이 ‘모든 상황에서 대응할 수 있는 자율주행기술을 만드는 것’ 을 목표로 개발되어서는 안된다. 경영진이 자율주행팀을 바라보는 시선을 다듬어가고 있다.
▪
디어가 다른 회사들에 비해 가지고 있는 장점과 접근 방향이 명확히 다르다는 점을 상기시켰다.
•
디어의 운영경험 덕분에, 수많은 플릿을 빠르게 배포할 수 있다.
•
배달로봇과 디어 자율주행은 풀어야 하는 문제가 아예 다르다는 점을 상기시켰다.
◦
배달로봇은 아파트 현관 앞부터 고민을 출발해서, 단지 안을 어떻게 돌아다닐까, 캠퍼스 안을 어떻게 돌아다닐까를 고민하는데 비해 디어 자율주행 킥보드는 크고 넓은 길을 어떻게 다닐까에 초점이 맞추어져 있다는 점을 인지시켰다.
▪
굉장히 제한적인 ODD (장소나 기상상황, 시간대 등 자율주행차가 대응할 수 있는 조건) 에서 자율주행이 가능하다는 단점을 극복시켜 줄 원격제어기술을 사용하고, 이로부터 쌓이는 데이터로 주행가능영역을 확장시켜 나가야 한다는 컨센서스를 조금씩 만들고 있다.
•
이것이 가능하기 위해서는 모빌리티 그 자체가 데이터 수집 플릿이 되는 것이 중요하다는 점을 인식시키고 있다 (Autonomy 2.0 에서 제안하는 컨셉에 이름을 붙였다.).
▪
킥보드 자체만 놓고 보았을 때 자율주행킥보드가 당장 5년안에 디어에 벌어다 줄 수 있는 금전적 이익이 절대 크지 않다는 점을 강조하며, 자율주행킥보드가 바꿀 미래에 대해 멋진 비전을 상상하며 개발하는 도중에 나오는 부산물들이 사회적으로/경제적으로 가치를 만들어야 한다는 점을 상기시켰다.
•
그 중 하나로, 디어의 데이터문제를 해결할 수 있는 4D (3D+time) Mapping & Labeling 이라는 아이디어를 제시했다.
◦
많은 기업들이 인도가 아닌 차도의 3D 데이터 구축에 집중하고 있다. 반대로 보행로 기반의 로봇을 만들려는 회사나, 교통약자를 위한 서비스에 유용하게 사용할 수 있는 데이터를 디어가 생산할 수 있게 될지도 모른다는 가능성을 제시했다.
◦
이를 달성하기 위해서 플릿이 그 자체로 데이터 수집 장치가 되어야 한다는 점과 연결시켜, Mobility as a Mobile Mapping System 이라는 컨셉을 제시했다.
◦
T60, T60 lite 의 사례를 들어 보며 세그웨이가 원격제어 기술과 자율주행 기술을 개발하고 있을지도 모른다는 점을 인지시켰다.
•
디어가 만들 미래에 대한 생각 구체화
◦
NIA 인공지능 학습데이터 공모전
▪
본선진출에는 실패했지만 디어가 어떤 점에서 강점을 가지고 있는지 생각해볼 수 있는 시간이었고, 디어가 자율주행 기술을 성공적으로 안착시키면 어떤 서비스 플로우가 만들어질지 생각을 다듬어볼 수 있었다.
•
전사적, 컨센서스
◦
자율주행팀에 비전이 필요하다는 요구사항을 전달했다.
◦
자율주행팀 지원에 대한 컨센서스를 다함께 만들 수 있도록 했다.
◦
2021년 8월~12월 재석형과 가졌던 one on one 에서는 거의 매시간 디어 자율주행의 미래에 대해서 이야기나누는 시간을 가졌다.
배운점과 회고
•
데이터셋이 없다는 문제가 만들어낸 많은 부문제들과 시행착오이다.
◦
가지고 있는 데이터셋이 적더라도 그 문제를 어느정도 경감시켜 줄 수 있는 딥러닝 방법론들이 있다. Transfer Learning, Contrastive Learning 에 모두 기웃거리게 만들었지만, 공부 끝에 둘 중 그 무엇이든 우리 상황에 맞게 시도하는 것은 ‘가성비’ 가 좋지 않을 것이라는 결론을 내릴 수 있었다. Transfer Learning 은 최종적으로 얻는 성능증가폭이 소비되는 컴퓨팅 자원에 비해 터무니없이 낮았다. Contrastive Learning 은 아카데믹에서 한창 발전 중이며 비슷한 유즈케이스를 찾기 어려웠다. 구현은 가능하겠지만, 디어는 시행착오를 많이 할 여유가 없다고 생각했다. 이러한 이유로 아직 사용하기 이르다는 결론을 내릴 수 있었고, 그만 알아볼수밖에 없었다. 설사 이것들이 된다고 하더라도, 우리 태스크에 맞는 데이터셋이 조금이라도 존재해야만 한다는 것을 배웠다.
◦
디어가 사용하는 공개 데이터셋에는 다양한 문제들이 존재했다. 이것들은 개발에 있어 수많은 병목을 만들어냈고, 아직까지도 해소되지 않고 있다. 이런 문제들을 구체화하며 어떤 것이 진짜 문제인지 고민해볼 수 있는 시간이었다.
▪
시맨틱 정보(semantic information) 가 손실된 경우가 많았다.
▪
위치 정보나 인접한 영상인지의 여부가 없었다.
▪
카메라 행렬(camera matrix) 등을 확인할 수 있는 메타데이터가 포함되어있지 않았다.
◦
디어의 데이터셋이 없었기에, 학습시킨 모델의 실제 성능을 확인하고자 한다면 플릿을 끌고 엘리베이터를 타고 내려가서 주행을 시켜보며 확인할 수밖에 없었다. 이것은 개발 속도를 굉장히 더디게 만든다.
◦
최종적으로는 디어의 자체 3D 데이터셋 생성 역량이 없다는 문제가 본질이었다는 생각이 들었다. 데이터를 확보하는 일과, 그 데이터를 잘 가공해서 모델을 학습시키고 지속적으로 업데이트시킬 수 있는 것 만큼 더욱 중요한 일은 없다는 커다란 배움을 얻게 되었다.
•
자율주행팀의 미래는 자율주행팀이 적극적으로 나서 챙길 줄 알아야 한다는 것을 배웠다.
to
1.