[Dev] 로봇 소프트웨어 개발 문화

로봇 소프트웨어 개발 문화를 어떻게 만들어야 할까?

로봇 소프트웨어 개발 문화

로봇 소프트웨어 개발 문화를 어떻게 만들어야 할까?

로봇 소프트웨어 개발은 단순한 소프트웨어 개발과는 차이가 있다. 로봇은 물리적인 환경에서 동작하며, 하드웨어와의 긴밀한 연계가 필요하기 때문에 코드의 신뢰성과 유지보수가 특히 중요하다. 하지만 아무리 뛰어난 기술을 보유하고 있어도, 좋은 개발 문화가 정착되지 않으면 장기적으로 효율적인 개발이 어려워지며, 어느순간 부터는 기술 부채가 쌓여 되돌릴 수 없는 상태에 이르게 된다. 또한 개발 처음부터 재대로된 개발 문화와 시스템을 구축하지 않고 중간에 레거시 시스템을 고친다는 것은 매우 머리아픈 일이다. 이번 포스팅에서는 두번째 스타트업에서 개발문화를 구축하면서 생각하고 있는 로봇 소프트웨어 개발 문화의 중요성과 이를 구축하는 방법에 대해 이야기해 보겠다.

개발 문화의 중요성

좋은 개발 문화는 단순히 “잘 짜인 코드”를 만드는 것 이상의 가치를 제공한다. 조직 내 개발 문화가 건강하면 다음과 같은 장점이 있다.

협업이 원활해진다: 코드 스타일과 리뷰 방식이 일관되면, 팀원들이 더 쉽게 서로의 코드를 이해할 수 있다.
버그와 기술 부채를 줄일 수 있다: 체계적인 코드 리뷰와 테스트 문화가 자리 잡으면, 문제를 조기에 발견하고 해결할 수 있다.
신규 개발자 온보딩이 쉬워진다: 문서화와 코드 컨벤션이 정립되어 있다면, 새로운 팀원이 빠르게 적응할 수 있다.
개발 속도가 꾸준히 유지된다: 단기적인 속도보다 장기적인 생산성을 고려한 개발 문화가 정착되면, 프로젝트의 유지보수가 쉬워지고 확장성도 높아진다.

로봇 소프트웨어 개발은 하드웨어와 직접 연결되므로, 잘못된 코드 하나가 물리적인 사고를 초래할 수 있다. 따라서 체계적인 개발 문화가 더욱 필수적이다. 아쉬운 부분은 한국의 많은 로봇 회사들이 이런 개발문화에 대한 중요성을 모르고 있는 경우가 매우 많다. 일반적인 B2C 소프트웨어를 개발하는 풀스택의 경우 컴퓨터공학을 기반으로 개발 문화가 형성되어 이런 개발문화의 중요성, 에자일 개발 등 개발 문화에 대해 신경을 쓰는 경우가 많다. 하지만 로봇 개발 회사의 경우 (특히 한국 로봇회사의 경우) 학교 출신의 로봇 관련 연구를 했었던 석사/박사 출신이 개발 문화를 만드는 경우가 많다 보니 이런 개발 문화에 대한 중요성, 그리고 필요성에 대해 인지하지 못하는 경우가 많은 것 같다. 심지어 형상관리 툴을 사용하지만 모든 개발자가 master 브랜치에서 코드 작업을 하고 바로 master로 commit을 넣는 경우도 심심치 않게 보았다. 이런 개발 문화에서는 코드의 퀄리티가 유지될 수 없을 뿐만 아니라 코드의 버전 관리도 불가능하다. 따라서 무엇보다도 로봇 소프트웨어 개발에서 개발문화는 가장 중요한 요소이다.

코드 리뷰의 중요성

코드 리뷰는 개발자의 실수를 줄이고 코드 품질을 향상시키는 중요한 과정이다. 단순히 “버그를 잡는 과정”이 아니라, 팀이 공유하는 개발 원칙과 철학을 유지하는 역할도 한다.

코드 리뷰가 필요한 이유

버그 예방: 코드 리뷰를 통해 동료 개발자가 실수를 발견하고 수정할 수 있다.
지식 공유: 리뷰 과정에서 코드에 대한 이해도를 높이고, 팀 전체의 개발 역량을 향상시킬 수 있다.
일관성 유지: 코드 스타일과 아키텍처가 팀의 기준에 맞게 유지될 수 있다.
기술 부채 감소: 불필요한 복잡성이나 잘못된 설계를 초기에 바로잡을 수 있다.

