나는 ‘개발자를 코칭하며 배운 7 가지’ 라는 제목의 글을 쓴 적이 있는데 내가 코칭한 대부분의 개발자들이 토로하는 고민이 있었다.

프론트를 해야 할지 백엔드를 해야 할지 잘 모르겠어요.

내 경험에 의하면 많은 이들이 자신에게 물어야 할 질문을 남에게 묻는다. 왜 그럴까? 자신이 무엇을 좋아하는지, 무엇을 하고 싶은지 잘 모르기 때문이다. 그래서 자신에게 해야 할 질문을 남에게 한다. 그렇지만 그 답답한 마음을 왜 모르겠는가. 그래서 나는 서부른 조언보다는 대화에서 스스로 힌트라도 찾을 수 있도록 충분히 들어 주는 편이다.

그럼에도 불구하고 ‘프론트냐 백엔드냐’를 고민하는 이들에게 작은 도움이라도 되길 바라는 마음으로 이 글을 쓴다.

어쩌면 ‘프론트냐 백엔드냐’의 문제가 아닐 수도 있다

먼저 둘 중 하나를 선택하는 문제에 대해 생각해 보자. 선택은 우리에게 스트레스를 준다. 빨리 무엇인가를 선택해야 할 것 같다. 선택하지 않으면 선택 장애 있는 것 같고 어중이떠중이가 되는 듯하다. 그리고 불안을 느낀다. 나는 그 이유가 어린 시절 부터 성인으로 성장하는 과정에서 충분히 고민하고 받아들이는 과정 없이 선택을 강요받아 왔기 때문이라고 생각한다. 꼭 선택해야 할까? ‘프론트냐 백엔드냐’라는 것도 내가 만든 게 아닌 남이 만든 기준이 아닌가.

책 <팩트풀니스>는 ‘세상을 오해하는 인간의 10 가지 본능’에 대해 말하고 있는데 ‘간극 본능'에서 이분법적 사고에 대해 아래와 같이 언급하고 있다.

내 생각에는 인간에게는 이분법적 사고를 추구하는 강력하고 극적인 본능이 있는 것 같다. (중략) 우리는 이분법을 좋아한다. 세상을 뚜렷이 구별하는 양측으로 나누는 것은 간단하고 직관적일 뿐 아니라, 충돌을 암시한다는 점에서 극적이다. 우리는 별다른 생각 없이 항상 그런 구분을 한다.

앞서 나는 ‘프론트냐 백엔드냐’의 질문은 남이 아닌 자신에게 물어야 한다고 말했다. 인간의 내면은 단순하지 않고 매우 복잡하다. 이분법적 사고는 문제를 단순화하는 데는 좋지만 복잡한 문제를 이해하는 것에는 대개 좋지 않다. 왜냐하면 복잡한 문제는 다양한 관점을 보아야 문제의 본질이 보이기 때문이다.

그렇다면 왜 선택을 고민하는 것일까? 프론트니 백엔드니 이전에 혹시 ‘내가 진짜로 원하는게 무엇인지’가 불명확한 것은 아닐까?

Form Follows Function

남에게 이래라저래라 하기 보다 내 얘기를 해보겠다. 나는 풀 스택 개발을 하고 있다. 사실 풀 스택 개발이 목적도 목표도 아니었다. 심지어 내가 풀 스택을 할지도 스스로 몰랐다.

그럼 어쩌다가 나는 풀 스택 개발자가 되었을까? 나는 스타업 회사에서 일하고 있다. 개발자가 나를 포함해서 2명이며 심지어 한 명은 CTO님이다. 그리고 개발자가 한 명이 하나의 서비스를 처음부터 끝까지 오롯이 개발하고 있다.

왜 이렇게 개발을 하고 있는 것일까? 물론 인력 부족의 문제도 있다. 하지만 그 이면에는 ‘내가 무엇을 원하는가’가 있다. 나는 ‘프론트를 하고 싶다’, ‘백엔드를 하고 싶다’라는 욕망 보다 ‘서비스 혹은 제품을 만들고 싶다’는 욕망이 크다. 그러다 보니 제품을 만들기 위해 필요하면 기획도 하고 설계도 하고 화면도 만들고 API도 만들고 인프라도 하게 되었다. 흔히 말하는 풀 스택 개발자가 된 것이다.

Form Follows Function은 공학의 원리로 '형태는 기능을 따른다'는 것이다. 밥솥의 모양은 왜 그렇게 생겼을까? 세탁기는 왜 그런 모양일까? 그 이유는 밥을 지으려니 그 모양이 된 것이고 빨래는 하려고 하니 그 모양이 된 것이다. 나에게는 프론트냐 백엔드냐가 혹은 풀스택이냐는 중요하지 않다 왜냐하면 내가 원하는 것을 얻기 위한 형태에 불과하기 때문이다.

불 충분한 정보로 서둘러 선택하기보다는…

다시 선택의 문제로 돌아가 보자. 무언인가 결정할 때에는 정보의 양이 중요하다. 우리는 선택의 기로에서 선택해야 한다는 강박과 불안에 결정하기에 충분한 정보를 얻지 않고 서둘러 결정하는 경향이 있다. 나는 ‘개발자를 코칭하며 배운 7 가지’ 글에서 ‘결정에 충분한 정보’를 언급했다.

