은성이는 개발자 앞에 놓인 문제들 중, 무엇이 잘못되었는지 모르는 상태(A:unknown-unknown)를 파악하고 실제로 해결하기까지(C:known-knwon) 이르지 않고, 무엇이 잘못되었는지만 알고 실제로 어떻게 해결하는지는 모르는 상태까지만 공부하는 것(B:known-unknown)이 개발자의 성장과는 거리가 먼 "무의미한 삽질" 이라고 생각하고 있었다(참고2).

<aside> 💡 디어의 은성이가 정의하는 무의미한 삽질: A → B 를 지나 C 까지 이르지 못하는 것

</aside>

재균이형은 여유가 없어서 "오늘 당장 어떤 일을 하기" 같은 일만 하고, 어떻게 더 잘하지? 의 고민과의 균형이 무너질 때 내가 표현하는 "반감기가 짧은, 무의미한 삽질같은 지식" 을 습득하게 되는 것 같다고 했다(참고1). 나는 이 표현을 두 가지로 해석할 수 있다고 생각한다.

• 첫째, 무엇이 잘못되었는지는 파악했으나, 어떻게 더 잘 할 수 있는지(B → C)에 대해서는 많이 신경쓰지 못한다. 이는 은성이의 의견과 비슷하다고 할 수 있다.
• 둘째, 무엇이 잘못되었는지를 파악하고, 그 문제를 어떻게 잘 해결할 수 있을까를 고민(A → B, B → C)할 수 있는 시간이 너무 적게 주어져서, unknown 추가적으로 탐색할 수 있는 기회 없이 known-known 내에서만 개발을 노력한다(참고3).

<aside> 💡 디어의 재균이형이 생각하는 무의미한 삽질: A → B, B → C 에 대한 고민을 충분히 하지 못하는 것

</aside>

from

1. ‣

opposite

1. 2_1_2_2. title: 살아가고자 하는 모습에 따라 known과 unknown의 기준이 달라진다. 예를 들어 개발자의 known-unknown에 대한 기준선은 아키텍터의 known-unknwon의 기준선과 다르다. 가장 먼저 선행되어야 하는 것은 known과 unknown이 정의되는 공간을 선택하는 것이다. 설사 그것이 옳지 않다고 하더라도 불안감을 갖지 않고 살아갈 수 있다.

to

1. 2_1_2_2. [info] title: 개발자가 unknown-unknown 을 known-unknown 으로 바꾸는 방법 - 집단과 개인의 관점에서
2. 3__1.2_2.1_1. title: unknown-unknown 에 대한 불안감을 unknown → known 전환방법을 몰라서 오는 불안과 속도에 대한 불안으로 나누어볼 수 있다.

참고

1. 우리의 상황은 지금 여유가 없는 것 같다. 당장 오늘까지 뭐 하기와 같이 어떤 태스크에 매달렸기 때문에 이걸 더 잘할 방법에 대해서 고민할 여유가 없었다. -재균