로봇 소프트웨어의 경우, 코드 한 줄이 실제 로봇의 동작에 영향을 미칠 수 있기 때문에 코드 리뷰는 더욱 철저히 진행해야 한다. 단순히 “문제가 없어 보인다”는 식의 리뷰가 아니라, 코드가 실제 환경에서 어떻게 동작할지 고려하며 리뷰해야 한다. 또한 코드에 버그가 있는 상태로 Master로 머지가 된다면 그에 대한 책임 또한 리뷰어에게도 있다는 사실을 항상 인지해야 한다. 리뷰 과정은 단순히 다른 동료의 코드를 훑어보는 과정이 아닌 개발의 일 부분임을 잊어서는 안된다.

효율적인 코드 리뷰 프로세스

효율적인 코드 리뷰 프로세스를 구축하기 위해서는 몇 가지 원칙을 따라야 한다.

1. 리뷰를 위한 명확한 기준 설정

코드 리뷰를 시작하기 전에 팀 내에서 명확한 기준을 세워야 한다. 예를 들어, 다음과 같은 항목을 정할 수 있다.

코드 스타일 가이드라인 (ex: Google C++ Style Guide)
PR(Pull Request) 크기 제한 (너무 큰 PR은 리뷰하기 어렵다)
테스트 코드 포함 여부

이러한 기준이 없다면 리뷰어마다 다르게 판단할 가능성이 높아지고, 리뷰 과정이 비효율적으로 변할 수 있다.

2. 코드 스타일 가이드 설정

개발자마다 함수명, 변수명, namespace 이름을 만드는 규칙, 포멧이 다르다면 코드는 금방 엉망이 될 것이며, 리뷰를 어렵게 만드는 요소가 된다. 공통으로 사용할 코드 스타일 가이드를 설정하는 것은 개발 문화의 가장 기본적인 요소이다. TIM Robotics의 경우에는 모든 언어가 Google Style Guide 따르고 있다. (링크) 일반적으로 Style Guide에는 코드 작성을 위한 함수명, 변수명, namespace명 등 모든 요소들에 대한 규칙을 포함한다. 예를 들어 Google Style Guide 기준으로 Class의 맴버 변수는 _ 라는 suffix 를 사용하며, const variable인 경우에는 k의 prefix를 사용한다. 모든 개발자가 이렇게 동일한 규칙을 사용함으로써 코드의 Readability가 높아지고, 리뷰하는데 시간이 감소하게 된다. 추가적으로 TIM Robotics는 좌표계의 변환 관계를 표현하는 방법, Time을 포함한 변수 표현 방법 등 다양한 스타일 가이드를 추가적으로 만들어 공유하고 있다. 내부 스타일 가이드는 개발을 하면서 부족한 부분을 발견하면 함께 논의하여 만들어 가는 과정이 매우 중요하며, 이 과정에서는 모든 개발자가 참여해야 한다.

3. Test 코드 작성하기

테스트 코드 작성은 하나의 추가 업무가 아닌 당연한 개발의 일부이다. 테스트 코드가 없는 코드는 개발 단계에서 검증 단계를 거치지 않았으며, 추가 수정이 있을때마다 버그가 발생할 수 있는 코드이다. 따라서 개발되는 모든 코드는 테스트 코드가 포함되어야 하며 PR에 항상 함꼐 포함되어 있어야 한다. CI 프로세스에서는 해당 PR에 테스트 코드가 포함되었는지, 커버리지가 일정 이상 인지 확인하여 Merge 가능 여부를 자동으로 판단하도록 시스템을 구성해야 한다.

4. PR(Pull Request) 크기 조절하기

PR은 Pull Request의 약자로 수정된 코드를 다른 사람에게 리뷰받는 프로세스를 의미한다. PR을 작성할 때 리뷰어에게 도움을 주기 위해 어떤 내용에 대한 수정사항인지 자세히 PR에 정리해서 PR을 생성하는 것이 기본 프로세스이다. PR을 작성 시 PR이 너무 크면 리뷰어가 모든 내용을 꼼꼼히 살펴보기가 어렵다. 10줄의 코드를 리뷰 요청하면 10개의 comment가 달리는데, 500줄의 코드 리뷰를 요청하면 한개의 리뷰도 돌아오지 않는다 라는 농담이 있다. 하나의 브랜치에서 여러 작업을 동시에 수행하여 수정사항이 너무 많으면 리뷰어는 수정사항에 대해서 이해하는데 시간이 오래걸려 포기해버리고 LGTM (Looks good to me) 리뷰를 던지는 경우가 발생한다. 따라서 일반적으로 한 번의 PR에서 너무 많은 기능을 추가하기보다는, 작은 단위로 쪼개어 올리는 것이 좋다. 작은 PR은 리뷰 시간이 단축되고, 변경 사항을 명확히 이해하는 데 도움이 된다.

5. 자동화 도구 활용하기

