주목할 만한 ‘K-오픈소스’ 프로젝트

스벨트전도사2025년 4월 30일About 5 min

주목할 만한 ‘K-오픈소스’ 프로젝트 관련

지금 가장 주목받는 ‘K-오픈소스’ 프로젝트들을 소개합니다. 타입스크립트 런타임 타입 검증을 가능케 한 typia, 초고속 웹 컴파일러 SWC, 선언형 그래픽 엔진 Flitter, 딥러닝 언어 nn, NHN의 TOAST UI까지—한국 개발자들의 놀라운 혁신을 확인해보세요.

왜 핵심 코드를 공개할까요?

스펀지밥에 나오는 플랑크톤을 기억하시나요? 게살버거의 비밀 레시피를 훔치려고 수백 번 시도했던 그 캐릭터 말이죠. 통상적으로 기술은 보호하고 감춰야 안전하다고 생각합니다. 특허를 내고, 영업비밀로 지정하며, NDA를 맺고 철저히 보호하는 것이 상식이죠.

그런데 오픈소스는 정반대의 길을 걷습니다. 비밀 레시피를 모두에게 공개해 버리는 것이니까요. 개인 개발자들의 자선이라고만 생각하시나요? 놀랍게도 기업들도 핵심 코드를 오픈하고 있습니다. 딥마인드는 LLM인 젬마 모델을, 메타(Meta)는 프론트엔드 프레임워크 리액트(React)를, 버셀(Vercel)은 리액트 프레임워크인 Next.js를 공개했습니다.

글로벌 빅테크 기업들은 어째서 자신들의 비법 소스를 남들에게 공개하는 걸까요? 그들이 선량하고 자비심이 넘쳐서 인류를 이롭게 하자는 홍익인간 정신을 가지고 있는 걸까요? 아마 그건 아닐 겁니다. 치열한 비즈니스 세계에서 이타주의보다는 치밀한 전략이 있기 마련이니까요.

코드를 공개하면 마케팅이 됩니다

자신의 기업이 건실하고, 실력 있고, 기술이 유망함을 알리면서도 이미 자리 잡은 대기업들 사이에서 시장에 존재감을 보이기 위해해 할 수 있는 가장 효과적인 전략은 무료 마케팅입니다. 자신의 기술이 아무리 훌륭해도 사람들이 알아주지 않으면 무슨 소용일까요? 그래서 아예 오픈해버리는 선택을 하는 겁니다.

우리 회사에서도 ‘열린생각’이라는 추론 AI 모델 학습 데이터셋을 허깅페이스(Hugging Face)에 오픈한 적이 있습니다. 오픈소스는 가장 훌륭한 마케팅입니다. 특히 스타트업이나 새로운 기술을 개발한 기업에게는 더욱 그렇죠.

이것은 단순한 노출 이상의 효과를 얻을 수도 있는 전략입니다. 개발자 커뮤니티에서 인지도를 높이고, 회사의 기술력을 입증하며, 심지어 채용 시장에서도 우위를 점할 수 있게 됩니다. "우리는 이런 기술을 만들 정도로 실력이 있어요."라고 직접 말하는 것보다, 코드를 공개적으로 보여주는 것이 훨씬 더 설득력 있으니까요.

출처: <FontIcon icon="iconfont icon-huggingface"/>허깅페이스 Korean-OpenThoughts-114k-Normalized, 작가 캡처 — 출처: 허깅페이스 Korean-OpenThoughts-114k-Normalized, 작가 캡처

"오픈하면 기술을 뺏기는 거 아닐까?" 우려의 목소리가 나올 수 있습니다. 맞습니다, 뺏길 수도 있죠… 만약 오픈한 뒤 기술 개발을 멈춘다면 말입니다. 하지만 오픈소스로 공개하는 쪽은 지속적으로 기술을 고도화합니다. 사내에는 더 나은 버전을 프라이빗하게 가지고 있을 수도 있고요. 이때 발전 속도는 오픈하지 않았을 때보다 오픈했을 때가 더 빠릅니다. 사내 직원들의 피드백뿐만 아니라 해외의 글로벌 개발자들로부터 공짜로 QA를 받을 수 있으니까요. 더욱이 그들은 버그까지 직접 수정해서 올려줍니다. 그것도 무료로요!

기술을 베끼려고 했던 기업들은 오픈소스가 빠르게 발전하는 모습을 보고, 스스로 따로 만들어서 관리하는 것보다 오픈소스를 그대로 쓰는 쪽이 자원 효율이 높다고 판단할 것입니다. 이렇게 여러 기업들이 우리 회사의 기술에 종속되는 것이죠.

더 나아가 그들은 자신들의 요구 사항을 구현하기 위해 우리 기술에 투자할 수도 있습니다. 직접적인 개발 기여는 물론, 스폰서십(sponsorship)이라는 금전적인 형태로도 참여합니다. 오픈소스 사업은 기업들에게 필요한 기술을 무료로 제공하는 동시에, 스폰서 기업의 요구 사항을 우선 처리하는 방식으로 이루어집니다. 쉽게 말해, "돈 내면 그거부터 해줄게."가 되는 셈입니다.

이는 생태계의 주도권을 확보하는 똑똑한 방법입니다. 리액트를 공개함으로써 메타는 웹 개발의 패러다임을 바꾸었고, 업계 표준을 주도하게 되었습니다. 이는 단순한 기술 공유가 아니라 디지털 생태계의 방향성을 결정하는 힘을 얻는 것입니다.

온 세상이 당신의 기술을 가르칩니다

메타는 리액트라는 라이브러리를 공개하고 벌써 버전 19까지 발전시켰습니다. 다양한 기능이 추가되며 라이브러리 사용법은 더욱 복잡해졌죠. 현재 메타 내의 웹 서비스들은 모두 리액트로 만들어지고 있습니다.

