첫 배포에서 배운 5가지 교훈

“이새씨 없었으면 이번 프로젝트 못했어요. 진짜 고생 많았어요.”

웹사이트 배포 후 첫 회식에서 들은 말이다. 시작부터 배포까지 처음으로 주도권을 가지고 진행한 웹사이트 론칭이었다. 이제 출시를 했고 앞으로도 수정 및 개선 사항이 많을 것이다. 그래도 처음으로 수만 명의 사람들이 들어와서 사용할 웹사이트를 만들었다는 사실이 못내 보람찼다.

많은 시간을 갈아 넣었다. 매일 야근, 매주 주말 작업에 밤을 꼬박 새워 가며 일을 하기도 했다. 이전 회사는 널럴해서 개발자가 일이 많다는 것에 공감하지 못했다. 배포를 한번 해보니 개발자 일이 많다는 것이 무슨 의미인지 이해가 됐다. 나의 잘못에서 오는 시간 낭비, 다른 사람의 잘못에서 오는 시간 낭비, 온갖 낭비를 뚫고 목표로 하는 프로덕트를 만들어 내야만 한다. 아직도 한참 모자라지만, 개발자 인생 첫 배포를 겪으면서 배운 점들을 정리하여 미래의 나와, 다른 햇병아리 개발자들에게 참고할만한 발자국을 남기고 싶어 이 글을 쓴다.

경험을 통해서 지식에 공감할수 있게 되었다

공부를 좋아하는 편이다. 남들이 이미 만들어 놓은 시행착오의 결과물을 섭취하는 게 효율적으로 느껴지기 때문이다. 공부를 통해서 지식을 알 수는 있다. 그러나 그 지식에 대해서 공감을 하기는 어렵다.

경험하면 지식에 대한 공감을 할 수 있다. 어떤 지식이든지, 그 지식이 생겨난 이유는 있다. 경험해 보면 이 지식이 왜 의미가 있는지에 대한 공감을 할 수 있다. 단순히 지식을 아는 것보다 훨씬 깊은 수준으로 지식을 활용할 수 있다.

오늘은 한 번쯤 들어본 이야기이지만, 제대로 실천하지 못해서 고생한 부분들에 관해서 이야기 하도록 하겠다.

1. 잘못 짠 코드의 문제는 고칠 때 발생한다

반복의 제거, 재사용하기 좋은 코드, 읽기 좋은 코드, 클린 코드, 변수화, 함수화, 컴포넌트화… 개발 공부를 하다 보면 반드시 듣게 되는 이야기다. 좋은 코드는 반복이 없고, 읽기 쉽고, 재사용하기 좋아야 한다.

좋은 말이고 취지를 이해하고 있다고 생각했다. 근데 당장 내 눈앞에 일정을 보고 있으면 저런 거 신경 안 쓰게 된다. 이거 빨리 끝내고 집에가서 유튜브 보다가 자고 싶다. 빨리 짜려 하다 보면 좋은 코드를 못 짜는 경우가 많다. 당장은 문제가 없다. 원하는 기능을 정확히 수행하는 코드니, 당장 문제가 될 게 없다.

그러나, 모든 것은 변한다는 진리는 개발에서도 적용 된다. 지금 만든 코드 분명히 바뀐다. 디자인이 바뀌거나, 기획이 바뀌거나, 다른 기능이 추가되거나… 이유는 다양하다, 하지만 단언컨데, 당신이 지금 짠 그 코드 나중에 다시 고치게 된다.

반복이 충분히 제거되지 않은 코드는 변화를 반영하기 어렵다. 바꿔야 하는 부분을 일일이 손으로 찾아가면서 바꿔 주어야 한다.

디자이너가 메인으로 활용하는 글씨 색을 바꿔야 할 것 같다고 한다. 지금까지 갈색을 썼지만, 검은색을 적용하는 게 더 맞는다는 판단을 했다고 한다. 해당 색을 사용한 엘리먼트의 개수만 적게 잡아도 400개다. 하나하나 색을 찾아다니면서 바꾸는데 족히 1개에 10초씩만 잡아도 1시간이 넘는 지루하고 재미없는 작업을 해야 한다. 실수로 400개를 다 처리하지 않고 390개 정도만 한 뒤 나중에 잘못을 발견할 수도 있다. 디자인이 다시 바뀌어서 다시 색을 바꿔야 한다면 생각만 해도 끔찍하다.

색을 $textcolormain 과 같은 변수에 저장해 두고 이변수를 계속해서 사용했다면 이 변수가 바라보고 있는 값을 바꾸면 된다. 10초도 안 걸릴 수도 있다. 변수에 저장하는 데 드는 시간을 넉넉잡아 5분이라고 쳐도 엄청나게 남는 장사라는 걸 알 수 있다. 실수로 놓치는 부분도 없다. 5분을 미리 투자해 놓으면 미래의 나는 50분 이상 더 편하다.

