실수로 사용한 Blender VSE

• Aras는 Blender에 Video Sequence Editor(VSE) 가 있다는 사실도 몰랐지만, Blender HQ 방문 뒤 약 두 달간 파트타임으로 Blender 4.1용 성능·품질 개선을 기여함
• 가장 눈에 띄는 변화는 타임라인 반응성으로, 약 3000개 strip이 보이는 Sprite Fright 프로젝트에서 스크롤·패닝 UI가 약 15fps에서 60fps 이상으로 개선됨
• ffmpeg 기반 RGB↔YUV 변환, Audaspace 오디오 리샘플링, 이미지 변환·필터링, VSE 효과 처리에 멀티스레딩·SIMD·수학 단순화가 적용됨
• 세 개의 Blender Studio 데이터셋에서 작성자 PC 기준 VSE 영화 최종 렌더 시간이 약 2배 빨라졌고, Sprite Fright 렌더링은 거의 13분에서 7분으로 줄어듦
• 총 37개 pull request가 리뷰·병합됐으며, Blender 4.1에는 현재 변경이 들어가고 이후 VSE 작업은 Blender 4.2부터 이어질 예정임

---

Blender VSE에 기여하게 된 경위

• Aras는 Unity의 Unite 2023 참석차 Amsterdam에 갔다가 남는 시간에 Blender HQ를 방문함
• 그곳에서 Francesco와 Sergey가 VSE 기여 의사를 물었고, 이후 Blender의 Video Sequence Editor를 건드리기 시작함
• 영상 편집, 타임라인, 시퀀서, 컬러 그레이딩, ffmpeg, 오디오 믹싱을 잘 모르는 상태였지만, 논쟁 여지가 적은 성능 최적화부터 진행함
• 약 두 달의 파트타임 작업 끝에 Blender 4.1에 들어갈 개선 묶음이 생김
  • Blender 4.1은 베타가 되었고, 일반 daily builds에서 받을 수 있음

타임라인 그리기와 UI 반응성

• VSE 타임라인은 화면 하단 영역이며, Sprite Fright edit 전체 프로젝트를 줌아웃하면 약 3000개 strip이 한 번에 보임
• 기존에는 이 타임라인에서 스크롤·패닝만 해도 UI 갱신이 약 15fps 수준에 머물렀음
• 변경 뒤에는 60fps 이상으로 동작함
  • 관련 PR: #115311
• 병목은 그래픽 API draw call을 삼각형 두 개 단위로 제출하는 구조였고, Superluminal 프로파일러에서 대부분 시간이 “quad 하나 그리기 시작”과 “quad 하나 그리기 종료” 함수 안에서 쓰였음
• 이 과정에서 오디오 waveform 표시의 이상 동작도 고치고 UI를 다듬었으며, waveform 표시는 기본값으로 켜짐
  • 관련 이슈: #115274

스코프 표시 품질과 속도 개선

• VSE는 이미지 히스토그램, waveform, vectorscope 같은 일반적인 스코프(scope) 표시 옵션을 제공함
• 히스토그램은 픽셀화된 이미지와 매우 강한 채도로 그려졌지만, 이제 더 부드러운 polygon, grid, 낮은 채도로 표시됨
  • 관련 PR: #116798
• Waveform의 parade 옵션은 너무 빨리 포화되는 문제가 있었고, 멀티스레딩 적용 후 15배 빨라짐
  • 관련 PR: #115579
• Vectorscope의 외곽 색상 육각형은 픽셀화가 심했으며, 이미지 에디터 vectorscope의 갱신된 design을 복사해 적용함
  • 관련 PR: #117738
• “과노출 영역 표시”에 해당하는 zebra stripes 옵션도 2~3배 빨라짐
  • 관련 PR: #115622
• 모든 스코프와 이미지 에디터 스코프는 언젠가 GPU compute shader로 처리되어야 한다는 생각도 덧붙임

ffmpeg RGB↔YUV 변환 최적화