그런데 이들은 신입 직원에게 사내 기술 사용법을 따로 가르칠 필요가 없습니다. 온 세상이 React를 쓰고 있고, React 강의와 부트캠프, 다양한 활용 사례가 활발히 공유되고 있기 때문입니다. 심지어 다른 라이브러리와 프레임워크조차도 React를 우선으로 고려하여 만들어집니다. 이런 생태계를 만들어낸 메타의 전략, 정말 대단하지 않나요?

이러한 전략은 버셀에서도 볼 수 있습니다. Vercel은 Next.js라는 리액트 프레임워크를 오픈소스로 공개하면서 서버 사이드 렌더링(SSR)과 정적 사이트 생성(SSG)의 표준을 만들어가고 있습니다. 개발자들이 Next.js를 사용할수록 자연스럽게 Vercel의 호스팅 서비스와 생태계에 의존하게 되는 영리한 전략입니다. 이제 많은 기업들이 Vercel 중심의 개발 환경에서 웹 애플리케이션을 구축하고 있습니다.

오픈소스가 모두에게 주는 선물

이러한 오픈소스 생태계는 참여하는 모든 이에게 다양한 혜택을 제공합니다. 개발자들은 최신 기술을 깊이 이해하고 실무에 바로 적용할 수 있으며, 글로벌 커뮤니티와 네트워크를 형성하고, 채용 시장에서 경쟁력 있는 포트폴리오를 구축할 수 있습니다. 스타트업은 초기 개발 비용 절감으로 빠르게 시장에 진입하고, 검증된 기술 스택을 통해 안정적인 서비스를 구축하며, 대기업과의 기술 격차를 효과적으로 좁힐 수 있습니다.

IT 생태계 전체로 보면 기술 발전이 더욱 가속화되고, 중복 개발이 방지되어 효율성이 증가하며, 기술 표준화를 통해 호환성이 높아지는 효과를 얻습니다.

한국인이 한 프로젝트도 있나요?

"한국은 IT 강국인데 왜 글로벌 오픈소스 프로젝트는 없을까?"라고 생각하시나요? 사실 한국의 개발자들은 오픈소스 생태계에서 활발히 활동하고 있습니다. 다만, 많은 사람들이 그 개발자들이 한국인이라는 사실을 잘 모를 뿐이죠.

그동안 한국은 글로벌 오픈소스 생태계에서 주로 '소비자' 역할을 해왔습니다. 해외에서 만들어진 오픈소스 기술을 활용하는 데는 익숙했지만, 글로벌한 영향력을 가진 오픈소스를 직접 만들어내는 사례는 상대적으로 적었습니다.

하지만 최근 몇 년간, 이 구도가 빠르게 변하고 있습니다. 개인 개발자들이 각자 흥미로운 오픈소스 프로젝트를 활발히 진행하고 있습니다. 타입스크립트(TypeScript) 컴파일러를 응용한 작업부터 딥러닝용 새로운 언어 개발, 그래픽 렌더링 라이브러리까지, 다양한 K-오픈소스 프로젝트들이 존재합니다. 그중에는 이미 들어본 오픈소스도 있을 겁니다. "그게 한국인이 만든 거였어?"라며 놀라게 될 수도 있습니다.

이 글에서는 주목할 만한 한국의 오픈소스 프로젝트 5가지를 소개해보려고 합니다. 각각의 프로젝트가 어떤 문제를 해결하기 위해 만들어졌는지, 그리고 개발자들의 일상을 어떻게 더 편리하게 만들어주는지 살펴볼 예정입니다. 여러분도 이 글을 읽고 오픈소스 개발에 흥미가 생기면 좋겠습니다.

Typia: 타입스크립트로 이런 거까지 된다고요?

"타입스크립트의 타입 체크는 런타임에서 가능할까요?"

이 질문은 많은 주니어 개발자들이 면접에서 마주할 수 있는 질문입니다. 저 또한 이 질문을 받은 적이 있죠. 대부분의 개발자는 "불가능합니다. 타입스크립트의 타입은 컴파일 타임에만 존재하고 런타임에서는 사라집니다."라고 답합니다. 그리고 그 대답은… 맞았습니다. 적어도 한국인 개발자자 samchon의 typia (samchon/typia)가 등장하기 전까지는요.

출처: <FontIcon icon="fas fa-globe"/>typia 홈페이지,작가 캡처 — 출처: typia 홈페이지,작가 캡처

사라지는 타입, 남겨지는 불안함

타입스크립트(TypeScript)의 가장 큰 아이러니는 바로 이것입니다. 열심히 작성한 타입 정의가 실제 애플리케이션이 실행될 때는 완전히 사라진다는 점이죠. 개발할 때는 타입 안전성이라는 든든한 울타리가 있지만, 빌드한 이후에는 그 울타리가 증발해 버립니다.

API로부터 데이터를 받아올 때, 파일을 불러올 때, 또는 사용자 입력을 처리할 때와 같은 상황에서 외부 데이터는 항상 불확실성을 내포하고 있습니다. "과연 내가 기대한 형태로 데이터가 들어올까?"라는 불안감을 해소하기 위해 개발자들은 런타임(runtime)에서 타입을 검증하는 별도의 라이브러리를 사용해 왔습니다.

// 타입 정의
interface User {
  id: string;
  email: string;
  age: number;
}

// Zod 같은 라이브러리를 이용한 스키마 재정의
const userSchema = z.object({
  id: z.string(),
  email: z.string().email(),
  age: z.number().min(0)
});

// 데이터 검증
const isValidUser = userSchema.safeParse(userData).success;

보이시나요? 같은 내용을 두 번이나 작성해야 합니다. 한 번은 타입스크립트를 위해, 또 한 번은 런타임 검증을 위해서 말이죠. 이런 중복 작업이야말로 개발자들을 괴롭히는 불필요한 노동이었습니다.

타입을 코드로 바꿔주는 typia

이런 문제를 해결하기 위해 typia는 재미있는 접근법을 사용했습니다. "타입스크립트 컴파일러가 타입을 분석해서, 그에 맞는 검증 코드를 자동으로 생성하면 어떨까?"