2. 작은 기능을 확실하게 수행하는 컴포넌트를 만들어야 한다

한편, 컴포넌트화를 잘못해서 오히려 손해를 보는 경우도 생긴다. 작은 일을 잘하는 컴포넌트를 만들어야 한다. 시간은 오래 걸리고 다시 반복해서 쓰기 어렵다.함수를 하나 만들었다. AJAX 요청을 보내고 response로 온 JSON 형식으로 만들고 만들어진 데이터를 내가 정의한 형태로 가공한 뒤 state에 저장해주는 함수였다.

처음에는 이런 함수를 만든 내가 뿌듯했다. 그러나 이 함수는 극도로 제한적인 경우에만 재활용이 가능했다. 특정 형태로 가공할 필요가 없거나 state에 저장할 필요가 없거나 하는 경우에 이 함수를 쓰기가 애매했다. 하나의 요청으로 3개의 state가 바뀌는 경우도 있었는데 이런 경우 하나의 state를 바꾸는 내가 만든 함수는 사용할 수 없었다.

함수를 만들어내고 적용하는데 들인 시간에 비해, 딱히 이 함수로 인한 효율을 만들어 내지 못했고, 이 함수를 3번도 체 사용하지 않고 다른 함수를 새로 만들어야 했다.

중복되는 기능이라고 해서 한꺼번에 함수로 만들면 재사용할 수 없다. 여러 개의 기능을 한꺼번에 다시 쓰게 되는 경우는 흔하지 않다. 가능한 한 작은 기능을 하는 코드를 만들고 그 코드를 엮어서 원하는 기능을 하도록 하는 편이 현명하다.

3. 개발 시간 산정은 당신이 생각하는 것의 2배를 말해라

누가 이 개발이 얼마나 걸리는지 묻거든, 당신의 예상에서 2배가 되는 시간을 말하는 편이 좋다. 나는 나의 개발 실력을 모른다.해보지 않았던 일이 얼마나 걸릴지에 대해서 예측하는 것은 어려운 일이다. 개발경력이 미천할 때, 직장에서 내가 수행하길 원하는 대부분의 작업은 내가 이전에 해본 적 없는 일일 가능성이 크다.

당신에게 이 일 얼마나 걸릴 것 같냐고 동료들이 물어볼 것이다. 당신은 해보지는 않았지만 어떻게 할 줄 알겠는 과업들을 바라보면서 이야기할 것이다. “이 정도면 2일이면 충분하죠.” 아니다. 당신이 해본 적 없는 일에 대해서는 일정을 일단 불려서 말하자.

나는 허세와 도전정신이 좀 있는 편이라서, 누가 물어보면 생각나는 대로 말했다. 능력 있는 사람으로 보이고 싶었다. 해보지는 않았지만 어떻게 할지는 감이 잡혀서 금방 할 줄 알았다. 아니었다. 해본 적 없는 일이라면 지금 생각하는 시간의 1.5배에서 2배는 부르자. 분명히, 단언하건대, 지금 상상하지 못하는 어떤 요인이 지금 해야 하는 일을 2배는 더 복잡하게 만들 거다.

position:fixed, bottom: 0을 주면 버튼이 윈도의 최하단에 항상 붙어 다닐 것만 같다. 쉽게 레이아웃을 구성할 수 있을 것 같다. 그런데 웬걸, 구현이 그렇게 되질 않는다. 도대체 뭐가 문제인지 이런저런 속성들을 넣고 빼본다. 그래도 문제는 해결이 안 된다. stack overflow의 바다를 헤매다가 문제를 발견한다. 부모 요소가 transform 요소를 가지고 있다면 자식 요소의 position : fixed는 absolute처럼 동작한다고 한다. 강의에서는 이런 걸 가르친 적이 없었다. 맨붕이다. 부모 요소에서 transform을 빼거나 버튼을 부모 요소 바깥으로 보내면서 기존의 기능은 동일하게 동작해야 한다. 기존의 코드를 고쳐서 버튼을 윈도의 하단에 고정했다. 갑자기 원래 잘 되던 부모 요소의 애니메이션이 먹통이다…….

공부하는 것이 아니라 실제로 뭔가를 만들기 시작하면 예상치 못한 사건들이 발생한다. 경험이 모자랄수록 이런 걸림돌을 예상하기 힘들다. 그러니 우리 같은 병아리 개발자들은 그냥 쪽팔리더라도 예상 시간의 2배를 부르자, 그러면 겨우겨우 그 일정을 소화 할 수 있게 될 것이다.

