Traversal.ai 공동 창업자들이 복잡한 엔터프라이즈 시스템의 인시던트 문제 해결 및 근본 원인 분석에 AI와 인과관계 머신러닝을 활용하는 독특한 접근 방식을 소개합니다. 이들은 기존의 관측 도구와 현재 AI 애플리케이션의 한계를 지적하며, 현대 마이크로서비스 아키텍처 내에서 방대한 양의 파편화된 원격 측정 데이터(로그, 메트릭, 추적, 코드, Slack 메시지 등)가 효과적인 문제 해결을 거대한 탐색 문제로 만든다고 강조합니다. Traversal의 핵심 혁신은 LLM의 의미론적 이해와 시계열 데이터의 통계 분석을 동적으로 결합하여 잠재적인 근본 원인을 지능적으로 좁혀나가는 에이전트 아키텍처에 있으며, 상관관계를 인과관계로 효과적으로 전환합니다. 이들의 제품은 소프트웨어 유지보수를 반응적인 '불 끄기'식 방식에서 벗어나, 명확한 플레이북이 없을 때도 신뢰할 수 있는 AI 기반 통찰력을 제공하여 '영웅 엔지니어' 문제를 해결하고, 보다 능동적이고 지능적인 프로세스로 전환하는 것을 목표로 합니다.
1. Traversal 창업자들의 배경과 회사 설립 계기
Latent Space 팟캐스트는 Kernel Labs의 Allesio와 Small AI의 Swixs가 진행하며, 이번 에피소드에서는 Traversal 공동 창업자인 Anish와 Raz를 초대했습니다. Anish는 싱가포르 출신으로 15년간 미국에서 기술 분야에 몸담았으며, MIT에서 컴퓨터 과학 박사 학위를 취득했습니다. 그의 연구는 주로 인과관계 머신러닝(Causal Machine Learning)과 강화 학습(Reinforcement Learning)에 초점을 맞추었습니다.
"상관관계가 인과관계가 아니라는 생각, 즉 AI 시스템이 데이터에서 인과관계를 어떻게 찾아내는지, 그리고 강화 학습은 본질적으로 광범위한 공간을 어떻게 효과적으로 탐색하는지에 대한 연구였습니다."
원래는 AI 연구 분야에서 교수로 평생 일하고 싶어 컬럼비아 대학 교수로 재직 중이었지만, 2024년 1월부터 LLM과 AI 에이전트 분야의 폭발적인 발전을 보며 기술 스타트업에서 새로운 도전을 결심했습니다. Anish는 MIT 동문인 Raz, Raj, Ahmed와 함께 Traversal을 창업했습니다. 특히 Citadel Securities 출신인 Ahmed는 시스템 가동 시간(uptime)이 매우 중요한 환경에서 문제 해결(troubleshooting)과 인시던트 대응(incident response)을 깊이 고민해왔던 경험을 바탕으로 이들에게 문제 해결 분야를 제안했습니다.
Raz는 인도에서 성장했으며, 그 역시 AI 연구 분야에서 경력을 쌓았습니다. 2015년 박사 과정을 위해 미국 버클리 대학에 입학했고, 무선 시스템의 관측 가능성(observability)을 다루는 스타트업 인턴십을 통해 인과관계 머신러닝에 흥미를 갖게 되었습니다. 그는 Wi-Fi 문제의 근본 원인(디바이스 문제인지, LAN 문제인지)을 분석하는 것에 매료되어 박사 과정 동안 이 분야를 집중적으로 연구했습니다. MIT에서 박사 후 연구원(postdoc)으로 재직하며 Anish를 만나 연구 관심사를 공유했고, 뉴욕에서 교수 생활을 시작하며 함께 Traversal을 설립했습니다.
"저는 상관관계가 인과관계가 아니라고 말할 때 농담 삼아 말합니다. '나는 학위가 있으니 이 말을 해도 돼. 너희는 따라야 해'라고요." 🤣
두 창업자는 처음에 명확한 아이디어 없이 매일 위워크에 모여 고민하다가, 인과관계 머신러닝, 강화 학습, 그리고 AI 에이전트의 교차점에서 문제 해결 분야가 완벽한 해결 과제임을 깨달았습니다. 그들은 이 분야가 AI 관점에서 "매우 풍부한 문제"라고 평가했습니다.
2. 복잡한 엔터프라이즈 환경에서의 문제 해결: Traversal의 독특한 접근 방식과 시장 타이밍
AI SRE(Site Reliability Engineering) 스타트업들이 많이 생겨났던 2024년 초, Traversal은 "AI 기반 인시던트 대응"이라는 분야에 집중하게 되었습니다. Anish는 처음에는 SRE 용어조차 몰랐지만, "첫 번째 원칙(first principles)"에 기반하여 문제에 접근했습니다. 그들은 LLM을 위한 AB 테스트, 동적 프롬프트 튜닝, LLM을 위한 제품 분석(Amplitude와 같은) 등 여러 아이디어를 탐색하다가, 코어 엔지니어링(core engineering) 분야의 문제에서 가능성을 발견했습니다.
이들이 이 문제에 끌린 주된 이유는 다음과 같습니다:
- 오랜 문제: 30~40년 동안 해결되지 않은 고질적인 문제였습니다. 🕰️
- 거대한 시장: 엔터프라이즈 환경의 복잡한 시스템에서 발생하는 문제 해결은 엄청난 시장 규모를 가지고 있었습니다.
Traversal은 이 문제 해결에 독점적인 우위를 가지고 있다고 생각했습니다. 그들의 접근 방식의 핵심은 "상관관계와 인과관계"를 구분하는 데 있습니다. 시스템 지연(latency)이 급증하는 등의 문제가 발생했을 때, 수많은 다른 지표들도 동시에 급증하는 경우가 많습니다. 이때 어떤 지표가 문제의 증상일 뿐인지, 아니면 진정한 근본 원인인지를 구별하는 것이 중요합니다.
"문제는 수천 개의 다른 스파이크가 동시에 발생한다는 것입니다. 어떤 스파이크가 실제 문제의 증상인지, 아니면 다른 문제 때문에 발생하는 상관관계인지, 혹은 진정한 근본 원인인지를 파악해야 합니다."
이는 "건초 더미에서 바늘 찾기"와 같으며, 수많은 "가짜 바늘" 속에서 진짜를 찾아내야 하는 문제에 비유됩니다. Traversal의 인과관계 머신러닝(Causal ML)과 강화 학습(Reinforcement Learning) 전문성은 이러한 탐색과 필터링에 최적화되어 있었습니다.
엔터프라이즈 환경에서는 로그, 메트릭, 트레이스, 코드, 설정 파일, Slack 메시지 등 페타바이트(petabytes) 규모의 방대한 데이터를 다룹니다. 이 모든 데이터를 LLM의 컨텍스트에 한 번에 넣고 문제를 해결하는 것은 불가능합니다. 따라서 Traversal은 데이터를 순차적이고 적응적으로 탐색하는 에이전트 시스템이 필수적이라고 보았습니다. 이러한 에이전트 시스템은 Elastic, Grafana, ServiceNow, Datadog 등 다양한 시스템에 자율적으로 질의하며 정보를 수집합니다.
또한, AI 기반 코딩 보조 도구들이 확산되면서 코드가 어떻게 작동하는지 이해하기 어려워지는 상황을 예측했습니다. 이는 소프트웨어 유지보수가 단순히 "불 끄기"식 대응이나 QA 작업으로 전락할 수 있음을 의미합니다. Traversal은 소프트웨어 개발이 아닌 소프트웨어 유지보수에 초점을 맞춰, AI 개발의 흐름에 맞춰 선제적인 문제 해결을 돕는 솔루션으로 자리매김하고자 했습니다. 🚀
3. Traversal의 작동 방식: 입력, 컨텍스트 구축, 그리고 AI 기반 문제 해결
Traversal은 기본적으로 사용자가 인시던트가 시작된 대략적인 시간과 간략한 문제 설명을 입력하는 것으로 시작합니다. 예를 들어, "4월 22일 저녁에 버킷 생성 중 지역 선택이 안 되었음"과 같은 정보입니다.
3.1. 자동 트리거 및 수동 조사 시작 🤖
Traversal은 주로 인시던트 채널(Slack 등)이나 경고 채널(alert channel)에서 자동으로 트리거됩니다. 알림을 받은 사용자는 Traversal UI로 이동하여 더 깊이 있는 조사를 수행할 수 있습니다. UI에서는 단순히 "리드(leads)"(단서)만 제공하는 Slack과 달리, AI가 제시하는 답변의 모든 관련 증거를 확인하고 후속 조치를 취할 수 있습니다.
또한, 시스템에 문제가 발생하지 않았을 때도 사용자가 Traversal UI를 방문하여 "시스템 건강 확인(health check)"을 수행하거나, 특정 시스템이 느려지는 등의 상황에서 "무슨 일이 일어나고 있는지 파악"하는 용도로도 사용될 수 있습니다.
3.2. 지능적인 컨텍스트 구축 🧠
사용자가 문제를 설명하면 Traversal은 "컨텍스트 구축(context building)"이라는 핵심 단계에 들어갑니다. 이 과정은 몇 분이 소요되는데, 다음과 같은 요소들을 지능적으로 활용하여 관련 정보를 끌어옵니다:
- 질문자 정보: 누가, 언제 질문하는지.
- Traversal의 지식 기반: 시스템 아키텍처에 대한 자체적인 이해.
- 라이브 데이터 쿼리: 로그, 메트릭, 트레이스 등의 실시간 데이터를 쿼리합니다.
Traversal은 이 모든 정보를 기반으로 "순차적 호핑(sequential hopping)"을 통해 서비스에서 서비스로, 인덱스에서 인덱스로 이동하며 관련된 서비스를 찾아내고, 이들의 연결 관계를 파악하여 컨텍스트를 구축합니다. 이 과정은 AI가 주도하며, 사용자는 초기 정보를 제공함으로써 조사를 가속화할 수 있습니다.
"Traversal이 이 질문을 분석하여 어떤 컨텍스트를 가져와야 할지 파악합니다. 백그라운드에서는 누가 언제 질문하는지, 그리고 자체적인 지식 기반과 시스템 아키텍처에 대한 이해를 활용합니다."
3.3. 방대한 데이터 처리와 LLM 컨텍스트 관리 📊
Traversal은 수억 개의 로그, 수만 개의 시계열 데이터, 수백 개의 풀 리퀘스트 및 배포, 수천 개의 대시보드 등 수백만 토큰에 달하는 방대한 데이터를 처리합니다. 이러한 데이터는 단일 LLM의 컨텍스트 창에 한 번에 들어갈 수 없습니다.
Traversal의 에이전트 아키텍처는 이 문제를 해결하기 위해 도구 오케스트레이션(tool orchestration)과 메모리 관리(memory management)를 수행합니다. 이를 통해 LLM이나 오케스트레이터 에이전트가 과부하되지 않도록 적절한 시점에 필요한 정보만 제공하여 컨텍스트를 유지합니다. 이는 데이터를 효율적으로 "절단(cutting down)"하고 관련 정보를 지속적으로 좁혀나가는 과정입니다.
"수억 개의 로그, 수만 개의 시계열, 수백 개의 풀 리퀘스트 배포, 수천 개의 대시보드를 살펴봤습니다. 이 데이터의 토큰 수는 수백만 토큰에 달합니다. 하지만 이 모든 데이터를 LLM이나 오케스트레이터 에이전트에 한 번에 넣으면 과부하됩니다. 그래서 우리는 에이전트 아키텍처를 통해 적절한 부분만 관리하여 답변에 빠르게 도달합니다."
3.4. 인과관계 ML과 통계 분석의 결합 ➕
Traversal의 핵심 차별점은 단순히 데이터를 모아 LLM에 질의하는 것을 넘어섭니다. Anish는 수십억 개의 잠재적 증상 중에서 실제 원인을 소수의 증상으로 좁혀나가는 과정 자체가 "엄청난 데이터 처리 파이프라인"이라고 설명합니다. 이 과정 전반에 걸쳐 AI 에이전트와 LLM이 작동하며 관련 정보의 양을 줄여나갑니다.
특히, Traversal은 독점적인 통계 테스트를 활용하여 시계열 데이터를 처리합니다. LLM은 시계열 데이터 처리에 약하기 때문에, Traversal의 AI 에이전트는 마치 데이터 과학자처럼 동적으로 최적의 통계 테스트 조합을 결정하여 탐색 공간을 필터링합니다. 동시에 로그, 메트릭, 트레이스 등과 관련된 의미론적 정보도 함께 활용합니다. Raz는 이를 "의미론이 통계를 만나는(semantics meets statistics) 프레임워크"라고 설명합니다.
"LLM은 시계열 데이터 처리에는 정말 약합니다. 바로 이때 훌륭한 통계가 필요한 거죠. 이 통계 테스트들은 AI 에이전트가 접근할 수 있는 도구 상자 같은 것입니다. 데이터 과학자처럼 동적으로 어떤 통계 테스트를 실행하여 탐색 공간을 필터링할지 결정합니다."
이렇게 함으로써 Traversal은 단순히 상관관계를 넘어 "근본 원인 후보"를 제시하고, 그 근거를 데이터에서 관찰된 "사실적 증상"에 기반하여 제시합니다. 이는 단순한 LLM 호출이나 기본적인 ReAct 에이전트로는 쉽게 달성할 수 없는 복잡한 과정입니다.
4. 자가 치유(Self-Healing) 및 비즈니스 모델: Traversal의 진화
Traversal은 문제의 근본 원인을 찾아내는 것을 넘어, 시스템을 "자가 치유(self-heal)"하는 방향으로 나아가고 있습니다.
4.1. 점진적인 자가 치유 접근 방식 🛠️
초기에는 보안상의 이유로 고객 시스템에 읽기 전용(read-only) API 접근만 허용합니다. 고객들은 일반적으로 인프라에 에이전트를 설치하는 것에 부담을 느끼기 때문입니다. 하지만 Traversal과 오랫동안 협력하여 신뢰가 쌓이면, "시스템 자가 치유"에 대한 논의가 시작됩니다.
Traversal의 자가 치유는 다음과 같은 방식으로 이루어집니다:
- 간단한 조치: 문제가 매우 국소적일 경우, 특정 커밋을 롤백(revert commit)하는 것과 같은 간단한 조치를 제안합니다.
- 기존 자동화 스크립트 활용: 많은 대기업들은 시스템을 치유하기 위한 수천 개의 자동화 스크립트를 가지고 있습니다 (예: 특정 파드 재시작, 인프라의 특정 부분 자동 확장). 문제는 어떤 스크립트를 실행해야 할지 모른다는 것입니다. Traversal은 근본 원인을 정확히 파악한 후, LLM의 의미론적 이해 능력을 활용하여 적절한 치유 스크립트를 연결하거나 매칭하여 실행을 제안합니다.
"사람들은 시스템에 무엇이든 할 수 있는 완전한 쓰기 권한을 부여하고 싶어 하지 않습니다. 그래서 화이트리스트(whitelisted) 명령어 세트가 필요하고, 이는 주로 고객들이 가지고 있는 기존 스크립트 형태로 이루어집니다."
Traversal은 고객들이 시스템에 대한 완전한 쓰기 권한을 주기를 원치 않으므로, 미리 승인된(whitelisted) 명령어 세트 내에서 작동하여 자가 치유를 수행합니다.
4.2. 비즈니스 모델 및 시장 경쟁 💰
Traversal의 비즈니스 모델은 기존 관측(observability) 도구 회사들과 차별화됩니다. 기존 회사들은 주로 저장하는 데이터의 양에 따라 요금을 부과하며, 다른 회사에 저장된 데이터에 대한 인사이트를 제공할 인센티브가 거의 없습니다. 하지만 엔터프라이즈 환경에서는 Splunk, Dynatrace, Datadog 등 7~8가지의 파편화된 도구를 동시에 사용하는 경우가 흔합니다. 문제를 해결하려면 이 모든 시스템을 순환적으로(iteratively) 오가며 정보를 파악해야 합니다.
Traversal은 이러한 시스템 및 팀의 파편화에서 기회를 찾았습니다.
"우리는 데이터 저장량을 판매하려는 것이 아니라, 조사 자체라는 결과(outcome)를 판매하려는 것입니다. 우리는 데이터가 어디에서 오는지에 대해 합리적으로 무관심하며, 일종의 관측 분야의 스위스와 같습니다."
Traversal은 데이터 저장에 기반한 요금이 아닌, "조사(investigation)"라는 결과에 기반한 요금 모델을 추구합니다. 현재는 두 가지 요소를 결합한 방식으로 요금을 책정합니다:
- 탐색 공간의 크기: 인프라의 복잡성 (호스트 수, 컨테이너 수 등).
- 수행하는 조사 횟수.
하지만 고객 지원 분야와 달리, Traversal의 기술은 아직 완전한 "자가 치유" 결과를 100% 보장하는 단계는 아닙니다. 현재는 "매우 좋은 단서(leads)"를 제공하는 수준입니다. 따라서 고객들은 순수한 "결과 기반(outcome-based)" 가격 책정에 대한 거부감이 있습니다. Traversal은 기술이 성숙함에 따라 완전한 결과 기반 가격 책정으로 전환할 계획입니다. 현재는 인프라 규모와 조사 횟수를 혼합하며, 인프라 규모에 더 비중을 둡니다.
완전한 엔드 투 엔드(end-to-end) 자가 치유가 가능한 경우에는 이미 결과 기반으로 판매를 시도하고 있습니다.
4.3. 자가 치유의 발전 단계와 미래 전망 🔮
Raz는 자가 치유 역시 에이전트처럼 연속체(continuum)라고 설명합니다. 현재 Traversal은 전체 문제의 10~20%에 해당하는 쉬운 문제에 대해서는 신뢰할 수 있는 근본 원인 분석 및 자가 치유를 수행할 수 있습니다. 이는 L1 또는 L2 엔지니어가 처리할 수 있는 수준의 작업입니다.
30~40%의 중간 난이도 문제 (수석 엔지니어의 확인이 필요한 경우)에 대한 자가 치유는 6개월에서 1년 이내에 가능할 것으로 예상됩니다.
하지만 코드베이스의 장기적인 재구성(re-architecture)과 같은 완전한 에이전트 시스템은 최소 2년 이상 걸릴 것으로 예상합니다. AI는 놀라움을 주지만, 실제 운영 시스템에서 발생하는 예측 불가능한 문제에 대응하고 코드 자체를 완벽하게 재구성하는 데는 시간이 더 필요할 것입니다. 단위 테스트(unit testing)로 해결될 수 있는 문제는 1~2년 내에 대부분 해결되겠지만, 더 심각한 문제는 아직 갈 길이 멀다고 봅니다.
5. AI 에이전트의 발전과 모델 선택: GPT-5에 대한 Traversal의 견해
Traversal은 다양한 AI 모델을 적극적으로 테스트하고 있으며, 특히 추론 모델(reasoning models)의 중요성을 강조합니다.
5.1. 추론 모델의 중요성 🧐
Traversal의 문제 해결 시나리오에서는 수많은 증상과 복잡한 시스템 아키텍처를 넘나들며 근본 원인을 추론해야 하므로, 추론 모델이 필수적입니다.
"추론 모델은 우리의 사용 사례에 필수적입니다. 수많은 증상과 복잡한 아키텍처를 넘나들며 근본 원인을 추론해야 합니다. 간단한 플래그십 모델은 작동하지 않을 것입니다."
그들은 모델을 쉽게 교체할 수 있는 유연한 아키텍처를 구축했습니다. AI 규제가 불확실하기 때문에, 고객사들은 자체 모델을 도입하기 어려운 경우가 많습니다.
5.2. 프론티어 모델 평가: OpenAI, Gemini, Anthropic 🧪
Traversal은 OpenAI(GPT-3, GPT-4), Google Gemini, Anthropic(Claude) 등 주요 모델들을 계속 평가하고 있습니다.
- OpenAI (GPT-3/4): 역사적으로 GPT-3가 추론 면에서 더 나았으며, 잘 지원되는 인프라 덕분에 빠르게 개발할 수 있었습니다.
- Google Gemini: 최근에는 Gemini도 꽤 좋은 성능을 보이지만, 인프라 지원이 다소 뒤처져 있어 아직은 OpenAI를 더 많이 사용합니다.
- GPT-5: GPT-5에 대한 평가는 아직 명확하지 않습니다.
"GPT-5는 생각해서는 안 될 때도 생각을 시작합니다. 아직 결정을 내리지 못했고, 최종 테스트를 진행 중입니다. 아직까지는 압도적인 긍정적인 신호는 보지 못했습니다."
Traversal은 GPT-5가 오히려 필요 없는 추론을 하는 경향이 있다고 언급하며, 여전히 평가 중입니다. 그들은 복잡한 엔터프라이즈 환경에서 "누락된 정보"나 "미흡하게 계측된 데이터"를 연결해야 하기 때문에, 단순히 사전 정의된 워크플로우만으로는 부족하고, 추론 모델이 반드시 필요하다고 강조합니다.
5.3. Claude의 도구 호출 능력 🎯
Anthropic의 Claude 모델은 도구 호출(tool calling) 능력이 뛰어나다는 평가를 받는데, Traversal 역시 이 점을 확인했습니다.
"스택의 에이전트 부분에서는 Anthropic으로 전환하고 있습니다. 도구 호출, 특히 막힌 부분을 풀어주는(unstucking) 데 있어서 Anthropic과 Claude가 더 뛰어나다는 신호가 있습니다."
잘못된 경로로 조사가 진행될 때, Claude는 다시 올바른 방향으로 전환하는 데 더 효과적이라는 경험을 공유했습니다.
5.4. Eval 파이프라인과 핵심 IP 📈
Traversal은 초기에는 "감(vibes)"에 의존하여 모델을 평가했지만, 지금은 "적절한 벤치마크"와 "매우 상세한 평가(eval) 파이프라인"를 갖추고 있습니다.
"저는 회사에 항상 말합니다. 이 회사의 핵심 IP 중 하나는 우리가 평가를 얼마나 잘하는지입니다. 최상의 AI 회사들은 항상 모델이 할 수 있는 것의 한계에 서 있어야 한다고 생각합니다."
AI 기업은 모델의 한계를 끊임없이 확장해야 하므로, 때로는 시스템이 작동하고 때로는 그렇지 않을 수 있습니다. 따라서 평가(evaluation)는 핵심적인 병목 현상이 되며, 여기에 많은 시간과 자원을 투자해야 합니다. Traversal은 "평가(eval)"가 핵심 지적 재산(core IP)이라고 강조하며, 이를 위해 박사 학위 소지자들을 적극적으로 채용하고 있습니다. 🧑🎓
6. 결론: "보여주는 것이 말하는 것보다 중요하다"와 채용 기회 🚀
Anish는 "보여주는 것이 말하는 것보다 중요하다(more showing less telling)"는 말을 강조하며, 이는 AI 및 다양한 기술 분야에서 많은 사람들이 같은 이야기를 반복하는 상황에 대한 메시지라고 설명했습니다. Traversal의 성공은 단순한 이야기나 주장이 아니라, 실제 프로덕션 환경에서 복잡한 인시던트를 해결하는 제품의 효용성을 보여줌으로써 이루어졌습니다.
6.1. 벤치마크와 핵심 IP의 딜레마 🤔
Traversal에게 벤치마크는 핵심적인 지적 재산입니다. 이는 회사가 얼마나 잘하고 있는지, 그리고 나아가야 할 방향을 결정하는 데 필수적입니다. 하지만 이러한 벤치마크를 공개하는 것은 회사의 핵심 가치를 외부에 노출하는 것과 같아서 "교착 상태(stalemate)"에 빠지게 된다고 Anish는 언급합니다.
6.2. PoC(개념 증명) 가속화의 과제 ⚡️
고객들은 종종 "카오스 엔지니어링(chaos engineering)"을 스테이징(staging) 환경에서 수행하여 Traversal의 성능을 평가하려 합니다. 하지만 Anish는 이러한 시뮬레이션 환경에서는 항상 좋은 결과를 보여주더라도, 고객들은 결국 "실제 프로덕션 환경"에서 테스트해야만 확신을 갖는다고 말합니다.
"고객들은 항상 '아니야, 아니야. 진정으로 알려면 프로덕션에서 테스트해야 해'라고 말합니다. 그럼 '대체 뭐야?'라고 할 수밖에 없죠." 🤷♂️
이는 프로덕션 환경을 충분히 사실적으로 시뮬레이션하려면 결국 또 다른 프로덕션 환경을 구축하는 것과 마찬가지이기 때문입니다. 현재 가장 효과적인 방법은 고객이 과거 10개의 프로덕션 인시던트 데이터를 제공하고, Traversal이 이를 분석하여 결과를 보여주는 것입니다. 고객들은 자신의 환경이 "가장 독특하고 복잡하다"고 믿는 경향이 있기 때문에, 실제 프로덕션에서 가치를 증명하지 않으면 확신을 얻기 어렵습니다.
6.3. Traversal의 채용 기회 🌟
Traversal은 현재 적극적으로 인력을 채용하고 있습니다. 특히 뉴욕에 기반을 둔 회사로, 뉴욕에서 일하거나 뉴욕으로 이주할 의향이 있는 사람들을 찾고 있습니다. AI와 인프라의 교차점에서 멋진 회사에서 일하고 싶은 사람들은 Traversal에 연락해달라고 Anish는 당부했습니다.
"우리는 현재 적극적으로 채용 중입니다. 저희는 뉴욕시에 전 직원이 함께 있습니다. 뉴욕에 거주하시거나 뉴욕으로 이주하고 싶고, AI 인프라의 교차점에서 멋진 회사에서 일하고 싶은 분들은 저희에게 연락해주세요."