이것이 바로 typia의 핵심 아이디어입니다. 타입스크립트의 정적 타입 정보를 분석해 런타임에서 동작하는 자바스크립트 검증 코드로 변환해주는 것이죠.

// 타입 정의만 하면
interface User {
  id: string & tags.Format<"uuid">;
  email: string & tags.Format<"email">;
  age: number & tags.Type<"uint32"> & tags.Minimum<0>;
}

// 자동으로 런타임 검증 함수가 생성됩니다
const isUser = typia.is<User>;
const isValid = isUser(userData); // true 또는 false

단 한 줄의 코드로 완벽한 타입 검증이 가능해졌습니다. 더 이상 타입과 검증 로직을 따로 관리할 필요가 없어진 것이죠.

예를 들어, 다음과 같은 TypeScript 코드가 있다고 해봅시다.

const isUser = typia.createIs<User>();
const valid = isUser(data);

이 코드는 컴파일 후 다음과 같이 최적화된 JavaScript 코드로 변환됩니다.

// 예시 코드, 실제는 보다 더 최적화된 코드가 생성됩니다
const isUser = (() => {
  return (input) => {
    return typeof input === "object" && input !== null &&
      typeof input.id === "string" && 
      /^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/.test(input.id) &&
      typeof input.email === "string" && 
      /^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+.[a-zA-Z]{2,}$/.test(input.email) &&
      typeof input.age === "number" && 
      input.age > 19 && input.age <= 100;
  };
})();

성능까지 챙긴 typia

typia의 진가는 단순한 코드 편의성을 넘어 실제 성능에서도 드러납니다. 믿기 힘들 정도의 성능 차이가 여기 있습니다.

20,000배 더 빠른 검증 속도: 기존의 class-validator보다 무려 2만 배 빠른 속도로 타입 검증을 수행합니다. 백엔드 서버에서는 이를 통해 성능이 약 10배 향상됩니다.
200배 빠른 JSON 직렬화: class-transformer보다 200배 빠른 JSON 처리 능력을 보여줍니다. 대용량 데이터 처리에 최적화되어 있습니다.
복잡한 유니온 타입 지원: 다른 라이브러리들이 어려워하는 복잡한 유니온 타입(union type)도 안정적으로 처리합니다.

이러한 성능 향상의 비밀은 어디에 있을까요? typia는 타입 분석을 런타임이 아닌 컴파일 타임에 수행합니다. 따라서 런타임에서는 미리 최적화된 코드만 실행되어 놀라운 속도 향상이 가능한 것입니다. 또한 typia는 타입스크립트의 타입 시스템을 확장하여 더욱 풍부한 표현이 가능하게 합니다. 단순히 "이것은 문자열이다"를 넘어, "이것은 이메일 형식의 문자열이다"와 같은 구체적인 제약 조건을 타입 레벨에서 정의할 수 있게 된 것이죠.

LLM 함수 호출까지 자동화하다

LLM의 함수 호출(Function Calling)은 요즘 AI 애플리케이션 개발에 필수적인 기능이 되었습니다. 하지만 이를 위한 스키마(schema) 정의는 여전히 골치 아픈 작업이었죠. OpenAI나 Anthropic에 맞는 형식으로 함수를 일일이 정의해야 했으니까요.

typia는 최근에 새로운 기능을 추가했습니다. typia.llm.application()이라는 기능을 통해, 타입스크립트 인터페이스에서 직접 LLM 함수 호출 스키마를 생성할 수 있게 만든 것입니다.

// 인터페이스 정의
interface WeatherService {
  getWeather(props: {
    city: string;
    date: string;
  }): Promise<{
    temperature: number;
    condition: string;
  }>;
}

// LLM 함수 호출 스키마 자동 생성
const schema = typia.llm.application<WeatherService, "chatgpt">();

이렇게 생성된 스키마는 아래와 같이 OpenAI API에 바로 전달할 수 있는 형태로 변환됩니다.

{
  "functions": [
    {
      "name": "getWeather",
      "description": "getWeather 함수",
      "parameters": {
        "type": "object",
        "properties": {
          "props": {
            "type": "object",
            "properties": {
              "city": {
                "type": "string",
                "description": "도시 이름"
              },
              "date": {
                "type": "string",
                "description": "날짜"
              }
            },
            "required": ["city", "date"]
          }
        },
        "required": ["props"]
      }
    }
  ]
}

이제 타입스크립트 면접 질문의 답은 바뀌어야 합니다.

"타입스크립트의 타입 체크는 typia를 사용하면 런타임에서도 가능합니다."

samchon이라는 닉네임을 가진 한국 개발자가 만든 이 혁신적인 라이브러리는 타입스크립트 생태계에 새로운 패러다임을 제시했습니다. 이 라이브러리를 알게 되었다면 타입스크립트로 런타임에 타입 체크를 할 수 있는지 질문받았을 때, 자신 있게 "가능합니다."라고 답할 수 있습니다.

samchon/typia

Super-fast/easy runtime validators and serializers via transformation

SWC: 초고속 웹 컴파일러

코드를 수정하고 저장 버튼을 누른 후, 브라우저가 새로고침되기까지 기다리는 몇 초의 시간. 개발자라면 누구나 경험해 본 지루한 순간이 있습니다. 특히 대규모 프로젝트에서는 빌드 시간이 몇 분, 심지어 몇십 분까지 걸리기도 하죠. 개발 생산성을 크게 떨어뜨리는 이 문제를 해결하기 위해 한 한국 개발자가 나섰습니다.

출처: <FontIcon icon="fas fa-globe"/>swc 홈페이지,작가 캡처 — 출처: swc 홈페이지,작가 캡처

웹에 러스트를 끼얹다

SWC (Speedy Web Compiler swc-project/swc)는 한국 개발자 'kdy1'이 만든 초고속 JavaScript/TypeScript 컴파일러입니다. SWC의 가장 큰 특징은 바로 속도입니다. 기존 웹 개발 도구의 표준이었던 Babel보다 단일 스레드에서 20배, 4개 코어에서는 무려 70배나 더 빠른 속도를 자랑합니다.

