안녕하세요! 그로스로그 입니다!😊 🌱
시스템 연결선이 폭발하는 지점, 파이썬 코드를 실행 직전에 가로채는 컴파일러, 확률을 정의하는 네 가지 방식입니다.
5기 4회차 두 번째 묶음입니다. 대기업 연동 실무 · 프레임워크 내부 · 학부 기초. 층이 완전히 다른 세 편인데, 하나가 관통합니다.
01
🔌 EAI(Enterprise Application Integration), 왜 필요한가
이동규 님
프로젝트에서 인터페이스(IF)를 담당하며 알게 된 EAI 개념을 정리한 글입니다.
대기업이 왜 시스템을 직접 연결하지 않고 앞단에 EAI를 두는지, 그리고 통합 패턴 세 가지의 장단점을 각각 짚습니다.
결론이 도구가 아니라 문서 쪽으로 갑니다 — "도구는 문제를 해결해주지 않는다."
실무에서 맡은 역할을 개념으로 정리한 기록입니다.
조금 더 들어가 보면
문제 상황부터 명확합니다.
그래서 EAI가 나왔고, 본질을 이렇게 잡습니다.
연결이 아니라 흐름이라는 구분입니다. 선을 잇는 게 아니라 데이터가 어떤 순서로 어떤 모양으로 흐를지를 정하는 일이죠.
💥 연결선이 폭발하는 지점
통합 패턴 셋을 장단점과 함께 나열한 대목이 이 글의 뼈대입니다.
| 패턴 | 구조 | 대가 |
|---|---|---|
| Point-to-Point | 시스템끼리 1:1 직접 연결 | 시스템이 N개면 연결선이 N(N-1)/2개로 폭발 |
| Hub-and-Spoke | 중앙 허브를 두고 모두 허브와 통신 | 관리는 쉬워지지만 허브가 SPOF가 됨 |
| ESB | 메시지 버스 위에서 느슨하게 결합 | 라우팅·변환·오케스트레이션을 버스가 담당 |
N(N-1)/2라는 숫자가 이 글에서 제일 강한 대목입니다. 시스템 5개면 10개, 10개면 45개예요. 하나 추가할 때마다 기존 전부와 이어야 하니까요. 왜 중간에 무언가를 두는지가 이 공식 하나로 설명됩니다.
그리고 허브를 뒀을 때의 대가도 같이 적습니다 — SPOF(Single Point of Failure). 연결선은 줄었는데 그 하나가 죽으면 전부 멈춥니다. 문제를 옮긴 것이지 없앤 게 아니라는 것.
📝 원문에서는 이렇게 못 박습니다
도구 이야기로 넘어가는 대목이 이 글의 결론입니다. webMethods, MuleSoft, IBM Integration Bus 같은 전통적 솔루션과 Boomi 같은 클라우드 기반 iPaaS를 소개하고 나서 이렇게 씁니다.
시점 · 데이터 · 키 · 형식. 이 넷을 사람이 먼저 정해야 한다는 것이고, 그게 정리되지 않으면 어떤 솔루션도 소용없다는 겁니다.
실제 구조도 한 줄로 보여줍니다 — 영업이 한 시스템에서 수주를 등록하면 주문 정보가 중계 솔루션을 거쳐 기간계로 전달되어 생산·물류 프로세스가 시작되는 흐름이요. 개념 설명 뒤에 실물이 하나 붙으니 앞의 패턴 이야기가 구체적으로 읽힙니다.
큐레이터 노트
도구를 소개하고 나서 도구로 안 된다고 적은 글이라 뽑았습니다.
솔루션 이름을 여섯 개나 나열해놓고 결론이 "도구는 문제를 해결해주지 않는다"입니다. 대신 인터페이스 정의서를 꼽아요. 화려하지 않은 답인데, 연동 프로젝트를 해본 사람이면 아는 답이기도 합니다.
대가를 같이 적은 것도 좋았습니다. Hub-and-Spoke가 연결선을 줄이는 대신 SPOF를 만든다는 것 — 패턴을 소개하면서 그 패턴이 새로 만드는 문제까지 적으면 고를 수 있는 정보가 됩니다.
5기 큐레이션에서 기업 시스템 연동을 다룬 유일한 글입니다. 웹·앱·AI가 많은 기수라 이 각도가 더 반가웠어요. 대기업 SI나 기간계 연동 쪽으로 진로를 보는 회원에게는 특히 참고가 될 기록입니다.
02
🔥 TorchDynamo
김류흔 님
PyTorch 2의 컴파일러 프론트엔드인 TorchDynamo를 논문과 공식 문서를 따라가며 정리한 글입니다.
핵심은 이겁니다 — CPython의 프레임 평가 API에 후킹해서, 실행 직전에 파이썬 바이트코드를 동적으로 수정한다는 것.
이어서 AOT autograd(역전파를 미리 준비하기)와 Recomputation(활성화 체크포인팅)까지 다룹니다.
원문·논문 링크를 붙여가며 쓴, 5기에서 가장 깊은 층을 다룬 글 중 하나입니다.
조금 더 들어가 보면
TorchDynamo가 하는 일이 세 줄로 정리돼 있습니다.
"hooks into the Python frame evaluation API in CPython to dynamically modify Python bytecode right before it is executed"
"extract sequences of PyTorch operations into an
FX graph (by rewrites Python bytecode)"실행 직전에 바이트코드를 고친다는 게 핵심입니다. 사용자가 쓴 파이썬 코드는 그대로 두고, 그게 실행되기 바로 전 단계에서 가로채 PyTorch 연산들을 그래프(FX graph)로 뽑아냅니다.
왜 그래프가 필요하냐면 — 연산을 하나씩 따로 실행하면 최적화할 여지가 없기 때문입니다. 전체 흐름이 그래프로 보여야 "이 둘은 합칠 수 있다", "이건 순서를 바꿔도 된다" 같은 판단이 가능해지죠.
⏪ AOT autograd — 역전파를 미리 준비하기
두 번째 개념도 이름에 답이 있습니다.
"analyzing the forward pass of your model and generating an optimized backward pass ahead of time."
보통 역전파는 순전파가 끝난 뒤에 계산 기록을 따라 거슬러 올라갑니다. AOT autograd는 순전파를 분석해서 역전파를 미리 만들어둡니다. 미리 만들면 그것도 최적화 대상이 되고요.
그 바탕이 되는 autograd도 함께 설명합니다 — 실행된 연산들의 기록을 Function 객체로 구성된 방향성 비순환 그래프(DAG)에 저장한다는 것.
📝 원문에서는 이렇게 확인합니다
Recomputation(Activation Checkpointing) 을 설명할 때 예시 하나를 놓습니다.
case) cos(cos(a+b+c+d))
중첩된 연산입니다. 역전파를 하려면 중간 결과들을 메모리에 들고 있어야 하는데, 깊어질수록 그게 부담이 됩니다. Recomputation은 저장하는 대신 필요할 때 다시 계산하는 방법이에요. 메모리와 연산량을 맞바꾸는 것이죠.
글이 논문 PDF, PEP 523, PyTorch 공식 튜토리얼 링크를 문장마다 달아둔 것도 눈에 띕니다. 어디서 온 내용인지 추적 가능하게 만든 형태입니다.
큐레이터 노트
프레임워크 안쪽을 들여다본 글이라 뽑았습니다.
PyTorch를 쓰는 기록은 많습니다. 모델을 만들고 학습시키는 이야기요. 이 글은 그 아래층을 봅니다 — torch.compile이 실제로 무엇을 하는가, 왜 바이트코드를 건드리는가.
한 층 아래로 내려가는 것이 이 글의 성격입니다. 쓰는 법을 아는 것과 왜 그렇게 동작하는지를 아는 것은 다르고, 후자를 알면 성능이 안 나올 때 어디를 볼지가 보입니다.
자료가 드문 영역이기도 합니다. TorchDynamo·AOT autograd를 한국어로 정리한 자료는 많지 않고, 대부분 영어 문서와 논문입니다. 그걸 따라가며 정리했다는 것 자체가 기여예요.
원문이 길지 않고 개조식이라 읽기에 친절한 글은 아닙니다. 그런데 자기가 읽으려고 만든 노트의 성격이 강해서 오히려 정직해요. 링크를 다 달아둔 것도 나중에 다시 찾아올 자신을 위한 장치로 보입니다.
03
🎲 확률의 개념
강규진 님
확률의 기본 개념을 정의 중심으로 정리한 글입니다. 방송통신대 통계 과목을 따라가며 남긴 기록이에요.
확률을 정의하는 방식이 하나가 아니라는 걸 보여줍니다 — 빈도론적 · 주관적 · 고전적 · 공리적 네 가지요.
표본공간과 사건, 덧셈 정리, 여사건, 조건부 확률, 그리고 베이즈 정리까지 이어집니다.
짧고 건조한 정리인데, 나열된 순서에 뼈대가 있습니다.
조금 더 들어가 보면
시작이 확률의 정의입니다.
그런데 바로 이어서 정의하는 방식이 여러 가지라는 걸 보여줍니다.
· 빈도론적 확률 — 반복적으로 측정되어 나타나는 사건의 비율
· 주관적 확률 — 경험을 통해 체감하는 믿음의 정도
· 고전적 확률 — 사건의 원소 수 / 표본공간의 원소 수
· 공리적 확률 — 0과 1 사이에 있는 측도 P
같은 것을 네 가지 방식으로 정의합니다. 동전을 던져 앞면이 나올 확률이 1/2이라고 할 때, 그게 "수없이 던지면 절반"이라는 뜻인지(빈도론적), "경우의 수가 둘이니까"라는 뜻인지(고전적), "내가 그렇게 믿는다"는 뜻인지(주관적) 다릅니다.
정의를 무엇으로 잡느냐에 따라 다른 체계가 따라옵니다. 통계학에 빈도주의와 베이즈주의라는 두 갈래가 있는 것도 여기서 시작하죠.
📝 원문에서는 이렇게 쌓아 올립니다
그다음부터는 도구가 순서대로 붙습니다.
표본공간 통계적 실험의 모든 가능한 결과의 집합
사건 표본공간의 부분집합
덧셈 정리 P(A∪B) = P(A) + P(B) − P(A∩B)
여사건 P(Aᶜ) = 1 − P(A)
조건부 확률 어떤 사건이 발생했다는 조건하에 다른 사건이 발생하는 확률
베이즈 정리 표본공간을 분할한 후 주어진 조건부 확률로부터
사건 발생확률과 새로운 조건부 확률을 구하는 정리
순서가 곧 구조입니다. 표본공간과 사건이 있어야 확률을 정의할 수 있고, 덧셈 정리가 있어야 여러 사건을 다룰 수 있고, 조건부 확률이 있어야 베이즈 정리로 갈 수 있어요.
덧셈 정리에서 − P(A∩B)를 빼는 이유도 이 순서 안에서 이해됩니다. 두 사건이 겹치는 부분을 두 번 세지 않기 위해서죠. 사건이 표본공간의 부분집합이라는 정의가 먼저 있어야 "겹친다"는 말이 성립합니다.
큐레이터 노트
정의를 여러 개 나란히 둔 글이라 뽑았습니다.
확률 정리는 대개 하나의 정의를 놓고 공식으로 넘어갑니다. 이 글은 네 가지 정의를 먼저 나열해요. 시험 대비 요약에서 이 부분이 남아 있는 게 눈에 띄었습니다. 문제를 푸는 데는 고전적 확률이면 충분한데, 왜 여러 정의가 필요했는지를 알아두면 나중에 베이즈 정리를 만났을 때 덜 낯설거든요.
짧다는 게 제외 사유는 아닙니다. 이 글은 개조식이고 설명이 거의 없습니다. 그런데 순서가 정확합니다 — 표본공간 → 사건 → 확률 → 연산 → 조건부 → 베이즈. 이 순서대로 외우면 나중에 하나가 기억나지 않아도 앞뒤로 복원할 수 있어요.
방송통신대 통계 과목을 듣는 회원이 많고, AI·데이터 쪽으로 가려면 반드시 지나야 하는 구간입니다. 같은 과목을 듣는 분들에게는 진도 확인용으로도 쓸모가 있을 기록입니다.
💡 세 편을 겹쳐 읽으며
기업 시스템 연동, PyTorch 컴파일러, 학부 확률입니다. 이보다 멀 수 있나 싶은데 세 편이 같은 것을 말합니다.
먼저 정리해야 도구가 일한다
이동규 님이 이걸 못 박습니다.
김류흔 님 글의 TorchDynamo도 같은 구조입니다. 컴파일러가 최적화를 하려면 연산들이 그래프로 정리되어 있어야 합니다. 그래서 바이트코드를 가로채 FX graph를 만드는 단계가 먼저 오죠. 정리가 먼저고 최적화가 나중입니다.
강규진 님 글도 그렇습니다. 확률을 계산하려면 표본공간과 사건이 먼저 정의되어야 해요. 무엇이 가능한 결과들인지 정하지 않으면 확률이라는 값 자체가 성립하지 않습니다.
셋 다 "좋은 도구를 쓰기 전에 정의부터"입니다.
대가를 같이 적었다
두 번째 공통점은 맞바꾸는 것을 적은 것입니다.
이동규 님은 Hub-and-Spoke가 연결선을 줄이는 대신 SPOF를 만든다고 적었습니다. 김류흔 님이 다룬 Recomputation은 메모리를 아끼는 대신 연산을 더 합니다. 강규진 님의 덧셈 정리는 겹치는 부분을 빼주지 않으면 두 번 세게 되고요.
공짜가 없다는 걸 각 층에서 확인하는 셈입니다.
층이 달라도 문제의 모양은 닮는다
세 번째는 이 회차 자체의 특징입니다. 대기업 연동 · 프레임워크 내부 · 학부 기초. 경력도 분야도 다른 세 사람이 같은 회차에 글을 올렸는데, 나란히 놓으면 관통하는 게 보입니다.
성장일지가 여러 배경의 사람을 한자리에 모아두기 때문에 가능한 일이기도 합니다. 각자 자기 자리에서 쓴 글인데, 모아 놓으면 "연결이 늘어나면 어떻게 되는가" 같은 질문이 층을 넘어 반복되는 게 드러나요.
이번 회차에서 가져갈 것
1. 시스템을 1:1로 잇기 전에 N(N-1)/2를 계산해보기.
5개면 10개, 10개면 45개입니다. 하나 추가할 때마다 기존 전부와 이어야 한다면 중간 계층을 검토할 시점입니다.
2. 허브를 두면 SPOF가 생긴다.
연결선이 줄어든 대신 그 하나가 죽으면 전부 멈춥니다. 문제를 없앤 게 아니라 옮긴 것이니 이중화 계획을 같이 세우세요.
3. 연동은 도구보다 정의서가 먼저.
시점 · 데이터 · 키 · 형식 네 가지를 사람이 정리해야 합니다. 이게 없으면 어떤 솔루션도 도와주지 못합니다.
4. 최적화는 정리 다음에 온다.
TorchDynamo가 바이트코드를 가로채 그래프를 만드는 이유입니다. 전체가 한눈에 보여야 합칠 것과 미룰 것이 정해집니다.
5. 메모리와 연산량은 맞바꿀 수 있다.
Recomputation처럼 중간 결과를 저장하는 대신 다시 계산하는 선택지가 있습니다. 둘 중 무엇이 더 비싼 자원인지를 먼저 보세요.
6. 확률은 정의하는 방식이 여럿이다.
빈도론적 · 주관적 · 고전적 · 공리적. 어느 정의를 쓰느냐가 통계 방법론의 갈래를 정합니다. 베이즈 정리로 갈 때 이 구분이 다시 나옵니다.
7. 정리 노트는 순서가 곧 구조.
표본공간 → 사건 → 확률 → 연산 → 조건부 → 베이즈처럼요. 순서대로 적어두면 하나를 잊어도 앞뒤로 복원할 수 있습니다.
성장일지는 멤버들이 2주에 한 번씩 자신의 성장을 기록하는 활동이에요. 지난 기수의 성장일지를 다시 읽으면서, 그때 소개해드리지 못한 글을 하나씩 꺼내고 있습니다.
좋은 글 남겨주신 이동규 님, 김류흔 님, 강규진 님께 감사드립니다! 😊
다음 큐레이션으로 다시 찾아오겠습니다! 🌱
- 에디터 · 성장일지 큐레이터 -
※ 본 큐레이션은 각 저자가 공개한 글을 소개하는 것이며, 모든 원문의 저작권은 저자에게 있습니다. 저자 본인의 요청이 있을 경우 즉시 수정 또는 삭제합니다.