• Blender는 오디오·비디오 읽기와 쓰기에 주로 ffmpeg 라이브러리를 사용함
• Blender 내부에서는 ffmpeg 명령줄 도구가 아니라 libavcodec 같은 코드 라이브러리를 쓰며, libswscale은 영화 프레임의 RGB↔YUV 변환을 담당함
• libswscale은 멀티스레드 변환을 지원하지만, 단순히 sws_getContext()와 sws_scale()을 쓰면 완전히 단일 스레드로 동작함
• 멀티스레딩을 쓰려면 초기화 시점에 "threads" 파라미터를 설정해야 하므로 sws_alloc_context(), av_opt_set_int(), sws_init_context()를 직접 사용해야 함
• 또한 sws_scale()은 내부적으로 멀티스레딩을 하지 않기 때문에 sws_scale_frame()을 써야 했고, 이 과정에서 AVFrame 생성 방식의 문제도 드러남
• 결과적으로 영화 파일 쓰기 시 RGB→YUV 변환이 상당히 빨라짐
  • 관련 PR: #116008
• 영화 파일 읽기에서도 멀티스레드 YUV→RGB 변환을 사용하고, vertical flip을 같은 작업에 합침
  • 관련 PR: #116309

오디오 리샘플링

• VSE에서 영상을 렌더링할 때 “비디오 또는 오디오 프레임을 생성”하는 시간의 거의 절반이 Blender가 사용하는 오디오 라이브러리 Audaspace 안에서 쓰이는 상황이 확인됨
• 병목은 오디오 인코딩이 아니라 인코딩 전 믹싱이었고, 대부분은 48kHz 영화 안에 44.1kHz 같은 오디오 strip이 섞일 때 발생하는 리샘플링에 쓰임
• Audaspace에는 두 가지 리샘플링 모드가 있었음
  • Blender 내부 재생: 샘플 사이를 선형 보간하는 Linear resampler
  • 영화 렌더링: Julius O Smith’s algorithm 기반 리샘플러
• 리샘플러 품질은 단일 주파수가 증가하는 합성음을 리샘플링한 뒤 spectrogram을 보는 방식으로 비교함
  • 목표는 Audacity의 “best” 설정처럼 추가 주파수가 최대한 적은 결과임
• Audaspace의 preview 리샘플링은 계산은 빠르지만 많은 추가 주파수를 만들었고, rendering 리샘플링은 spectrogram 품질이 좋았음
• 새 medium 리샘플링 품질을 Audaspace에 추가했고, 작성자가 보기에는 거의 같은 결과를 내면서 계산은 약 3배 빨라짐
• Blender는 렌더링 시 이 medium 설정을 사용하게 됨
  • Windows Ryzen 5950X PC에서 Sprite Fright 2000프레임 렌더링이 92초에서 73초로 줄어듦
  • 관련 PR: #116059

이미지 변환과 필터링

• VSE에서 이미지, 영화, 텍스트, scene 등 시각 결과를 만드는 strip은 위치, 회전, 스케일, crop을 적용할 수 있음
• 이런 변환은 strip이 만든 이미지를 새 이미지로 변환하는 방식이며, 기존에도 CPU에서 멀티스레드로 처리됐음
• GPU가 아니라 CPU에서 처리되는 이유는 아직 GPU 구현이 없고, GPU가 없는 render farm에서 렌더링하려는 사용 사례를 위해 CPU fallback이 현재는 필요하기 때문임

• Half-pixel 오차 수정

  • 기존 코드에는 여러 off by half a pixel 오류가 있었고, 많은 경우 상쇄되거나 보이지 않았지만 특정 상황에서는 드러남
  • 작은 이미지를 16배로 확대할 때 Bilinear 필터가 이미지를 원본 픽셀의 절반만큼 밀었고, 배경색인 magenta가 끼어드는 현상도 있었음
  • 반대로 이미지를 정확히 2배 축소할 때 Bilinear 필터가 필터링을 전혀 하지 않는 문제도 발생함
  • Bilinear와 다른 필터의 “off by something” 오류가 수정됨
  • 관련 PR: #116628

• Bilinear 투명 테두리 처리

  • Blender 4.0 이전 VSE에는 Nearest, Bilinear, Subsampled3x3 세 가지 필터 옵션이 있었고, 이 중 Bilinear만 결과 이미지 주변에 원본 texel 절반 너비의 투명도를 추가했음
  • 이 동작은 미디어를 확대할 때 눈에 띄었고, 왜 이런 차이가 생겼는지는 기억하는 사람이 없었음
  • VSE의 Bilinear 필터 코드에서 “투명도로 블렌딩”하는 동작을 제거함
  • 다만 회전만 적용할 때는 기존 투명도 처리 덕분에 edge에 일종의 안티앨리어싱이 생겼기 때문에, 대신 destination 이미지의 edge pixel에 transparency anti-aliasing을 적용함
  • 관련 PR: #117717