이처럼 놀라운 성능 향상이 가능했던 비결은 무엇일까요? 바로 Rust라는 프로그래밍 언어를 선택한 것에 있습니다. kdy1은 대부분의 웹 도구가 자바스크립트로 작성되는 환경에서 과감하게 Rust를 선택했습니다. Rust는 메모리 안전성을 제공하면서도 C/C++에 필적하는 속도를 제공하는 현대적인 언어입니다.

자바스크립트로 작성된 Babel은 Node.js 환경에서 실행되기 때문에 근본적인 성능 한계가 있었습니다. 반면 SWC는 Rust의 성능 이점을 최대한 활용하여 컴파일러의 속도 한계를 완전히 새롭게 정의했습니다.

SWC는 단순한 컴파일러 이상의 가치를 가지고 있습니다. 확장성을 고려한 플랫폼으로 설계되어, 다양한 도구들이 이를 기반으로 구축될 수 있습니다. 코드 변환, 번들링, 최소화 등 여러 기능을 모듈화하여, 필요한 부분만 선택적으로 사용할 수 있는 유연성을 제공합니다. 또한 Rust의 웹어셈블리(WebAssembly, WASM) 지원을 통해 거의 모든 플랫폼에서 동작할 수 있어, 웹 개발 환경을 더욱 다양화하는 데 크게 기여합니다.

Next.js도 SWC를 도입했습니다!

SWC의 잠재력을 알아본 것은 웹 개발 프레임워크 분야의 선두주자인 버셀이었습니다. Next.js는 서버 사이드 렌더링을 지원하는 리액트 프레임워크입니다. 서버 사이드 렌더링을 구현할 때 Next.js를 사용한다고 해도 과언이 아닐 정도로 업계 표준이 된 유명 프레임워크죠.

이러한 유명 프레임워크인 Next.js가 버전 12부터 SWC를 기본 컴파일러로 도입했습니다. 그 결과는 놀라웠습니다.

개발 모드에서의 Fast Refresh 속도가 3배 더 빨라졌습니다.
프로덕션 빌드 속도가 5배 향상되었습니다.
코드 변환 및 최소화(미니파이)가 17배 더 빠르게 처리됩니다.

Next.js에서의 SWC 도입은 단순한 성능 향상 이상의 의미를 가집니다. 이를 통해 Next.js는 다양한 기능을 더욱 효율적으로 제공할 수 있게 되었습니다. Styled Components 같은 CSS-in-JS 라이브러리를 더 빠르게 처리하고, Jest 통합을 통해 테스트 환경 설정을 간소화하며, 로컬 패키지나 노드 모듈(Node Modules)의 코드를 자동으로 변환하고 번들링할 수 있게 되었습니다. 또한 불필요한 콘솔 출력 제거, 리액트 속성 제거 등 다양한 최적화 옵션도 제공합니다.

이 기능들은 과거엔 주로 Babel 플러그인으로 구현되었던 것들입니다. 하지만 이제는 SWC를 통해 훨씬 더 빠르게 처리됩니다. 덕분에 Next.js 개발자들은 프로젝트 규모가 커져도 빠른 개발 경험을 유지할 수 있게 되었습니다.

이런 건 외국 개발자들만 하는 줄 알았는데...

SWC는 한국 개발자들도 글로벌 소프트웨어 산업에 큰 영향을 미칠 수 있음을 보여주는 좋은 사례입니다. SWC의 개발자는 현재 버셀에서 일하고 있으며, Next.js의 GitHub 저장소에서도 그의 기여를 심심찮게 발견할 수 있습니다. 일반적으로 개발 도구는 영미권 개발자들이 주도해 왔습니다. 하지만 SWC는 이런 고정관념을 깨고 한국의 기술력을 전 세계에 증명했습니다. 버셀, 바이트댄스(ByteDance), 텐센트(Tencent), 쇼피파이(Shopify)와 같은 글로벌 기업들이 이미 프로덕션 환경에서 SWC를 사용하고 있으며, Next.js, Parcel, Deno와 같은 주요 자바스크립트 도구들도 이미 SWC를 채택했습니다.

오늘날 수많은 웹 개발자들이 한국에서 탄생한 이 도구를 통해 더 빠르고 효율적인 개발을 하고 있다는 사실은 정말 놀랍습니다. SWC의 성공은 단순한 기술적 혁신을 넘어, 글로벌 오픈소스 생태계에서 한국 개발자들의 위상을 높인 중요한 이정표가 되었습니다. 앞으로 더 많은 한국 개발자들이 세계적인 오픈소스 프로젝트를 이끌어갈 수 있도록 영감을 제공했다는 점에서, SWC의 가치는 단지 코드 그 이상이라고 할 수 있습니다.

GitHub - swc-project/swc: Rust-based platform for the Web

Rust-based platform for the Web. Contribute to swc-project/swc development by creating an account on GitHub.

Flitter: 선언적으로 캔버스와 SVG를 다루는 렌더링 엔진

출처: <FontIcon icon="fas fa-globe"/>flitter 홈페이지,작가 캡처 — 출처: flitter 홈페이지,작가 캡처

선언적 프로그래밍? 이게 뭐지?

웹 개발을 하셨다면 jQuery와 리액트의 차이를 느껴보셨을 겁니다. jQuery에서는 이런 식으로 코드를 작성했죠.

// jQuery 방식 - 명령적(imperative) 접근법
$("button").click(function() {
  // 버튼을 숨긴다
  $(this).hide();
  // 메시지 요소를 생성한다
  $("<p>버튼이 클릭되었습니다!</p>").appendTo("container");
  // 메시지 스타일을 변경한다
  $("container p").css("color", "red");
});

매 단계마다 "이걸 해라, 저걸 해라"라고 DOM을 직접 조작하는 방식입니다. 반면 리액트는 어떨까요?

