안녕하세요, 저는 로넌입니다. Equal1에서 양자 소프트웨어 엔지니어링 팀을 이끌고 있습니다. Equal1은 첨단 스핀 기반 기술을 활용하여 완전 통합형 양자 컴퓨터를 설계하고 구축합니다. Equal1은 아일랜드, 미국, 캐나다, 일본, 루마니아, 그리고 제가 거주하는 네덜란드에 사무소를 두고 있습니다. 이전에는 양자 제어 시스템을 만드는 회사인 Qblox에서 근무했습니다.

Equal1에서 저는 고성능 RacQ 양자 컴퓨터를 구동하는 풀 스택 시스템 구축에 집중하고 있습니다. 이 시스템은 수천 개의 논리적으로 보정된 큐비트 이상으로 확장 가능하도록 설계되었습니다. 어떤 사람들은 이 시스템을 양자 프로세서(QPU)의 “두뇌"라고 부릅니다.

저는 매일 새로운 것을 배울 수 있고, 훌륭하고 유능한 동료들과 함께 일할 수 있어서 제 일이 정말 흥미롭다고 생각합니다. 제가 배운 것들을 공유하기 위해 이 블로그를 시작했어요. 물론, 비밀을 누설하는 건 아니고요!

궁금한 점이 있으면 ronan으로 이메일을 보내주세요. 더 자세한 정보를 원하시면 LinkedIn에서 연결해 주세요!

면책 조항: 저는 낮에는 Equal1에서 근무하지만, 이 블로그는 개인적인 프로젝트이며 고용주의 견해를 반영하는 것이 아닙니다. 여기에 공유된 생각, 잡담, 의견은 전적으로 저의 것이며, 그 누구의 검토, 승인 또는 수정도 거치지 않았습니다.

시스템 아키텍처 개요 Link to heading

큐블록스 재직 당시 제 역할은 시스템 아키텍트였습니다. 아래는 당시 제 역할에 대한 메모입니다.

시스템 아키텍처 역할 Link to heading

시스템 아키텍트(sysarch)가 정확히 어떤 일을 해야 하는지에 대한 질문을 자주 받습니다. 답은 회사, 사업 국가, 사업 영역에 따라 다르지만, 한 가지 공통된 개념이 있습니다. 바로 소통입니다.

네, 아키텍트의 역할은 개발 및 엔지니어링 팀, 최고 경영진, 고객 등 누구에게든 복잡한 아이디어를 간단하게 전달하는 것입니다. 그 시작은 고객 및 제품 팀과 함께 문제를 이해하는 것인데, 이것이 바로 이 직무의 가장 흥미로운 부분입니다. 고객을 만족시키는 솔루션을 만들어내는 것이죠!

그다음으로는 전통적인 시스템 요구사항 분석이 이어지고, 종종 개념 증명 프로토타입 제작 단계가 있는데, 이 단계에서 저는 주로 직접 참여합니다. 그 후 제품 개발이 진행되는데, 저는 기술 리더로서 제품이 완성될 때까지 여러 부서의 팀과 협력합니다. 마지막으로 제품 출시 후 서비스가 제공됩니다.

건축적 결정 Link to heading

어떻게 아키텍처 관련 결정을 내릴 수 있을까요? 아키텍트의 역할은 직접 결정을 내리는 것이 아니라, 결정을 내리는 데 필요한 정보를 통합하여 문제의 틀을 잡는 것입니다. 예를 들어, 제품 팀(“이 신제품 개발 비용은 얼마인가요? 출시 기간은 얼마나 걸리나요?")이나 CxO 팀(“이 새로운 기술에 투자할 가치가 있을까요? 투자 수익률(ROI)과 장기 전략은 무엇인가요?")의 의견을 수렴하는 것이죠.

이는 주관적인 판단 없이 각 가능한 해결책의 장단점을 조사하고 정의함으로써 데카르트적 관점을 취하는 것을 의미합니다. 또한 구현 노력뿐만 아니라 장기적인 유지 관리, 운영 비용, 팀의 인지 부하까지 고려하여 비용 대비 효과를 평가하는 것을 의미합니다.

더 중요한 것은 사회적 조화를 협상하는 것 또한 중요하다는 점입니다. 엔지니어들이 싫어하거나 제품 관리자들이 이해하지 못하는 아키텍처 결정은 실패할 수밖에 없기 때문입니다. 결정을 내린다는 것은 모든 사람을 그 여정에 참여시키는 것을 의미합니다. 제품 및 비즈니스 단계에서는 선택이 비즈니스 가치를 창출하는지 확인해야 합니다. 엔지니어링 단계에서는 선임 엔지니어들의 의견을 구하여 실행에 대한 책임감을 갖도록 해야 합니다.

리팩토링 기준 Link to heading

