성장에 은탄환은 없다

첫 회사에 입사하기 전부터 ‘같이 성장할 수 있는 회사’를 찾고 싶었고, 내 목표는 개발자로서 ‘멈추지 않고 성장하는 것’이다. 작년에 이 주제로 많이 고민했었고 그 내용을 발표에서 공유하기도 했었다. 지금 다시 생각해본 성장에 ‘은탄환’은 없고 매번 많은 고민을 통해 이뤄진다고 생각한다. 그 내용을 짧게 정리해 보려 한다.

정의

‘성장’이라는 단어는 사전적으로 규모가 점점 커진다는 뜻이다. 그럼 개발자의 성장은 무엇일까? 새로운 기능을 구현 하는 데에 막힘 없이 한 번에 개발할 수 있는 것? CS지식이 탄탄하여 누군가 질문했을 때 막힘없이 대답할 수 있는 것? 저마다의 정의는 조금씩 다르다. 중요한 것은 ‘내가 생각하는 성장 단계’가 무엇인지 나만의 관점을 가지는 것이라고 생각한다.

나는 이 기준을 이렇게 정의했다.

새로운 기능을 잘 구현하지 못해도 괜찮다. 지식과 방법은 구글링을 통해 얻을 수도 있고 옆자리 동료에게 물어보면 10분 만에 답이 나오기도 한다. 그렇기 때문에 ‘아는지 모르는지’라는 기준이 성장의 척도가 되기에는 부족하다고 생각한다.

물론, 경험으로 축적되는 지식과 노하우는 성장이라고 할 수 있겠다. 하지만, 주니어 개발자 관점에서 ‘무엇을 모른다’라고 해서 그 사람이 성장하지 못하는 주니어는 아닌 것 같다는 이야기이다.

나의 관점

개발자에게 ‘나의 관점’은 무엇일까? 프로젝트를 하다 보면 만날 수 있는 여러 가지 상황에 대해 ‘내가 좋다고 생각하는 것’을 자신있게 말할 수 있는 것이라고 생각한다.

좋은 폴더링은 무엇인지, 유지보수가 쉬운 프로젝트는 어떤 요소들을 갖추어야 하는지, common 혹은 util 이라는 이름으로 정의하는 요소들은 어떤 상황에 사용되어야 하는지 등에 대해 고민하고 나만의 관점을 가지는 것이다.

프로젝트만 한다고 성장하지 않는다

‘나의 관점’을 많이 만들 수 있는 상황중 하나는 새로운 프로젝트를 시작할 때이다. 하지만, 많은 프로젝트를 한다고 해서 반드시 성장할 수 있는 건 아니다.

중요한 것은 그 프로젝트를 할 때 얼만큼의 고민을 했는가? 이다. 최근 새로운 프로젝트에서 다음과 같은 고민을 했었다.

다른 사람이 쉽게 프로젝트를 파악하려면 어떤 것들이 필요할까

나름 도메인이 어려운 프로젝트를 진행했다. 처음 듣는 용어도 많았고, 복잡하게 처리되어야 하는 조건처리가 많았다. 이 프로젝트에서 가장 중요한 것은 ‘다른 사람이 쉽게 파악할 수 있도록’하는 것이라고 생각했다. 약간의 중복이 생긴다 해도 읽기 쉽다면 그렇게 진행하려고 했다.

아래는 내가 고민했던 몇 가지 요소들이다.

top-level directory의 의미

가장 첫 depth폴더는 프로젝트를 파악하는 첫 시작점이므로 조금이라도 의미 없다고 생각되는 폴더링은 지양했다. 유의미하게 폴더를 나누는 것만큼 중요한 것은 남용하지 않는 것이다.

프로젝트를 관통하는 규칙들

새로운 사람이 쉽게 파악하기 위해서는 프로젝트 전체에 ‘쉬우면서도 깨지지 않을 규칙’이 있어야 한다. 하나의 컴포넌트라고 할지라도, 어디에 위치해야 하는지, 합성을 통해 구현할지 props를 통해 구현할지 등을 많이 고민했다. 이 외에도 폴더와 파일명에 일관된 규칙을 어떻게 정의할지, 도메인을 아는 영역과 그렇지 않은 영역을 어떻게 분리해야 유지보수 가능하고 다른 사람에게 쉽게 읽힐지 등을 고민했다.

공통이란 무엇인가

많은 시간 이 문장으로 고민했었다. 이 프로젝트는 하나의 서비스만 관리하는 프로젝트였는데, 이미 도메인이 분리된 상황에서 공통요소가 무엇일지 많이 고민했었다.

‘컴포넌트의 재사용성은 중요하다.‘라는 문장에 사로잡혀 매번 ‘이 컴포넌트가 재사용 되려면 어떻게 해야 할까?‘라는 생각을 했었는데, 결국 이 고민의 결론은 ‘이 프로젝트에서 컴포넌트를 재사용할 일은 그렇게 많지 않다.‘였다. 좋은 코드보다는 중복이 조금 생기더라도 읽기 쉬운 구조와 코드를 지향했다.

그 결과, Alert과 Dimmed 등의 Wrapper와 Text Style 등을 결정하는 요소 등만 공통 컴포넌트로 바라보았다.

변화에 유연하게 대응하는 방법

앞선 단락에서 중복보다도 중요한 것은 읽기 쉬운 코드라고 했지만, 중복되는 요소 또한 프로젝트 파악에 좋지 않을 수 있다. 예를 들어, 기존의 List에서 디자인이 조금 변경된 새로운 스펙을 대응할 때 기존 컴포넌트를 재활용하지 못한다면, 좋은 컴포넌트라고 생각하지 않기 때문이다.