// 리액트 방식 - 선언적(declarative) 접근법
function App() {
  const [isButtonClicked, setButtonClicked] = useState(false);
  
  return (
    <div id="container">
      {!isButtonClicked && (
        <button onClick={() => setButtonClicked(true)}>
          클릭하세요
        </button>
      )}
      {isButtonClicked && (
        <p style={{ color: 'red' }}>
          버튼이 클릭되었습니다!
        </p>
      )}
    </div>
  );
}

리액트에서는 "어떻게" 보다는 "무엇을" 보여줄지를 선언합니다. 상태에 따라 UI가 어떻게 보여야 하는지를 설명하면, 실제 DOM 업데이트는 리액트가 알아서 처리해주죠.

캔버스: 또다시 절차적 코드 작성하기

그런데 웹 그래픽을 다룰 때, 특히 Canvas를 사용할 때는 어떨까요? 안타깝게도 다시 절차적인 코드로 돌아가게 됩니다.

// Canvas의 일반적인 사용법 - 절차적
const canvas = document.getElementById('myCanvas');
const ctx = canvas.getContext('2d');

// 사각형 그리기
ctx.fillStyle = 'blue';
ctx.fillRect(10, 10, 100, 100);

// 텍스트 추가
ctx.fillStyle = 'white';
ctx.font = '16px Arial';
ctx.fillText('Hello Canvas', 20, 50);

// 이벤트 처리도 모두 수동으로...
canvas.addEventListener('click', function(e) {
  const rect = canvas.getBoundingClientRect();
  const x = e.clientX - rect.left;
  const y = e.clientY - rect.top;
  
  // hitTest를 직접 구현해야 함
  if (x >= 10 && x <= 110 && y >= 10 && y <= 110) {
    console.log('사각형 클릭됨!');
  }
});

캔버스(Canvas)는 DOM과 달리 요소들을 객체로 추적하지 않습니다. 모든 것이 그저 픽셀일 뿐이죠. 그래서 요소의 위치 계산, 이벤트 감지, 렌더링 최적화 등을 모두 개발자가 직접 구현해야 했습니다.

선언적 접근방식으로 캔버스와 SVG 다루기

이런 문제를 해결하기 위해 탄생한 것이 바로 Flitter입니다. Flitter는 구글(Google)의 Flutter 프레임워크에서 영감을 받아 웹에서 캔버스와 SVG를 선언적으로 다룰 수 있게 해주는 강력한 렌더링 엔진입니다.

// Flitter 사용 예시 - 선언적 접근법
import { Container, Text, TextStyle, GestureDetector, AppRunner } from '@meursyphus/flitter';

const app = new AppRunner({
  view: document.getElementById('app'),
});

app.runApp(
  Container({
    width: 200,
    height: 100,
    color: 'blue',
    child: GestureDetector({
      onClick: (e) => {
        console.log('Container clicked!');
      },
      child: Text('Hello, Flitter!', {
        style: new TextStyle({ color: 'white', fontSize: 20 }),
      }),
    }),
  })
);

이제 캔버스나 SVG를 사용하더라도 리액트와 같은 선언적 프로그래밍 방식을 유지할 수 있게 되었습니다.

Flitter의 핵심 특징

강력한 렌더링 엔진

Flitter는 강력한 렌더링 엔진을 기반으로 복잡한 그래픽과 UI를 효율적으로 처리합니다. 렌더 객체 트리를 사용하여 화면에 표시되는 요소들을 관리하고, 필요한 부분만 업데이트하는 최적화된 렌더링 파이프라인을 제공합니다.

선언적 프로그래밍 모델

Flitter는 상태가 변경되면 화면이 자동으로 업데이트되는 선언적(declarative) 패러다임을 따릅니다. 개발자는 UI가 어떻게 보여야 하는지만 정의하면 됩니다. 복잡한 DOM 조작이나 캔버스 명령은 Flitter가 자동으로 처리합니다.

듀얼 렌더러 지원 (SVG와 Canvas)

Flitter는 SVG와 Canvas, 두 가지 렌더러(renderer)를 모두 지원합니다. 상황에 따라 벡터 그래픽(SVG)이나 비트맵 그래픽(Canvas)을 선택할 수 있으며, 두 렌더러 간의 전환도 간편합니다.

// SVG 렌더러 사용
const app = new AppRunner({
  view: document.getElementById('app'),
  renderer: 'svg', // SVG 렌더러 선택
});

// Canvas 렌더러 사용
const app = new AppRunner({
  view: document.getElementById('app'),
  renderer: 'canvas', // Canvas 렌더러 선택
});

내장된 제스처 감지

Flitter는 복잡한 사용자 상호작용을 처리하기 위한 제스처 감지 기능을 내장하고 있습니다. 기존에는 캔버스에서 클릭 감지를 위해 hitTest 로직을 직접 구현해야 했지만, Flitter에서는 이 모든 것이 자동으로 처리됩니다.

GestureDetector({
  onClick: (e) => console.log('클릭됨!'),
  onDoubleClick: (e) => console.log('더블 클릭됨!'),
  onDragStart: (e) => console.log('드래그 시작!'),
  onDragUpdate: (e) => console.log('드래그 중...'),
  onDragEnd: (e) => console.log('드래그 종료!'),
  child: /* 자식 위젯 */
})

컴포넌트 기반 아키텍처

Flitter는 컴포넌트 기반 아키텍처를 채택하여 코드의 재사용성과 유지보수성을 높였습니다. 상태가 있는 위젯(StatefulWidget)과 상태가 없는 위젯(StatelessWidget)을 통해 다양한 UI 요소를 구현할 수 있습니다.

// 상태가 있는 위젯 예시
class Counter extends StatefulWidget {
  createState() {
    return new CounterState();
  }
}

class CounterState extends State<Counter> {
  private count: number = 0;

  incrementCounter() {
    this.setState(() => {
      this.count++;
    });
  }

  build() {
    return Container({
      padding: EdgeInsets.all(16),
      color: Colors.blue[100],
      child: GestureDetector({
        onTap: () => this.incrementCounter(),
        child: Text(`Count: ${this.count}`, {
          style: new TextStyle({ color: Colors.black, fontSize: 24 }),
        }),
      }),
    });
  }
}

