팀이 함께 설계해 나가는 로봇 소프트웨어, 디든로보틱스 권순표 CTO 인터뷰

"사람들 눈에는 로봇이 잘 움직이는 모습만 보여요. 그 동작 하나를 실제 로봇에 올리기까지, 여러 사람의 코드가 부딪히지 않고 맞물려야 하죠."

권순표 CTO가 디든로보틱스 소프트웨어의 핵심으로 코드보다 '협업할 수 있는 구조'를 먼저 꼽는 이유입니다. 로봇 한 대가 움직이려면 보행, 인식, 판단을 맡은 엔지니어들의 코드가 한 몸 안에서 동시에 돌아가야 합니다.

그는 KAIST 휴보랩에서 강화학습 기반 보행 제어와 비전 기반 지도 생성을 연구했고, 지금은 디든로보틱스 공동창업자이자 CTO로서 기술 로드맵을 만들고 소프트웨어 부문을 이끌고 있습니다. 특히 각자 만든 제어기를 실제 로봇에 올리는 공통 기반을 전담하는 플랫폼 소프트웨어 팀을 따로 두었습니다.

하드웨어를 만드는 제조업 기반 회사지만, 협업 구조만큼은 소프트웨어 중심 기업처럼 설계했다는 것이 그의 설명입니다. 연구실의 개인 프로젝트와 회사의 협업 프로젝트는 무엇이 다른지, 디든로보틱스의 소프트웨어는 어떤 방향으로 가고 있는지 들어봤습니다.

조선소로 가는 로봇의 지도를 그리는 사람

Q. 디든로보틱스에서 어떤 일을 맡고 계신지 소개해 주세요.

CTO로서 로봇이 조선소 현장에 들어갈 수 있도록 기술 로드맵을 짜고 있습니다. 이를 각 팀에 나누고, 팀에서 올라오는 피드백을 받는 게 저의 주된 역할입니다.

스타트업 초기 멤버이자 디든로보틱스의 첫 CTO로서, 창업자들이 만들어 둔 시스템을 모든 구성원이 잘 익혀서 오래 쓸 수 있도록 지원하는 일도 하고 있어요. 회사 밖으로는 저희 기술이 어떻게 쓰일 수 있는지 알리고, 판매로 이어질 수 있도록 중간에서 조율하는 역할도 합니다.

소프트웨어 부문에는 네 팀이 있어요. 모션 지능, 판단 지능, 비전 지능 팀은 로봇이 어떻게 움직이고, 판단하고, 주변을 인식할지를 다룹니다. 나머지 하나인 플랫폼 소프트웨어 팀은 조금 다릅니다. 다른 세 팀이 만든 제어기와 기능이 실제 로봇 위에서 함께 돌아가도록 공통 기반을 만드는 팀이에요. 

▲ 시뮬레이션에서 학습한 보행(왼쪽)을 실제 디든 스파이더(오른쪽)에 옮긴 모습. 출처: 디든로보틱스 홈페이지

가장 모르는 분야를 찾아 로봇으로

Q. 로봇공학에는 어떻게 관심을 갖게 되셨나요?

성균관대 기계공학과를 다녔는데, 기본적으로 공부하는 걸 좋아했어요. 기계공학은 공학 중에서도 수학이 많이 필요한 분야라 잘 맞았고요. 무언가를 만드는 일에 특별히 흥미가 있었다기보다는, 대학원에 가서 더 많은 걸 배우고 싶었습니다. 그래서 어디에 가면 가장 많이 배울 수 있을까, 내가 모르는 게 가장 많은 분야가 어디일까 생각해 보니 답은 로보틱스였어요.

그렇게 KAIST 휴보랩에 들어갔습니다. 휴보랩은 2015년 미국 DARPA 로보틱스 챌린지에서 우승한 연구실이에요. 제가 이곳 출신이라 그렇게 생각할 수도 있지만, 국내에서 로봇을 만드는 연구실로는 손꼽히는 곳이라고 생각합니다. 지금 이곳에서 연구실을 이끄는 박해원 교수님*은 정말 대단한 분이시고, 그 아래에서 연구하는 사람들도 각자 특색이 뚜렷하고 정말 열심히 하고 잘해요.