• Cubic, Box, Auto 필터

  • 일반 VSE strip transform에는 cubic 필터 옵션이 없었고, 특수 Transform Effect strip에만 존재했음
  • Blender에서 “Bicubic”은 실제로 Cubic B-Spline 필터를 뜻하며, Mitchell-Netravali filter의 B=1, C=0 계수와 같음
  • 작성자는 이를 “ringing은 없지만 blur가 많은” 선택으로 정리함
  • VSE에는 두 종류의 cubic filtering 옵션이 들어감
  • 관련 PR: #117100, #117517
  • Blender 3.5의 “Subsampled 3x3” 필터는 실제로 3x3 크기로 하드코딩된 box filter였고, 3x3이 아닌 비율로 축소하면 무너지기 시작했음
  • 이 필터는 고정 3x3이 아닌 조정된 Box filter로 바뀜
  • 관련 PR: #117584
  • 사용자가 선택해야 할 필터가 많아져서 VSE strip의 기본값으로 Auto filter option이 추가됨
  • 관련 PR: #117853
  • 스케일·회전이 없으면 Nearest
  • 2배 초과 확대면 Cubic Mitchell
  • 2배 초과 축소면 Box
  • 그 외에는 Bilinear

• 필터링 성능 개선

  • 이미지 필터링 과정도 더 빨라짐
  • 내부 루프에서 virtual function 제거, Bilinear 필터링에 SIMD 일부 적용: #115653
  • Cubic 필터링 단순화와 SIMD 추가: #117100
  • Box 필터의 수학 단순화: #117125
  • 화면 전체를 덮는 solid image 아래 항목을 건너뛰는 최적화가 scale이 있을 때 동작하지 않던 문제 수정: #117786
  • 작성자 PC에서 3840x2160 프로젝트에 1920x1080 이미지 하나를 2배 확대하고 Bilinear 필터링을 쓸 때, sequencer preview 전체 그리기가 36.8ms에서 15.9ms로 줄어듦
  • 업샘플 필터 비교용 인터랙티브 페이지도 제공함: aras-p.info/img/misc/upsample_filter_comp_2024

VSE 효과 최적화

• Blender Studio의 실제 영화 데이터셋은 effect를 많이 쓰지 않았지만, 코드에서 보이는 부분을 중심으로 VSE effect도 최적화함
• 대부분의 변화는 멀티스레딩 적용임
  • Glow effect: 멀티스레드 적용, 6~10배 빨라짐 #115818
  • Wipe effect: 멀티스레드 적용, Clock wipe의 과도한 삼각함수 계산 단순화, 6~20배 빨라짐 #115837
  • Gamma Cross effect: 제곱근 호출 하나를 피하려고 복잡한 table과 interpolation을 쓰던 방식을 바꿔 4배 빨라짐 #115801
  • Gaussian Blur effect: 중복 계산을 피해서 1.5배 빨라짐 #116089

최종 렌더 시간 변화

• Blender Studio에서 받은 세 개의 데이터셋 기준, 작성자 PC에서 VSE 영화 최종 렌더 시간이 약 2배 빨라짐
• Sprite Fright edit 렌더링은 거의 13분에서 7분으로 줄어듦
• 작성자는 추가 속도 향상을 바라고 있으며, “2배 속도 향상을 세 번 더 하면 꽤 좋다”는 식으로 표현함

작업 방식과 다음 단계

• 사용자에게 보이는 변경 외에도 테스트 추가, 리팩터링, 정리 작업을 위한 pull request가 있었고, 총 37개 pull request가 완료·리뷰·병합됨
• 작성자는 이 정도 작업을 “실제 직장”에서는 하기 어려웠을 것 같다고 평가함
  • Unity에서 2015~2022년 사이였다면 같은 시간에 위 작업의 약 30% 정도, 어쩌면 그보다 적게 했을 것 같다고 함
  • 2010년 무렵의 “ancient” Unity에서는 가능했을 수도 있다고 덧붙임
• 회사 규모, 프로세스, 기대치, 커뮤니케이션, 정치 같은 요인이 얽히면 비용을 받는 회사 환경에서 오히려 같은 작업이 느려지거나 중간에 취소될 수 있다고 봄
• Blender가 프로세스가 사람들을 돕기보다 의욕을 꺾고 느리게 만드는 규모·복잡도·워크플로로 가지 않기를 바람
• Blender 4.1은 베타가 되었기 때문에 기능 면에서는 완료 상태이며, VSE 관련 4.1 변경은 현재 release notes 상태로 들어감
• Blender 4.2 작업이 시작되며, 이후에도 명확한 계획 없이 VSE를 계속 만질 생각임
  • 진행 상황은 Weekly Updates 포럼 섹션에서 볼 수 있음