Flitter는 어떻게 쓸 수 있나요?

Flitter는 다양한 그래픽 중심의 애플리케이션을 개발할 때 사용할 수 있습니다. 복잡한 데이터를 시각적으로 표현하는 차트와 그래프를 간편하게 구현할 수 있으며, 상호작용과 애니메이션을 추가해 사용자 경험을 향상할 수 있습니다. 특히 ERD(Entity-Relationship Diagram)나 마인드맵과 같은 다이어그램 편집기를 구현하는 데 이상적입니다. 요소 드래그(drag), 연결선 생성, 확대/축소 등의 복잡한 기능을 선언적으로 구현할 수 있어, 코드 관리가 훨씬 수월해집니다.

또한 게임, 드로잉 도구, 시뮬레이션 등 사용자와의 상호작용이 많은 그래픽 중심 애플리케이션에서도 Flitter를 활용할 수 있습니다. 내장된 제스처(gesture) 감지 기능과 고성능 렌더링 엔진 덕분에 복잡한 인터랙션(interaction)도 쉽게 구현할 수 있죠. 실제로 Flitter를 사용해 구현된 인터랙티브 ERD 도구 EasyRD는 Flitter의 강력한 기능을 보여주는 좋은 예입니다.

Flitter는 웹 그래픽 개발 방식에 혁신을 가져오는 렌더링 엔진입니다. 선언적 접근 방식으로 캔버스와 SVG를 다루기 때문에, 개발자들이 복잡한 그래픽 애플리케이션을 더 쉽고 효율적으로 구현할 수 있도록 도와줍니다.

사실 이쯤에서 조용히 밝혀야 할 것 같은데요. 이 글에서 소개한 Flitter 라이브러리의 개발자 Moon-DaeSeung은 바로 접니다. 원래 개인적으로 차트 라이브러리를 만들어 쓰려고 했는데, 차트 만들기가 생각보다 너무 어려워서 이 렌더링 엔진부터 개발하게 되었습니다. 그러다 보니 이렇게 오픈소스로 공유하게 되었네요. 관심 있으신 분들은 한번 사용해 보시고 피드백을 주시면 정말 감사하겠습니다.

meursyphus/flitter

Flitter is a powerful framework inspired by Flutter, supporting both SVG and Canvas to create high-performance graphics and user interfaces. It is designed to easily implement complex data visualiz...

TOAST UI: 한국 기업이 선보인 세계적 오픈소스 컴포넌트

내가 애용했던 라이브러리

NHN의 TOAST UI Chart는 제가 웹 개발을 하면서 가장 애용했던 차트 라이브러리 중 하나입니다. 다른 라이브러리로는 구현하기 어려웠던 복잡한 차트 커스텀(custom)도 TOAST UI로는 비교적 쉽게 구현할 수 있었습니다. 직접 코드를 분석해 봤는데, ChartJS에 비해 코드 구조가 훨씬 깔끔하더라고요. 사실 이 경험이 제가 오픈소스에 관심을 갖게 된 계기가 되기도 했습니다. "나도 이렇게 좋은 오픈소스를 만들어 보자."라는 생각이 들었으니까요.

지금이야 Toss의 overlay-kit이나 WRTN의 agentica처럼 한국 기업들이 다양한 오픈소스를 선보이는 시대가 되었지만, TOAST UI가 처음 공개되었을 당시에는 한국 기업이 오픈소스를 주도한다는 것이 매우 드문 일이었습니다. NHN은 다른 기업들과는 다른 길을 선택했고, TOAST UI라는 이름으로 고품질의 웹 컴포넌트 라이브러리를 오픈소스로 공개했습니다.

당시 국내 기업이 이렇게 방대한 규모의 오픈소스 프로젝트를 공개한다는 것은 매우 이례적인 일이었습니다. 특히 단순한 토이 프로젝트(toy project)가 아니라 실제 제품에도 사용할 수 있을 만큼 완성도 높은 컴포넌트를 공개했다는 점이 놀라웠죠.

다재다능한 TOAST UI 라이브러리

TOAST UI는 다양한 웹 개발 필요를 충족시키는 라이브러리들을 제공합니다. 그중에서도 가장 인기 있는 컴포넌트들을 살펴보겠습니다.

Chart: 데이터를 생동감 있게 표현하는 차트 라이브러리

TOAST UI Chart는 라인, 바, 파이 차트 등 다양한 유형의 데이터 시각화 도구를 제공합니다. 단순히 예쁜 차트만 그리는 것이 아니라, 복잡한 데이터를 직관적으로 표현할 수 있는 다양한 기능을 갖추고 있습니다. 특히 엑셀(Excel)로 데이터 내보내기나 이미지로 저장하기 같은 실용적인 기능도 포함하고 있어, 실무에서 매우 유용하게 사용됩니다.

Editor: 마크다운과 WYSIWYG을 모두 지원하는 텍스트 에디터

TOAST UI Editor는 마크다운 문서를 텍스트와 WYSIWYG(What You See Is What You Get) 모드로 동시에 편집할 수 있게 해줍니다. 구문 강조, 스크롤 동기화, 실시간 미리보기 등의 기능을 갖추고 있어 문서 작성 경험을 한층 향상시킵니다. 또한 차트 삽입도 지원하여 데이터 시각화와 문서 작성을 한 곳에서 할 수 있습니다.

Grid: 강력한 데이터 그리드 솔루션

TOAST UI Grid는 대량의 데이터를 효율적으로 표시하고 관리할 수 있는 그리드 라이브러리입니다. 데이터 편집, 필터링, 정렬, 페이지네이션 등의 기능은 물론, 다양한 cell editor와 renderer를 통해 원하는 형식으로 데이터를 표시하고 편집할 수 있습니다. 특히 복잡한 테이블 형태의 데이터를 다루는 애플리케이션에서 진가를 발휘합니다.

