Lessons for 2023 Q3

새 회사에서 일하게 된 지 벌써 1년이 넘었네요. 그럼에도 여전히 회사일은 할 때마다 새롭습니다. 이번에도 일하며 느꼈던 것들을 간단하게 끄적여 봅니다.

이번 끄적임은 근황이 다소 바빠서 늦었습니다. 하드 고장나서 복구하는데 진땀 흘렸고, 연휴도 뭔가 바쁘게 지나갔고, 회사일도 점점 바빠지고 -_-;.

승진

이직해온 이 회사에서 얼마나 버틸수 있을까 생각하며 첫 출근을 하던 때가 엊그제 같은데, 벌써 승진을 하게 되었습니다. 사정상 당장 별다른 보상은 없지만 그래도 쫓겨나지는 않겠구나 싶어서 좋습니다.

앞으로도 열심히 해야만 한다…

돈이 되는 개발, 쓰기보다는 듣는 개발 하기

지난 날동안 최고의 개발자가 되기 위해서 나름 많은 노력을 해왔습니다. 주어진 요구사항에 부합하는 (혹은 그보다 더 나은 방안을 제시하거나) 개발을 하거나, 버그가 발생하면 신속하고 정확하게 디버깅을 하는 것들이 그러한 일들이죠. 즉 주어진 일을 잘 처리하는 게 개발자로서 최고의 역량이라고 생각해 왔습니다.

하지만 요즈음 저에게 주어지는 일들은 사뭇 다른 듯 합니다. 단순히 주어진 일을 처리하는 것과 어떤 일을 해야 하는지 이해하는 것은 꽤 다르다는 것을 요즘 느끼고 있습니다. 물론 혼자 개발할 시절에도 해야 할 일들 목록을 만들고 이에 따라 진행해 본 적은 있습니다. 하지만 고객과 시장의 상황을 이해하고 이에 따른 제품을 디자인해서 이를 개발레벨까지 (거기에 일정까지 고려해서) 계획하는 것은 다른 분야라는 것을 느끼고 있습니다.

이를테면 요구사항을 충족하기 위해 나온 제품 A와 B가 있는데 더 시장성이 높을 것으로 생각되는 A를 고르고 B는 쳐내는 식의 결정이 PM에서 내려옵니다. 그러면, 이를 가지고 시간이 촉박하니 완벽보다는 일단 구동이 가능하게 하는 식으로 큰 그림의 설계를 함과 동시에, 타 팀간의 연동에서는 우리 모듈 외에도 다른 모듈의 작동원리를 정확하게 파악해서 설계에 흠이 없는지 확인하고, 그러면서도 아키텍쳐 레벨에서는 consistency와 high TPS를 유지하기 위해서 SQS 및 파이프라인 및 최적화된 DB 설계를 꾀한다던가 같은 것들이죠. 그리고 이러한 결정사항을 팀원들과 같이 공유해서 공감대를 얻어냅니다.

이런 걸 하다 보니 단순히 코드를 짜는 것 이외의 능력이 더더욱 필요하다는 것을 느끼고 있습니다. 코드와 설계를 읽을 수 있어야 할 수 있는 일이 점점 늘어나고 있습니다. 단순히 코드만 잘 짜서는 훌륭한 개발자가 될 수 없음을 뼈저리게 느끼네요.

덤으로 코드를 리뷰해야 할 일들이 계속 늘어나면서, 코드 레벨의 작업에서도 코드를 쓰기보다는 읽는 일이 훨씬 더 많아지고 있네요. 여러모로 레벨이 올라갈수록 코드를 짜는 일과는 아무래도 거리가 멀어지고, 코드(나 설계)를 이해해야 하는 능력이 더더욱 중요해짐을 느낍니다.

대답은 빠르게

잘 모르는 것에 대해서 대답하는 것은 쉬운일이 아닙니다. 그리고 회사를 다닌지 1년이 되었지만 아직도 솔직히 이 거대한 코드덩어리에 대해서 제가 잘 모르는 부분이 너무나도 많습니다. 그런 부분에 질문이 들어올 때마다 바로 질문하지 못하고 회피하곤 했습니다. 혹은, 너무 바빠도 “그냥 하루 뒤에 대답해야지” 하고 넘긴 적도 가끔 있었습니다. 제가 멀티태스킹을 참으로 못하는 것도 이유 중 하나입니다.

