저는 남들보다 기억력이 좀 떨어지는 대신 이해력이 높다고 생각합니다.
나름 오랫동안 저의 이해의 방법에 대해 고심해봤고, 크게 3가지 방법으로 나누어졌습니다.
- 원리(mechnism)
- 의도(context)
- 역할(abstraction)
먼저 원리는 명확합니다. 동작의 원리를 파헤치고 근본적인 원리를 이해하려 합니다.
의도는 설계자의 의도를 파악하고 어떤 맥락에서 이것이 필요했는지를 추론하거나 질문하여 알아냅니다.
마지막으로 역할입니다. 이미 있는 개념으로 추상화하여 이해를 돕거나 의도와 연계하여 어떤 역할을 맡고있는지 파악하고 시스템 설계 시엔 역할이 중복되지 않도록 합니다.
예시를 들어보겠습니다.
얼마 전 운영 중인 클러스터에서 PV(PersistentVolume)를 재생성했는데,
파드가 이런 에러를 내며 스케줄링되지 않았습니다.
“0/7 nodes are available: 1 node(s) didn’t match PersistentVolume’s node affinity”
PVC는 이미 Bound 상태였고, 노드도 충분히 여유가 있었습니다.
분명 이상이 없어 보이는데 왜 안 될까 — 이럴 때 제가 문제를 파고드는 방식은 항상 같습니다.
원리: PVC는 바인딩되는 순간의 PV 정보를 스냅샷처럼 가져갑니다.
PV가 재생성되면서 node affinity가 바뀌어도, 이미 Bound된 PVC는 이 변화를 반영하지 않습니다.
즉 PVC 입장에서는 “예전 PV” 기준으로 스케줄링 힌트를 계속 들고 있던 것입니다.
의도: 왜 PVC를 이렇게 설계했을까 생각해보니, EBS 같은 스토리지는 특정 AZ에 종속됩니다.
WaitForFirstConsumer라는 옵션이 존재하는 이유도 같은 맥락이었습니다 —
파드가 어느 AZ에 스케줄링될지 확인한 뒤에 그 AZ에 맞춰 볼륨을 만들겠다는 의도.
PVC가 바인딩 시점을 기준으로 고정되는 것도, 이 일관성을 지키기 위한 설계였습니다.
역할: PVC는 “요청”, PV는 “실제 리소스의 추상화”라는 역할 분리를 이해하고 나니 결론이 명확해졌습니다.
PV만 바꾸는 건 반쪽짜리 변경이고, PVC도 반드시 함께 재생성해야 한다는 것.
원리만 알았다면 “왜 안 되지”에서 멈췄을 거고,
의도만 알았다면 “그렇구나” 하고 넘어갔을 겁니다.
세 가지를 같이 봐야 “그래서 무엇을 해야 하는가”까지 도달합니다.
적어도 새로운 시스템을 마주할 때는 이 세 가지 질문이 가장 빠른 길이 되어 주는 것 같습니다.
I think my memory is a bit weaker than average, but my ability to understand more than makes up for it.
I’ve spent a long time thinking about how I actually understand things, and it comes down to three angles.
- Mechanism
- Context
- Abstraction
Mechanism is the clearest one. I dig into how something actually works, down to the underlying principle.
Context means figuring out the designer’s intent — inferring or asking what situation made this necessary.
Abstraction is the last piece. I map a new concept onto one I already have, or tie it back to its context to see what role it’s actually playing — and when designing a system, I make sure roles don’t overlap.
Let me walk through an example.
A while back, I recreated a PV (PersistentVolume) on a cluster in production, and the pod refused to schedule with this error:
“0/7 nodes are available: 1 node(s) didn’t match PersistentVolume’s node affinity”
The PVC was already Bound, and there was plenty of free capacity on the nodes.
Nothing looked wrong, so why wasn’t it working — and this is where I always dig in the same way.
Mechanism: A PVC captures the PV’s information at the moment of binding, like a snapshot.
When the PV is recreated with a different node affinity, the already-Bound PVC doesn’t pick up the change.
From the PVC’s point of view, it was still holding scheduling hints based on the “old” PV.
Context: Thinking about why PVCs are designed this way, storage like EBS is tied to a specific AZ.
The WaitForFirstConsumer option exists for the same reason — the intent is to confirm which AZ the pod lands in first, then create the volume to match. Locking the PVC to its binding-time state is part of preserving that same consistency.
Abstraction: Once I understood that a PVC is a “request” and a PV is “an abstraction over the actual resource,” the conclusion was obvious. Changing the PV alone is only half the fix — the PVC has to be recreated along with it.
If I’d only had the mechanism, I would have stopped at “why isn’t this working.”
If I’d only had the context, I would have nodded and moved on.
Only holding all three together gets you to “so here’s what I actually need to do.”
At least when I’m facing a new system, these three questions seem to be the fastest way in.
댓글 (0)