Optimizing an IDE for an Evolving Language Ecosystem
본 논문은 언어 서버 프로토콜과 기존 핵심 컴파일러를 활용하여 진화 중인 Move 스마트 계약 언어용 고성능 IDE 구축 전략을 제시하고, 생태계 성장을 지원하기 위해 필요한 인프라 최적화와 얻은 교훈을 상세히 설명합니다.
원본 논문은 CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) 라이선스로 제공됩니다. 이것은 아래 논문에 대한 AI 생성 설명입니다. 저자가 작성하거나 승인한 것이 아닙니다. 기술적 정확성을 위해서는 원본 논문을 참조하세요. 전체 면책 조항 읽기
새로운 도시를 처음부터 짓는다고 상상해 보세요. 당신은 건물의 설계도 (프로그래밍 언어) 와 건설 노동대 (컴파일러) 를 가지고 있습니다. 하지만 누구나 그곳에 실제로 살거나 유용한 것을 건설하기 전에, 길을 안내하고 특정 주소를 찾으며 건설 중 발생하는 실수를 수정해 줄 초지능 어시스턴트가 필요합니다. 코딩 세계에서는 이 어시스턴트를 IDE(통합 개발 환경) 라고 부릅니다.
Mysten Labs 팀이 작성한 논문은 Move(스마트 계약을 위한 언어) 라는 새로운 도시를 위한 이 "초지능 어시스턴트"를 어떻게 구축했는지 설명합니다. 여기서는 간단한 비유를 사용하여 그들이 어떻게 했는지 그 이야기를 풀어보겠습니다.
큰 딜레마: 새 엔진을 만들 것인가, 기존 엔진을 사용할 것인가?
새로운 어시스턴트를 구동하기 위해 자동차 엔진이 필요할 때, 당신은 두 가지 선택지가 있습니다.
- 어시스턴트만을 위해 처음부터 완전히 새로운 엔진을 만드는 것. 이는 운전자를 돕는 한 가지 일만 하는 맞춤형 엔진을 만들기 위해 특수 정비공을 고용하는 것과 같습니다. 이 엔진은 작업에 완벽할 수 있지만, 시간이 오래 걸리고 비용이 많이 듭니다.
- 이미 가지고 있는 엔진을 사용하는 것. 도시 건설자들은 설계도를 완성된 건물로 변환하도록 설계된 거대하고 강력한 엔진 (컴파일러) 을 이미 보유하고 있었습니다.
팀은 옵션 2를 선택했습니다. 그들은 어시스턴트를 기존 도시 엔진에 연결하기로 결정했습니다.
- 위험: 이 엔진은 설계도를 그리는 동안 사람들을 돕기 위해 만들어진 것이 아니라, 건물을 완성하기 위해 만들어졌습니다. 따라서 너무 느리거나 무거울 수 있습니다.
- 보상: 엔진이 이미 존재했기 때문에, 새로운 엔진을 만드는 데 몇 년을 기다리는 대신 어시스턴트를 거의 즉시 가동할 수 있었습니다.
문제: 엔진이 너무 느렸습니다
처음에는 어시스턴트가 작동했지만, 매우 둔했습니다. 도서관 사서에게 책을 찾아달라고 요청한다고 상상해 보세요. 만약 사서가 한 페이지를 찾기 위해 도서관 뒤쪽까지 걸어가고, 모든 선반을 하나씩 확인하며 모든 책의 표지를 끝까지 읽어야 한다면, 당신은 오랫동안 기다려야 할 것입니다.
Move 도시가 커짐에 따라 도서관도 커졌습니다. 개발자가 코드에 아주 작은 변경을 가할 때마다, 어시스턴트는 전체 도서관 (코드와 모든 종속성) 을 처음부터 다시 읽어야 했습니다. 이는 1 초 이상 걸렸는데, 개발자에게는 영원처럼 느껴졌습니다.
해결책: 어떻게 속도를 높였는가
팀은 엔진을 재건축하지 않고 최적화해야 한다는 사실을 깨달았습니다. 그들은 세 가지 주요 "조정"을 적용했습니다.
1. "미리 읽기" 도서관 (종속성 사전 컴파일)
문제: 개발자가 자신의 이야기를 변경할 때마다 어시스턴트는 표준 도서관 책들 (사전이나 수학 가이드 등) 을 매번 다시 읽었습니다.
해결: 그들은 "이봐, 사전은 아무도 바꾸지 않아!"라고 깨달았습니다. 그래서 그들은 미리 읽은 선반을 만들었습니다. 표준 도서관 책들을 한 번 읽고 중요한 메모를 적어 특수 선반에 두었습니다. 이제 어시스턴트가 단어를 확인해야 할 때, 도서관 뒤쪽까지 걸어가는 대신 선반에서 메모를 가져오면 됩니다.
- 결과: 대기 시간이 거의 1 초에서 밀리초의 일부로 단축되었습니다.
2. "부분 점검" 전략 (증분 컴파일)
문제: 미리 읽은 선반이 있더라도, 개발자가 100 페이지 분량의 이야기를 변경하면 어시스턴트는 변경되지 않은 부분까지도 여전히 전체 이야기를 다시 읽으려 했습니다.
해결: 그들은 어시스턴트에게 (좋은 의미로) 게으르게 되라고 가르쳤습니다. 개발자가 50 페이지만 변경했다면, 어시스턴트는 50 페이지만 다시 읽습니다. 나머지 99 페이지에 대해서는 "이 부분은 이미 알고 있어, 변경되지 않았어"라고 말합니다.
- 결과: 이 조치는 거대한 코드베이스에서도 어시스턴트가 즉시 반응하는 것처럼 느끼게 했습니다.
3. "공유 배낭" (메모리 최적화)
문제: 어시스턴트는 거대한 배낭을 들고 있었습니다. 배낭이 너무 무거워서 개발자가 세 가지 다른 프로젝트를 열면, 어시스턴트의 배낭이 너무 무거워져 컴퓨터가 느려지거나 충돌했습니다. 어시스턴트가 지금 당장 볼 필요가 없는 세부 사항까지 모든 책의 모든 세부 사항을 들고 있었습니다.
해결: 그들은 배낭을 재배치했습니다. 무겁고 불필요한 세부 사항을 버리고 필수 메모만 남겼습니다. 또한, 세 명의 개발자가 같은 사전이 필요한 프로젝트에서 작업할 때, 세 개의 별도 사전이 필요하지 않다는 사실을 깨달았습니다. 그들은 세 프로젝트 모두에서 하나의 사전만 공유했습니다.
- 결과: 배낭이 훨씬 가벼워져서 어시스턴트는 땀 한 방울 흘리지 않고 여러 프로젝트를 동시에 처리할 수 있게 되었습니다.
배운 교훈
논문은 새로운 언어를 위한 유사한 어시스턴트를 구축하려는 사람들을 위한 몇 가지 "경험 법칙"으로 결론을 내립니다.
- 모든 것을 한 번에 만들지 마라: 첫날부터 완벽한 엔진이 필요하지 않다. 도시가 커짐에 따라 가지고 있는 것으로 시작하고 조정하라.
- 캐싱을 예상하라: 두 번 하지 않도록 작업을 저장 (미리 읽은 선반과 같은) 할 계획을 항상 세우라.
- 무게를 주의하라: 당신이 (메모리) 같은 "물건"을 얼마나 많이 나를 수 있는지에 주의하라. 무거운 배낭을 날 수 있다고 해서 해야 한다는 뜻은 아니다.
- 회복 탄력성을 가지라: 개발자가 오타를 내면 어시스턴트가 그만두고 포기해서는 안 된다. "실수를 보았지만, 나머지 문장을 계속 도와주겠어"라고 말해야 한다.
결론
팀은 기존 장비를 어떻게 사용했는지 지혜롭게 함으로써 느리고 무거운 건설 엔진을 빠르고 민첩한 어시스턴트로 성공적으로 변모시켰습니다. 그들은 새로운 엔진을 만들지 않았습니다. 단지 기존 엔진을 훨씬 더 효율적으로 작동하게 만들었을 뿐입니다. 이를 통해 개발자들은 좌절 없이 스마트 계약 도시를 빠르게 건설할 수 있게 되었습니다.
연구 분야의 논문에 파묻히고 계신가요?
연구 키워드에 맞는 최신 논문의 일일 다이제스트를 받아보세요 — 기술 요약 포함, 당신의 언어로.