코드에 생각을 담자

 

 엘리스 수료가 끝나고 6개월이 지나서야 발견한 대감동의 피드백이다. 그리고 정확히 최근에 내가 하는 생각이기도 하다. 사실 개발을 시작할 때부터 당시까지는 늘 코치님이 계셨기 때문에, 빨리 코드를 보여주고 피드백을 받으려는 경향이 강했다. 1차에서는 API를 주고받는 웹을 이해했고, 2차에서는 리액트가 어떻게 굴러가는가를 이해했다. 3차에서는 내가 작성한 코드에 대해서 제안을 많이 받았기 때문에, 좀 더 편해지는 코드를 보는게 재미있었다. DDD에서 계속 느끼고 스트레스를 받았던 게 내 코드가 상대적으로 가벼워보인다는 거였다. 그때는 이게 어디서 오는 불편함인지 몰랐다. 그냥 코드에 대해 토론하는 다른 사람들이 신기할 뿐이었다. 그러다가 잠깐 있다가 해커톤을 나가면서 또 하나 프로젝트를 헤치우고, 회의감이 들었다. 코드를 어떻게 발전시켜야할지에 대한 감이 안잡혔다. 그래서 CS의 문제인가 싶어서 이론을 더 공부하는 방향을 잡고 있다가 클라우드 트랙에 참여했다. 나 포함 3명의 프론트엔드가 있었기 때문에 내가 맡은 페이지는 3개 뿐이었다. 분량이 엄청 크지 않아 마크업도 일주일이면 될거같고, api 연결도 마지막 일주일이면 될듯했기 때문에, 코치님도 계신 김에 디자인 패턴을 도입해봤다. 협업과 디자인 패턴이 같이 들어오니까 생각의 연속이었다. 컨벤션 맞추는건 물론이고, 상대방이 어떤 케이스에서 사용하는지 모르는 상태이기 때문에 다 생각하면서 컴포넌트를 구성해야했다. 처음에 모르고 그냥 작성해놔서 계속 케이스 추가하고, 리팩토링 했다. 검색바도 케이스가 너무 많아서 그걸 다 생각하는걸 어떻게 해야할지 모르겠어서 제일 마지막으로 미뤄났다. 결국에 검색바만 남았을 때 케이스를 다 종이에 적어가면서 케이스를 나눴다. 사실 좀 뇌가 멈춰버리니까 당황스러웠는데, 이 과정에서 다시 개발에 재미를 붙일 수 있었다. 뭔가 반복되는 CRUD, 아카이빙으로 매번 제자리 걸음하는 느낌이었는데, 이렇게 코드의 확장성과 리팩토링을 여러번 해보니까 다시 개발을 하는 기분이었다.

 

 운좋게 피드백이 있는 프로젝트를 다시하면서 느낀거지만, 수료기간동안 조금씩 피드백에 의존하는 경향을 키워왔던 것 같다. 누군가에게 의존하는 편이 전혀 아닌데도 피드백의 편안함에 익숙해졌다. 가장 최근 멘토링에서, 당신이 시작할 때는 아무것도 없는 상태였기 때문에 직접 구르면서 더 효과적으로 배워 지금 주니어들이 시니어를 원하는 현상이 좋지 않아보인다는 말씀을 하신 분이 계셨다. 처음에는 가이드라인과 피드백을 통해서 빠르게, 효율적으로 성장할 수 있는걸 바라는게 당연하지 않나는 생각을 했다. 마지막으로 공부한게 고등학생 때라, 인강 등이 익숙해서 더 그랬다. 피드백을 다시 받아보면서 이 편안함에 너무 익숙해져버렸다는게 느껴졌다. 혼자서 생각하고 재구성해나가면서 나아갈 방향을 잡아가야했는데, 이 생각하는 과정을 경시하는게 너무 익숙해져버렸다.

 

 아마도 수료가 끝난 6개월 동안 이러한 맥락을 혼자서도 느끼고 있었는데, 마주하니 더 확고해졌다. 그래서 요즘엔 같은 상황의 개발자들과 이야기하려고 시도하고 있다. FE닌자에서도 같은 입장에서 시니어 없이 리팩토링 할 점을 찾아나서는 모습, 새로운 지식을 갈구하는 모습을 옆에서 직접보니 뭔가 열정이 생겼다. 특히 혼자서 코드를 까보고 해석에 어려움을 겪을 때, 아무리 해석에 어려움을 겪어도 혼자서도 잘 해나갈 수 있다는 자신이 생겨서 만족스럽다. 그런데 생각보다 주변에 프론트엔드 개발자가 없다. 애초에 이런 경험들이 프론트엔드를 거의 혼자서 진행하다보니 더 그랬던 것 같기도 하다. 그래서 링크드인을 시작했는데, 링크드인에서 보이는 프론트엔드 개발자에게 모두 팔로우를 걸었더니 피드가 흥미로워졌다. 다른 사람들이 요즘 프론트엔드 개발에 대해서 하는 생각, 최근 트렌드, 그냥 사회생활에서 겪었던 이야기들을 공유하는 걸 보니 재미있었다. 물론 생각만 많고 다른 사람 앞에서 의견 공유 잘 못하는 나는 갈 길이 멀다. 그래도 나와 결이 비슷한 프론트엔드 개발자를 찾고 이야기하고 싶다.