4. 읽기 좋은 코드가 좋은 코드다

기능적인 이유와는 별개로 사람이 읽기 좋은 논리 구조, 충분한 주석, 명시적인 변수명이 사용된 코드를 짜는 편이 좋다.

다른 사람과 일하던 혼자 일하던지 이건 중요한 일이다. 내가 만든 코드가 천 줄이 넘어가기 시작하면, 내가 그때 왜 이런 구조를 사용했는지 까먹는 경우가 빈번하게 발생한다. 이때 코드를 읽기 어렵게 짜 놓으면 과거의 코드를 수정하는 데 애를 먹는다.

이번 프로젝트에서는 내가 대부분의 프론트엔드 작업을 했다. 어차피 다시 이 코드를 보는 사람도 나일 확률이 굉장히 높았기에, 가독성 부분에서 별 고민 없이 코드를 작성했다. 그런데 프로젝트가 1달이 넘어가면서부터 문제가 생기기 시작했다.

컴포넌트 이름을 잘못 지어서 무슨 일을 하는 컴포넌트인지 명확하지 않았다. 만들 당시에는 아무런 문제가 없던 컴포넌트였지만, 1달쯤 지나서 찾아 고치려고 하니, 엉뚱한 컴포넌트의 코드를 고치고 있던 적이 있었다. 아무리 코드를 고쳐도 아무런 변화가 없어 속 터졌는데, 엉뚱한 부분을 고치고 있었으니 당연한 결과였다. 이로 인한 시간 및 정신력 낭비도 무시할 수 없을 만큼 발생했다.

5. 한번 할 때 잘 만들어 놓으면, 나중이 편하다

대충, 빨리하고 나서 마무리를 잘 다듬는다. 나는 대부분의 일을 이렇게 처리한다. 처음부터 잘하려고 하면 아무것도 못 하고 일의 진척이 없다. 경험상 일단 하고 나서 고치는 게 작업 시간을 더 줄여 주었다.

완벽주의에 사로잡혀 아무것도 못 하는 것보다는 훨씬 나은 접근 방식이지만, 처음에 너무 대충해 놓으면 나는 물론 주변 사람들까지 더 피곤해지는 경우가 나오는 듯하다.

초기 코드를 대충 짜면 먼저 말한 변화에 대응하기 어려운 코드를 짜게 되는 경우가 있다. 초기에 충분히 고민해 놓지 않으면, 미래의 내가 사용할 수 있는 시간을 상당히 빼앗기게 된다.

처음에 대충 구현한 기능들 중 나중에 다시 고치는 것을 까먹은 부분들이 많이 생기는 경우가 있다. 이렇게 되면 나의 시간뿐만 아니라 QA 하시는 분들의 시간까지 같이 소모되어서 비효율이 더 많이 증가하는 것 같다는 생각이다. PC 화면에서 모바일과 같은 폰트 크기를 썼다든지, 마진이 다르게 들어갔다든지 하는 사소한 문제를 계속 잡아내고 고치느라 후반부에 은근히 에너지가 많이 소모되었다.

완벽주의에 잡혀서 진도를 못 나가고 있는 것도 어리석지만, 초창기에 힘을 너무 덜 쏟는 것도 어리석다. 딱 기준을 정하기는 어려운 일이다. 경험을 통해 감을 키우는 수밖에 없다고 생각한다. 이번 경험이 감을 늘리는 데 도움이 되었길 바란다.

중요하다고 알고 있는 것과 중요하다고 느끼는 것은 천지 차이다

야식 먹고 양치 안 하고 자다가 치과 가서 100만 원 내고 이를 갈아 끼웠다. 어금니를 파내고 때우고 지지는 고통을 상상하면 아직도 몸서리쳐진다. 그 뒤로 나는 밤양치를 까먹은 적이 없고 치실도 하루에 1번씩은 한다.

양치 중요한 거 누가 모르는가? 치실하면 좋은지 누가 모르는가? 다 알지만 안 하는 거다. 100만 원 날리고 시간 날리고 아파보니, 진짜로 중요하다고 느껴지더라. 중요함을 피부로 느낀 후 별로 귀찮음 없이 매일 양치와 치실을 한다.

코드도 똑같다. 잘못 짜면서 고생을 해보아야 좋은 코드가 왜 좋은지 안다. (적어도 나는 그런 사람인가 보다) 들어서만 알고 있던 중요한 원칙들이 왜 중요한지 피부로 느꼈다. 처음 짤 때 잘 짜는 편이 훨씬 에너지가 덜 드는 방향으로 일할 수 있다는 걸 느꼈다. 그래서 앞으로는 더 좋은 코드를 짜려고 노력할 수 있을 것 같다.