그런 경우 매니저나 시니어 스태프가 붙어서 대신 답변을 주는 경우가 있는데, 생각해보면 그들은 저보다 더 바쁜데도 불구하고 잠깐 시간을 내어서 답변을 해준 셈입니다. 그들도 그렇게 하는데, 내가 그렇게 하지 않는다면 무능력한 사람 취급을 받게 되는 것입니다. 여기까지 생각이 미치니, 제 행동 방식이 회사와 맞지 않았구나 생각을 하게 되었습니다. 알고 있는 건 바로 답변해주고, 모르는 건 확실하지 않다는 답변과 함께 시니어를 멘션하면 비교적 편하게 빠르게 답변할 수 있겠더라고요.

그러니까, 질문은 빠르게 답변하는 게 맞는 겁니다. 그에 대답이 설령 확실하지 않더라도요. 현재 나 보고 있어~ 이 표현이 중요한 겁니다.

모든게 부족한 스타트업

너무 당연한 소리인데, 글로 보는 거랑 실제 겪는거랑은 약간 차이가 있다는 걸 느낍니다. 어떤 상황이냐면, 일단 진행되는 프로젝트는 많은데 사람 수가 적다 보니 개개인 모두가 터무니 없이 많은 워크로드를 받게 됩니다. 팀 규모도 작습니다. 팀 내 개개인이 서로 다른 프로젝트를 진행하는 경우도 심심치 않게 있고, PM이 프로젝트 서너개를 동시에 물고 진행하는 경우도 왕왕 있습니다.

정상적인 상황은 아니기에, 대기업이었다면 사람이 부족하니 더 뽑아달라, 혹은 사람이 부족해서 이 일을 할수가 없다고 항소하며 징징댈 수 있습니다. 하지만 스타트업은 징징댄다고 뭘 할수 있나요. 돈이 없는데! 결국 이를 감내할 수 있느냐가 흔히 이야기하는 “스타트업 정신”이 아닐까 싶습니다.

이외에도 완벽함보다 수익성을 추구하는 방향성 등에서 일반적인 회사랑은 조금 다른 느낌이 있습니다. 아, 물론 이런 소리를 한다고 해서 완벽성을 추구하지 않는다던가 이런 건 절대 아닙니다!

이 길이 맞나…

바라던 대로 커리어는 계속 쌓이고 있고, 더 높은 곳으로 향해가고 있음을 어렴풋이 느낍니다. 하지만 제 마음은 약간은 그렇지 못한 듯 합니다. 하드 복구를 하며 옛 추억들을 뒤져가며 느끼는 건데, 코드를 마구마구 짜면서 느꼈던 그 당시의 희열이 지금의 저에게는 없습니다. 컴퓨터 하지 말라고 전자기기를 죄다 뺏겨가면서도 몰래몰래 밤새 umpc로 코드를 짰던 시절도 있었는데, 이제는 집에 와서 뭔가 해야하는 일들(주로 커리어 유지를 위해 읽어야 할 것들 책들…)만 하지, 뭔가 만들고 싶다는 욕망이 예전같지가 않습니다.

나이가 먹어서 그런 걸까요. 아니면 제 성향이 바뀐 걸까요. 아니면 제가 가는 길이 이 길이 아닌 걸까요. 중간 점검을 해보고 싶지만, 아직은 뛰어야 할 때라 그럴 여유가 부족합니다. 하지만 하고 싶은 걸 찾지 못한다면 지금 일을 열심히 할 필요가 있을까요? 다 즐기려고 하는건데. 아무튼 고민 좀 해봐야 할 것 같습니다.

구동사를 이용해서 원어민처럼 영어 하기

현지인들과 이야기하면서 가장 크게 느끼고 있는 것은 특정 단어보다 동사구/부사구 등으로 이야기 하는게 훨씬 매끄러운 경우가 많다는 것입니다. 사실 생각해보면 한국어도 비슷한 경우가 많습니다. “차가 속도가 잘 안 올라가네” 보다 “차가 잘 안 나가네” 같은 표현이 더 깔끔한 것처럼요. 그리고 동시에 원어민들도 구절 형태로 표현하는 경우가 많기 때문에, 그러한 표현에 익숙하지 않으면 순간 대화를 따라가지 못하게 되더라고요. 이러한 표현들은 직접 써보기 전까지는 그 필요성을 체감하기 힘들지 않나 그런 생각이 드네요.

그래서 그러한 잘 쓰이는 숙어들을 최근에(도) 열심히 공부하고 있습니다. 사실 공부 시작한 지는 좀 됐는데 (거진 3~4달?), 아직도 끝을 못 맺었네요. 덕분에 개발 관련 공부는 계속 늦춰지고 있습니다. 아무래도 본업을 하기 어려워지는 요즈음입니다. ㅜㅜ