코드 품질을 고려하지 않고 먼저 떠오르는 대로 코딩하면 처음에는 시간을 절약할 수 있다. 그러나 이런 코드는 머지않아 취약하고 복잡한 코드베이스로 귀결될 것이며, 점점 더 이해하기 어렵고 추론할 수 없는 코드가 된다. 새로운 기능을 추가하거나 버그를 수정하는 것이 점점 더 어려워지고 시간도 더 많이 걸리는데, 작동하지 않는 코드를 처리하고 재설계해야 하기 때문이다.
<좋은 코드, 나쁜코드>

 

그래서 요즘에는 코드를 작성하는 방법에 대한 책에 관심이 간다. 코드의 재사용성, 확장성을 열어두는 것에 대해 이해는 했지만, 사실 여전히 이 코드가 좋은 코드인가에 대한 의문은 크다. 기준이 없으니 판단을 할 수 없고, 그래서 시도의 연속이다. 예전에는 일단 많이 작성하고 많이 느끼면 다듬어질 거라고 생각했고, 배워가는 과정에서는 확실히 다듬어졌지만, 요즘에는 뭔가 빙빙 도는 느낌이 컸다. 그래서 책을 읽으면서 다른 사람들의 사고를 이해하고 있다. 솔직히 자바로 된 글도 많고, 책을 안 읽은지 오래라서 집중력도 쉽지 않은데, 읽으면서 내가 갖고 있는 잘못된 습관들을 인지하게 된다.

---

 그리고 이 블로그는 남들에게 보여주기 위한 내 기술 블로그가 아니다. 그냥 내가 성장하는 과정의 일기장이다. 내가 구현 속도가 빠른건 일단 직관으로 결론을 내리고, 해당 페이지와 컴포넌트를 구성하기 때문에 내 최선의 정답이 있는 상태에서 코드를 작성하기 때문이다. 생각이 없이 작성한다기보다는, 내 코드를 잘 믿어버려서 그대로 유지하는게 문제다. 그런데 어느 순간부터 돌아보니 어떠한 직관을 통해서 결론을 내렸는지 기억나지 않았다. 리팩토링을 해주려면 내가 어떤 부분에서 잘못 생각했는지를 알아야하는데 그 연결지점이 끊어져버리니까 처음에 생각한 그 코드로 짜고 있는 경우가 있었다. 그래서 티스토리로 옮기고 그냥 다 내 생각을 담아냈다. 그래서 이건 그냥 개발 일기장이다. 두서없고 기승전결도 없어도 글에서 주가 막 바뀌더라도, 이건 그냥 내 일기여서 어쩔 수 없다.