Calendar: 직관적인 일정 관리 도구

TOAST UI Calendar는 월간, 주간, 일간 뷰(view) 등 다양한 캘린더 보기 방식을 제공합니다. 기본 팝업 UI를 통해 일정 추가, 편집 및 삭제를 쉽게 할 수 있으며, 드래그 앤 드롭(drag and drop)으로 일정을 간편하게 이동할 수도 있습니다. 복잡한 일정 관리 기능을 필요로 하는 애플리케이션에 이상적인 솔루션입니다.

Image-editor: 다양한 기능을 갖춘 이미지 편집기

심플하면서도 아름다운 UI를 가진 TOAST UI Image-editor는 편집, 그리기, 텍스트 입력 기능을 제공합니다. 또한 다양한 이미지 필터를 적용할 수 있어 웹에서 바로 이미지를 편집하고 가공할 수 있습니다.

그 외 다양한 컴포넌트

TOAST UI는 위의 주요 라이브러리 외에도 다음과 같은 다양한 컴포넌트를 제공합니다.

App Loader:모바일 기기에서 특정 앱을 로드하거나 설치
Auto Complete: 입력 텍스트에 따른 자동 완성 기능
Color Picker: 직관적인 색상 선택 도구
Context Menu: 사용자 정의 컨텍스트 메뉴
Date Picker: 날짜 선택 컴포넌트
Pagination: 페이지 이동 컴포넌트
Rolling: 캐러셀 컴포넌트
Select Box: 선택 상자
Time Picker: 시간 선택 컴포넌트
Tree: 계층 구조 데이터 표현 컴포넌트

고품질의 컴포넌트 라이브러리

TOAST UI 라이브러리의 가장 큰 장점 중 하나는 깔끔한 코드 구조와 높은 확장성입니다. 특히 Chart 라이브러리는 ChartJS와 같은 유사한 라이브러리보다 코드가 잘 정돈되어 있어 커스터마이징(customizing)하기 쉽습니다.

TOAST UI의 성공은 한국 기업들이 오픈소스를 통해 글로벌 개발 생태계에 기여할 수 있다는 가능성을 열었습니다. 이제 많은 한국 기업들이 오픈소스를 활발하게 공개하고 있지만, TOAST UI가 그 첫 걸음을 내디뎠다는 점에서 그 의미는 특별합니다.

NHN

NHN has 105 repositories available. Follow their code on GitHub.

nn: 딥러닝 개발을 위한 실험적 언어

nn의 onnx 그래프<br/><출처: 작가 캡처> — nn의 onnx 그래프
<출처: 작가 캡처>

새로운 분야의 오픈소스 도전

최근 오픈소스 세계를 보면 블록체인 분야에서 Solidity나 Move 같은 특화 언어가 등장하고 있습니다. 대부분 대형 팀이나 기업들이 주도하는 프로젝트들이죠. 그런데 이와는 다른 영역에서 흥미롭고 실험적인 언어가 조용히 개발되고 있습니다. 바로 깃허브(GitHub) ID 'SieR-VR'로 활동하는 개발자가 만들고 있는 'nn'이라는 딥러닝 특화 언어입니다.

사실 새로운 프로그래밍 언어를 만드는 일은 쉬운 도전이 아닙니다. 그럼에도 이런 시도가 나온 배경에는 딥러닝 개발 과정에서 개발자들이 실제로 겪는 불편함이 존재합니다.

딥러닝 개발자의 고충: "이 텐서의 모양이 뭐였더라?"

딥러닝 모델을 개발하다 보면 항상 부딪히는 문제가 있습니다. 바로 텐서의 모양(shape)을 추적하는 일입니다.

x = torch.randn(64, 64, 3)  이미지 텐서
x = x.permute(2, 0, 1).unsqueeze(0)  차원 재배열
x = model(x)  모델 통과
여기서 x의 모양은?

PyTorch나 TensorFlow에서는 코드를 실행해보기 전까지는 텐서의 최종 모양을 정확히 알기 어렵습니다. 특히 여러 레이어를 거치면서 reshape, transpose 등의 연산이 추가되면 추적이 더욱 어려워집니다.

nn 언어: 컴파일 타임에 모양 체크

SieR-VR이 개발 중인 nn 언어는 이 문제를 정면으로 해결합니다. 코드를 실행하기도 전에, 컴파일 단계에서 모든 텐서의 모양을 계산하고 검증할 수 있습니다.

// nn 언어 예시
x: Tensor[64, 64, 3];  // 이미지 텐서

// 합성곱 레이어 적용 (커널 3x3, 패딩 1, 스트라이드 1, 출력 채널 16)
y = Conv2D[3, 1, 1, 16](x);

// 컴파일러가 자동으로 계산: y의 타입은 Tensor[64, 64, 16]

이 간단한 예시만으로도 nn 언어의 강력함이 드러납니다. Conv2D 연산 후 텐서의 모양이 어떻게 변할지 컴파일러가 자동으로 계산해주기 때문에, 개발자는 더 이상 복잡한 수식을 머릿속으로 계산할 필요가 없습니다.

// 좀 더 복잡한 예시
x: Tensor[64, 64, 3];
conv = Conv2D[5, 0, 1, 32](x);  // 패딩 없는 5x5 커널
// 출력 모양: Tensor[60, 60, 32] - 컴파일러가 자동 계산

pool = MaxPool2D[2, 2](conv);  // 2x2 풀링
// 출력 모양: Tensor[30, 30, 32] - 컴파일러가 자동 계산

실행 전에 이러한 모양 검증이 가능하다는 것은, 실행 시간에 발생할 수 있는 모양 불일치 오류를 사전에 방지할 수 있다는 의미입니다. 딥러닝 개발 과정에서 가장 흔하게 발생하는 오류 유형을 원천적으로 차단하는 셈이죠.

프로토타입에서 언어로

