논어(論語)는 공자가 제자들과 나누었던 대화들을 여러 사람들이 기록하여 모아둔 책으로, 제자들의 질문에 대한 공자의 가르침을 기반으로 하기 때문에 첫 사회생활을 시작하는 신입사원들에게 많은 도움이 되는 책입니다. 저 역시 첫 사회생활을 시작하였을 때, 이해할 수 없는 많은 상황들을 겪으며 힘들어할 때, 회사에서 사준 읽기 쉬운 “논어“를 읽으면서 많은 부분들에 대해서 다시 생각해볼 수 있었습니다. 그 중, 시간이 한참 지난 지금도 계속 머리를 떠나지 않는 몇 가지 구절이 있어 다시 한 번 되새길 겸 글로 정리해봅니다.
나이가 한 두 살 더 들었다고 시니어 개발자라고 말할 수 있는 것도 아니고, 함부로 조언해줄 수 있는 입장도 아니지만, 무엇이든 배우려는 열정이 넘치는 주니어 개발자들에게 조금이나마 힘이 될 수 있지 않을까 하는 기분 좋은 상상을 하며 글을 써봅니다.
子曰, 不在其位 不謨其政 (부재기위 불모지정)
공자께서 말씀하셨다. 그 위치에 있지 않거든 그 정사를 논의하지 말아야 하느니라.
회사생활에 조금씩 적응되어갈 무렵, 이상적인 사회생활을 꿈꾸었던 많은 신입사원들은 조금씩 이해할 수 없는 회사의 부조리함을 확인하게 됩니다. 물론, 회사에는 잘못된 부분들과 개선해야 하는 부분들이 너무나도 많습니다. 이미 타성에 젖은 선배들보다 신입사원들의 눈이 문제를 정확하게 볼 수도 있습니다. 그러나 이 구절을 통해 제가 말하고자 하는 부분은 이러한 회사의 부조리함이라기보다 서로 다른 역할에서 발생하는 문제를 해결하는 방법에 대한 것입니다. 이 구절은 주니어 개발자들에게 두 가지 부분에서 조금 다르게 해석되어 적용될 수 있습니다.
전임자의 아웃풋을 비난하지 말라.
특정 서비스나 시스템을 처음부터 개발하게 된다면 좋겠지만, 많은 경우 이미 많은 부분이 진행되거나 완료된 이후의 아웃풋을 넘겨받는 경우가 많습니다. 누구나 한 번쯤은 다른 사람의 소스코드를 보며 ‘아 뭐 이런 식으로 만들었어’라고 속으로든 겉으로는 말해본 적이 있을 겁니다.
물론, 실제로 전임자의 책임감이 부족하여 그 결과물이 지나치게 엉망인 경우도 존재합니다. 그러나 많은 경우, 그것이 주어진 기간과 인력으로 최선을 다한 것일 수 있습니다. 또는, 전임자의 아웃풋을 낮게 평가하는 것이 내가 빨리 인정받을 수 있는 가장 쉬운 방법이라는 것을 잠재의식 속에서 판단한 결과일 수도 있습니다.
개발자라면 누구나 향후 예상되는 변경사항과 확장성을 고려하여 철저하게 설계된 인터페이스를 기반으로 개발하고자 합니다. 그러나, 잘 알다시피 현실은 이를 쉽게 허락하지 않습니다. 전임자 또한 우리와 같은 상황이었을 겁니다.
빡빡한 일정에 대한 압박은 물론, 수시로 변경되는 요구사항 때문에 전임자의 아웃풋은 우리의 마음에 썩 들지 않을 수 있습니다. 주니어 개발자들이 반드시 알아야 할 점은, 전임자의 아웃풋은 개선의 대상이 될 수는 있지만, 비난의 대상이 되어서는 안된다는 점입니다. 다른 사람의 소스코드를 보았을 때 잘못된 점보다는 배울 점은 없는지 찾아보고, 개선할 부분이 없는지 찾아보는 자세가 바로 주니어에서 시니어로 넘어가는 과정이라고 할 수 있습니다.
기획, 디자인 등 다른 역할을 철저히 신뢰하라.
불특정 다수를 대상으로 하는 서비스를 개발하다보면 누구나 한번쯤 기획 또는 디자인 등 다른 역할을 하는 사람들과 부딪히는 경험을 하게 됩니다. 각자의 역할은 다르지만 모두가 공통적으로 하는 일은 “주어진 문제를 해결하는 것” 입니다.
이때, 서로 문제를 바라보는 시각이 다르기 때문에 해결방법에 대한 의견도 서로 다를 수 밖에 없습니다. 이러한 문제를 충분한 의사소통을 통해 풀어나가지 못하는 경우, 서로가 서로의 역할을 넘어서 다른 사람의 정사를 논의하는(謨其政) 일이 발생하게 됩니다. 예를 들어, 개발자는 디자인이 촌스럽다고 불평하게 되고, 기획은 개발 난이도에 대하여 스스로 평가하게 됩니다. 기획자와 개발자 간의 소통에 대해서는 작년에도 “화성에서 온 기획자, 금성에서 온 개발자“라는 제목으로 포스팅한 바가 있습니다.
주니어 개발자들은 기획이 얼마나 많은 시간을 투자하여 차별화 요소를 만들기 위해 고민하는지 이해해야 합니다. 물론, 그 과정에서 일정과 예산을 고려하지 못한 지나치게 이상적인 결과물이 도출될 수도 있습니다. 이러한 경우 커뮤니케이션을 통해 구현 가능한 일정과 범위로 조율하는 것이 바로 주니어에서 시니어로 성장해가는 과정이라고 할 수 있습니다. 기획, 마케팅, 디자인, 세일즈 등 다른 역할이 개발보다 쉬워보인다면 스스로 아직 주니어라는 점을 자각하는 것이라고 할 수 있습니다.
子曰, 不患人之不己知 患不知人 (불환인지불기지 환불지인)
공자님께서 말씀하셨다. 남이 나를 알아주지 않는다고 근심하지 말고, 내가 남을 알아보지 못하는 것을 근심하라.
사람은 누구나 다른 사람으로부터 인정받고자 하는 욕구를 가지고 있습니다. 이것은 사람의 성격에 따라 결정된다기 보다 본능이기 때문에 사람이라면 누구나 공통적으로 가지고 있는 특성입니다. 근대 심리학의 창시자로 일컬어지는 윌리엄 제임스는”인간의 본성에서 가장 깊은 원칙은 인정받고자 하는 열망이다.“라고 말했습니다.
개발자는 많은 직업들 가운데, 이상하게도 ‘자존심’이라는 부분과 연결이 많은 직업입니다. 그 이유는 아마도 하는 일의 결과물이 눈에 명확하게 보이기 때문에 다른 사람의 평가를 받는 경우가 많고, 언제 어디서나 존재할 수 있는 ‘버그’라는 존재 때문에 비난을 받는 경우도 많기 때문일 겁니다. 이러한 이유로, 많은 주니어 개발자들이 초기에 실력을 인정받기 위해 많은 어필을 하게 됩니다.
개발 속도로 인정받는 것은 주니어 개발자만의 특권이다.
문제는 인정받고자 하는 주제가 ‘개발 퍼포먼스’인 경우 입니다. 주니어 개발자가 가장 쉽게 받을 수 있는 칭찬은 “아니? 이걸 벌써 다했어?” 입니다. 이런 이야기를 들을 때면 나의 실력을 인정받는 것 같고, 어깨가 으쓱해집니다.
저 또한, 이러한 칭찬 덕분에 많은 자신감을 얻었고, 지금까지 재미있게 개발자로 일할 수 있는 원동력이 되었습니다. 하지만, 이러한 칭찬은 점점 나를 개발 속도에 집착하게 만들게 됩니다. 물론, 개발 생산성은 개발자에게 매우 중요한 요소입니다. 하지만, 남들보다 두 배 빨리 개발할 수 있는 사람은 두 명의 개발자로 쉽게 대체될 수 있다는 점을 명심해야 합니다.
누구나 다른 사람들로 부터 인정받기 시작하면 나를 인정해준 사람들을 실망시키지 않기 위해서 계속 기대치에 부흥하고자 하는 노력을 하게 됩니다. 이 과정에서 “요즘 왜 이렇게 일이 느려?” 라는 이야기를 감당하는 것은 생각보다 어려운 일입니다.
하지만, 시니어 개발자가 되기 위해서는 다른 두 세명으로 대체할 수 없는 나만의 무기가 필요합니다. 이를 위해서는 다른 사람에게 인정받는 것과 나의 내실을 다지는 시간을 적절히 분배하여 균형을 맞추어야 합니다. 30대 중반이 되어 개발자로서 면접을 볼 때 ‘당신은 무엇을 잘 합니까?’ 라는 질문에 ‘엄청 빨리 개발합니다.’ 라고 대답하지 않으려면 빠른 개발속도에 대한 칭찬에 대해서 조금은 내려놓는 방법을 익혀 나가야 합니다.
다른 사람을 인정할 줄 알아야 나도 인정받을 수 있다.
개발을 진행하다 보면 다른 개발자들이 맡은 부분이 조금 더 쉬워보이고, 내가 하는 일이 가장 어려워 보이는 경우가 많습니다. 그래서 다른 사람의 좋은 결과물을 쉽게 인정하지 않으려 하게 됩니다.
하지만, 시간이 한참 지난 뒤에 그 때 나와 함께 일했던 사람이 정말 뛰어난 사람이었다는 점을 뒤늦게 깨닫게 되는 경우가 많습니다. 이를 뒤늦게 깨달았을 때에는 이미 내 자신이 한없이 부끄러워진 다음입니다. 주니어 개발자는 항상 환불지인(患不知人)이라는 구절을 되새기는 자세가 필요합니다. ‘내가 지금 정말 뛰어난 사람을 몰라보고 있는 것이 아닌가?’ 하며 다른 사람의 뛰어난 점을 찾아내려는 자세야 말로 내가 성장하고 인정 받을 수 있는 지름길입니다. 삼국지(三國志)의 유비 역시 방통을 처음 보았을 때는 그가 봉추라는 것을 알아보지 못하였으니, 나 역시도 뛰어난 사람을 몰라볼 수 있는 것은 당연한 일입니다.
보너스 : 아무리 멀리 왔어도 잘못 온 길이라면 돌아가야 한다.
– 티베트 속담
마지막으로, 논어의 내용은 아니지만 제가 종종 일하며 되새기는 티베트 속담을 하나 소개할까 합니다. 위에서도 언급했지만, 개발자라면 누구나 향후 확장성을 고려한 설계와 개발을 추구합니다. 그러나 바쁜 일정 등으로 추후에 문제가 소지가 될 수 있는 개발하게 되는 경우가 많이 있습니다. ‘지금은 바쁘니 일단 이렇게 개발하고 나중에 바꾸자’라고 생각하며 개발하는 것은 어쩌면 피할 수 없는 운명일 수도 있습니다. 이렇게 시간이 지날수록 개발자는 “기술 부채(Technical Dept)“를 쌓아가게 됩니다. 이 부채는 서비스나 시스템이 종료되기 전까지 항상 개발자의 발목을 붙잡을 것 입니다.
문제는, 이러한 기술 부채를 해결할 수 있는 시간이 왔을 때는 이미 너무 많이 와버렸다는 점입니다. 이러한 부채를 해결하는 시간에 더 많은 새로운 기능들을 구현할 수 있다는 유혹도 떨쳐버릴 수 없습니다. 하지만 개발자라면 반드시 현재 어느 정도의 기술 부채가 존재하는지를 인식하고 있어야 하며, 이를 지속적으로 의사결정 과정에 이슈제기 하며 해결해 나가고자 하는 의지를 가져야 합니다. 사실 이 속담은 개발자보다 전체적인 일정을 계획하는 사람들에게 더 필요할 수도 있습니다. 그러나 책임감 있는 개발자라면 언제나 이러한 기술 부채를 해결하려고 노력해야 합니다.
원문: Guruble Blog