[GN⁺]

Hacker News 의견들

• “실제 직장”이었다면 이런 일을 못 했을 것 같음
  커리어에서 잘 안 풀린 점이 있다면, 전혀 독특한 수학을 직접 풀어내는 무급 프로젝트에서는 두 달 만에 평소 2년치보다 더 해내지만, 돈 받고 하는 프로젝트에서는 결과가 대체로 평균적이라는 식으로 갈라졌다는 점임
  정말 열심히 시도했는데도 그 중간을 찾지 못했고, 작년에 무료로 하던 일에 돈을 받을 가능성이 생기자 결국 아예 손을 못 대게 됐음

  • 혼자가 아님. 평생 비슷한 일을 겪었고, 그래서 동기부여에 대해 사람들이 하는 말, 예를 들어 이윤과 임금만이 일을 끝내게 한다는 생각을 전부 의심하게 됐음
    그러다 Marx의 소외 이론을 접하고 훨씬 말이 되기 시작했음. 그는 일이 건강한 사람들이 주로 하는 활동이라는 관찰에서 출발했지만, 그것을 남을 위해 일하고 자기 노동의 산물로부터 소외되는 것과 혼동하면 안 된다고 봤음
    https://en.m.wikipedia.org/wiki/Marx's_theory_of_alienation
  • 지금까지 했던 가장 훌륭하거나 흥미로운 일 중 돈 받고 한 일은 없었음
  • 프로젝트 관리가 그런 종류의 일을 전부 죽여버림
    어떤 곳은 1~2주 동안 뭐든 할 수 있는 완충 구간을 두는 좋은 시스템이 있고, 그게 이런 문제를 완화해 줌
  • 가장 보람 있고 영향력 있었던 일은 전부 거의 돈을 못 받거나 아예 못 받은 일이었음. 이제는 피하기 어려운 일처럼 느껴지고, 소프트웨어 일을 조금 우울하게 만듦
  • 꽤 흥미로운 현상이고, 대부분 팀 규모와 돈을 벌어야 한다는 필요에서 온다고 봄
    열정 프로젝트에서는 돈을 받지 않으니 기대치가 낮고, 뭔가를 해야 할 의무도 없으며, 사실상 원하는 일을 자유롭게 할 수 있음. 그래서 관심 있는 새 기술이나 도구를 탐색하는 식으로 자기에게 흥미롭고 영향 있는 일을 고르게 됨
    돈이 개입되는 순간 돈을 내는 사람의 기대가 들어오고, 새롭고 낯선 시도는 실패할 가능성이 크기 때문에 더 어려워짐
    결국 돈이 걸리면 사람들은 더 나은 해법이 잠재적으로 있어도 위험이 크면 피하고, 예측 가능한 결과를 선호한다고 봄

• 정말 인상적이고, 원글 작성자가 그냥 길에서 Blender HQ로 걸어 들어간 게 아니라는 점도 분명함. Unity에서 쌓은 오랜 경험이 해당 영역을 이해하는 데 꽤 도움이 됐을 것 같음
  이 변경 [1]이 특히 좋았음. 이미지 처리 단계를 최적화하면서 테이블 기반 “최적화”를 아주 많이 제거하고 그냥 부동소수점 계산으로 바꿨는데, 원글 작성자의 머신에서 약 4배 빨라졌음. 훌륭함
  [1]: https://projects.blender.org/blender/blender/pulls/115801/fi...

  • 그뿐 아니라, 차이를 보면 코드 100~150줄을 3줄로 바꿨음. 이런 풀 리퀘스트는 꿈에서나 만들어볼 수 있을 듯함
  • 좋은 최적화이긴 한데, return c * c;가 정말 sRGB 감마의 좋은 근사인지 궁금함

• Aras가 여러 오픈소스 그래픽 프로젝트에 불쑥 들어가 엄청난 속도 향상과 개선을 만들고, 또 다른 임의의 그래픽 프로젝트로 넘어가 같은 일을 반복하는 흐름이 지난 몇 년간 가장 마음에 듦

  • Gaussian Splats도 가지고 놀면서 놀라운 결과를 냈음
    https://github.com/aras-p/UnityGaussianSplatting