* 박해원 교수: KAIST 기계공학과 교수이자 휴머노이드 로봇 연구센터장이다. 미국 국립과학재단(NSF) CAREER 상(2018)을 받았고, 자석발 보행 로봇 MARVEL 연구로 Science Robotics(2022) 표지를 장식했다. 현재 디든로보틱스 CSO를 맡고 있다.

Q. 창업은 언제부터 생각하셨나요?

대학원에 간 뒤로 창업을 계속 생각했어요. 그때는 이유를 몰랐는데, 지나고 보니 제가 한 일의 가치를 합리적으로 평가받을 수 있다는 점이 좋았던 것 같습니다.

보통은 내가 이만큼의 일을 했는지 측정하기 어렵고, 남과 비교하기도 어렵잖아요. 창업은 무엇을 잘했는지에 대한 기준이 비교적 분명하다고 생각해요. 결과가 어떻든 내가 어느 정도인 사람인지 그대로 드러나니까, 오히려 마음이 편하다고 생각했어요.

어떤 것으로 창업할지 계속 생각했지만, 당시에는 현장에 적용할 만한 수준의 로봇이 아직 없어서 마땅한 아이디어를 찾지 못했습니다. 그러다 대학원에 있는 동안 AI 붐이 일면서, 로봇이 실제 세계로 나아갈 가능성이 열리고 있다고 느꼈어요.

마침 연구실 동료들이 사족보행 로봇에 자석발을 붙여 철제 벽을 오르게 한다는 아이디어로, KAIST 학생 창업 프로그램인 E*5 KAIST*에서 2022년 하반기 우수팀(2위)으로 선정됐어요. 저도 늘 창업을 생각하고 있었기 때문에, 이야기를 나누며 뜻이 맞아 함께 시작하게 됐어요. 아이디어도 좋았고, 휴보랩 구성원들과 함께할 수 있다는 점도 컸죠.

* E*5 KAIST: KAIST 창업원이 2012년부터 운영해 온 KAIST의 대표 학생 창업 지원 프로그램이다.

혼자 짜던 코드가 팀의 코드가 되기까지

Q. 회사에서 소프트웨어를 개발하면서 연구실에서는 몰랐던 어려움이 있었나요?

아주 많죠. 가장 먼저 떠오르는 건 '협업'이에요. 연구실에서는 코드를 짜고 실험하는 일이 거의 개인 업무입니다. 선후배가 실험을 도와줄 수는 있지만, 어떻게 개발하고 더 나은 모듈을 만들지는 온전히 자기 몫이에요. 코드가 개인 프로젝트가 되는 셈이죠.

회사는 다릅니다. 로그가 계속 쌓여야 하고, 내 작업이 다른 사람의 작업과 합쳐져 큰 결과물 하나를 이뤄야 해요. 연구실이 작고 깊은 작품을 만드는 곳이라면, 회사는 깊이가 조금 덜하더라도 전체가 유기적으로 돌아가게 만들어야 하는 곳입니다.

과제 하나하나도 쉽지 않아서, 역량이 뛰어난 엔지니어들이 각자의 생각을 분명히 내놓아요. 그러다 보니 이들의 코드를 하나로 합칠 때 부딪히는 일이 많죠. 각자의 철학이 분명한 건 어쩔 수 없으니, 결국 누구의 방식이 옳으냐가 아니라 무엇을 선택하느냐의 문제예요. 그래서 저희는 한 사람이 잘 짠 코드보다 여러 사람이 함께 쓸 수 있는 구조를 먼저 두기로 방향을 정했습니다.

저희 소프트웨어에는 V1과 V2가 있고, 지금 V2로 옮겨 가는 단계예요. V2의 가장 중요한 키워드는 협업입니다. V1이 로봇을 움직이는 기초 설계에 집중한 코드라면, V2는 여러 사람이 함께 개발할 수 있도록 협업을 철저히 고려해 짠 코드예요.

전통적인 협업 방식은 이미 있었지만, 요즘은 AI가 개발 방식 자체를 크게 바꾸고 있어서 이 변화를 협업에 어떻게 받아들일지도 어려운 문제예요. 저희가 V2로 옮겨 가는 이유도 여기에 있어요.

Q. 하드웨어 팀과의 협업은 어떤가요?

