《뛰어난 습관을 배우세요》 디자이너는 개발자와 | 커리어리

《뛰어난 습관을 배우세요》 디자이너는 개발자와 협업하는 경우가 많습니다. 저는 개발자 분이 정리한 회의록을 보고 놀랄 때가 많았습니다. 시스템적인 글쓰기라고 해야할까요? 구조화된 글쓰기라고 해야할까요? 목적이 분명하고 군더더기 없는 회의록을 보면서 정갈하다고 생각했습니다. 일을 하면서 자신의 부캐로 개발 기록과 커리어에 대한 고민을 쓰는 개발자 블로그를 보면서 감탄할 때 저는 그 회의록이 떠오릅니다. 소개해드리는 김성호(shiren) 님의 글은 반복적인 하는 작업을 '루틴'으로 만들고 이를 빠르게 해내는 습관에 대한 이야기입니다. 저는 반복적으로 하는 작업이 있다면 가장 나에게 맞는 최적화된 루틴을 만들고 그 작업을 할 때마다 생각 없이 그대로 하는 편이에요. 정해진 루틴은 고집스럽게 유지하진 않고요. 경험에 따라 혹은 관련 지식이 늘어남에 따라 루틴을 조금씩 개선합니다. 루틴은 “현재 내가 이 일을 잘 하기 위해 알고 있는 위한 가장 나은 방법”이라고 할 수 있겠네요. 그리고 실행할 때는 이 생각 저 생각 할 필요 없이 그냥 실행합니다. 각 단계에 대한 생각만 하는 것이죠. 예를 들어 제가 사는 아파트는 매주 한 번 재활용 수거를 하는데 재활용을 할 때도 버릴 것들을 정리하는 순서가 있고 다 정리된 재활용 봉투를 손에 쥐는 순서와 방법이 있습니다. 루틴이라는 게 뭐 거창한 게 아니라 이렇게 가볍고 일상적인 것입니다. 이렇게 단순한 일에도 루틴이 있으니 당연히 개발을 할 때도 루틴이 있어요. 뭐 저만 있는 것처럼 말하고 있지만 여러분들도 의식적이던 무의식적이던 많을 루틴을 가지고 있을 거예요. 무의식적이고 원초적일수록 나쁜 버릇일 가능성이 크죠. 프로그래머로 일하기 시작하면서 초반에는 거의 무의식적으로 작은 루틴들을 만들고 업무를 진행했었어요. “일에는 순서가 있다”라는 말에 동조하는 편이었죠. 그러다 언젠가 켄트 백(Kent Beck) 형님의 짧은 문장을 만나게 됩니다. “make it work, make it right, make it fast” 어떻게 보면 TDD의 철학이 그대로 드러난 문장인데요. 이런 문장은 해석하기 나름이겠지만 당시 제가 실행하던 루틴과 비슷했어요. 이런 일 처리 방식이 나쁘진 않구나라고 생각했죠. 그래서 문장에 어울리게 루틴을 더 수정했어요. 루틴에 대해서 의식적으로 고민하고 진지하게 생각하고 루틴을 루틴이라고 부르기 시작했죠. 어느덧 거의 10년 정도 흘렀네요. 켄트백 형님의 문장을 나름대로 해석한 저의 루틴은 아래와 같습니다. ➊ 일단 동작하게 만듭니다 지금 해야 하는 작업이 이미 익숙한 작업이라면 이 단계의 일정 부분은 금방 넘어갈 수 있을 것 같아요. 학습 단계와 프로토타입 단계라고 볼 수 있는데요. 어쨌거나 개떡같은 코드라도 필요한 동작을 수행할 수 있도록 만드는 단계입니다. 익숙한 기술이라면 학습 단계는 넘어갈 수 있을 것이고요. 그렇지 않다면 크건 작건 R&D가 필요한 상황이죠. 필요한 것들을 공부하면서 내가 지금 해결하려는 요구 사항이 아무튼 충족되도록 코드를 작성합니다. 코드는 깔끔하지 않아도 돼요. 호기심으로 여러 가지 시도도 해볼 수 있고요. 내용에 따라 다르겠지만 TDD가 적용되는 상황이라면 이 과정에서 의미 있는 TC가 만들어져야 합니다. 결국 이 단계에선 TC만 유용하게 남을 수 있어요. TC가 유용하다는 건 프로토타입이나 실험을 통해 구조 안에서 모듈이 책임과 역할을 다할 수 있도록 모듈의 인터페이스 설계는 어느 정도 완성되었다는 말이고요. 상세 구현은 엉망진창이어도 상관없습니다. ➋ 옳게 만듭니다 첫 번째 단계에서는 학습하면서 이것저것 시도해보느라 배운 건 많지만 코드는 엉망일 수 있어요. 학습을 하면서 사용한 일부 코드들이 효율적이지 않아 이리저리 많이 돌아간 경우도 있을 것이고 불필요하거나 중복적인 코드가 있을 수 있어요. 그리고 동작에 필요한 코드만 구현한 나머지 굉장히 낙관적인 코드일겁니다. 실패의 가능성을 염두에 두지 않은 거죠. 예외케이스들을 점검해봐야 합니다. 지원하는 사용 환경들을 고려해야 하기도 하고요. 프런트엔드라면 크로스 브라우징 테스트가 필요할 수 있겠네요. 변경되거나 추가된 코드가 다른 영역이나 기능에 미칠 영향도 검토해봐야 할 필요도 있고요. 사이드 이펙트가 생기면 안 되니까요. 아무튼 현재 알려진(알고 있는) 가장 나은 방법을 이용해 실용 가능한 코드로 바꾸는 거죠. 두 번째 단계는 사실 리팩토링 단계라고 보면 될 것 같아요. 리팩토링은 만들어진 인터페이스와 TC를 믿고 모듈의 내부 코드에 온전히 집중하는 시간이에요. 인풋과 아웃풋은 최대한 유지한 채 코드를 개선하는 거죠. 하나의 모듈은 응집도를 높이기위해 혹은 더 나은 구조를 위해 분리될 수도 있구요. 그래서 내부에 숨겨져있던 기능도 별도의 역할과 책임을 갖는 모듈로 다시 태어날 수 있어요. 어찌 되었건 분리되면 테스트 케이스도 이동하거나 추가, 수정돼야합니다. 두 번째 단계까지오면 일단 작업은 완료되었다고 볼 수 있어요. 이제 PR을 만들고 코드리뷰를 요청할 수 있습니다. ➌ 더 나은 것으로 만듭니다 옳은 것과 나은 것은 다릅니다. 옳은 것 이상의 것이 나은 것이겠죠. 사실 제일 어려운 단계이고 익숙한 작업이라면 두 번째 단계에서 이미 해결될 수도 있어요. 바로 퍼포먼스 측면에서 병목을 찾거나 리소스를 더 적게 사용하게 만드는 단계입니다. 이 과정에서 일부 코드의 클린함이 퍼포먼스를 위해 희생될 수도 있고요. 이 세 번째 단계는 한 번으로 끝나지 않고 시간이 흘러 관련된 지식을 습득할수록 계속 추가 작업이 있을 수 있는 단계입니다. 더 나은 구현을 위해 다시 첫 번째 단계에서 다시 시작할 수도 있고요. 켄트 백 형님은 세 번째 단계를 “make it fast”라고 했지만 저는 그것 이상의 의미를 두는 단계입니다. 개인 지식 데이터 베이스에 배운 것을 정리합니다. 저는 데이원 이란 저널링 도구를 사용해서 깨닫거나 배운 것을 그냥 막 넣어요. 꼭 세 번째 단계에서가 아니라 개발 도중에도 막 넣죠. 이렇게 기록한 내용들로 글을 작성해서 공유를 하거나 가볍게는 동료들과 이야기해 볼 수 있는 화두로 사용할 수 있습니다. 더 나은 코드를 만들거나 더 나은 개발자가 되는 단계인 거죠. [ 큐레이터의 문장 🎒 ] "난 뛰어난 프로그래머가 아니에요. 단지 뛰어난 습관을 지닌 괜찮은 프로그래머일 뿐이에요" [ 함께 보면 좋은 콘텐츠 📮 ] Shiren, ⟪욕 안 먹는 개발자되기⟫ https://blog.shiren.dev/2021-04-20/

개발을 잘 하는 습관

Shiren

2021년 5월 18일 오전 9:35

댓글 1

주간 인기 TOP 10

지난주 커리어리에서 인기 있던 게시물이에요!

현직자들의 '진짜 인사이트'가 담긴 업계 주요 소식을 받아보세요.

커리어리 | 개발자를 위한 커리어 SNS