본문으로 건너뛰기
피드

Unity를 보고 드디어 C++ 코루틴이 왜 필요한지 이해했다

backend 약 4분
vote
0
댓글
북마크

C++ 코루틴의 실용적 유스케이스를 Unity의 이펙트 시스템에서 발견. 복잡한 상태 머신을 단순한 함수로 변환하는 것이 코루틴의 핵심 가치이며, Unity 스타일 co_yield 핵으로 100줄 미만의 코루틴 실행기를 C++에서 구현하는 방법을 소개.

  • 1

    C++ 코루틴 6년차인데 프로덕션에서 본 사람이 거의 없음

  • 2

    Unity의 이펙트 코루틴이 실용적 유스케이스의 좋은 예시

  • 3

    co_await는 어렵지만 co_yield로 '다음 프레임까지 양보' 패턴은 쉽게 구현 가능

  • 4

    전체 코루틴 실행기가 100줄 미만, 사이드 이펙트 제거 시 병렬화도 가능

"드디어 C++ 코루틴이 왜 필요한지 알겠다"

  • C++ 코루틴이 나온 지 6년인데, 프로덕션 코드에서 본 적이 있는 사람이 거의 없음. 이유가 두 가지: 저수준 보일러플레이트가 너무 많고, 피보나치 제너레이터 말고는 쓸만한 예제가 없었기 때문
  • 글쓴이가 Unity의 C# 코루틴을 보고 드디어 감이 옴. Unity에서는 코루틴으로 이펙트나 일시적 동작(ephemeral behaviour)을 구현하는데, 이게 진짜 실용적인 유스케이스임

코루틴이 빛나는 순간

  • 간단한 페이드아웃이야 람다로도 되지만, 여러 단계의 순차적 동작이 필요하면 얘기가 달라짐. 예: TimeWarp 이펙트처럼 이동 → 대기 → 이동 → 대기를 반복하는 경우
  • 이걸 코루틴 없이 C++로 짜면 수동 상태 머신이 됨. 상태 변수, 분기, 전환 로직... 코드 리뷰에서 통과시키고 싶지 않은 수준의 코드가 나옴
  • 코루틴을 쓰면? 상태 머신이 그냥 평범한 함수로 변환됨. "읽기 어려운 상태 머신을 매우 단순한 함수로 바꾸는 것", 이게 코루틴의 핵심 가치라는 거

Unity 스타일 핵으로 C++에서 구현하기

  • co_yield는 C++23의 <generator>로 비교적 쉬운데, co_await가 어려움. 뭘 기다리는지, 누가 깨워주는지, 어떤 실행 큐를 쓰는지... 답이 정해져 있지 않은 질문이 너무 많음
  • 글쓴이의 해결책: Unity가 10여 년 전에 쓴 것과 같은 핵을 씀. co_yield로 "다음 프레임까지 양보"를 표현하는 거. 의미론적으로는 맞지 않지만, 실용적으로는 완벽하게 동작함
  • 전체 코루틴 실행기 구현이 100줄도 안 됨. effects.add(TimeWarp(object))로 이펙트를 추가하고, 메인 루프에서 effects.run() 호출하면 끝

보너스: 사이드 이펙트 제거 → 병렬화

  • 한 발 더 나가면, co_yield로 렌더링 객체를 반환하게 만들어서 사이드 이펙트를 없앨 수 있음
  • 사이드 이펙트가 없으니 루프를 병렬로 돌릴 수도 있음. 게임 이펙트 시스템이 100줄 미만의 코드로 완성되는 거

ℹ️참고

> C++26에서 execution이 표준화되면 co_await를 제대로 쓸 수 있겠지만, 대부분의 프로젝트는 이미 자체 스케줄러와 스레드 풀이 있어서 통합이 쉽지 않을 전망. 당장 코루틴의 가치를 체감하고 싶다면 이 "Unity 핵"이 가장 현실적인 진입점임.

코루틴의 가치를 이론이 아니라 실무 관점에서 설명하는 좋은 글. co_await의 복잡함을 피하면서 co_yield로 바로 생산성을 얻는 접근이 현실적.

댓글

댓글

댓글을 불러오는 중...

backend

잘못된 추상화보다 중복이 낫다는 샌디 메츠의 고전 조언

샌디 메츠는 중복을 없애려다 잘못된 추상화를 만들면 코드가 조건문과 파라미터로 부풀어 더 위험해진다고 말한다. 이미 틀어진 추상화는 억지로 보존하지 말고, 다시 호출부에 인라인해서 중복을 되살린 뒤 현재 요구사항에 맞는 새 구조를 찾는 편이 빠르다는 주장이다.

backend

리눅스 커널, 6년·360개 넘는 패치 끝에 strncpy 제거

리눅스 커널이 오랫동안 버그의 원인이던 strncpy API 사용을 Linux 7.2에서 제거했어. NUL 종료 동작이 직관적이지 않고 불필요한 zero-fill로 성능 문제도 있던 API를 6년 동안 약 362개 커밋으로 걷어낸 작업임.

backend

덕디비는 왜 빠를까: 서버 없는 분석 엔진의 내부 구조 뜯어보기

DuckDB가 단일 바이너리, 인프로세스 실행, 컬럼형 저장, 최적화 패스, Parquet 푸시다운으로 빠른 분석 쿼리를 처리하는 방식을 깊게 설명한 글이다. 6GB Parquet 파일을 노트북에서 바로 SQL로 읽는 경험 뒤에 어떤 설계가 깔려 있는지 따라간다.

backend

피지독, 포스트그레스를 수평 확장시키겠다고 550만 달러 투자 유치

피지독은 포스트그레스 앞단에 프록시를 두고 샤딩과 라우팅을 처리해 수평 확장을 가능하게 하겠다는 오픈소스 프로젝트다. 이미 프로덕션에서 초당 200만 건이 넘는 쿼리를 처리하고, 확인된 규모만 20테라바이트 이상을 샤딩했다고 밝히며 550만 달러 투자를 공개했다.

backend

펜타시스템, EDB 포스트그레SQL로 국내 엔터프라이즈 DB 전환 시장 공략

펜타시스템테크놀러지가 EDB와 파트너 계약을 맺고 국내에 EDB 포스트그레SQL 기반 데이터 플랫폼을 공급한다. 기존 상용 DBMS 정책 변화로 비용 부담이 커진 기업들을 겨냥해, 오픈소스 기반 엔터프라이즈 데이터 플랫폼 전환 수요를 잡겠다는 전략이다. 금융, 공공, 제조, 유통, 클라우드, AI 데이터 분석 환경까지 적용 범위를 넓히려는 움직임이다.