부딪히는 일은 늘 있어요. 소프트웨어 팀 안에서도 마찬가지고요. 중요한 건 그걸 잘 풀어 가는 겁니다. 저희는 임원진이 하드웨어와 소프트웨어를 모두 풀스택으로 다뤄 봤다는 점이 강점이에요. 양쪽을 다 아는 임원진이 중간에서 중재할 수 있거든요.

예를 들어 자석발 바닥에 달린 센서가 예상대로 작동하지 않는다고 해 볼게요. 소프트웨어를 하는 사람은 먼저 '센서가 고장 났네'라고 생각합니다. 그런데 센서를 만든 사람은 본인이 잘 만들었다고 생각하니까 '왜 이렇게 세게 걷지?'라고 생각할 수 있어요. 실제로는 보행을 더 부드럽게 바꾸는 방법도 있고, 소프트웨어에서 센서의 이상을 감지하는 기능을 만들 수도 있습니다.

이때 '센서가 고장 났어요'라고만 말하면 틀린 말은 아니지만, 하드웨어 쪽에서는 책임을 혼자 지는 느낌을 받을 수 있어요. 이런 말이 오가면 저는 이후에 맥락을 덧붙이거나, 말한 사람에게 악의가 전혀 없었다는 점을 하드웨어 쪽에 설명합니다.

하드웨어 쪽도 생각이 분명한 만큼 논리력이 뛰어나서, 잘 설명하면 '아쉽지만 그럴 수 있겠네요' 하고 잘 이해해 주세요. 생각이 분명한 사람이 많다는 건 양날의 검이지만, 잘 엮으면 아주 좋은 결과로 이어져요.

Q. 시험장에서 현장으로 나갔을 때는 어떤 차이가 있었나요?

기술적으로 고려할 게 많았어요. 저희는 CAD 도면을 기준으로 로봇의 위치를 추정하는데, 현장 구조물은 도면과 조금씩 다를 수 있습니다.

조명 조건도 달라요. 라이다는 철판에 반사되는 빛의 양에 따라 성능이 달라져서 환경에 맞춰 튜닝해야 하는데, 시험장과 현장은 조건이 아주 다르거든요. 같은 형광등처럼 보여도 파장대를 분석해 보면 다를 수 있습니다. 이런 조건을 하나씩 확인하고 반영하는 게 로봇을 실제로 현장에서 쓰이게 만드는 일이에요.

▲ 구조물 안에서 로봇의 위치를 실시간으로 추적하는 모습. 출처: 디든로보틱스 홈페이지

코드보다 구조가 경쟁력인 이유

Q. 하드웨어는 자석발이나 구동기처럼 강점이 눈에 보이는데, 소프트웨어의 강점은 무엇인가요?

공개된 기술은 사실상 모두가 공유하고 있어요. 그래서 회사가 어떤 철학과 방향으로 소프트웨어를 만들어 나가는지가 가장 중요하다고 봅니다.

산업 현장에 들어가는 로봇은 결국 그 일에 맞는 형태로 최적화돼요. 저희가 사족보행 로봇으로 시작했지만 디든 워커와 디든 휴머노이드를 만든 것도 같은 이유예요. 한 가지 형태로 모든 일을 할 수는 없고, 일마다 잘 맞는 형태가 따로 있거든요.

지금 로보틱스 산업에서 학습에 가장 많이 쓰는 데이터는 사람의 데이터예요. 영상에도 사람이 가장 많이 나오고, 모션 캡처로 사람의 움직임을 모으기도 쉽죠. 휴머노이드가 빠르게 발전하는 이유이기도 하고, 저희도 이 데이터를 충분히 활용할 수 있어요. 조금 더 어려운 건 사람 모양이 아닌 로봇이에요. 사족보행 로봇처럼 참고할 사람 데이터가 없는 형태도 현장에는 꼭 필요하거든요. 자석발은 더 그렇습니다. 사람은 자석으로 철판 벽에 붙어 걸어 본 적이 없으니, 따라 할 사람의 동작 자체가 없죠.

그래서 이런 로봇의 데이터를 어떻게 모을지가 중요한데, 그 프레임워크를 누가 만들어 두느냐가 관건이에요. 저희는 모델 기반 제어로 물리적으로 가능한 동작을 직접 만들어 학습 데이터로 쓰는 방식으로, 사족보행 로봇의 데이터도 쉽게 모을 수 있는 프레임워크를 만들고 있습니다.