선택을 할 때 중요한 것은 ‘결정에 충분한 정보'이다. 정보가 충분하지 않은 상태에서 고민만 하다가는 시간만 낭비한다. 실용적인 접근 방법은 여러 선택지를 모두 조금씩 해보고 결정하는 것이다. 언뜻 보면 낭비일 것 같은 말이다. 모두 해보라니... 나는 전에 어떤 프로그래밍 언어를 쓸 것인가를 고민한 적이 있었다. 두 가지 선택지가 있었다.

• Node.js
• Python

문제는 내가 둘 다 실제로 해본적이 없다는 것이었다. 해본적도 없으면서 고민한다니 웃기는 일이었다. 결국 나는 간단한 기능을 일주일씩 두 가지 언어를 모두 구현해 보았다. 해보니 알게 되었다(결정에 충분한 정보). 지금 내 맥락에는 Python이 맞다는 것을...

결정에 충분한 정보를 얻기 위해 다양하고 풍부한 경험을 쌓아 보는 것을 어떨까? 어떤 이는 어중이떠중이가 될 수 있지 않냐고 반문할 수도 있겠다. 나는 목표 없이 이것저것을 하는 것과 목표를 가지고 이것저것을 하는 것은 다르다고 생각한다.

책 <일의 미래>에서는 우리가 앞으로 살아가야 할 사회는 문제를 찾아 해결하고 다른 사람들과 소통하고 정보를 주고받는 협업 능력이 중요해진다고 말한다. 미래에 국한된 얘기가 아니다. 과거에도 현재에도 미래에도 일의 핵심은 의사소통인 것이다. 요즘 개발은 프론트 엔드, 백엔드, DevOps 등으로 과거에 비해 많이 분업화되어 있다. 분업화되어 좋은 점은 일의 효율성을 좋아진다는 것이다. 하지만 소프트웨어는 유기적이다. 결국 통합 비용이 커지기 마련이다. 통합 비용의 대표적인 것이 바로 의사소통 비용이다. 오죽하면 <오늘도 개발자가 안 된다고 말했다>라는 책이 나왔을까.

해결하기 어려운 문제는 대부분 복합적인 문제이다. 이런 문제를 해결하기 위해서는 의사소통이 핵심이지만 회의를 할 때 관찰해 보면 서로가 서로를 너무 몰라서 문제가 무엇인지 알지 못하는 경우가 많다. 내가 프론트 전문가라고 가정해 보자. 만일 백엔드를 알고 있다면 통합적 사고를 통해 문제의 원인 파악과 해결이 수월해질 수 있다.

내 안에의 욕망을 찾고 욕심을 내기 시작할 때

사회 초년생 시절의 나는 개발자를 해야겠다는 직업적 선택은 있었지만 그래서 ‘무엇을 개발해야겠다’는 없었다. 그러다 보니 변화하는 환경에 적응하며 ‘하고 싶은 것이 있느냐?’는 불편한 질문에 분명하게 대답하지 못 한 체 살았었다. 그리고 문득 나는 꿈을 떠올렸다. 그리고 생각했다.

인정하자. 그래 나는 지금 꿈이 없어. 그러면 내가 생각할 때 멋진 꿈을 꾸는 사람과 함께 일하는 거야. 그 꿈을 이루기 위해 함께 한다면 그 과정에서 나도 내가 하고 싶은 것을 발견할 수도 있지 않을까?

그 후 나는 내가 마음에 드는 꿈을 꾸는 사람을 찾았고 함께 일했다. 시작은 선장이 아니어도 좋았다. 일등 항해사면 어떠냐 내가 마음에 드는 꿈을 함께 하고 있는데. 멋진 꿈은 좋은 동료들을 불러 모으는 힘이 있는 듯하다. 나는 좋은 동료를 만나 자극을 주고 받으며 성장했고 내 안의 욕망을 깨닫기 시작했다.

책 <한국인에게 나는 누구인가> 에서는 나를 더 나답게 만드는 것이 욕심이라 했다. 내 안의 욕망을 깨닫고 욕심을 내기 시작할 때 나는 더욱 나답게 만들어 내가 진짜로 무엇을 원하는지 깨달을 수 있으리라 믿는다.

건투를 빈다

도움이 되었을지 혼란을 더 가중시켰을지 모르겠다. 이런 부류의 문제는 정답이 없고 본인이 처한 맥락에 따라 천차만별이다. 그래서 이래라저래라 하는 조언 보다는 내 경험을 위주로 말했다.

내가 개발자로 일을 시작할 때에는 상대적으로 기술 스택이 단순하고 직군이 세분화되어 있지 않아 이런 선택은 없었다. 세상은 많이 변했다. 예전보다 개발자 대우가 좋아졌지만 그만큼 치열해진 것도 사실이다. 기술 변화 속도가 빠르고 새로 배워할 것이 산더미다. 정신없이 변하는 환경에 살다 보니 내 생각이 자라는 것도 쉽지 않은 상황이다.

그럼에도 불구하고 고민하는 개발자들에게 조금이라도 도움이 되길 바란다.