신입 개발자 시절부터 성장하는 데 도움을 준 몇 가지 방법이 있는데 그중에 하나가 '라면 끓이기'였다.
만약에 내가 사수님이라면
만약에 내가 팀장님이라면
만약에 내가 CTO라면
나는 어떻게 했을까?
이런 식으로 내가 저 사람이라면 어떻게 할지를 생각해 보는 것은 여러모로 성장에 도움이 됐다. 특히 두 가지 측면에서 도움이 됐는데, 첫째는 기술적 지식이나 도메인 지식의 부족한 부분들을 발견할 수 있다는 점에서 였고, 둘째는 논리적 사고와 전개를 키울 수 있다는 점에서였다. 하나하나씩 살펴보자.
신입이던 그 어느 날, 나는 이런 생각을 했다.
'무엇을 모르는지를 모르는 게 문제다'
신입 시절의 나
그렇다. 신입으로 현업에서 일을 시작하게 되면 무엇을 모르는지 모르기 때문에 어디서부터 어떻게 시작해야 할지 참 난감하다. 어찌 보면 모르는 게 당연한 시절이지만, 대부분의 신입들이 그렇듯, 모르는 게 있으면 안 될 것 같은 그런 기분이 들기 마련이다. 그렇다고 막무가내로 아무렇게나 닥치는 대로 공부할 수는 없는 노릇 아닌가? 한정된 시간 속에서 당장 실무에 도움이 되는 지식들부터 공부하고 싶은데 문제는 그 지식들이 무엇인지 어떻게 알 수 있냐는 것이다.
내가 소속된 팀이 운영하는 서비스의 기술 스택을 파악하거나 이미 짜인 코드들을 보면서 지식을 늘려가는 방법도 있겠고, 정리된 문서가 있으면 그 문서들을 찾아보는 방법도 있겠다. 여기에 한 가지 팁을 더하고 싶다. 라면을 끓이자!!!
만약에 내가 사수님이라면 어떻게 대응했을까?
사수님은 개발 경험이 나보다 많거나 이미 현재 업무에 어느 정도 익숙한 분일 것이다. 그런 분들에겐 보통 동료 개발자나 기획자, PM, PO, 심지어 CTO나 대표로부터 이런저런 문의가 오기 마련이다. 오프라인으로 문의가 오든 메신저 개발팀 방에 문의가 오든 사수님께 문의가 오면, 나라면 어떻게 대답할 것 같은지를 생각해 보자.
"app 2 app 인증을 했는데도 제대로 토큰이 발급되지 않는데 혹시 이유를 알 수 있을까요?"
"A라는 api를 100 tps 정도로 호출하여 사용할 것 같은데 혹시 무리가 없을까요?"
"상품을 추천하는 기준이 어떻게 되나요? 이미 좋은 평점을 받은 제품이 있다면, 후발 주자로 시장에 진입한 동일 품목의 다른 제품은 상대적으로 추천받기 불리할 것 같은데 이에 대한 보완이 되어 있는지 궁금합니다"
"B라는 API를 사용하기 위해 Authorization 헤더에 bearer 타입의 토큰을 넣었는데도 403 forbidden을 받았어요. 무슨 이유에서 였을까요?"
"사용자가 개인 정보를 변경했음에도 여전히 친구들은 변경 전의 정보가 보인다고 합니다. 바로바로 업데이트가 되는 것 아니었나요?"
"API에 쿼터(quota)를 적용해 주실 수 있나요?"
"배달 라이더에게 어떤 기준으로 배달 요청을 할당하고 있나요?"
이런 종류들의 문의를 사수님이 받았다면, 나라면 어떻게 대답할 것인가?
여기서 크게 세 갈래로 나뉜다. 질문 자체가 이해가 안 되거나, 질문은 이해가 됐는데 어떻게 대답해야 할지 잘 모르겠거나, 어느 정도 대답도 할 수 있을 정도거나, 셋 중에 하나다.
신입 때는 질문 자체부터 이해가 잘 안될 것이다. 혹은 질문은 이해가 됐지만 어떻게 대답해야 할지 잘 모를 것이다. 기술적으로든 혹은 서비스 도메인 지식적으로든 아는 것이 거의 없기 때문이다. 낙심할 필요 없다. 무엇을 모르는지를 모르는 신입에게는 모르는 것을 발견했다는 것만큼 좋은 것도 없다!
문의한 내용 자체가 이해되지 않을 때는 모르는 부분을 메꿔야 한다. 개념 자체가 생소하다면 그 개념을 공부해야 하고, 서비스 도메인 지식이 부족해서 이해가 잘 안된다면 그 부분을 파악해서 채워야 한다. 그렇게 꾸준히 지식이 쌓이면 어느 정도 대답도 해낼 수 있다. 특히 서비스 도메인과 관련된 지식을 습득할 때는, 문의한 내용과 관련된 코드가 어디에 있는지까지 파악한다면 더할 나위 없이 좋다. 지식보다 정확한 것은 현재 동작하고 있는 코드이기 때문에 (서비스 도메인 지식이나 스펙은 나도 모르게 outdate 될 수 있으므로..) 어느 위치에 해당 로직이 구현되어 있는지 알고 있다면, 그 위치의 로직을 확인하여 정확하게 대답할 수 있기 때문이다.
문의에 대한 대답이 어려운 이유는 (앞서 언급한 것처럼 기술적 혹은 도메인적 지식이 부족해서 일 수도 있지만) 아직 신입이거나 주니어여서 시야가 좁아서 전체 구조적으로 보지 못하기 때문일 수 있다. 혹은 어디서부터 점검하고 어떻게 개선해야 하는지에 대한 논리적인 감각이 아직 없기 때문일 수도 있다. 지식이 부족해서 대답을 못하는 것은 지식을 채워 나가면 되지만, 시야나 감각적인 부분은 어떻게 키워나갈 수 있을까?
이런 경우에는 사수님이 어디를 살피고 어떻게 논리적으로 풀어 가는지를 참고하여 배우는 게 큰 도움이 된다. 보통은 문의에 대한 답을 하면 추가적인 질문이 나오기 마련이다. 즉, 질문과 답변의 티키타카가 생기게 되는데 이런 일련의 과정 속에서 사수님이 무엇을 고려하며 대답하는지, 도대체 사수님의 뇌 속에서 어떤 사고의 과정을 거쳤기에 저런 대답이 나오는 것인지 추측해 보면서 사수님이 전개하는 논리의 길을 따라가 보자. 그러다 보면 어느 순간! 나도 앞으로 어떤 부분을 확인하고 또 염두 해 가면서 해결책을 모색해야 하는지 감이 생기고, 어떻게 생각을 전개해야 논리적으로 말이 되는지를 판단할 수 있는 사고력이 증가하여, 훗날 여러 문의나 문제를 만나더라도 합리적이고 논리적으로 풀어나갈 수 있는 한 명의 독립적인 개발자로 성장할 수 있게 된다.
만약 어느 정도 문의에 대한 대답을 할 수 있을 정도가 됐다면, 축하한다! 당신은 그만큼 성장한 것이다! 지식의 범위도 더 넓어졌고 깊이도 더 깊어졌다. 시야도 더 넓어지고 나름 자신만의 솔루션을 줄 수 있을 만큼 논리적 기반이 탄탄해졌다. 이 정도 수준이 됐다면 앞으로는 사수님이 문의에 대응하는 방식이나 전개를 보면서 '나라면 이렇게 했을 텐데.. 사수님은 왜 그렇게 하신 걸까?'라는 생각이 종종 들 수 있다. 그때마다 스스로 고민해 보고 여전히 답이 잘 나오지 않으면 사수님께 정중히 물어보자. 대부분의 사수님은 왜 그렇게 답변하셨지 설명해 주실 것이고, 듣다 보면 나는 미처 생각하지 못했던 영역이 있었다는 것을 깨닫게 될 것이다. 깨닫는 것은 뭐다? 성장이다!!
만약 사수님의 나의 의견을 들어보고 '와우! 그 방법이 더 적절한 것 같네요!'라고 한다면, 더 더 축하한다! 더 성장한 것이다! 여러분의 성장을 인정해 주는 훌륭한 사수님과 함께 말이다!!
위의 내용은 사수님이 문의를 받았을 때의 상황을 상정하고 설명했지만, 꼭 사수님이 아니더라도, 꼭 문의가 아니더라도 라면을 끓일 수 있다. 사수님이 아니라 개발자 동료일 수도 있고, 문의가 아니라 서비스 장애 원인 분석 중일 수도 있다. 포인트는, 상황에 간접적으로라도 나를 노출시켜서 잘 몰랐던 부분을 발견하고, 앞서가고 있던 그 누군가가 어떻게 해결하는지를 보면서 시야를 넓히고 논리력을 키워나가는 것에 있다.
서두에 신입은 무엇을 모르는지조차도 모르는 존재라고 했다. 그렇다. 뭐시 중헌지 모르는 게 신입이다. 그런 측면에서, 문의 상황에 혹은 서비스 장애 대응 상황에 라면을 끓이며 나를 노출시켜 보는 것.. 무엇이 중요한지 더 빠르게 파악하도록 돕는 나름의 지름길 아닐까?
지금도 나는 이 습관을 그대로 유지하고 있다. 이젠 시니어 개발자이다 보니, 최근에는 CTO라면을 많이 끓였던 것 같다. 내가 CTO라면 어떻게 결정했을까? 어떤 철학과 문화로 개발팀을 이끌어나갔을까? 어떤 기술 스택을 사용했을까? 초기 개발 환경 세팅은 어떻게 했을까? 등등의 라면들을 말이다. CTO라면을 끓이면서 좀 더 거시적인 측면에서 생각해 보게 됐고, 기술 외적인 측면으로도 생각의 범위를 넓히는 데 도움이 됐다.
이쯤 되니 내일 점심은 라면이 당긴다. ㅎㅎ
여러분도 라면 끓여보시겠습니까?
p.s
좋은 사수님과 동료들을 만나는 것은 잘 성장하는데 매우 중요한 요소임이 자명하다. 이번 글에서는 좋은 사수님과 동료들을 어떻게 만날 수 있는지를 다루지는 않았다. 대신 꼭 부탁드리고 싶은 것은, 이 글을 보는 여러분도 훗날 누군가의 사수, 누군가의 동료, 누군가의 팀장이 될 텐데, 신입 개발자나 주니어 개발자의 성장에도 마음을 쓰는 귀인이 되어주시길 꼭 부탁드린다.