▲ 로봇이 모은 데이터를 학습에 쓸 수 있는 형태로 자동 정리하는 과정. 출처: 디든로보틱스 홈페이지

Q. 형태가 다른 세 기체가 소프트웨어 하나를 함께 쓴다고 들었습니다.

개념 자체는 어렵지 않아요. 세 로봇이 소프트웨어 하나를 쓰면 기능을 한 번 고쳐도 세 로봇에 함께 반영되고, 관리할 코드도 하나로 줄어요. 

하지만 실제로 해 보면 이야기가 달라요. 세 로봇은 생김새도 움직이는 방식도 다르잖아요. 이걸 소프트웨어 하나로 돌리려면 실무진이 정말 고생해야 하고, 실무진의 협업 능력이 아주 좋아야 합니다.

디든 스파이더, 디든 워커, 디든 휴머노이드를 개발하던 분들이 모두 이 구조 위로 모이고 있어요. 그래서 저는 이걸 기술이 대단하다기보다, 저희의 협업이 잘 된 사례라고 봅니다.

▲ 왼쪽부터 디든 스파이더, 디든 워커, 디든 휴머노이드. 출처: 디든로보틱스 홈페이지

Q. 엔지니어 입장에서 '이 회사는 소프트웨어를 잘한다'고 말할 수 있는 기준은 무엇일까요?

저희 소프트웨어의 철학 자체가 협업이에요. 지금 있는 구성원과 앞으로 들어올 구성원 모두 혼자서도 자신만의 제어기를 만들 수 있는 분들입니다. 그런데 그 제어기를 실제 로봇에 올리기까지의 과정이 굉장히 복잡해요. 이 과정을 협업 관점에서 편하게 만든 게 저희 소프트웨어의 특징이고, 이를 고민하기 위해 플랫폼 소프트웨어 팀이 따로 있습니다.

학습으로 만든 보행 정책(policy)을 실제 로봇에 올리려면 센서가 제대로 작동하는지, 실시간성은 지켜지는지, 로그는 잘 남는지까지 모두 확인해야 해요. 겉으로는 잘 드러나지 않는 일이죠.

협업을 철저히 고려해 짠 V2는 개인 입장에서 V1보다 귀찮게 느껴질 때가 있어요. '그냥 이렇게 짜면 안 되나' 싶은 부분도 보이고요. 하지만 이런 부분을 조금씩 양보하기 시작하면 모두가 쓸 수 있는 소프트웨어가 됩니다. 개인적인 욕심은 내려놓고, 시간을 더 들여 협업할 수 있는 코드를 만드는 게 중요해요. 

▲ 시뮬레이션 안에서 여러 로봇을 동시에 학습시키는 모습. 출처: 디든로보틱스 홈페이지

Q. 디든로보틱스가 다른 로보틱스 기업과는 어떤 점이 다르다고 생각하시나요?

이것도 협업인 것 같아요. 사실 이런 협업 구조는 소프트웨어가 주력인 SaaS·플랫폼 기업들이 잘 갖추고 있거든요. 저희는 제조업 기반이라 하드웨어와 소프트웨어를 함께 다루고 실제 하드웨어를 움직여야 하니, 그 방식을 그대로 가져올 수는 없었습니다. 그래도 협업 구조만큼은 소프트웨어 기업처럼 설계해야 한다고 봤어요. 그래서 그 방식을 저희 환경에 맞게 바꿔 적용했습니다. 이 방향도 제가 혼자 정한 건 아니고, 다른 회사를 거쳐 오신 팀장님들의 이야기를 듣고 걸러낸 결론입니다.

그렇게 바꿔 적용한 방식 중에서도 가장 중요한 건 로그라고 생각합니다. 생각이 뚜렷한 사람들은 각자의 언어로 소통하기 쉬운데, 모두가 공통으로 쓰는 언어는 숫자거든요. 로그를 잘 남겨 두면 '이렇게 해 봤는데 안 됐어요'라고 길게 설명하는 대신 로그 하나를 보여 주면 되고, 대화가 훨씬 수월해져요.

가상의 조선소에서 배우고, 진짜 현장에서 걷는다

