꿀벌개발일지

개발한 지 얼마 되지 않았을 때는 코드를 멋지게 짜는 것이 좋았습니다. 복잡한 로직을 짧게 줄이거나, 유행하는 패턴을 적용하면 왠지 더 뿌듯했습니다. 성능 차이가 크지도 않은데 괜히 비트 연산을 써서 있어보이게 만들기도 하고, 그냥 잘라서 비교하면 될 문자열을 굳이 정규식을 사용해 전후방 탐색까지 동원해가며 복잡하게 처리하기도 했습니다. 함수형 프로그래밍에 빠졌을 때에는, 함수에 함수를 넘기고 그 함수가 다른 함수를 호출하는 식의 코드를 짜기도 했고요. 디펜던시 인젝션이 멋있어 보일 때는 단순히 함수로 호출하면 될 코드를 여러 개의 객체로 감싸 추상화하기도 했습니다. 그때는 그런 코드들이 더 수준 높고 잘 만든 코드라고 생각했습니다. 배경지식이 있어야 이해할 수 있으니, 왠지 더 고급스럽게 느껴지기도 했고요. 아마도 ‘이것 봐, 나는 이런 것도 알고 있어!’ 하고 내보이고 싶은 마음도 있었던 것 같습니다. 그런데 시간이 지나면서 생각이 달라졌습니다. 처음엔 있어 보였던 코드들이 막상 수정하려고 하면 골치 아팠습니다. 한 눈에 이해되지 않아서 한참을 들여다봐야 했고, 결국 너무 어려워서 다시 작성한 경우도 많았습니다. 유행하는 패턴을 적용했던 코드들은 유행이 지나니 촌스럽게 보이기도 했고요. 그렇게 시행착오를 겪으며, 오래 고민하지 않아도 한 번에 읽고 이해할 수 있는 코드가 실용적이라는 걸 깨닫게 되었습니다. 예전에는 반복을 없애는 것이 깔끔한 코드라고 생각하기도 했습니다. 같은 코드가 두 번 이상 나오면 무조건 정리하는 것이 정석이라 믿었고, 반복되는 패턴을 찾아 추상화하는 것이 능력이라고 여겼습니다. 하지만 지나친 추상화는 오히려 코드를 읽게 어렵게 만들었습니다. 모듈이 지나치게 쪼개져있거나 여러 패턴이 겹쳐 있으면, 코드를 따라는 것조차 부담스러웠습니다. 이런 코드들은 고치는 것보다 새로 짜는 게 더 쉬울 때도 많았습니다. 지금은 직관적인 코드가 더 좋다고 생각합니다. 구조가 단순하거나 중복된 부분이 있더라도, 한 번에 보고 이해할 수 있는 코드가 더 낫습니다. 한 줄로 압축된 로직보다, 다소 장황하더라도 고치기 쉬운 코드가 더 실용적입니다. 누구나 쉽게 수정할 수 있는 코드라면 더 좋겠습니다. 코드는 혼자만 보는 것이 아니니까요. 설령 혼자만 본다고 하더라도, 몇 달 뒤의 나는 남과 다름없으니까요. 저 역시 쉽고 오래 유지할 수 있는 코드를 짤 수 있도록 더 고민하고 노력해야겠습니다.