소프트웨어 제품을 보유한 모든 기업이 끊임없이 던지는 질문이 있습니다. 바로 “언제, 왜 리팩토링을 해야 할까?“입니다. 기존 제품이 느리고 불안정하며, 누적된 기술 부채로 인해 문제 해결에 너무 많은 시간이 소요될 때 리팩토링을 해야 한다고 생각하는 것이 일반적입니다. 하지만 이것이 항상 정답은 아닙니다. 오히려 아키텍트의 역할은 제2의 시스템 효과(https://en.wikipedia.org/wiki/Second-system_effect)를 예방하는 것입니다.

제 개인적인 철학은 day-1 결정을 적용하고, “양방향 문” 테스트를 통해 이를 검증하는 것입니다. 즉, 리팩토링이 단방향 문(기본 데이터베이스 패러다임 선택처럼 되돌리기 거의 불가능한 문)인지, 아니면 양방향 문(내부 라이브러리 선택처럼 나중에 쉽게 변경할 수 있는 문)인지 확인하는 것입니다. 단방향 문은 철저한 검증이 필요하고, 양방향 문은 신속한 처리가 중요합니다.

공학 문화 진흥 Link to heading

언뜻 보기에 시스템 아키텍트의 역할은 엔지니어링 팀(문제 해결 시간 단축)과 제품 팀(제품 출시 시간 단축) 모두에게 가치를 창출하는 적절한 엔지니어링 문화를 옹호하는 것이기도 합니다.

영웅 vs 엔지니어: 문제 해결에만 보상하면 오히려 문제를 악화시킨다. 일반적으로 개발 과정에서 시간을 절약하기 위해 지금 엔지니어링/소프트웨어 스택에 투자하는 것이 좋지만, 실제 과제는 투자와 과잉 설계 사이의 적절한 균형을 찾는 것입니다. 제품 개발과 유지 관리를 더 쉽게 만들어주는 적절한 도구와 소프트웨어 구성 요소를 개발하는 것이 중요하지만, 가치를 더하지 않는 부분을 과도하게 설계하는 것은 바람직하지 않습니다.

이는 또한 아키텍트가 제품 팀 및 최고 경영진 팀과 자주 소통하여 끊임없이 문제 해결에만 매달리는 대신 미래 지향적인 엔지니어링에 노력을 기울이는 팀의 업무를 장려해야 함을 의미합니다.

팀 재편성 Link to heading

어느 시점에 이르면 시스템을 리팩토링하는 것만으로는 충분하지 않게 되는데, 이때 콘웨이의 법칙이 적용됩니다. “시스템을 설계하는 모든 조직은 조직의 커뮤니케이션 구조를 그대로 복제한 구조를 가진 설계를 만들어낼 것이다.”

해결책은 항상 인력 재배치가 아니라, 팀의 산출물을 비즈니스 조직에 맞춰 재조정하여 두 팀의 시너지 효과를 개별 구성원의 합보다 크게 만드는 것입니다. 팀의 소통 구조가 비효율적이어서 충분한 가치를 창출하지 못한다면, 팀의 성과를 비즈니스에 더 큰 가치를 제공하는 더 나은 구성 요소와 API 약속으로 정의하는 시스템을 구축해야 합니다. 반대로 팀이 새로운 구성 요소를 개발하지 못한다면, 작업을 더 간단한 구성 요소로 나누고 더 명확한 API 약속을 제공하도록 해야 합니다.

하지만 더 중요한 것은 이것이 팀과 조직 간의 사회적 조화를 이끌어내는 데 있다는 점입니다. 팀이 스스로 변화하여 더 많은 가치를 창출하는 회사를 상상해 보세요. 그것이야말로 이상적인 상황이 아닐까요?

AI와 디자인 루프 Link to heading

AI는 제 업무 방식을 어떻게 바꿨을까요? 엄청나게 많이 바꿨습니다! 개발자들이 분위기 코딩을 하듯이, 건축가들은 LLM에 직접 입력하여 코드를 생성할 수 있는 “분위기 디자인”(그리고 분위기 시스템 요구사항)을 더 잘 작성해야 합니다.

AI는 디자인 반복 작업을 할 때 매우 유용합니다. 동일한 디자인의 다양한 변형을 빠르게 생성하여 여러 옵션을 신속하게 탐색할 수 있도록 해주기 때문입니다. 이렇게 생성된 디자인은 프로토타입을 빠르게 제작하여 가정 사항과 개발 복잡성을 검증할 수 있습니다.

하지만 더 중요한 것은 AI가 엔지니어를 대체하기 위한 것이 아니라 그들의 역량과 창의성을 향상시키기 위한 도구라는 점을 기억하는 것입니다. AI는 엔지니어의 판단과 전문 지식을 대체하는 도구가 아니라 설계 프로세스를 개선하는 도구입니다.

예를 들어, 아래 그림을 확인해 보세요. 오른쪽 그림이 큐비트 3( _Z₂Z₃ )에 오류가 있는 것처럼 보이지만 실제로는 큐비트 1과 ₂ 에 비잔틴 오류가 있다는 것을 몇 명의 LLM(Little Quiz Manager)이 알려줄 수 있을까요? (전체 설명)

일부 엄선된 일러스트 Link to heading