Q. 디든로보틱스의 로봇은 보행을 어떻게 배우나요?

학습에 쓰는 시뮬레이터에 자석발 관련 정보와 관절의 유격 같은 요소를 정교하게 넣고 있어요. 조금씩 저희만의 시뮬레이터를 만들어 가고 있는 셈입니다. 의미 없이 넣은 요소는 하나도 없어요.

중요한 건 학습 데이터를 만드는 방식이에요. 데이터를 만드는 방법으로는 모션 캡처, 영상, 원격 조작(teleoperation)이 잘 알려져 있죠. 저희는 여기에 더해 시뮬레이터 안에서 자체 개발한 알고리즘으로 사족보행 로봇의 움직임을 만들어냅니다. 예를 들어 블록 간 이동용 액세스홀(Access Hole)을 어떻게 통과할지를 알고리즘으로 계산해 동작을 만드는 거예요.

알고리즘으로 만든 동작은 정확하지만 느리고, 실제 로봇에서는 시뮬레이션에 없던 떨림이 생기기도 해요. 그래서 이 동작을 기준 데이터로 주고, 강화학습으로 따라 하게 하면서 떨림은 줄이고 더 빠르게 움직이도록 학습시킵니다.

학습 환경도 중요해요. 액세스홀의 위치와 모양, 론지(선박 내부 강성 보강재)의 다양한 형태, 케이블 배치 같은 조건을 저희가 경험한 내용을 바탕으로 가상 환경에 만들어냅니다.

▲ 선박 블록 구조를 바탕으로 자동 생성한 가상 학습 환경. 출처: 디든로보틱스 홈페이지

Q. 조선소 안에서 로봇의 움직임은 어떻게 정하고 계산하나요?

저희는 로봇이 할 일을 웨이포인트로 이동하기, 벽면 오르기, 액세스홀 통과하기 같은 태스크로 나누고, 이를 시나리오 하나로 묶어요. 조선소 작업은 도면에 따라 순서가 정해져 있어서, 그 순서를 시나리오로 옮겨 두면 클릭 한 번으로 정해진 순서대로 로봇이 움직입니다.

로봇이 벽면에 붙어 있을 때 다음 발을 어디에 둘지 사람이 정해 주면, 그 사이를 어떻게 움직일지는 로봇이 계산해요. 목표 지점까지 직선으로 움직일 수 없고 다리를 접고 돌려 가며 움직여야 해서, 공간에 샘플을 여기저기 뿌려 보며 경로를 찾는 샘플링 기반 방식을 씁니다.

▲ 출발 자세(파란색)에서 목표 자세(빨간색)까지 이어지는 동작을 계산하는 모습. 출처: 디든로보틱스 홈페이지

현장이 믿고 맡기는 로봇, 함께 자라는 팀

Q. 산업 현장에서는 '신뢰성'이 중요합니다. 백 번 시도해 백 번 성공하려면 소프트웨어에는 무엇이 필요할까요?

백 번 해서 백 번 성공하는 건 맞는 목표라고 생각해요. 다만 로봇은 변수가 너무 많아서, 예외 상황이 절대 생기지 않게 하라는 요구는 현실적이지 않거든요. 중요한 건 예외 상황이 생겼을 때 사람이 다치지 않고, 더 큰 손상으로 이어지지 않게 하는 거라고 생각합니다.

다양한 산업 현장에는 이미 수많은 로봇이 들어가 있어요. 하지만 이 로봇들도 고장은 나죠. 그럼에도 현장에서 쓸 수 있는 이유는, 이상이 생기면 로봇이 멈추고 어디에 문제가 있는지 알려 주기 때문입니다. 옆에 있던 사람이 그걸 보고 쉽게 해결할 수 있죠. 그래서 저희는 예외 상황이 생겼을 때 로봇을 안전하게 멈추고, 어떤 예외 상황인지 분명히 알려 주는 시스템을 만드는 데 집중하고 있어요.

예전에는 실험을 한 번 할 때마다 조마조마하며 지켜봤어요. 새 소프트웨어에서는 문제가 생겨도 로봇이 멈추고 무엇이 문제인지 알려 줘요. 그러면 사용자도 개발자도 안심합니다. 저는 그게 실패하지 않는 거라고 봐요.