일이 어렵다고 고민하는 후배들이 있었습니다. 어떤 친구는 이해가 되지 않아 답답하다고 했고, 또 어떤 친구는 시간이 촉박한데 원하는 결과가 나오지 않아 초조하다고 했습니다. 자신 있게 말할 수 있습니다. 걱정하지 않아도 된다고요. 물론 지금 당장은 힘들고 막막하겠지만, 처음엔 원래 다 어려운 법입니다. 이런 고민을 한다는 건 심리적으로 압박을 느끼고 있기 때문일 것입니다. 주어진 일을 잘 해내야 한다는 부담, 기대에 미치지 못할까 걱정하는 마음 때문일 수도 있습니다. 어쩌면 이미 만족스럽지 않은 평가를 받아들고 난 뒤일 수도 있고요. 처음엔 마음대로 되지 않는 게 당연합니다. 용어도 낯설고, 업무의 흐름이나 전체적인 그림도 잘 그려지지 않으니까요. 하지만 일이라는 건 하다 보면 익숙해지고, 시간이 지나면 자연스럽게 능숙해집니다. 지금 어려운 이유는 단순히 경험이 부족해서일 뿐입니다. 일을 맡긴 사람은 답답할 수도 있겠지만, 아마 그도 처음엔 비슷한 과정을 거쳤을 겁니다. 누구나 그랬을 거예요. 그러니 너무 조급해하지 말고, 마음을 조금 내려놔도 괜찮습니다. 지금 익숙하게 다루고 있는 것들이 처음엔 얼마나 어려웠는지 떠올려보세요. 처음에는 용어조차 이해하기 어려운 것들도 많았을 겁니다. 저는 개발을 처음 배울 때 ‘객체’라는 개념이 도무지 이해되지 않아 스스로 한심하게 느껴졌던 기억이 납니다. 자료구조가 너무 어렵게 느껴져서 개발이 적성에 맞지 않는다고 생각한 적도 있었습니다. 그런데 지금 돌이켜보면, 그때 왜 그렇게 어려웠을까 싶을 정도입니다. 그러니 지금 배우는 것이 어렵다고 해서 너무 위축될 필요는 없습니다. 지금 맡은 일이 유난히 어렵게 느껴지더라도 너무 걱정하지 마세요. 회사에서 나에게 맡겼다는 것은 해결할 수 있는 범주의 일이라는 뜻입니다. 팀에서 할당한 업무라면, 팀의 수준에서 충분히 해결할 수 있는 일이기도 하고요. 미지의 난제가 아닌 이상, 결국 해결 방법은 있을 것이고, 방법을 찾는 것도 경험이 쌓이면 익숙해집니다. 고민해 봐도 해결이 어렵거나 긴가민가하면, 너무 오래 붙잡고 있지 말고 주변에 물어보세요. 경험이 있는 사람들에게는 어려운 문제가 아닐 수도 있습니다. 도움을 요청한다고 해서 거절하는 동료는 많지 않습니다. 오히려 설명하는 과정에서 도와주는 사람도 배우게 되니, 부담 갖지 말고 편하게 질문하세요.

일이 지겨울 때가 있습니다. 평소엔 괜찮았는데 일이 지겨워졌다면, 그럴만한 이유가 있을 것입니다. 일이 너무 익숙해져서 쉬워졌거나, 같은 일을 반복하다보니 흥미가 떨어졌을 수 있습니다. 혹은 일의 목적이 공감되지 않거나, 이 일이 과연 의미가 있는지 의문이 들기 때문일 수도 있고요. 아니면 원치 않던 일을 맡게 되어서일지도 모르겠습니다. 어떤 이유에서든 이런 상황이 오면, 의욕이 사라지고 일도 하기 싫어집니다. 이럴 때 가장 확실한 방법은 더 도전적인 업무를 맡거나, 새로운 환경을 찾아보는 것입니다. 이참에 회사를 옮겨보는 것도 방법일 수 있고요. 하지만 이런 선택은 많은 에너지가 들고, 실행하기 쉽지 않습니다. 무엇보다, 지금의 지겨움이 단순히 스쳐가는 감정일 수도 있습니다. 한 가지 현실적인 방법은 ‘나’의 환경을 바꿔서 몰입할 수 있게 만들어 보는 것입니다. 일이 너무 쉬워서 지겹다면 난이도를 높여보고, 목적이 공감이 되지 않는다면 나만의 목표를 설정해보는 것입니다. 같은 일이지만 사이사이에 ‘작은 도전’들을 넣어보는 것입니다. 저도 그랬는데, 한 가지 일을 2년 정도 하다 보면 지겹다는 느낌이 들기 시작했습니다. 업무에 익숙해지면서 효율은 높아졌는데, 자연스럽게 흥미가 떨어지더라고요. 하지만 일은 계속해야 하니 나름대로 방법을 찾아보았습니다. 한 번은 개발 환경을 일부러 어렵게 만들어 보기로 했습니다. 익숙했던 IDE 대신, 평소에 배우려고 미뤄뒀던 VIM 에디터로 환경을 바꿨습니다. 낯선 환경에 일을 마무리하기까지는 좀 더 시간이 걸렸지만, 새로운 도전을 하다보니 일하는 시간은 오히려 재미있었습니다. 신기하게도 얼마 지나지 않아 지겨움이 사라져버리기도 했고요. 게다가 이 때의 경험으로 지금도 에디터에서 VIM 플러그인을 설정해서 쓰고 있습니다. 딱 봐도 지루하고 반복적인 업무를 맡을 때도 있었습니다. 이럴 땐 어떻게든 자동화 할 수 있는 방법을 찾아보려고 노력했습니다. 가끔은 좋은 해결책이 나오는데, 오히려 시간만 쓴 적도 많았습니다. 하지만 그 과정은 흥미로웠고, 새로운 기술을 익히는 경우도 있었습니다. 이렇게 하니 지겨웠던 일도 새로운 도전 과제의 연습 대상이 되더라고요.