• 내가 쓰는 음악 플레이어 MusicBee에도 이런 일을 해보고 싶음
  오픈소스였다면 말이지. 제작자는 이제 거의 손대지 않고, 완전히 무료였고 항상 그래 왔는데 왜 오픈소스가 아닌지 이해가 안 됨
  사소하게 거슬리는 문제, 깨졌거나 느리거나 이상한 자잘한 부분이 너무 많아서 여가 시간에 꼭 고쳐보고 싶음
  그리고 지금 와서 FooBar 같은 다른 걸로 옮기는 건 일이 너무 많음. HQPlayer도 써봤지만 UI/UX가 너무 끔찍해서 넘어갈 수 없었음

  • 2013년에 Steven이 이미 여러 번 말했듯, 가까운 시일 내에 MusicBee를 오픈소스화할 계획은 없다고 했음
    프로젝트를 계속하고 싶지 않아질 때 소스 코드를 공개하는 건 고려할 선택지 중 하나지만, 이건 프로그래밍이 즐거워서 하는 취미 프로젝트이고 절대 전문적인 방식으로 운영할 일이 아니라고 했음
    본업에서 사람 관리에 충분한 시간을 쓰고 있으니 여기서까지 그러고 싶지 않으며, “버스에 치이면 어떡하나” 같은 우려가 있는 사람은 다른 앱을 쓰는 게 맞다고도 했음
    https://web.archive.org/web/20170721042120/https://getmusicb...
  • 소프트웨어 프로젝트를 오픈소스로 만들면 그 순간 사람 관리 프로젝트가 되기 때문임
  • 오픈소스 프로젝트로 코드를 작성하려면 사람들이 생각하는 것보다 훨씬 높은 완성도가 요구됨. 그냥 프로그램이 잘 돌아가게 만드는 것보다 훨씬 일이 많음
  • 대안은 있음. 전체를 오픈소스로 다시 작성하면 됨
  • Windows를 그만 쓰고 나서도 계속 그리웠던 유일한 소프트웨어가 MusicBee였음
    유지보수되고 있었다면 Wine으로 돌리는 걸 고려했겠지만, 지금은 음악 관리자라는 개념 자체를 포기하고 그냥 mpv로 듣는 앨범을 재생함. 그리고 항상 앨범 단위로 들음. 재생목록은 사양함

• 2020년부터 모든 영상 편집에 Blender VSE를 써왔고, 개선되는 모습을 보니 정말 좋음
  안정성과 기능 구성을 생각하면 이미 Linux에서 최고의 영상 편집기라고 봤음. Blender의 기존 애니메이션 도구를 전부 쓸 수 있다는 것도 장점임

• VSE는 정말 많은 사랑이 필요함. 팟캐스트에 모든 도구를 오픈소스로 쓰고 싶었는데, Blender에서 크로마키가 들어간 mp4 시퀀스를 렌더링하니 1.5시간 영상에 10시간이 걸렸음
  결국 DaVinci Resolve 무료판으로 옮겼음

  • Blender VSE는 현재 영상 렌더링에 GPU 가속이 없어서 CPU가 전체 작업을 처리함
    또 재인코딩이 필요 없을 때도 DaVinci Resolve처럼 건너뛰지 못하고 전체 프레임을 하나씩 렌더링함. 이 부분이 개선되면 Blender의 성능과 효율에 큰 도움이 될 것임
  • Blender의 다중 스레드 렌더링은 VSE 작업에 잘 맞게 확장되지 않는다는 문제가 있음. 각 프레임을 쪼개는 데 초점이 있어 여러 코어를 잘 활용하지 못함
    예전에 타임라인의 서로 다른 지점에서 여러 렌더 작업을 별도 프로세스로 시작하는 플러그인 [1]을 실험해 봤고, 렌더링을 크게 빠르게 만들 수 있었음
    지금은 Linux에서도 Resolve로 옮겼는데, Blackmagic 카메라를 쓰고 있어서 그쪽이 더 잘 맞기 때문임
    [1] https://github.com/AkBKukU/blenderSubprocessRender
  • 한 프로젝트에서 VSE를 썼음. 고통스럽긴 했지만 결과물은 만들었고, 당시에는 확실히 최고의 무료 소프트웨어 영상 편집기였음
    지금은 새 버전을 Final Cut Pro로 작업 중임