Q. 디든로보틱스에서 일하면서 언제 가장 보람을 느끼시나요?

힘들다는 생각도 매일 하고, 보람도 매일 느껴요. 내부에서 정말 고생해서 만든 기능을 현장이나 시험장에서 테스트했을 때 원하는 성능이 문제없이 나오면, 그 순간이 정말 기쁩니다. 시험장에서 고생하며 스트레스를 받던 팀원들이 그때는 정말 행복해하거든요. 그 모습을 볼 때가 좋아요.

구성원들의 성장을 볼 때도 뿌듯합니다. 로봇이나 이 산업을 처음 경험하던 분들이 1~2년 사이에 많이 성장해서, 이제는 일을 요청드리면 생각보다 많은 부분이 문제없이 진행돼요. 개인이 성장해야 회사도 함께 성장한다고 생각해서, 임원진 입장에서는 구성원의 성장을 어떻게 도울지 끊임없이 고민합니다.

Q. 소프트웨어 엔지니어를 채용할 때는 무엇을 가장 중요하게 보시나요?

코드를 잘 짜는 건 기본이에요. 그런데 다들 너무 잘 짜시기 때문에, 결국 협업할 자세가 되어 있는지가 가장 중요하다고 봅니다. 

어떻게 일해 오셨는지도 물론 묻지만, 저희가 실제로 겪고 있는 협업 사례를 그대로 말씀드리고 이런 문제를 어떻게 해결하겠느냐고 물어요. 저도 정확한 답을 알 수는 없는 질문입니다. 그래서 면접 자리에서 사실상 토의를 해요. 그 과정에서 지원자가 제 말을 그대로 받아들이기만 하는지, 자신의 철학으로 다른 방향을 제시하는지를 봅니다.

Q. 앞으로 디든로보틱스에서 어떤 모습을 기대하시나요?

기대하는 모습은 처음부터 명확했어요. 기술적으로는 영화 〈아바타〉 시리즈 중 한 편에 건설 현장을 누비는 육족 보행 로봇이 나와요. 그게 정확히 저희가 원하는 방향입니다. 그 장면을 처음 봤을 때 '저거 우리 건데?' 싶을 만큼 반가웠어요.

저희 비전 중 하나는 사람이 못하는 일을 로봇이 하자는 거예요. 사람을 대체하려는 게 아니라, 사람이 하기 힘든 일을 로봇이 맡는 것입니다. 산업 현장의 그런 일들을 저희 로봇이 맡게 되는 그림을 그리고 있어요.

회사 내부적으로는, 지금 구성원들이 특색도 뚜렷하고 실력도 정말 뛰어난 분들이라고 생각해요. 네 명에서 시작해 수십 명으로 커지는 과정에서 생기는 소통 문제를 풀어 가려고 노력하고 있지만, 저도 처음 겪는 일이라 경험 있는 분들이 많이 와 주셨으면 합니다.

지금의 뛰어난 구성원들이 각자의 강점을 마음껏 발휘할 수 있는 회사, 그래서 나중에 다른 곳에 가더라도 '디든로보틱스에서 왔다'는 것만으로 인정받는 회사가 되었으면 좋겠어요.

▲ 디든로보틱스의 첫 제품인 디든 스파이더. 출처: 디든로보틱스 홈페이지

사람들 눈에 보이는 건 로봇이 잘 움직이는 모습이지만, 그 뒤에는 여러 사람의 코드가 부딪히지 않고 맞물리도록 먼저 설계한 구조가 있습니다. 로그를 공통 언어로 삼고, 문제가 생기면 로봇이 멈춰서 원인을 알려 주게 만들고, 가상의 조선소에서 배운 로봇을 진짜 현장에서 걷게 하는 일도 모두 그 구조 위에서 이뤄집니다.

디든로보틱스 소프트웨어 팀이 함께하고 싶은 엔지니어도 분명합니다. 혼자서도 제어기를 만들 수 있을 만큼 뛰어나면서, 자기 생각을 분명히 말하되 팀과 함께 더 나은 선택을 찾는 사람입니다. 로봇이 실제로 움직이는 구조를 함께 만들고 싶다면 디든로보틱스 채용 페이지에서 지금 열려 있는 포지션을 확인해 주세요.