Anthropic의 Claude C Compiler(CCC)를 통해 AI 코딩의 현재 수준, 한계, 그리고 소프트웨어 엔지니어링·지식재산·팀 운영에 미칠 변화를 살펴본다.
2026년 2월 18일
Chris Lattner
Engineering
컴파일러는 컴퓨터 과학에서 특별한 위치를 차지합니다. 컴퓨터 과학 교육에서 정전(定典) 같은 과목이기도 하고, 하나를 만들어 보는 것은 일종의 통과의례입니다. 컴파일러를 만들면 소프트웨어가 실제로 어떻게 동작하는지—언어, 추상화, 하드웨어, 그리고 인간의 의도와 기계 실행 사이의 경계—를 정면으로 마주하게 됩니다.
컴파일러는 한때 인간이 기계와 대화하도록 도와주었습니다. 이제는 기계가 인간이 컴파일러를 만들도록 돕기 시작했습니다.
저는 경력의 상당 부분을 컴파일러와 프로그래밍 언어에 바쳤습니다. 그래서 Anthropic이 Claude C Compiler (CCC)를 발표했을 때 특히 주의 깊게 보았습니다. 제 기본 평가는 간단합니다. 이것은 실제 진전이며 업계의 이정표입니다. 세상이 끝나는 징조는 아니지만, 그렇다고 단순한 과대광고도 아닙니다. 다들 심호흡 한 번 하시죠.
AI가 C 컴파일러를 만든 것이 진정한 의미에서 혁명적이라고 하기는 어렵지만, AI 코딩이 얼마나 발전했는지, 그리고 다음에는 어디로 향할지에 대해 많은 것을 드러냅니다.
본격적으로 들어가기 전에, 핵심 요점을 먼저 정리하겠습니다.
엔지니어링 팀에 대한 함의는 현실적이고 즉각적입니다. 글의 마지막에서 저는 이러한 통찰을 Modular에서 제 팀에 대한 구체적인 기대치로 어떻게 바꾸고 있는지 공유합니다.
Claude C Compiler가 왜 중요한지 이해하려면, 먼저 컴파일러 자체가 인간이든 인공지능이든 “지능”을 시험하는 얼마나 드러내기 좋은 테스트인지 이해해야 합니다.
컴파일러는 동시에 여러 어려운 영역이 교차하는 지점에 놓여 있습니다. 형식 언어 설계, 대규모 소프트웨어 아키텍처, 깊은 성능 제약, 그리고 무자비한 정확성 요구가 한데 얽힙니다.
대부분의 애플리케이션은 버그를 어느 정도 견딜 수 있지만, 컴파일러는 그렇지 못합니다. 단 하나의 잘못된 변환이 조용히 틀린 프로그램을 만들어 내며, 수많은 사용자의 생산성을 무너뜨릴 수 있습니다. 모든 계층은 서로 협력하면서도 엄격한 불변조건(invariant)을 유지해야 합니다.
역사적으로 이것이 컴파일러가 컴퓨터 과학 교육에서 통과의례가 된 이유입니다. 컴파일러는 추상화 계층을 가로질러 사고하도록 강제합니다. 텍스트를 구조로, 구조를 의미로, 의미를 최적화된 기계 동작으로 바꾸는 과정이기 때문입니다.
LLVM 컴파일러 설계에 관한 제 이전 글에서 발췌.
이 과정은 더 깊은 무언가—인간의 의도를 정확한 실행으로 번역하는 과정—를 닮아 있습니다. 그래서 컴파일러는 AI 시스템 통합의 벤치마크로서 유난히 흥미롭습니다.
이전 세대의 AI 코딩 도구는 함수 작성, 스크립트 생성, 코드 빈칸 채우기 같은 로컬 작업에서 인상적이었습니다. 그런 작업은 패턴 인식과 단기 추론을 시험합니다.
Claude C Compiler는 다른 수준에서의 진전을 보여주는 이정표입니다. AI 시스템이 전체 엔지니어링 시스템 전반에서 일관성을 유지하고, 여러 서브시스템을 조율하며, 아키텍처 구조를 보존하고, 테스트와 실패의 복잡한 피드백 루프 속에서 시간이 지나며 정확성에 수렴해 가는 모습을 보여 줍니다. AI는 _코드 완성_에서 _엔지니어링 참여_로 이동하기 시작했습니다.
하지만 컴파일러가 현대 AI 시스템과 유난히 잘 맞는 더 깊은 이유도 있습니다. 컴파일러 엔지니어는 매우 읽기 쉽고(legible) 구조화된 아키텍처를 구축합니다. 컴파일러는 계층화된 추상화, 일관된 네이밍 규칙, 조합 가능한 패스(pass), 그리고 결정적 피드백(“동작한다/동작하지 않는다”—명확한 성공 기준)을 갖습니다. 이런 속성 덕분에 컴파일러는 대규모 소스 코드를 학습한 머신러닝 시스템에게도, 인간에게도 유난히 학습하기 좋습니다.
이 관점에서 보면, CCC는 수십 년에 걸친 소프트웨어 엔지니어링 실천의 검증입니다. 컴파일러 엔지니어들이 개발한 추상화가, 이제 기계가 그 안에서 추론할 수 있을 만큼 충분히 구조화되어 있었다는 뜻이니까요. 이는 놀라운 이정표입니다. 다만 동시에 중요한 한계도 시사합니다.
Claude C Compiler에서 가장 흥미로운 점 중 하나는 Anthropic이 전체 소스 히스토리를 공개했다는 것입니다. 많은 AI 데모와 달리, 이것은 누군가가 실제로 검사할 수 있는 엔지니어링 산출물이지, 단지 다듬어진 결과물이나 벤치마크 점수가 아닙니다. 커밋 히스토리 전체, 설계 문서, 향후 계획까지 포함한 저장소 전체가 공개되어 있습니다. 즉, 시스템이 컴파일러를 어떻게 만들었는지 실제로 연구할 수 있습니다. 저도 실제로 시간을 들여 그렇게 했습니다.
첫 번째 주요 커밋은 시스템의 기본 아키텍처를 사실상 “원샷(one-shot)”으로 잡습니다. 시작부터 CCC는 고전적인 컴파일러 구조를 따릅니다. 주요 서브시스템은 상당히 놀라운 수준의 설계 문서도 갖고 있는데, 예를 들어 다음과 같습니다.
저장소 전반의 설계 선택은 대학 강의에서 가르치고, LLVM이나 GCC 같은 기존 컴파일러에서 널리 쓰이는 확립된 컴파일러 관행을 일관되게 반영합니다. IR에는 LLVM 개발자라면 즉시 익숙할 개념들이 들어 있습니다. 예컨대 GetElementPtr 같은 명령어, 베이직 블록의 “터미네이터”, Mem2Reg 등이 그렇습니다. 널리 쓰이는 컴파일러 설계 기법에 대한 탄탄한 지식을 가진 것으로 보입니다.
서브시스템 컴파일러 아키텍처 예시
LLVM과 GCC 코드는 분명히 학습 데이터에 포함되어 있고, Claude는 그 큰 부분을 CCC를 위해 Rust로 사실상 번역했습니다. 설계 문서에는 두 시스템 모두에 대한 상세한 지식이 드러나며, 구현 접근에 대한 숙고된 관점도 담겨 있습니다. 일부는 CCC가 기존 선행 기술을 학습했다는 점을 비판하지만, 저는 그런 비판이 우스꽝스럽다고 봅니다. 저도 Clang를 만들 때 GCC로부터 배웠으니까요!
Pushpendre Rastogi는 CCC와 에이전트 스케일링 법칙에 관한 훌륭한 블로그 글을 썼습니다. 반복적인 에이전트 워크플로가 구현과 테스트 커버리지를 점진적으로 확장해 가는 과정을 보여 줍니다.
코드 고고학 타임라인, Pushpendre Rastogi 제공(허가를 받아 포함)
종합해 보면, CCC는 실험적 연구용 컴파일러라기보다 유능한 교과서형 구현에 가깝습니다. 강한 학부 팀이 프로젝트 초기에 만들 법한, 다만 수년의 정련을 거치기 전 단계의 시스템 말이죠. 그것만으로도 대단한 일입니다.
CCC에서 가장 많은 것을 말해 주는 부분은 실수입니다. 몇몇 설계 선택은 사람이 일반적인 추상화를 세우려는 것과 달리, “테스트 통과”에 최적화된 흔적을 보여 줍니다. 몇 가지 예를 들면:
마지막 항목이 특히 큰 문제입니다. CCC가 테스트 스위트 밖으로는 잘 일반화하지 못할 것임을 시사하며, 이는 버그 트래커(이슈)와 확인된 사례로도 뒷받침되는 듯합니다. 이런 결함은 놀랍다기보다 유익합니다. 현재 AI 시스템이 “알려진 기법을 조립하고, 측정 가능한 성공 기준으로 최적화”하는 데는 뛰어나지만, 프로덕션 품질 시스템에 필요한 개방형 일반화에는 어려움을 겪는다는 점을 보여 주기 때문입니다.
그리고 이 관찰은 곧바로 더 깊은 질문으로 이어집니다. 이것이 AI 코딩 자체에 대해 무엇을 말해 주는가?
Claude C Compiler에서 가장 흥미로운 교훈은 AI가 컴파일러를 만들 수 있다는 사실이 아닙니다. 컴파일러를 어떻게 만들었는가입니다. CCC는 새로운 아키텍처를 발명하거나 낯선 설계 공간을 탐색하지 않았습니다. 대신 GCC, LLVM, 그리고 학계 문헌에 의해 형성된 수십 년의 컴파일러 엔지니어링 합의(consensus)에 매우 가까운 무언가를 재현했습니다. 구조적으로는 올바르고, 익숙하며, 잘 알려진 기법에 기반합니다.
현대 LLM은 대단히 강력한 “분포 추종자(distribution follower)”입니다. 방대한 기존 작업에서 패턴을 학습하고, 그 집단적 경험의 중심부에 가까운 해법을 생성합니다. GCC, LLVM, 학계 문헌이 빚어낸 수십 년치 컴파일러로 학습했다면, 그 계보를 반영한 결과가 나오는 것은 자연스럽습니다. 이는 Richard Sutton의 Bitter Lesson—확장 가능한 방법이 널리 성공한 구조를 재발견한다—와도 밀접하게 맞닿아 있습니다.
비유가 도움이 됩니다. 영어 문학으로 학습하면 모델이 셰익스피어 풍의 산문을 만들어낼 수 있습니다. 문학이 1600년대에 진화가 멈췄기 때문이 아니라, 셰익스피어가 학습 분포에서 밀도가 높은 영역을 차지하기 때문입니다. 모델은 널리 쓰이고 강화된 것을 학습합니다. 같은 역학이 (하필 컴파일러 설계에서!) 여기서도 나타납니다.
인류 지식의 모든 과정이 대규모로 흡수된다면—그 다음 커리큘럼은 누가 쓸까?
CCC는 AI 시스템이 한 분야의 _교과서적 지식_을 내재화하고, 이를 대규모로 일관되게 적용할 수 있음을 보여 줍니다. AI는 이제 확립된 엔지니어링 관행 안에서 신뢰할 만하게 동작할 수 있습니다. 이는 반복의 고된 노동을 크게 줄여, 엔지니어가 최첨단에 더 가까운 지점에서 시작하게 해 주는 진짜 이정표입니다. 하지만 동시에 이 작업의 중요한 한계도 부각합니다.
알려진 추상화를 구현하는 것과, 새로운 추상화를 발명하는 것은 다릅니다. 이 구현에서 저는 새로운 것을 보지 못했습니다.
역사적으로 컴파일러의 진보는 표준 구성 요소를 빨리 조립하는 데서 오지 않았습니다. 새로운 IR, 새로운 최적화 모델, 프로그램과 하드웨어 상호작용을 구조화하는 새로운 방식 같은 개념적 도약에서 왔습니다. 또한 사람들을 함께 일하게 만드는 것—새로운 방식으로 엔지니어를 고무하고 동기를 부여하는 것—에서도 왔습니다.
현재 AI 코딩 시스템은 성공 기준이 명확하고 검증 가능할 때 탁월합니다. 예: 프로그램을 컴파일하라, 테스트를 통과하라, 성능을 개선하라. 이런 환경에서는 반복적 정련이 매우 잘 작동합니다. 빨강/초록 TDD는 효과가 있습니다!
혁신은 다릅니다. 새로운 추상화를 발명할 때 성공은 아직 측정되지 않습니다. 존재하지 않는 아이디어에 대한 테스트 스위트는 없고, 좋은 설계를 정량화하기도 어렵습니다.
따라서 AI 코딩은 자동화의 또 다른 진전으로 이해하는 것이 가장 적절합니다. 구현, 번역, 정련의 비용을 극적으로 낮춥니다. 그 비용이 내려갈수록 희소 자원은 위로 이동합니다. 어떤 시스템이 존재해야 하는지, 그리고 소프트웨어가 어떻게 진화해야 하는지 결정하는 일이 더 중요해집니다.
코드를 쓰는 일이 쉬워질수록, 소프트웨어를 설계하는 일은 그 어느 때보다 중요해집니다. 맞춤형 소프트웨어를 더 싸게 만들 수 있을수록, 진짜 도전은 올바른 문제를 선택하고 그로 인해 발생하는 복잡성을 관리하는 것입니다. 또한 이 모든 소프트웨어를 누가 유지보수할 것인지에 대한 큰 열린 질문도 보입니다.
Claude C Compiler는 지식재산에 대한 중요하지만 불편한 질문도 던집니다. 수십 년간 공개된 코드를 학습한 AI 시스템이 익숙한 구조, 패턴, 심지어 특정 구현까지 재생산할 수 있다면, 학습과 복제의 경계는 정확히 어디일까요?
일부 관찰자는 CCC가 기존 구현을 강하게 닮은 산출물을 재생성하는 사례를 지적했습니다. 표준 헤더와 유틸리티 코드 같은 것들입니다. 이는 “클린룸” 개발 주장에도 불구하고 제기됩니다. 이런 예시는 “소스 자료를 명시적으로 참조하지 않고, 방대한 선행 작업에서 통계적으로 학습”하는 시스템을 현행 법 체계가 설명하기 어렵다는 점을 드러냅니다.
동시에 이런 상황은 완전히 새롭지 않습니다. 인간도 기존 시스템을 공부하고 패턴을 내재화한 뒤 새로운 맥락에 재적용하며 배웁니다. 차이는 규모와 자동화입니다. AI는 수십 년의 엔지니어링 지식을 생성 모델로 압축해, 즉시 해법을 재생산할 수 있게 합니다. 이는 아이디어가 널리 공유되어도, 특정 표현은 여전히 라이선스를 가질 수 있다는 점에서 소유권에 대한 전통적 가정을 흔듭니다.
우리는 독점 소프트웨어의 자동 재구현이 가능한 새로운 시대를 맞고 있습니다. 그렇다고 패러다임이 갑자기 쓸모없어졌다는 뜻은 아닙니다. AI는 확립된 설계의 재생산 비용을 낮추므로, 경쟁 우위는 고립된 코드베이스에서 실행력, 생태계, 지속적 혁신으로 이동할 것입니다. 이는 리눅스와 오픈소스가 처음 널리 채택되던 때처럼 법과 제도적 규범을 변화시키도록 압박할 것입니다. 그러한 전환기와 마찬가지로, 빠르게 변하는 시대를 따라가지 못하는 레거시 생태계를 대신해 인간 협업의 생태계 중력이 더 강해질 것이라고 저는 봅니다.
AI 코딩이 주로 _구현을 자동화_한다면, 다음에는 무엇이 일어날까요?
역사는 분명한 패턴을 보여 줍니다. 무언가를 만드는 비용이 극적으로 떨어지면, 우리는 같은 것을 더 싸게 만들기만 하지 않습니다. 완전히 새로운 것을 만듭니다.
컴파일러 자체가 완벽한 예입니다. 초기 프로그래머는 어셈블리를 손으로 작성했지만, 컴파일러가 신뢰할 만해지자 개발자는 훨씬 더 야심차졌고, 추상화가 복잡성을 관리 가능하게 만들면서 산업 전체가 생겨났습니다. 코드를 쓰는 일이 쉬워질수록 결과는 “프로그래머가 줄어드는 것”이 아니라 “소프트웨어가 늘어나는 것”일 가능성이 큽니다. 실험이 늘고, 더 전문화된 도구가 나오고, 이전에는 자동화할 가치가 없던 문제들이 해결될 것입니다.
1957년 IBM 704로 항공 연구를 수행하는 모습 (NASA)
바뀌는 것은 엔지니어링 작업의 경제성—특히 리라이트, 마이그레이션, 보일러플레이트 구현 같은 기계적 작업의 대규모 제거—입니다. 이런 활동은 필요하지만 혁신적이진 않은 경우가 많고, AI 시스템은 바로 이런 종류의 작업에 유난히 강합니다. 엔지니어는 타이핑으로 구현을 쌓기보다 시스템을 지휘하는 쪽으로 이동합니다. 의도를 명시하고, 결과를 검증하고, 아키텍처를 빚어 나갑니다.
구현 비용이 싸질수록 엔지니어의 역할은 위로 이동합니다. 희소한 기술은 올바른 추상화를 선택하고, 의미 있는 문제를 정의하고, 인간과 AI가 함께 진화시킬 수 있는 시스템을 설계하는 능력이 됩니다. 이는 소프트웨어 엔지니어링과 프로덕트 사고의 경계를 더 흐릴 것입니다. 더 이상 제한 요인은 소프트웨어를 _만들 수 있느냐_가 아니라, 무엇을 _만들어야 하느냐_와 그 뒤따르는 복잡성을 어떻게 관리하느냐입니다. AI는 좋은 구조와 나쁜 구조 모두를 증폭시키므로, 관리가 엉망인 코드는 이해 불가능한 악몽으로 스케일할 것입니다.
그러면 다음 질문이 생깁니다. 프로그래밍이 이렇게 근본적으로 바뀐다면, 소프트웨어 엔지니어 자신에게는 무슨 일이 일어날까요?
소프트웨어 개발에서의 큰 변화는 언제나 프로그래머의 의미를 바꿔 왔습니다. 초기 엔지니어는 하드웨어를 직접 다뤘고, 이후 세대는 컴파일러와 고수준 언어를 신뢰하는 법을 배웠습니다. 각 전환은 수작업을 줄이는 대신, 엔지니어가 달성할 수 있는 기대치를 높였습니다. AI 코딩은 그 진화의 다음 단계입니다.
구현이 점점 더 자동화될수록, 소프트웨어 엔지니어링의 핵심 기술은 줄 단위로 코드를 쓰는 것에서 시스템을 형성하는 것으로 이동합니다. 무엇이 존재해야 하는지, 구성 요소들이 어떻게 맞물리는지, 시간이 지나도 복잡성이 이해 가능하게 남도록 어떻게 유지할지를 고민할 수 있습니다. 좋은 소프트웨어는 판단력, 커뮤니케이션, 명확한 추상화에 달려 있습니다. AI 시스템은 이를 대체하기보다 오히려 증폭합니다.
가장 효과적인 엔지니어는 코드 생산에서 AI와 경쟁하지 않을 것입니다. 대신 AI와 협업하는 법을 배울 것입니다. AI를 써서 아이디어를 더 빠르게 탐색하고, 더 넓게 반복하며, 인간의 노력을 방향성과 설계에 집중시키는 것입니다. 이런 도구는 과거의 컴파일러, 버전 관리, CI처럼 빠르게 소프트웨어 개발 스택의 표준 일부가 되고 있습니다. AI와 효과적으로 일하는 법을 배우는 것은 빠르게 핵심 직무 역량이 되고 있습니다. 오늘 AI를 무시하는 것은 20년 전 소스 컨트롤 도입을 거부하는 것과 비슷합니다.
출처: Luca Rossi의 The Era of the Software Factory에서 인용한 CircleCI State of Software Delivery Report, 2026. 최상위 팀은 빠르게 격차를 벌리고 있다.
AI 툴링을 성공적으로 받아들이는 팀과 그렇지 못한 팀 사이의 격차는 이미 측정 가능하며 빠르게 커지고 있습니다. CircleCI 2026 State of Software Delivery Report에 따르면 상위 5% 엔지니어링 팀은 전년 대비 산출량이 거의 두 배로 증가한 반면, 하위 절반은 정체했습니다. 2025년 가장 생산적인 팀은 2024년 선두 팀의 약 10배 처리량을 제공했습니다.
그렇다면 현실적인 질문이 생깁니다. 팀은 성공을 위해 어떻게 적응해야 할까요?
아래는 제가 이 변화를 Modular에서 구체적인 기대치로 번역한 방식입니다.
Claude C Compiler 같은 발전은 제가 엔지니어링 업무를 생각하는 방식과 팀에 요구하는 바를 바꾸어 놓았습니다. AI 도구의 혜택을 온전히 누리려면 의도적인 도약이 필요합니다. 수십 년 동안 형성된 습관은 자동으로 바뀌지 않고, 조직은 더 좋은 도구가 존재한다고 해서 저절로 변혁되지 않습니다.
동시에 우리는 현실적이어야 합니다. AI 시스템은 강력하지만 완벽과는 거리가 멉니다. 진전은 AI와의 협업에서 나오지, AI에 대한 책임 방기에서 나오지 않습니다. 목표는 인간을 루프에서 제거하는 것이 아니라, 인간을 루프 안에서 더 높은 레버리지 위치로 옮기는 것입니다.
그에 따라 세 가지 기대치가 있습니다.
엔지니어링부터 G&A, GTM에 이르기까지 모든 구성원은 생산성과 의사결정을 가속하기 위해 AI 도구를 적극 도입할 것으로 기대됩니다. 세상은 빠르게 움직이고 있고, 우리는 변화를 받아들여야 합니다.
중요한 점은, 이것이 책임을 도구로 이전하지 않는다는 것입니다. 예를 들어 대규모 프로덕션 소프트웨어를 만드는 엔지니어는 정확성에 대해 여전히 책임이 있습니다. 설계 품질과 장기 유지보수성도 마찬가지입니다. AI는 우리의 역량을 확장하지만, 판단을 아웃소싱해주지는 않습니다. AI로 만든 결과물은 손으로 쓴 결과물만큼 깊게 이해되고, 검증되고, 소유되어야 합니다. 평판은 프롬프트가 아니라 결과로 쌓입니다.
역사적으로 엔지니어링 노력의 큰 부분은 기계적 작업—코드 리라이트, 인터페이스 적응, 시스템 마이그레이션, 기존 패턴을 새로운 환경에서 재생산—에 쓰였습니다. AI는 이런 작업에서 인간보다 빠르게 더 나아지고 있습니다. 우리는 기계적 작업에서 자동화와 경쟁해서는 안 됩니다. 대신 엔지니어는 의도를 엄격하게 명료화하고, 테스트로 결과를 검증하고, 설계를 개선해야 합니다.
인간의 노력은 창의성과 판단이 가장 중요한 곳에 집중되어야 합니다. 그리고 이제 모든 엔지니어는 관리 책임을 갖습니다. 마이그레이션과 구현이 가속됨에 따라, 아키텍처 진화의 병목은 “사람이 리라이트를 얼마나 빨리 하느냐”가 아니라 “시스템이 다음에 어디로 가야 하는지 얼마나 명확히 정의하느냐”가 됩니다.
AI는 구조를 증폭합니다.
문서화가 잘 된 시스템은 확장과 진화가 극적으로 쉬워지고, 구조가 나쁜 시스템은 혼란으로 더 빨리 스케일합니다. 문서, 명확한 인터페이스, 명시적 설계 의도는 이제 선택적 오버헤드가 아니라 운영상의 레버리지입니다.
구현 비용이 0에 가까워질수록, 희소 자원은 코드 작성에서 사람 정렬(alignment)로 이동합니다. 가장 큰 기회는 같은 목표를 향해 협업하는 ‘비슷한 생각을 가진 사람들의 커뮤니티’와, 개발자가 과거를 반복해서 다시 만들지 않고 함께 앞으로 나아갈 수 있는 생태계를 만드는 데 있습니다.
우리 팀에게 이것은 다른 개발자가 성공하도록 돕는 도구와 플랫폼에 집중한다는 뜻입니다. 기존 코드를 앞으로 전진시키고, 최신 컴퓨팅을 활용하게 하며, 인간과 AI의 협업을 가능하게 하는 시스템 말이죠. 이는 Modular의 AI 컴퓨트를 민주화한다는 미션과 직접적으로 맞닿아 있으며, 전 세계 프로그래머가 만들 수 있는 것의 범위를 확장합니다.
Claude C Compiler는 소프트웨어나 컴파일러 엔지니어링의 종말을 의미하지 않습니다. 오히려 문을 더 넓게 열어 줍니다. 구현이 쉬워질수록, 진정한 혁신을 위한 여지는 더 커집니다.
구현의 장벽이 낮아진다고 엔지니어의 중요성이 줄어드는 것이 아니라, 비전, 판단, 취향의 중요성이 올라갑니다. 만드는 일이 쉬워질수록, 무엇을 만들 가치가 있는지 결정하는 일이 더 어려운 문제가 됩니다. AI는 실행을 가속하지만, 의미, 방향, 책임은 근본적으로 인간에게 남아 있습니다.
코드를 쓰는 것이 목표였던 적은 없습니다. 의미 있는 소프트웨어를 만드는 것이 목표입니다. 미래는 새로운 도구를 받아들이고, 가정을 도전하며, 사람들이 함께 만들 수 있도록 돕는 시스템을 설계하는 팀의 것이 될 것입니다.
이것이 Modular의 미션을 처음부터 이끌어 온 미래이며, AI의 새로운 시대가 가능하게 한다고 제가 믿는 미래입니다.
우리와 함께 AI의 미래를 만들고 싶으신가요? Modular는 채용 중입니다.
