요약
테슬라·뉴럴링크 출신 엔지니어들이 AI 에이전트가 실물 보드 없이 펌웨어를 검증하는 시뮬레이터를 내놨습니다.
본문
안녕하세요, HN 여러분. 저희는 Simantic( https://simantic.com )의 아나프와 승민입니다. 엔지니어와 AI 에이전트가 하드웨어 없이 펌웨어를 테스트하고 검증할 수 있게 해 주는 시뮬레이션 계층을 만들고 있습니다.
Simantic을 시작하기 전에 저희는 뉴럴링크와 테슬라 같은 회사에서 펌웨어 엔지니어로 일했습니다. Cybertruck과 Roadster가 아직 초기 시제품이던 시절의 프로젝트처럼 정말 멋진 일을 여럿 맡았습니다.
저희는 ChatGPT가 나오기 전부터 펌웨어 일을 했습니다. 그 뒤로 최신 AI 모델들이 지금 수준까지 발전하면서 엔지니어링과 개발 업무가 얼마나 많이 자동화되는지 지켜봤습니다. 소프트웨어에서는 AI가 컴퓨터 안에서 코드를 실행하고 테스트하는 데 몇 초면 됩니다. 하지만 펌웨어 엔지니어인 저희에게는 그런 호사가 없었습니다. AI 에이전트가 펌웨어를 몇 초 만에 작성해도, 테스트하려면 실물 보드에 펌웨어를 올려야 했습니다. 그다음 10여 년 전에 만들어진 소프트웨어가 딸린 비싸고 불편한 도구로 직접 테스트를 돌려야 했습니다.
검증 주기를 앞당기려고 저희는 시뮬레이션 계층을 만들었습니다. 이 계층 덕분에 AI 에이전트는 엔지니어가 대신 테스트를 돌려 주기를 기다리지 않고, 직접 펌웨어를 테스트해 증거를 바탕으로 판단할 수 있습니다. 예전에는 개발 보드에서 펌웨어를 손으로 테스트하는 데 몇 시간씩 썼지만, 이제는 저희 시뮬레이션으로 몇 초 만에 검증합니다.
제공하는 기능은 다음과 같습니다.
- 터미널을 벗어나지 않고 API 호출 한 번으로 프로그래밍하고 실행할 수 있는 가상 개발 보드입니다.
- 저희 시뮬레이션을 검증 엔진으로 삼아 증거에 근거해 판단하는 펌웨어용 AI 코드 리뷰어입니다.
- 커밋할 때마다 마이크로컨트롤러의 시뮬레이션 버전으로 펌웨어를 검증하는 하드웨어 프로젝트용 CI/CD 파이프라인입니다.
AI 코드 리뷰 세션에서 저희 시뮬레이션을 쓰는 데모는 다음 영상에서 볼 수 있습니다: https://www.youtube.com/watch?v=kBK1ZjGWWbQ
이용자들은 비행 제어기, 전기차, 로봇, 위성 같은 분야의 베어메탈(운영체제 없이 하드웨어에서 바로 돌아가는 방식)과 RTOS(실시간 운영체제) 개발에 Simantic을 쓰고 있습니다. 항공 전자 장비와 자동차처럼 안전이 핵심인 시스템에서는 튼튼한 시뮬레이션 체계가 대단히 중요합니다. 펌웨어를 고칠 때마다 사람의 목숨이 걸리기 때문입니다. 수십만에서 수백만 달러짜리 기계라면 더욱 그렇습니다.
최근에는 위성을 만드는 초기 우주 스타트업이 아직 손에 없는 하드웨어를 대상으로 펌웨어를 테스트하도록 도왔습니다. 이런 위성용 개발 모듈은 10만 달러가 넘기도 하는데, 저희는 비용과 시간을 100분의 1로 줄여 줬습니다.
사업 초기에 저희는 더 나은 시뮬레이션을 만들겠다는 생각은 세웠지만, 어떻게 만들지는 뚜렷하지 않았습니다. 그래서 펌웨어 업계에서 이미 쓰이는 오픈소스 에뮬레이션 프레임워크인 Renode( https://github.com/renode/renode )와 QEMU( https://www.qemu.org/ )를 바탕으로 소프트웨어를 개발하는 방안을 검토했습니다. 사실상 Renode를 감싼 래퍼(기존 도구를 겉에서 감싸는 프로그램)인 MVP(최소 기능 제품)를 만들었지만, 이 방식에 한계가 많다는 것을 곧 깨달았습니다.
Renode 쪽 개발 속도에 발목이 잡혔습니다. 마주친 문제를 고치려고 GitHub에 기여도 해 봤지만, 빠르게 움직여야 하는 저희 같은 스타트업에는 기능이 병합되는 속도가 충분히 빠르지 않았습니다.
Renode는 Dotnet으로 만들어졌는데, 저희가 바라는 것보다 느렸습니다. Renode는 모든 코드를 아직 손으로 쓰던 2017년에 나왔으니 돌이켜 보면 이해가 됩니다. 그래도 언어 자체에서 오는 한계가 있었습니다.
오픈소스 도구들은 저희가 절대 쓰지 않을 기능으로 비대해져 있었습니다. 기능의 폭은 넓었습니다. 하지만 빼거나 고칠 수 없다는 이유만으로 우회해야 할 것이 많았습니다. 이용자들은 시뮬레이션 정확도에 불만을 제기했습니다. Renode는 근본적으로 에뮬레이터입니다. 그런데 이용자들, 특히 타이밍 정확도가 핵심인 시스템을 만드는 분들은 펌웨어를 검증하기에 정확도가 부족하다고 봤습니다.
이런 문제들 때문에 저희는 전부 Rust로 작성한 시뮬레이션 엔진을 처음부터 새로 만들었습니다.
저희 시뮬레이션은 정확도에 집중합니다. 오픈소스 프레임워크는 확장성과 개발자 경험에 치중하는 경우가 많습니다. 그래서 일부 모델을 깊이 파기보다 다양한 모델을 갖추는 쪽으로 타협한 부분이 많았습니다.
저희는 시뮬레이션 모델을 실제 하드웨어에 최대한 가깝게 맞추려고 자체 하드웨어 검증 장비를 하루 24시간 돌립니다. 차이가 발견되면 최대한 빨리 고칩니다. 지금은 개발 보드를 Saleae Logic MSO와 SWD 버스에 연결해 리눅스 PC로 제어하는 형태입니다. 이 PC에서 Claude가 24시간 내내 이런 차이만 찾고 있습니다.
클라우드 호스팅 시뮬레이터는 지금 바로 쓸 수 있습니다! 개발자 요금제 라이선스에는 네이티브 바이너리도 포함되어, 제한 없이 각자의 컴퓨터에서 펌웨어를 로컬로 실행할 수 있습니다.
https://simantic.com/cloud-sim 에서 살펴보시기 바랍니다. 여러분의 GitHub 저장소에서 AI 펌웨어 리뷰 봇을 쓰려면 여기서 시작하시면 됩니다: https://simantic.com/dashboard/simantic-bot .
현재 STM32F0, F4, H7 시리즈의 일부 모델과 ESP32-S3/C3, RP2040을 지원합니다. 매주 새 모델을 내놓고 기존 모델을 개선하려고 계속 작업하고 있습니다.
감사합니다. 궁금한 점이 있으면 [email protected] 로 메일을 보내 주시기 바랍니다.
HN 반응
- Claude로 에뮬레이터를 직접 만들거나 벤치 테스트를 돌리면 된다는 반론에, 작성자들은 문서에 없는 칩 동작과 유지보수를 강점으로 꼽았습니다.
- 실제 칩과의 차이를 수치로 공개해야 신뢰를 얻는다는 요구가 이어졌고, 아날로그 회로까지 다루지 못하는 한계도 지적됐습니다.
이건 칩을 시뮬레이션하는 거잖아요. 그럼 아날로그와 디지털이 섞여 있고 복잡하기는 매한가지인 IC가 잔뜩 올라간 제 실제 보드의 시뮬레이션은 여전히 제가 직접 짜야 하나요?
아쉽지만 그렇습니다. 지금은 혼합 신호 영역이 제한적이고, 이는 의도한 설계입니다. IC와는 데이터 수준이나 핀 수준 트랜잭션으로 상호작용해야 하고, 그 신호도 디지털 레벨까지만 다루며 아날로그는 없습니다.
사실 펌웨어 혼합 신호 코시뮬레이션은 원래 저희 제품 구상에 들어 있었습니다. 펌웨어를 돌리면 SPICE 수준의 시뮬레이션이 같이 돌아가는 식이었죠. 하지만 속도와 정밀도 사이의 균형이 아직은 맞지 않았습니다. 장기 프로젝트에 힘을 분산하다 보니 YC 기간 동안 보여줄 결과가 없었고요.
아날로그 IC 용도로 비슷한 질문을 하시는 고객이 많아서, 이 문제는 반드시 다시 다룰 겁니다. 한 번에 한 걸음씩 가야 해서요.
핀 수준 모델링으로는 놓치기 쉬운 곳이 ADC입니다. "펌웨어 버그"라고 부르는 것 중 상당수는 사실 큰 분압 저항 때문에 샘플 커패시터가 제때 충전되지 못해서, 읽은 값이 낮게 나오거나 직전 채널에 영향을 받는 문제거든요. 소스 저항과 샘플링 시간의 관계만 모델링해도 상당수를 잡아낼 수 있을 겁니다.
저도 같은 생각이에요. 게다가 제 펌웨어는 Claude가 쓰는데 정말 꽤 잘 써요. 벤치 환경에서 테스트까지 할 수 있고요. 그래서 솔직히 이 시뮬레이터가 살아남을 가능성은 크지 않다고 봐요. 쓴소리이긴 한데, 빨리 받아들일수록 좋을 거예요.
네, Claude가 꽤 훌륭한 펌웨어를 쓸 수 있다는 데는 전적으로 동의합니다! 하지만 엔터프라이즈 개발팀 규모에서 테스트를 하려면 시뮬레이션이 필요합니다. 중요한 임베디드 시스템에서는 지금까지도 그랬고 앞으로도 그럴 겁니다. 오히려 반대라고 생각합니다. 시뮬레이션의 필요성은 더 커지기만 할 겁니다. 사람들이 LLM에 펌웨어를 맡기기 시작한 것도 올해부터였고, 업계에서 본 바로는 AI가 좋아질수록 개발에 쓸 수 있는 시뮬레이션도 더 좋기를 바라게 됩니다.
또 다른 요인은 실리콘 공급 부족입니다. 특히 자동차 업계에서 두드러지는데, 팀들이 막힌 곳을 풀려고 더 나은 시뮬레이션을 찾으면서 수요가 급증하고 있습니다.
에이전트로 대규모 출시를 하려면 지금은 그 어느 때보다 좋은 테스트 파이프라인이 필요합니다. 저희는 벤치 테스트를 대체하려는 것이 아니라, 여러분이 갖춘 환경을 더 강화하려는 것입니다.
물론 하드웨어와 남는 시간만 있다면 LLM을 어떤 하드웨어 환경에서 몇 주씩 계속 반복해서 돌리면 되기는 합니다.
그런데 AI 덕분에 하드웨어 업체가 제품과 함께 시뮬레이션 모델을 제공하는 일이 흔해진다면요? 저는 그쪽으로 가기를 바라고 있어요. 그렇게 안 되더라도 FOSS 애호가들이 모델을 만들어 줄지도 모르고요.
하드웨어 업체가 자사 하드웨어와 함께 시뮬레이션 모델을 제공해야 하고, 또 제공할 수 있다는 말씀은 맞습니다. 칩 업체들은 테이프아웃 전에 전적으로 시뮬레이션에 의존해 칩을 테스트하니 가능하다는 건 알고 있습니다.
저희도 칩 업체와 협력해 보려 했습니다(이름은 밝히지 않겠지만 세계 10대 마이크로컨트롤러 설계사 중 두 곳입니다). 그런데 현실에서는 업체가 직접 시뮬레이션을 제공하는 게 그들에게는 다소 앞뒤가 맞지 않는 일입니다.
업체는 칩을 팔아서 돈을 버는데, 시뮬레이터를 제공하면 사람들이 칩을 덜 살 거라고 생각합니다. 제공하더라도 Synopsys Virtualizer처럼 라이선스 하나에 50만 달러나 하는 엄청나게 비싼 제품일 겁니다.
RISC-V나 오픈소스 MCU는 시뮬레이션하기 쉽습니다. RTL을 Verilator 같은 것에 돌리기만 하면 완전히 동작하는 시뮬레이션이 생기니까요.
저희는 칩 업체들이 결국 그렇게 해 주기를 바랍니다. 저희도 펌웨어 엔지니어이고, 현장에서 일할 때 필요했던 시뮬레이션 소프트웨어를 만드는 것이 목표입니다. 저희가 만들든 업체가 만들든 모두에게 좋은 일이라고 생각합니다.
누군가 만들어 준다면 물론 좋은 일이지만, 곧 AI의 도움으로 데이터시트만 있으면 누구나 그런 시뮬레이션 모델을 만들 수 있게 될 것 같아요. 설령 그렇게 간단하지 않더라도 오픈소스 쪽 사람들이 만들 거고요.
안녕하세요.
먼저 출시를 축하드립니다. 저는 이런 제품을 많이 써 봤는데, 꼭 필요한 제품입니다. 이 분야에는 모든 경우에 맞는 하나의 해법이 없습니다. 벤더마다 저마다의 특이점이 있으니까요. 그래서 이 문제는 도전해 볼 만한 훌륭한 문제이고, 이 일에 뛰어드신 것에 박수를 보냅니다.
Renode와는 어떻게 다른지 조금 더 설명해 주실 수 있나요?
그리고 기존 업체들이 탄탄하게 자리 잡은 시장에 들어가시는 겁니다. 펌웨어 대부분은 중국에서 개발되고 있고요. 이런 상황에서 어떻게 자리를 잡을 계획이신가요?
감사합니다. 말씀하신 대로 시장은 매우 파편화되어 있습니다. 그래서 작게 시작해서 stm32를 주력으로 깊이 모델링하고 있습니다. 특이점은 매일 새로 발견하고 있습니다! errata에도 데이터시트에도 없는 MCU 컨트롤러의 동작을 본 적이 있는데, 그게 현장 테스트의 묘미입니다.
저희가 Renode와 가장 다른 점은 실리콘 검증과 시뮬레이션을 정직하게 유지하겠다는 의지라고 생각합니다. 실측한 차이를 실제로 공개하는 시뮬레이터를 찾기가 어려웠고, 저희는 그 방향으로 갈 겁니다. 실리콘 검증 벤치마크는 아직 공개하지 않았지만 앞으로 몇 달 안에 공개할 예정입니다!
기존 업체들은 이 틈새를 충분히 채우지 못합니다. 그래서 저희가 존재하고, 스타트업으로서 이 틈새가 필요한 분들을 위해 그 자리를 채울 수 있습니다. 중국이든 다른 어디든 마찬가지입니다.
Renode 래퍼 이야기는 유익합니다. 직접 만들 것인가 감쌀 것인가(build-versus-wrap)라는 결정이 많은 인프라 스타트업이 막히는 지점이니까요. 래퍼는 데모까지 빠르게 가게 해 주지만, 업스트림 로드맵과 버그를 어느 쪽도 통제하지 못한 채 떠안게 됩니다. 안전이 중요한 고객에게는 속도보다 충실도가 더 어려운 문제일 것 같습니다. 회의적인 항공전자 팀에게 시뮬레이션한 주변장치 타이밍이 실제 실리콘과 일치한다는 것을 어떻게 보여 주실 건가요? 흔히 쓰는 MCU 몇 종에 대해 하드웨어 트레이스와의 상관관계 데이터를 공개하면 어떤 기능 목록보다 신뢰를 얻는 데 도움이 될 것 같습니다.
맞습니다, 정확한 지적입니다. 저희가 이야기를 나눠 본 여러 항공우주 팀이 CI에 Renode와 QEMU를 써 보려다가, 타이밍 메커니즘이 형편없고 매우 부정확해서 결국 포기했습니다.
저희는 시뮬레이션의 타이밍을 최대한 정확하게 만들려고 노력합니다. 실리콘과 시뮬레이션 사이의 모든 차이를 정리한 보고서를 곧 공개해서, 이런 팀들이 무엇을 기대해야 하는지 정확히 알 수 있게 할 예정입니다.
저희는 HIL 테스트를 대체하려는 것도 아닙니다. 저도 펌웨어 엔지니어로서 하드웨어가 언제나 진실의 원천이라는 것을 알고, 그 점을 바꿀 생각은 없습니다. 저희가 할 수 있는 일은 하드웨어에서 해야 하는 테스트의 양을 줄이는 것입니다. HIL 테스트는 앞으로도 항상 느리고 번거로울 테니까요. 애플리케이션 로직이나 CAN 버스 같은 곳에 쓰레기 데이터를 재현하는 일은 시뮬레이션에서 테스트하는 편이 훨씬 낫고, 저희는 바로 그 틈을 공략하고 있습니다.
궁금한 점이 더 있으면 알려 주세요!
LLM 봇 계정입니다.
저는 펌웨어 엔지니어인데, Claude와 Qwen에게 두 시간쯤 시켜서 멀티칩 에뮬레이터를 직접 만들었어요. 여러 펌웨어 이미지를 gpio, UART, SPI 등으로 서로 연결할 수 있고요. 제가 프롬프트로 시킨 것도 아니에요. 걔네가 알아서 이런 기능이 필요하다고 판단하고 에뮬레이터를 만들었어요.
Claude가 이미 알아서 제안하고 만들어 준 것 말고, 이 제품이 제공하는 게 뭔가요?
직접 만든 에뮬레이터에서 제가 알고 싶은 건 누가 그것을 검증하느냐입니다. 펌웨어를 쓴 모델이 데이터시트를 보고 주변장치 모델까지 쓰면, 예를 들어 SPI FIFO 플러시나 타이머 프리스케일러를 잘못 읽었을 때 그 오해가 양쪽에 모두 박혀서 테스트가 엉뚱한 이유로 통과합니다. 창업자분들이 말한 errata 수준의 특이점이야말로 데이터시트에서 뽑은 모델에는 들어 있지 않은 것입니다. 현실적인 검증법은 차분 비교입니다. 실제 보드에서 버스에 로직 애널라이저를 물려 트레이스를 몇 개 캡처하고, 같은 자극을 에뮬레이터에 재생해서 사이클 타이밍과 레지스터 상태를 비교하는 것이죠. 그러지 않는다면 직접 만든 시뮬레이터의 통과 결과는 검증되지 않은 것으로 취급하겠습니다.
에뮬레이터는 누구나 만들 수 있습니다. ISA는 공개 문서화되어 있고 MCU 데이터시트도 공개되어 있습니다. 글에서 썼듯이 Renode나 QEMU 같은 오픈소스 에뮬레이터도 있고요. 저희와 Claude로 직접 에뮬레이터를 만드는 방식 사이에는 크게 두 가지 차이가 있다고 봅니다.
MCU의 ISA와 주변장치 동작이 문서화되어 있어도, LLM만으로는 제대로 다룰 수 없는 하드웨어의 미묘한 부분이 있습니다. 레지스터 트랜잭션 타이밍, 그리고 하드웨어 버그(그렇습니다, 칩 설계자도 설계에서 실수를 하고 그것은 문서에 나오지 않습니다) 같은 것은 몇 주씩 계속 벤치 테스트를 해야 발견하고 고칠 수 있습니다.
유지보수입니다. 네, Claude는 정말 뛰어납니다. 하지만 여전히 실수를 합니다. 저희는 그 점을 알고 있고, 버그가 있을 때마다 시뮬레이션 소프트웨어를 계속 업데이트합니다. 반면 제품을 만들고 코드를 출시하는 것이 일인 펌웨어 엔지니어라면, 하루 종일 시뮬레이터를 고치고 업데이트하는 것보다 본업에 시간을 쓰고 싶으실 거라고 생각합니다. 유지보수는 저희가 해 드리니, 만들고 싶은 것에 집중하실 수 있습니다.
답변이 되었기를 바랍니다! AI가 시간과 자원만 충분하면 이를 못 한다고 주장하는 것은 아닙니다. 다만 이런 가치를 알아보시는 분들은 다른 일에 시간을 쓰고 싶어 하실 뿐입니다.
출시 축하드려요! 로보틱스나 칩 회사가 쏟아져 나오는 지금이 이런 제품에 정말 좋은 시기 같아요.
하드웨어 시뮬레이션은 잘 몰라서 그런데, 시뮬레이션에서 결정적(deterministic)인 부분과 확률적이거나 ML 기반인 부분은 각각 어느 정도인가요?
시뮬레이션 자체는 결정적입니다. 입력이 같으면 출력도 같습니다. 다만 하드웨어 동작에 대한 데이터를 수집하는 과정에는 자연히 확률적인 부분이 조금 있습니다. ML 기반 모델링은 전혀 하지 않습니다. 아쉽게도 내부에서 엄청 빠른 LLM이 돌아가는 건 아닙니다.
AI의 도움을 받는 하드웨어 개발에서 큰 병목을 해결하는 제품입니다. AI 에이전트는 펌웨어를 빠르게 생성할 수 있지만, 하드웨어 동작에 맞춰 믿을 수 있게 테스트하는 것은 전혀 다른 문제입니다. 시뮬레이션 정확도와 실제 실리콘 대상의 지속적인 검증에 초점을 맞춘 점이 특히 흥미롭습니다. AI 코딩 에이전트가 발전함에 따라 임베디드 개발 워크플로의 중요한 일부가 될 것으로 보입니다.
이미 발전했다고 감히 말씀드리겠습니다!
출시 축하드려요, 정말 멋진 제품이네요!!
저는 소프트웨어 쪽에서 에이전트 툴링을 다루는데, 말씀하신 양상이 저희 쪽에서도 똑같이 나타나요. 생성은 빠르고 싸졌는데 검증은 여전히 느리고 사람 손을 타요. 소프트웨어에서는 리뷰 대기열이 병목이 됐고요.
펌웨어에서는 그 대기열이 물리적인 보드였으니 더 심하겠네요!
검증 장비가 찾아낸 차이를 어떻게 분류하시는지 궁금해요. 시뮬레이션과 보드의 타이밍이 어긋나면 어느 쪽이 틀렸는지 어떻게 판단하세요? 그리고 모델이 아니라 보드 설정 탓인 경우는 얼마나 되나요?
오늘 행운을 빌어요, 응원할게요!
제가 하는 Python/Postgres 작업에서는 단위 테스트가 락 동작을 잡아내지 못해서, CI에서 일회용 Postgres 컨테이너에 마이그레이션을 돌려요. 시뮬레이터와 보드가 어긋날 때 실패한 보드 트레이스를 정확한 펌웨어 리비전과 함께 보관하는 것도 같은 종류의 증거가 될 것 같아요. 보드를 기준으로 삼는다는 건 저도 납득이 되고요.
하하, 덕분에 생각났는데, 제 펌웨어와 통신하려고 직접 짠 USB 엔드포인트 C++ 코드를 pytest로 감싸는데 AI가 Python GIL을 깜빡해서 호스트 USB가 전부 먹통이 된 적이 있어요. 락이 제 코드에 어떤 영향을 주는지 저도 몰랐고요. 그래도 Opus 4.6이었으니까 봐줬어요.
감사합니다. 맞아요, 어디서 이야기를 나눠 봐도 검증이 새로운 병목입니다. 그래도 하드웨어에서는 꽤 간단합니다. 보드가 왕입니다! 지금 저희 환경은 앞으로 몇 달 뒤보다 단순한 편이에요. "시나리오"에 구성 요소를 점점 더 추가할 거거든요.
그래도 좋은 지적입니다. 저희도 테스트 중인 개발 보드에서 나온 벤치 아티팩트와 실제 양산 PCB에서는 나타나지 않을 현상을 구분하는 문제를 고민하고 있어요.
Simantic이 Siemens Simatic S7-1500 PLC 지원을 추가하면 헷갈리려나요?
하하, 세상에 PLC 시뮬레이션 소프트웨어가 또 하나 생기는 건 바라지 않겠죠?
지원하는 모델 목록이 문서에 있나요? 제가 제일 먼저 찾아본 게 그거였거든요.
오늘 중으로 공개할 예정입니다. 업데이트가 워낙 많다 보니 모델 지원 현황을 계속 최신으로 유지하는 게 부담이 됐어요. 그래도 cloud-sim API 자체가 실행 가능한 모델을 보여 줍니다. STM32F042/F048, ESP32-C3, RP2040, STM32F072, STm32F446, STm32 F401입니다. 곧 올리겠습니다!
왜 로컬 에뮬레이터가 아니라 클라우드 서비스죠? 이해가 안 되네요.
둘 다 제공합니다! 클라우드 서비스는 지금 누구나 써 볼 수 있고, 유료 로컬 라이선스 버전도 있어요.
저희도 처음에는 로컬만 제공했는데, 클라우드에는 장점이 몇 가지 있다는 걸 금방 알게 됐어요. 사용자가 GitHub 연동을 매끄럽게 쓸 수 있고, 커밋마다 알아서 돌아가는 설정을 선호하는 분도 꽤 많거든요.
클라우드의 편리함을 쓰셔도 되고, 개발자 라이선스로 직접 구성하셔도 됩니다.