그래서 props의 개수는 줄이고, 많은 부분을 children을 통한 합성으로 처리했다. 큰 object를 받거나 많은 props를 넘겨줄 경우 상위 컴포넌트에서는 코드가 짧아져 읽기 편할 수 있지만, 해당 컴포넌트는 재활용되기 힘들 수 있다.

모든 요소에서 이런 점들을 고려한 것은 아니다. 앞선 예시처럼 List, Card 등의 컴포넌트는 디자인이 빈번하게 수정될 수 있는 영역이라고 생각했기 때문에 특히 이런 부분을 많이 신경썼다.

프로젝트 구조에 구체적인 내용은 기회가 된다면 별도의 글로 다루어 보고자 한다. 새로운 프로젝트에서 이런 고민을 할 수 있어 즐거웠다. 프로젝트 초반에는 코딩하는 시간보다 아이패드에 무언갈 적는 시간이 2배 이상 길었던 것 같다. 중요한 것은 무엇을 하느냐보다, 그것을 어떤 방법으로 할 것인가라고 생각한다.

넘어가지 않는 것

개발에는 공부할 것이 정말 많다. 여러 가지 CS 지식도 공부해야하고, JavaScript를 공부한다! 라고 하면 아마 6개월 이상 이 언어를 이해하는데 에만 시간이 소요될 수도 있다. 하지만 나는 이런 지식을 아는지 여부가 중요하다고 생각하지 않는다. (물론 알고리즘도)

지식이 왜, 언제, 어떻게 쓰이는지 아는 것이 중요하다고 생각한다. ‘필요할 것 같아서’가 아니라 이 상황을 해결하는 데에 부족했던 지식을 채우기 위해 공부하는 것이 나에겐 공부 동기가 되었다.

예를 들어, 장애가 발생했는데 그 장애의 원인이 내가 모르는 분야였다면 그 지식은 그때부터 ‘나에게 꼭 필요한 지식’이 된다. 미리 알고 있어서 빠르게 대응할 수 있었다면 더 좋겠지만, 책이나 블로그를 한 번 읽었다고 해서 내 지식이 되는 것은 아니기에 쉽게 기억나지 않을 수도 있다.

장애뿐만 아니라 개발 상황에서 해결하기 어려웠던 버그를 만났다면, 긴 시간 삽질했던 이유가 어떤 지식의 부족 때문은 아니었는지 한 번쯤 되돌아보자.

이럴 때 넘어가지 않는 것만으로도 많은 공부가 될 수 있다고 생각한다.

목표는 크게, 자세는 겸손하게

현재 회사 CTO님께서 해주신 말씀이 있다.

“그러니까 다 해야 된다.”

나는 궁극적으로 “모두 하는 개발자”가 되고 싶다. 정확히는, 우선 웹 서비스와 관련된 모든 부분을 공부해 보고 싶다.

최근까지 웹 프론트엔드 개발자로서 해야 하는 일과 다른 분야에 요청해서 해결해야 하는 일을 명확히 구분하려고 했었다. 하지만 지금은 ‘웹 서비스 개발자’가 되고 싶다는 목표로, 서비스에 필요한 모든 요소를 가능한 많이 직접 컨트롤하고 싶다. 내가 만든 화면이, 유저 경험이, 인터랙션이 어떻게 유저에게 전달되는지 그 전반을 컨트롤 할 수 있는 개발자가 되고 싶다.

지금 다니고 있는 회사에서 가장 감사한 부분 중 하나이다. 웹 서비스 배포와 관련된 부분을 직접 IaC로 관리하고, 더 궁금하거나 불안한 점이 있다면 관련 분야 누구에게나 코드 리뷰를 요청할 수 있다. 프론트엔드 개발자로서 화면을 넘어 많은 부분을 직접 책임질 수 있는 경험은 많은 공부와 자극이 되었다. 기회가 된다면, 꼭 IaC형태가 아니더라도 내가 만든 서비스가 어떻게 배포되고 운영되는지 알아보는 것을 추천하고 싶다.

그리고, 항상 겸손해야 한다. “세상은 넓고 괴수는 많다.”라는 말처럼 내가 아직 공부하지 못한 분야가 많다. ‘전방위적인 성장’을 도모하고 싶다고 했지만, 프론트엔드 분야에도 내가 아는 부분 보다 알지 못하는 부분이 많다. 그래서 동료나 주변 개발자의 질문을 가볍게 여겨서는 안 된다고 생각한다.

내가 알고 있는(혹은 알고 있다고 착각하는) 분야 일지라도, 얼마 전까지는 모르는 분야였을 수 있으며 심지어 잘못 알고 있을 수도 있다. 멍청한 질문은 없으며, 오히려 그 질문에 답변하는 시간을 통해 한 번 더 정리할 수 있는 시간을 가질 수 있다. 이 기회를 무시하거나 가볍게 여겨서 지나치지 않으려고 한다.

정리

구구절절 여러 가지 이야기를 한 것 같은데, 나에게 ‘성장’이라는 단어가 무겁고 어렵게 느껴졌기 때문이다. 모든 것에 정답이 있지 않듯, 이 글도 지금 시점에서 고민했던 내용의 결론일 뿐이다.

예전에는 ‘좋은 코드를 짜는 개발자’가 되고 싶었다면, 이제는 ‘옆자리 좋은 동료’가 되고 싶다는 새로운 목표도 생겼다. 새로운 키워드에 대해 치열하게 고민해 보고 결론이 생길 때쯤 새로운 글을 쓸 것 같다.