개발자가 된 후 클린 코더를 다시 읽었다
1년 동안 내 생각은 얼마나 달라졌을까
지금으로부터 1년 전인 19년 11월에 클린 코더라는 책을 샀다. 당시에 나는 개발자로 전직을 하기 위해 코딩 교육을 받기 시작했을 때였는데, 개발과 관련된 책을 한 번 읽어보고 싶다는 마음에 책을 샀었다.
지금 생각해보면 원래 내가 사려고 생각했던 책은 '클린 코더'가 아니라 '클린 코드'였던 거 같다. 둘 다 밥 아저씨가 쓰긴 했지만, '클린 코드'는 말 그대로 좋은 코드를 쓰는 방식을 설명한 책이고, 내가 읽은 '클린 코더'는 좋은 코더, 개발자가 되는데 생각해보면 좋을 점을 담은 책이다. 근데 또 지금 드는 생각은 코딩을 겨우 쳐보기 시작한 시점에서 '클린 코드'를 읽었으면 더 많이 이해하지 못했을 것 같다. '클린 코더'도 잘 이해가 되지 않았었기에...
'클린 코더'는 잘 읽히는 책이다. 코드는 한 줄도 나오지 않고, 어떻게 보면 당연한 내용들이 나와있는 책이다. 사례가 담긴 코딩 도덕 교과서 같은 느낌이 좀 있다.
처음 책을 읽었을 때는 말 그대로 코딩을 거의 쳐보지 않았던, 입문생의 시점이었다. 다른 사람과 협업을 해본 경험이 거의 전무하고, 코드 다운 코드도 작성한 적이 없던 때였다. (코드 스테이츠라는 부트캠프에서 기초 수업만 들은 상태였다.)
그래서였는지 책을 읽기는 했지만 크게 공감이 간다거나 하지는 않았다. 마치 도덕 교과서처럼 당연히 모든 개발자들이 이 책에서 얘기하듯이 도덕적으로 코딩을 하고 있겠거니 생각하는 정도에 그쳤었다.
그런데 1년이라는 시간 동안 개발자가 되기 위해 준비하고, 또 개발자가 되어서 일을 해보니 책의 내용이 공감이 가고, 깨닫는 게 많아졌다. 이래서 책은 시간을 두고 여러 번 읽어야 한다고 하나보다.
그래서 지금부터 공감이 가고 깨달은 내용을 몇 자 적어보려고 한다.
아니라고 말하기
부트캠프에서 프로젝트를 할 때의 일이었다. 프로젝트에서 주어진 기간은 2주였고, 이 기간 안에 특정 서비스를 클론 하는 프로젝트를 진행하고 있었다.
프로젝트를 시작하는 날, 각자가 하고자 하는 개발 범위를 선택했고, 이에 맞춰서 개발을 진행해가고 있었다. 그런데 일주일이 지나는 시점이 되니, 메인 페이지와 로그인 UI를 담당한 분의 작업이 불안해 보이기 시작했다. 매일 스크럼 회의를 진행할 때는 작업이 거의 다 완료되었다고 했는데 정작 완료된 결과물을 볼 수가 없었다.
초반에는 로그인과 연결할 수 있는 API 가 나오지 않아서, UI 부분이 덜 완성되었다는 걸 인지하지 못했는데, API와 붙이는 시점이 되니 UI가 작업이 제대로 되지 않았다는 걸 깨닫게 되었다. 그럼에도 계속 다 끝낼 수 있다고 하셔서 작업을 맡겼으나, 결국 프로젝트 발표날에 로그인 기능과 메인 페이지는 보여줄 수 없게 되었다.
나중에 듣고 보니 API를 연결하기 전에는 UI 부분이 제대로 작동하는지 확인을 못한 상태에서 개발이 거의 다 되었다고 생각을 하였으나, 정작 API를 붙이려고 하니 작동하지 않아 말 그대로 멘붕 상태에 빠졌던 것 같다. 그럼에도 계속할 수 있다고 개발을 진행하였으나 결국에는 기능을 만들지 못하게 되었다.
특정 역할을 맡았는데 이를 책임지지 못한다는데서 오는 미안함과 겸연쩍음 등이 기한을 지키지 못하겠다는 말을 못 하게 만든 셈이다. 하지만 결과적으로 못한다는 말을 못 했기 때문에 프로젝트는 원하는 목적을 성취하지 못한 채 마무리할 수밖에 없었다.
못한다는 말을 말하는 게 어렵긴 하지만, 이로 인해 생긴 부정적인 상황을 타개해나가는 게 더 어렵다는 걸 생각하고 개발을 해야 할 것 같다.
이 일을 경험하고 난 뒤에 책을 읽고 나니 '아니라고 말하기'가 얼마나 중요한지 깨닫게 되었다. 그리고 나 조차도 상대방이 아니라고 말하지 못할 때, 좀 더 확인을 해서 프로젝트에 영향을 주는 일이 일어나지 않게 했어야 한다는 생각을 하게 되었다. 당시에는 내 코드를 작성하기 바빠서 깊게 생각하지 않고, '한다고 했으니 다 하겠지'라는 생각으로 프로젝트 기간을 허비했던 것 같다. 뭐가 그리 급했는지.
근데 이제는 마음가짐이 달라졌다. 나든 다른 사람이든 할 수 없는 일이라는 판단이 든다면, '안된다고' 말하고 같이 해결책을 찾아서 원하는 결과를 가져오도록 할 것이다.
명확하게 약속하기
책에서는 약속을 하는 행동이 아래와 같은 세 부분으로 나뉜다고 말했다.
1. 하겠다고 말한다.
2. 진심을 담는다.
3. 실제로 실행한다.
말 그대로 약속은 명확하게 해야 한다. 개발에서의 약속이란 '일정에 맞춰 어떠한 개발을 완료하겠다'라는 의미를 가진다. 하지만 보통 개발자뿐만이 아니라 일반 사람들은 약속을 할 때 좀 더 모호하게 하는 경향이 있다.
내일까지 해보도록 노력해볼게요 / 내일까지 할 수 있을 거예요 등
위와 같은 말은 약속이 아니라 책임을 회피하려는 돌려 말하기에 가깝다. 이는 화자와 청자에게 모두 해당되는 이야기다. 위의 말들에는 책에서 말했던 약속의 첫 번째 부분인 '하겠다고 말한다'가 들어있지 않다. '할 수 있을지도 모른다'라고 했지, '하겠다'라고 말하지 않았다. 정작 내일이 되어 완료하지 못해도, 나는 노력해보고, 할 수 있을지도 모른다고 했을 뿐, 하겠다고 말한 게 아니기 때문에 책임을 덜 수 있다고 생각한다.
청자도 이에 어느 정도 동조한 셈이다. 청자는 이 말을 들었을 때, 약속을 확실히 해 마감 기한을 지켰어야 했다.
이처럼 약속을 명확히 하지 않는다면, 나뿐만 아니라 팀 전체, 조직 전체에 문제를 끼칠 수 있다. 물론 약속을 명확히 하는 것도 중요하지만, 지킬 수 있는 약속을 하는 것도 중요하다. '약속을 명확히 했다 -> 책임 소재를 명확히 했다'로 끝나면 안 된다. 정해진 기한이 있다는 건 그 기한 내에 처리해야 할 문제가 있다는 이야기이고, 이 문제가 정해진 기한 내에 끝나야 조직이 정상적으로 동작한다.
그러자면 개발에 소요되는 일정을 되도록 정확히 산정해야 한다. 입사하고 정말 초기에는 개발 일정을 산정한다는 데에 대한 감이 전혀 없어서, 이 정도면 되겠지 하고 일정을 산정해서 보고했었다. 하지만 요건 분석이나 코드에 대한 검토가 되지 않은 상태에서 산정한 일정이었고, 개발을 하면 할수록 일정이 늘어났다.
중요한 기능을 담당했던 건 아니라서 문제는 없었지만, 정해진 일정을 미루는 행동 자체는 신뢰를 깎아먹는 일이다. 팀뿐만 아니라 사업부와의 신뢰도 깎아먹을 수 있다.
그래서 이제는 요건을 받으면, 스토리 보드를 보면서 사업부에서 원하는 정확한 요건을 파악하고, 코드를 분석한 후 가능한 지킬 수 있는 일정을 산정하려고 노력하고 있다.
코드에 집중하기
밥 아저씨는 지쳤을 때, 근심이 많을 때 등 코드에 집중할 수 없을 때는 개발을 하지 말라고 한다.
물론 그런 상황에서도 개발을 할 수는 있지만, 이때 작성한 코드가 이후에 나를 더 괴롭힐 수 있다. 코드를 효율적이고 효과적으로 짜기 위해서는 많은 생각을 해야 하고, 또 이 코드가 가져올 결과물들도 생각해야 하는데, 집중을 할 수 없고 다른 생각이 들어오면 충분한 개발을 위한 생각을 할 수가 없다.
어찌어찌 개발을 완료해도 개발하는 내내 잡생각이 많았다면, 어떤 생각으로 코드를 작성했는지 기억도 잘 나지 않고, 결과물도 좋지 않을 것이다.
이 부분은 개발할 때뿐만 아니라 모든 일에 해당하는 거라서 쉽게 쉽게 읽고 지나갔다.
TDD 작성하기
밥 아저씨가 TDD를 중요하게 생각해서 책의 많은 부분을 TDD 얘기에 할애했는데, 그중 이 부분이 가장 기억에 남는다.
TDD는 코드를 고치는 용기를 가질 수 있게 한다.
곱씹어봐도 맞는 말이다. 개발 범위가 작을 때는 크게 상관없지만, 이미 개발이 진행된 지 오래된 코드에 손을 대기란 쉬운 일이 아니다. 내가 만지고 있는 기능은 잘 작동해도, 다른 기능에도 영향을 미쳤는지 확인하는 건 가능은 하지만 시간이 오래 걸리는 일이다. 그러다 보니 기존 코드에 새로운 개선사항을 반영하려는 시도가 적어질 수밖에 없다.
하지만 TDD를 적용하고 있다면 이야기가 달라진다. 내가 특정 코드를 개선해도, 테스트만 돌려보면 기존에 작성된 코드들에 문제가 발생했는지 바로 알아낼 수 있다. 이는 코드의 점진적인 개선에 긍정적으로 작용한다.
아직 테스트 코드를 많이 작성해보지는 못했지만, 장기적으로는 TDD를 도입해서 코드의 질을 높일 수 있도록 해야겠다.
그래도 개발을 좀 배웠다고 1년 전보다 시야가 많이 넓어졌다. 첫 번째 읽을 때는 밥 아저씨가 왜 이런 것들이 중요하다고 말하는지 잘 이해하지 못했었는데, 다시 읽어보니 하나하나가 주옥같은 이야기들이었다.
또 1년이 지나고 책을 읽게 되면 더 많은 부분이 보이지 않을까 싶다.
다음엔 클린 코더 말고 클린 코드를 읽어야지.
