devcken.io

Thoughts, stories and ideas.

Intuition, Insight

개발자에게 있어 중요한 능력은 수도 없이 많다. 문제 해결 능력, 합리적 사고력, 수학적 해석 능력, 습득력, 관련 기술 지식 등등, 대표적인 지식 노동자 중 하나라고 할 수 있다.

지식 노동자에게 필요한 능력에는 이외에도 무시할 수 없는 두 가지가 더 있는데, 바로 직관력과 통찰력이다.

직관력의 사전적 의미는,

[명사] 판단이나 추리 따위의 사유 작용을 거치지 아니하고 대상을 직접적으로 파악할 수 있는 능력.

또 통찰력의 사전적 의미는,

사물이나 현상을 통찰하는 능력.

통찰력의 경우 그 의미에 통찰이라는 단어가 또 들어가 좀 애매한데, 말하자면 '사물의 관찰력으로 꿰뚫어 보는 능력'이라 할 수 있다.

여기서 두 단어가 뜻하는 바가 비슷하면서도 오묘하게 다른데, 직관력은 겉으로 보기 힘든 어떤 사물의 면모를 볼 수 있는 힘을 말하며, 통찰력은 어떤 사물이나 현상에 대해서 포괄적, 다각적으로 볼 수 있는 힘을 말한다.

직관력과 통찰력이 있다면 개발자에게 어떤 점이 좋을까?

이 두 능력의 공통적인 부분은 바로 '해보지 않고도 알 수 있다'라는 것에 있다. 해보지 않고도 할 수 있다니 그 얼마나 대단한 능력인가? 그런데 그러한 능력을 얻기 위해서는 어떤 조건이 따른다.

어떤 일이나 사물에 대해 어느 정도 능통해야 한다. 어떠한 경험도 없이 직관과 통찰을 얻기란, 박혁거세처럼 알에서 태어나는 정도의 탄생 신화로 태어난 사람만 가능하지 않을까?

직관과 통찰은 그냥 생겨나는 것이 아니라 어떤 일이나 사물에 숙련되고, 또 다른 여러 가지 것들을 융합하여 생겨날 수 있다.

그런데 이 좋은 능력에도 문제가 있다. 그 중 하나가 측정하기 매우 어렵다는 것이다. 직관과 통찰은 사실 우리 주변에서 많이 일어나지만 그것으로 어떤 성과 또는 효과가 일어났는지 우리는 알아차리기 어렵다.

또 다른 문제는 바로 직관과 통찰의 오용과 남용이다. 내가 이 포스트를 통해 말하고자 하는 부분은 여기에 있다.

직관과 통찰은 맞고 틀리고의 문제라기 보다는, 어떤 정답을 얻어내기 위한 방법에 도달하기 위해 사용하는 지름길 같은 것이다. 물론, 직관과 통찰로 어떤 문제가 단번에 해결되는 경우도 아주 간혹 있지만, 아주 운이 좋은 경우라고 봐야 한다.

또, 직관력과 통찰력이 아주 높은 사람이라면, 그러한 행운의 빈도가 높긴 하겠지만, 그들의 그러한 능력만으로 일이 해결되는 경우는 아마 거의 없을 것이다.

주변에서 자신의 직관력 내지 통찰력을 맹신하는 개발자들을 꽤 보아왔다. 나도 가끔 느끼는 이러한 능력에 감탄(?)하곤 하지만, 사실 돌이켜보면 그 두 가지 능력으로 일이 말끔히 해결된 적은 없는 거 같다. 그렇다고 보기보다는 답을 얻어내는 과정을 좀 더 빠르고 쉽게 만들어주는 느낌이 강하다.

직관과 통찰이 가지는 문제점 중 하나는 그것이 주는 기쁨에 있다. 그것으로 어떤 문제가 해결된 것처럼 보일 때, 또는 해결될 것처럼 보일 때 우리는 어떤 카타르시스를 느끼는 것 같다.

사실 개발자는 이성적 존재여야 한다. 좀 더 명확하게 얘기하자면 과학자여야 한다. 과학자란 어떤 존재인가? 어떤 가설을 세우고 그 가설이 맞는지를 검증하기 위해 남들이 인정할 정도의 실험을 수도 없이 실행해 그 가설이 진리임을 알아내기 위한 사람 아닌가?

개발자도 그와 아주 비슷한 일은 한다. 어떤 문제에 대한 문제 해결 방법을 세우고 그 방법이 맞는지 검증하기 위해 테스트 코드를 작성해 그 방법이 옳다는 것을 증명해내는 존재다.

이 때 직관력과 통찰력은 아주 중요한 역할을 하는데, 그 중 몇 가지를 예로 들어보겠다.