nn 언어는 처음부터 언어로 시작된 것이 아닙니다. SieR-VR은 처음에 C++의 템플릿 시스템을 활용해 StaticNet이라는 프로토타입을 개발했습니다. 이를 통해 컴파일 타임에 텐서 모양을 추적하는 아이디어를 검증했죠. 하지만 C++ 템플릿의 한계로 인해, 타입 계산 속도가 느리고 추론 기능이 제한적이었습니다. 이후 TypeScript 컴파일러 관련 작업을 하며 얻은 경험을 바탕으로, 아예 새로운 언어를 만들기로 결정했습니다.

한국 오픈소스의 새로운 지평

프로그래밍 언어를 개발하는 것은 거대 기업이나 연구 기관, 혹은 수십 명의 개발자가 참여하는 대형 오픈소스 프로젝트에서나 시도하는 일로 여겨져 왔습니다. 하지만 nn 언어는 한국의 개인 개발자가 실제 문제를 해결하기 위해 시작한 프로젝트입니다.

nn 언어가 흥미로운 점은 LSP(Language Server Protocol) 지원도 함께 개발되고 있다는 것입니다. 이는 Visual Studio Code와 같은 에디터에서 코드 자동 완성이나 오류 표시 같은 기능을 사용할 수 있게 해주는 기술인데, 이 정도 규모의 초기 프로젝트에서 볼 수 있는 것은 생각보다 드문 일입니다.

사실 SieR-VR은 제가 일하는 회사의 팀원이기도 합니다. 아직 많이 알려지지 않은 초기 단계의 프로젝트지만, 꾸준히 개발 중인 것으로 알고 있습니다. 관심 있으신 분들은 GitHub에서 프로젝트 진행 상황을 확인해보시면 좋을 것 같습니다.

다양해지는 한국 오픈소스

nn 언어는 한국 오픈소스 생태계에 또 하나의 다양성을 더해주고 있습니다. 지금까지 소개한 다른 프로젝트들이 주로 웹 개발 영역에 집중되었다면, nn은 딥러닝이라는 조금 다른 분야에서의 시도라는 점에서 더욱 반갑습니다. 물론 아직은 초기 단계이고 갈 길이 멀겠지만, 이런 다양한 시도들이 모여 한국 오픈소스 생태계가 점점 더 풍성해지고 있다는 생각이 듭니다. 앞으로의 발전 과정이 기대되는 프로젝트입니다.

nn-lang/nn

domain-specific language for deep neural networks

세상을 바꾸는 작은 시작, 오픈소스

"내가 만든 코드가 과연 누군가에게 가치가 있을까?" 많은 개발자들이 오픈소스를 시작하기 전 갖는 의문입니다. 그러나 이 글에서 소개한 프로젝트들은 이런 의문을 던진 개발자들이 그럼에도 불구하고 자신의 코드를 세상과 공유했을 때, 어떤 놀라운 일이 일어날 수 있는지 잘 보여줍니다.

오픈소스 프로젝트를 시작하면 예상치 못한 여러 가지 선물을 받게 됩니다.

글로벌 피드백은 당신의 코드를 더 견고하게 만듭니다.

혼자서는 상상할 수 없었던 버그와 개선점을 전 세계 개발자들이 찾아주고, 때로는 직접 수정까지 해줍니다. 이보다 더 좋은 코드 리뷰가 있을까요?

개발자로서의 성장은 자연스럽게 따라옵니다.

다른 개발자들의 질문에 답하고, 이슈를 해결하고, PR을 검토하는 과정에서 자신도 모르게 전문성이 쌓입니다. 오픈소스 프로젝트는 최고의 학습 플랫폼입니다.

커리어의 도약대가 될 수도 있습니다.

이 글에서 소개한 많은 개발자들은 자신의 오픈소스 프로젝트를 통해 글로벌 기업의 영입 제안을 받거나, 업계에서 인정받는 전문가가 되었습니다. 당신의 GitHub는 어떤 이력서보다 강력한 포트폴리오가 될 수 있습니다.

시작은 작게, 성장은 함께

오픈소스를 시작하는 데 거창한 아이디어나 완벽한 구현이 필요하지 않습니다. 때로는 자신이 매일 부딪치는 작은 문제를 해결하는 도구가 다른 많은 개발자들에게 큰 도움이 될 수 있습니다.

Flitter와 같은 프로젝트는 처음에는 개인적인 필요에서 시작된 경우가 많습니다. "차트 라이브러리를 만들려다가 생각보다 어려워서 렌더링 엔진부터 만들게 된" 것처럼, 때로는 예상치 못한 방향으로 발전하기도 합니다. 완벽을 추구하기보다는 작은 것부터 시작하고 커뮤니티와 함께 성장해 나가는 과정이 오픈소스의 매력입니다.

세상이 당신의 코드를 기다리고 있습니다

"내 코드가 과연 가치가 있을까?"

이런 의문을 이제 이렇게 바꿔 생각해 보면 어떨까요?

"내가 해결한 문제를 다른 누군가도 겪고 있지 않을까?"

당신이 직면한 문제, 당신이 발견한 해결책, 당신만의 독특한 관점은 누군가에게 영감이 되고 도움이 될 수 있습니다. 그것이 전 세계 수천 명의 개발자들이 사용하는 거대한 프로젝트로 성장할 수도 있고, 단 한 명의 개발자에게 "아하!" 순간을 선사하는 작은 도구에 그칠 수도 있습니다. 그러나 그 가치는 결코 작지 않습니다.

오픈소스는 기술적 솔루션을 넘어 '공유'와 '협력'의 문화를 형성합니다. 지식과 경험을 나누는 작은 행동들이 모여 K-오픈소스의 미래를 만들어가고, 어쩌면 전 세계 개발자 생태계에도 의미 있는 변화를 가져올 수 있지 않을까 기대해 봅니다. 조금이라도 관심이 생겼다면 용기를 내어 첫 걸음을 떼어보는 것도 좋겠습니다. 누군가에게 당신의 코드가 큰 도움이 될지도 모르니까요.

주목할 만한 ‘K-오픈소스’ 프로젝트