안녕하세요, Shrijith Venkatramana입니다. 저는 모든 커밋에서 실행되는 AI 코드 리뷰어인 git-lrc를 만들고 있습니다. 개발자들이 이 프로젝트를 발견할 수 있도록 Star Us를 눌러주세요. 꼭 한 번 사용해 보시고 제품 개선을 위한 피드백을 공유해 주세요.

모든 UI 프레임워크는 결국 동일한 문제에 직면합니다: 화면의 요소들을 어떻게 배치할 것인가?

버튼은 정렬되어야 합니다. 사이드바는 늘어나야 합니다. 카드는 줄바꿈(wrap)되어야 합니다. 모바일 레이아웃은 적응형(adapt)이어야 합니다. 갑자기 애플리케이션을 만드는 대신 레이아웃 알고리즘을 작성하고 있는 자신을 발견하게 됩니다.

웹은 Flexbox를 통해 이 문제를 대체로 해결했습니다. 하지만 데스크톱 앱, 게임 UI, PDF 생성기, 터미널 애플리케이션, 또는 심지어 Go로 작성된 이미지 렌더러를 만들고 있다면 어떨까요?

레이아웃을 처음부터 다시 만드실 건가요?

다행히도, 그렇지 않습니다.

Meta에서 원래 개발된 레이아웃 엔진인 Yoga를 사용하면 Go를 포함한 거의 모든 곳에서 동일한 Flexbox 모델을 재사용할 수 있습니다.

어떻게 가능한지 살펴보겠습니다.

Yoga란 정확히 무엇인가요?

Yoga는 UI 툴킷(toolkit)이 아닙니다.

버튼을 그리지는 않습니다.
텍스트를 렌더링하지도 않습니다.
HTML에 대해서는 아무것도 모릅니다.

대신, Yoga는 단 하나의 질문에 답합니다:

요소 트리(tree of elements)와 Flexbox 규칙 세트가 주어졌을 때, 각 요소는 어디에 위치해야 하며 크기는 얼마여야 하는가?

그것이 전부입니다.

이를 기하 엔진(geometry engine)이라고 생각하세요.

Your widgets
      │
      ▼
...

이러한 분리 덕분에 Yoga는 믿을 수 없을 정도로 이식성(portable)이 높습니다. 동일한 엔진이 다양한 렌더링 시스템 전반에서 레이아웃을 구동합니다.

Go 개발자가 왜 관심을 가져야 할까요?

Go를 작성하고 있다면, 브라우저 외부의 무언가를 만들고 있을 가능성이 높습니다.

예시는 다음과 같습니다:

• 데스크톱 애플리케이션 (desktop applications)
• 터미널 사용자 인터페이스 (terminal user interfaces)
• PDF 생성기 (PDF generators)
• 대시보드 (dashboards)
• 게임 인터페이스 (game interfaces)
• 다이어그램 생성기 (diagram generators)
• SVG 렌더러 (SVG renderers)
• 커스텀 시각화 도구 (custom visualization tools)

이 모든 것에는 레이아웃이 필요합니다.

Yoga가 없다면, 개발자들은 종종 다음과 같은 코드를 작성하게 됩니다:

button.X = sidebarWidth + 20
button.Y = headerHeight + 15
button.Width = windowWidth - 40

이런 방식은 금방 취약해집니다.

대신, 여러분은 _관계 (relationships)_를 기술합니다.

Container
├── Sidebar (고정 너비)
└── Content (채우기 위해 확장)

Yoga가 여러분을 대신해 실제 수치를 계산합니다.

브라우저 없는 Flexbox

만약 여러분이 다음과 같이 CSS를 작성해 본 적이 있다면:

.container {
    display: flex;
    flex-direction: row;
...

여러분은 이미 Yoga의 대부분을 배운 셈입니다.

동일한 개념들이 존재합니다:

• Flex Direction (플렉스 방향)
• Justify Content (콘텐츠 정렬)
• Align Items (아이템 정렬)
• Flex Grow (플렉스 확장)
• Flex Shrink (플렉스 축소)
• Gap (간격)
• Padding (패딩)
• Margin (마진)

DOM 요소를 직접 조작하는 대신, 레이아웃 노드 (layout nodes)를 설정하게 됩니다.

트리는 다음과 같은 모습일 수 있습니다:

Root
├── Header
├── Body
...

Yoga는 이 트리를 순회하며 모든 사각형 (rectangle)을 계산합니다.

Go에서 첫 번째 레이아웃 구축하기

두 개의 패널이 있는 가로 레이아웃을 만든다고 가정해 봅시다.

• 왼쪽 패널: 고정 너비
• 오른쪽 패널: 남은 공간을 채움

구조는 다음과 같습니다:

Root (800px)
├── Left (200px)
└── Right (확장)

Go 바인딩 (binding)을 사용하면 코드는 놀라울 정도로 짧습니다:

root := yoga.NewNode()
root.StyleSetWidth(800)
root.StyleSetHeight(600)
...

레이아웃이 계산된 후에는 다음과 같습니다:

Left:
    x = 0
    width = 200
...

좌표 계산 (coordinate math)이 없다는 점에 주목하세요.

여러분은 의도 (intent)를 기술합니다.

Yoga는 기하학 (geometry)을 계산합니다.

동적 콘텐츠 측정하기

실제 인터페이스는 단순히 상자들로만 이루어져 있지 않습니다.

텍스트는 변합니다.

이미지는 크기가 조정됩니다.

위젯은 고유한 크기 (intrinsic sizes)를 가집니다.

Yoga는 이를 **측정 함수 (measure functions)**를 사용하여 처리합니다.

노드에 고정된 너비와 높이를 주는 대신, 콘텐츠가 실제로 얼마나 많은 공간을 필요로 하는지 Yoga에게 알려주는 콜백 (callback)을 제공합니다.

개념적으로는 다음과 같습니다:

textNode.SetMeasureFunc(func(...) Size {
    return MeasureText(...)
})

레이아웃 과정에서 Yoga는 다음과 같이 묻습니다:

"내가 이만큼의 너비를 준다면, 당신의 높이는 얼마나 될까요?"

이것은 브라우저가 문단을 배치하는 방식과 정확히 일치합니다.

중요한 점은 Yoga가 텍스트를 직접 측정하지 않는다는 것입니다.

폰트, 이미지 및 렌더링 (rendering)에 대한 책임은 여전히 여러분의 애플리케이션에 있습니다.

Yoga는 오직 레이아웃만 수행합니다.

Yoga가 렌더링 파이프라인 (Rendering Pipeline)에 통합되는 방식

일반적인 아키텍처는 다음과 같습니다:

Application State (애플리케이션 상태)
        │
        ▼
...

이러한 분리는 다음과 같은 몇 가지 장점을 가집니다:

• 렌더링 (rendering)과 레이아웃 (layout)이 독립적으로 유지됨
• 렌더러 (renderer)를 교체하는 것이 더 쉬워짐
• 레이아웃이 결정론적 (deterministic)이 됨
• 위젯 (widgets)이 화면 좌표를 알 필요가 없음
• 웹 개발에서의 Flexbox 지식을 직접적으로 전이할 수 있음

많은 현대적인 UI 시스템은 애플리케이션이 성장함에 따라 확장성이 뛰어나기 때문에 이 아키텍처를 따릅니다.

마치며

Yoga의 가장 큰 강점 중 하나는 이미 익숙한 멘탈 모델 (mental model)을 브라우저 외부로 가져온다는 점입니다.

모든 프로젝트마다 새로운 레이아웃 시스템을 발명하는 대신, 수많은 인터페이스를 통해 검증된 성숙한 Flexbox 구현체를 사용할 수 있습니다.

데스크톱 애플리케이션, 렌더러, 에디터, 대시보드, PDF, 게임 또는 커스텀 그래픽 파이프라인 (graphics pipelines)을 구축하는 Go 개발자들에게 Yoga는 레이아웃 문제의 한 부류를 통째로 제거해 줍니다. 모든 좌표를 직접 계산하는 대신, 인터페이스가 어떻게 보여야 하는지를 기술하는 데 집중할 수 있습니다.

UI의 복잡성이 증가함에 따라, 이러한 구분은 점점 더 가치 있어집니다.

Go 프로젝트에서 Yoga 또는 다른 레이아웃 엔진을 사용해 본 적이 있나요? 여러분이 무엇을 만들고 있는지, 그리고 수동 좌표 계산보다 선언적 (declarative) 레이아웃 시스템을 선호하는지 궁금합니다.

*AI 에이전트는 코드를 빠르게 작성합니다. 하지만 사용자에게 알리지 않고 조용히 로직을 제거하거나, 동작을 변경하고, 버그를 유발하기도 합니다. 이는 종종 프로덕션 환경에서 발견됩니다.

git-lrc는 이를 해결합니다. git commit에 후킹하여 모든 diff를 반영하기 전에 검토합니다. 60초면 설정이 완료됩니다. 완전히 무료입니다.*

어떤 피드백이나 기여도 환영합니다! 온라인에서 소스 코드를 확인할 수 있으며, 누구나 사용할 준비가 되어 있습니다.

GitHub logo HexmosTech / git-lrc

Git Commit에서 실행되는 무료 마이크로 AI 코드 리뷰

| 🇩🇰 Dansk | 🇪🇸 Español | 🇮🇷 Farsi | 🇫🇮 Suomi | 🇯🇵 日本語 | 🇳🇴 Norsk | 🇵🇹 Português | 🇷🇺 Русский | 🇦🇱 Shqip | 🇨🇳 中文 | 🇮🇳 हिन्दी |

git-lrc

커밋에서 실행되는 무료 마이크로 AI 코드 리뷰

Go Report Card

gitleaks.yml

osv-scanner.yml

govulncheck.yml

semgrep.yml

dependabot-enabled

오늘날의 GenAI(생성형 AI)는 브레이크 없는 레이싱 카와 같습니다. 무언가를 설명하기만 하면 대량의 코드 블록이 즉시 나타나며 빠르게 가속합니다. 하지만 AI 에이전트는 사용자에게 알리지도 않은 채 조용히 문제를 일으킵니다. 로직을 제거하거나, 제약 조건을 완화하고, 비용이 많이 드는 클라우드 호출을 도입하며, 자격 증명(credentials)을 유출하고, 동작을 변경해 버립니다. 그리고 당신은 종종 이를 운영 환경(production)에서야 발견하게 됩니다.

git-lrc는 당신의 제동 시스템입니다. 이 도구는 git commit에 연결되어, 변경 사항이 반영되기 전에 모든 디프(diff)에 대해 AI 리뷰를 실행합니다. 설정은 60초면 충분하며, 완전히 무료입니다.

요약하자면, git-lrc는 장애, 보안 침해, 기술 부채가 발생하기 전에 이를 방지하도록 돕습니다.

한눈에 보기: 10가지 위험 카테고리 · 100개 이상의 실패 패턴 추적 · 모든 커밋에 적용…

GitHub에서 보기