개발 프로세스에서 자동화 툴을 사용하여 자동화 할 수 있는 부분은 최대한 적용하는 것이 효과적이다.

코드 스타일 검사: Clang-Format, Prettier, Clang-tidy 등을 활용하여 스타일을 자동으로 맞춘다.
정적 분석 도구: SonarQube, cppcheck 등을 이용해 잠재적인 버그를 찾는다.
CI/CD 파이프라인: 코드 리뷰 전에 자동으로 빌드, 테스트를 실행해 코드의 안정성을 확인한다.

개발자들끼리 특정 스타일 가이드를 따르기로 약속했다고 하더라도 개발과정에서 누구라도 실수를 할 수 있다. 이러한 실수들은 자동화 툴을 사용해서 자동으로 감지되도록 시스템을 구성해야 한다. TIM Robotics는 clang-format과 clang-tidy를 함께 사용하고 있다. clang-format은 코드 전반적인 format에 대하여 자동으로 감지하고 수정해준다. clang-tidy는 코드 스타일 검사와 정적 분석이 모두 포함되 있으며, 특히 함수, 변수명들이 정의한 스타일과 다르게 작성된 부분을 자동 검출하는데 유용하며, 잠재적인 버그들도 함께 검출할 수 있다. 이러한 툴들은 개발 과정에서 개발자들이 활용하는 것 뿐만 아니라 CI 과정에서 다시 한번 수정 사항에 대하여 테스트를 하고, 문제가 발견했을 때 오류를 발생시켜 수정된 코드가 Master 브랜치로 Merge되는 것을 방지한다. 이런 자동화 도구를 적극적으로 활용함으로써 리뷰어는 코드 스타일이나 간단한 실수를 지적 하는 대신, 전체적인 코드의 구성, 아키텍처, 그리고 로직에 집중하여 리뷰를 할 수 있다.

6. 건설적인 피드백 제공하기

코드 리뷰는 팀원 간의 협업 과정이므로, 피드백을 줄 때는 긍정적인 방식으로 접근하는 것이 중요하다.

“이 부분은 잘 구현하셨네요! 하지만 여기서는 이런 방식이 더 좋을 것 같습니다.”
“이 로직이 잘 동작하긴 하지만, 성능 최적화를 위해 이런 접근도 고려해볼 수 있을 것 같아요.”

단순한 비판이 아니라, 대안을 제시하는 피드백이 더 효과적이다. 때로는 리뷰만으로는 의도한 내용을 정확히 전달하기 어려울 때 코드를 수정하여 제안하는 것도 방법이다.

7. 리뷰 시간을 정기적으로 확보하기

코드 리뷰는 “남는 시간에 하는 것”이 아니라, 개발 프로세스의 핵심 단계다. 따라서 리뷰를 위한 시간을 정기적으로 확보하는 것이 중요하다. 예를 들어, 매일 오전 10~11시는 코드 리뷰 시간으로 지정하는 등의 방식이 있다. 이런 방식이 재대로 동작하기 위해서는 PR을 작은 단위로 자주 작성하여 리뷰 요청을 해야 한다.

신규 개발자 온보딩 및 문서화

새로운 개발자가 팀에 합류했을 때 빠르게 적응할 수 있도록 돕는 것도 좋은 개발 문화의 일부다. 이를 위해 다음과 같은 요소를 준비하는 것이 좋다.

1. 개발 환경 설정 가이드 제공

개발 환경을 빠르게 구축할 수 있도록, Docker 같은 자동화된 환경 설정 방법을 제공한다.
“개발 환경 설정 가이드” 문서를 준비해 놓는다.

2. 코드베이스 문서화

프로젝트의 전체 구조를 설명하는 아키텍처 다이어그램을 제공한다.
주요 모듈과 라이브러리의 역할을 정리한 문서를 만든다.

3. 온보딩 미션 제공

신규 개발자가 코드베이스를 이해할 수 있도록, 작은 기능을 직접 추가해보는 미션을 제공한다.
테스트 코드 작성이나 작은 버그 수정부터 시작하도록 유도한다.

결론

좋은 개발 문화를 만드는 것은 하루아침에 이루어지는 일이 아니다. 하지만 코드 리뷰 프로세스를 정립하고, 자동화 도구를 활용하며, 명확한 문서화와 온보딩 시스템을 갖춘다면, 지속 가능한 로봇 소프트웨어 개발 환경을 만들 수 있다.

개발 문화는 단순한 규칙이 아니라, 팀 전체가 함께 만들어가는 과정이다. 한국의 로봇 산업이 더 고도화 되기 위해서는 모든 로봇 회사들이 이러한 개발 문화를 갖춰야 한다고 생각한다.