• Blender 3D 프로그램의 어떤 부분이든 더 빠르게 만드는 건 꽤 어려울 것 같음. 이미 단연 가장 빨리 시작되는 3D 애플리케이션이고, GUI 반응도 가장 빠름
  Houdini가 2등이긴 한데, 가까운 2등은 아님

  • 의외로 아직 낮게 달린 과일이 많이 있음
    몇 년 전 ‘blobby’ 생성기 코드를 건드리다가 다중 스레딩을 추가해 훨씬 느리게 만든 적이 있음. 다중 스레딩의 오버헤드를 넘어서면 더 빨라지긴 했지만, 기억상 일반적인 사용 사례 안에는 잘 들어오지 않아서 포기했음. 분명 실수도 좀 했을 것임
  • 코드 일부를 봤는데 아직 개선 여지가 많다고 생각함. 글에서 나온 것처럼 최적화라는 명목으로 접근이 아주 복잡하지만 실제로는 느리게 만들 가능성도 비슷한 코드가 놀랄 만큼 많음
    예를 들어 텍스처 페인팅은 픽셀마다 포인터 간접 참조를 3번쯤 하는 식이고, 내 PC에서도 꽤 버벅임
  • 애니메이션 도구에는 개선 여지가 엄청 많고, 실제로 작업 중인 듯함. Vulkan 전환도 큰 도움이 될 것처럼 보임

• “Blender에 영상 편집 도구 모음이 있다는 걸 알고 있었나요? 저도 몰랐습니다 :)”라고 했지만, Blender로 애니메이션을 만드는 사람 대부분은 알고 있을 것 같음
  렌더링한 프레임을 영상 파일로 만드는 기본적인 방법이기 때문임

  • 프레임을 바로 영상 파일로 렌더링할 수 있고(ffmpeg 옵션), 초보자나 가벼운 사용자는 많이 그렇게 할 것 같음
    합성기를 써서 미리 렌더링한 프레임 시퀀스를 영상 파일로 만들 수도 있음
    다만 대부분은 Resolve 같은 다른 프로그램에서 영상 편집을 선호할 것 같고, VSE는 “기본적인 자르기는 필요하지만 변형, 제목, 효과는 필요 없는” 좁은 영역에 있어서 많이 쓰이지 않는 느낌임
    누군가 변형과 효과 개선을 계속하고 언젠가 3점 편집도 추가해 주면 좋겠음

• 아, Aras였구나. 그는 대단함. 정말 대단한 Aras가 풀네임이었던 걸로 기억함
  그래픽스 코딩 등에서 뛰어나고, 코딩할 때 좋은 몰입 흐름도 있는 것 같음
  글이 읽기 좋고 재미있음. 사람이 말하는 걸 듣는 느낌임. 중간의 “However!” 같은 문장도 그렇고
  마지막에 일반적인 회사에서 표준적인 문화와 프로세스 기대에 짓눌리면 생산성이 30%가 된다는 부분도 공감됨. 직원을 “자기 일”에 묶어두는 비용에는 실제로 엄청난 생산성 감소가 포함됨
  이런 사례를 계속 보면서 기술자들이 사람과 활동을 더 잘 조직하는 방법을 배우고, 그 배움을 믿어서 고생산성/높은 몰입을 실제 조직 방식에 통합하기 시작했으면 함
  글이 암시하듯, 그렇게 하면 기술 업계에서 일하는 게 더 즐거워질 수 있음. 기술을 가지고 노는 것만큼 거의 재미있어질 수도 있음

• https://projects.blender.org/blender/blender/pulls/116089에 대해 덧붙이면, inline은 무엇보다 먼저 단일 정의 규칙에 영향을 줌
  간단히 말해 헤더에 함수를 정의해 두고 여러 .cc 파일에서 호출하면, inline으로 표시하지 않는 한 링커 오류가 남
  실제 인라인 최적화에 미치는 효과는 “없음”부터 “컴파일러가 연결 방식 때문에 다르게 가중치를 둘 수도 있음”, “실제로 힌트로 받아들임”까지 다양하고, 링크 타임 최적화에서도 비슷한 고려가 있음
  컴파일러에 훨씬 강한 인라인 신호를 주려면, 특히 정의된 파일 안에서만 쓰는 함수라면 익명 네임스페이스 안에 정의하는 편이 좋음
  원래 그 함수에 inline을 붙인 의도는 실제 인라인화를 얻으려는 시도였을 수 있음. 측정 가능한 이득은 분명하지 않지만, 불가능한 것도 아님