첫번째, 문제 해결 방법, 즉 알고리즘을 만들 때 그 역할을 수행한다. '아 이 문제는 이렇게 하면 되겠다'라는 생각이 떠오르는 이유는 경험에서 나오는 것인데, 여기서 더 나아가 '이렇게 하면 되겠구나?'라는 생각이 든다면 그것은 직관력이나 통찰력에 의한 것일 가능성이 크다. 그리고 이때는 그야말로 문제를 파악할 수 있는 능력이 있어야 하므로 직관력이 좀 더 필요할 거 같다.

통찰력도 필요한데, 만약 문제 해결 방법이 쉽사리 떠오르지 않을때이다. '어떤 다른 측면은 없나?', '더 나은 방법은?' 등을 고민하는 순간 필요하다.

두번째로, 테스트 코드를 작성할 때 직관력과 통찰력이 필요하다. 90년대 말, 2000년대 초에 접어들면서 TDD에 대한 필요성이 대두되기 시작했다. 물론 우리 나라에는 그보다 훨씬 늦은 2000년대 말에 소개되기 시작했고 2010년대 중반에 들어서야 조금 자리 잡기 시작한거 같다. 개발자들은 테스트 코드 작성 자체에는 그리 힘들어하지 않는다. 물론, 테스트할 대량의 데이터를 만들고 그것을 대입해 프로덕션 레벨의 코드를 만든다는 것이 고난의 길이다. 하지만 진짜 힘들어하는 것은 '바로 무엇을 테스트할 것인가?', 즉 테스트 케이스 수립이다.

알고리즘 문제를 풀때는 테스트 케이스가 분명한 경우가 거의 대부분이다. 로직 자체에 대한 경우는 물론이고, 대부분 반복의 횟수, 경계값, 실행 속도, 메모리 사용량 등 정형화된 테스트 케이스를 통과시키면 되는 것들이 대부분이다.

그런데, 우리가 흔히 작성하는 코드들은 그러한 것들은 물론이고 테스트 케이스가 애매한 것들이 많다. 한번에 딱 떠오르지 않기도 하고, 너무 큰 덩어리라 어떻게 테스트해야할지 감이 오지 않는 경우도 많다. 물론, TDD에 숙련되면 이러한 것들이 좀 더 쉬워지기는 하겠지만, 이 때 발휘되어야 하는 통찰력의 힘을 무시할 수는 없다.

통찰력은 어떤 상황을 다각적으로 바라볼 수 있는 능력을 말하는데, 테스트 케이스 작성에 그 능력이 필요하다. 해결해야 하는 문제 그리고 그 방법, 그 방법을 검증하기 위한 것이 테스트 케이스인데, 그 상황을 다각적으로 볼 수 있어야 풍부한 테스트 케이스 작성이 이루어지고 그래야 확실한 증명이 된다.

그런데 이러한 직관력과 통찰력을 잘못 사용하는 경우가 많다. 사실 이 포스트 쓰는 나도 그런 경우가 많은데, 나의 직관력 또는 통찰력을 맹신하는 것이다.

머리 속으로 생각해보고 '우와 이거야!'라고 생각하는 것까지는 괜찮다. 당연히 그러한 과정이 필요하고 그 때 필요한 능력이 그 녀석들이니까! 그런데, 문제는 이 이후부터 발생한다. 그렇게 얻어낸 방법에 대해서 '증명'하지 않는다는 것이다. 그냥 믿어버린다. 물론 모든 경우를 테스트하기란 현실적으로 어려움이 있다. 하지만, 직관과 통찰로 믿었던 방법들이 계속해서 문제를 일으키고 있다면 자신의 맹신을 경계해야 한다.

개발자가 자신이 생각한 방법, 즉 직관이나 통찰을 이렇게 맹신하는 이유는 소위 말하는 '귀차니즘'의 영역에 있는거 같다. 물론 어떤 문제는 테스트할 엄두도 나지 않는 경우가 있다. 하지만 그 문제를 더 작은 하위 문제들로 쪼개서 하위 문제만이라도 검증하는 과정이 필요하다. 물론 해보지 않아서 그 방법을 모르기 때문일 수도 있지만, 사실 거기에는 '귀차니즘'이라는 기생충이 살고 있는 것이다.

'다른 일도 바빠!'라는 말로 합리화하지만, 결국 검증하지 않고 계속해서 방법만 만들어내고 검증하지 않은 상태가 이어지기에 일도 쌓이는거다. 일이 쉽사리 풀리지 않을 때는 시간을 확보해 충분한 테스트 환경을 만들어내고 그 테스트 환경으로부터 다시 생각해봐야 한다.

내가 세운 가설에 문제는 없는지, 내가 만든 테스트 케이스에 오류는 없는지, 다른 측면에서 테스트 케이스는 없는지...

직관력과 통찰력은 슈퍼 파워가 아니다. 아이언맨이 가진 Jarvis 같은 도구일 뿐이다. 도구는 이용과 숙련의 대상이지 믿음의 대상이 아니다.