2023 회고

회사 일 외에 특별히 한게 없는 해이고, 회사 일은 어디까지 말을 해도 되고 하면 안되는지가 너무 어려워서 4사분기에 머리를 스쳐지나갔던 이야기만 조금 써볼게요.

아무도 손대지 못하는 코드

‘개발자에게 물어보세요’라는 책을 읽었는데 책의 중반부에 비해 처음과 마지막이 재미있었다. 특히 개발자 수와 작성한 코드 그래프가 너무 공감이 되었다. 개발자를 늘린다고 코드를 많이 쓸 수 있는건 아니다. 난 여기에 더해서 개발자가 많을 수록 ‘아무도 손대지 못하는 코드’가 늘어나면서 오히려 코드가 점점 지저분해지지 않나 하는 생각을 한다. 팀원이 몇명 되지 않고, 코드도 그 인원이 관리할 수 있을 수준일 때는 모두가 모든 구조를 인지할 수 있다. 인지랑 따라가는거랑 좀 다르긴 한데, 그래도 다음에 변화가 필요할 때 어느 부분을 체크해야하는지는 알 수 있다는 이야기다. 그런데 그 숫자가 넘어가기 시작하면 분명 내가 수정해야 하는 코드인데 매번 너무나 새로운 코드들을 맞이하게 된다. 찬찬히 파악할 수 있다면 그나마 낫겠지만, 보통은 그만큼의 시간이 주어지지 않는다. 그럼 보통 어떻게 하게 되냐, if문에 else가 하나 늘어나거나 and 조건이 하나 늘어나거나 or 조건이 하나 늘어난다. 그렇게 점점 가짓수가 늘어나다가 아무도 손대지 못하는 코드만 남는다. 그나마 사람이라도 그대로 있으면 가능할 것을, 사람도 계속 바뀌면 정말 이유도 알지 못한 채 거기 있어야만 하는, 하지만 개선을 하기는 힘든 상태가 되는 것 같다. (대부분 이런 경우의 국룰은 문서도 테스트도 커밋메세지도 잘 없다.) //it's magic. don't touch 하는 개발자 주석 유머가 괜히 나온게 아니다. 이 지경이 되면 그냥 새로 짜는게 낫지 않나 싶은데 그것조차 쉽지 않은건 다시 그게 왜 존재하는지 모르니까 뭐부터 확인해야하는지 어디에서 확인해야 하는지도 명확하지 않다. 그건 그 코드가 현재 잘 돌아가는지 돌아가지 않는지랑은 완전 별개의 문제라서, 오히려 너무 잘 돌아가서 오랫동안 딱히 수정이 없었고 그 상태로 사람이 바뀌는 상황을 조직 차원에서 피하면 좋지 않을까 하는 생각을 했다. 일부러라도 시간을 떼서, 멀쩡히 돌아가고 있는 코드의 테스트를 추가할 수 있는 시간을 주고, 개선할 점이 있다면 개선할 수 있는 시간을 주고, 코드 분석을 통해서 발견한 리스크가 있다면 막을 수 있게 해주고. 그거 미리 해두면 개발자가 코드를 이해하고 있는 상태일 테니까 진짜 문제가 있거나 변경이 필요할 때 더 빠르게 할 수 있어서 장기적으로는 그렇게 시간이 더 들지도 않을 것 같은데. 이렇게 하는 조직이 있을까?

매직 넘버는 3

개발자는 반복된 작업을 싫어한다, 공통적인 부분은 인터페이스로 묶는다 같은 이야기를 책에서는 자주 하는데 완벽하게 내부 시스템에 관련된 부분은 그렇게 할 수 있겠지만, 외부와 맞닿고 현실 세계외 닿는 부분은 엔지니어가 설계 단계에서 변화할 부분을 예상한다는건 거의 오만에 가깝지 않나 하는 생각을 한다. 해당 도메인에 대해서 공부를 한다고 해도, 결국 그 도메인에 얽혀있는 다른 회사의 사양이란건 내 생각대로 오지 않을 수 있기 때문에 답이 아니었던 것 같다. 모든걸 예상하고 대비하는 것은 불가능하다. 그걸 추구하다가 오버 엔지니어링이 될 확률도 높다. 필요한 것은 사전 대비의 시간이 아니라, 변화가 있을 때 변화만큼만 덧붙이지 않고 근본적으로 검토할 수 있는 시간이다. 그리고 그게 가장 필요하고 중요한 순간은 0이 1이 되는 시간도 1이 2가 되는 시간도 아니고 2가 3이 되는 시간인 것 같다. 0이 1이 될 때는 예상할 수 없는 것이 많다. 1이 2가 될 때는 둘이 같은 점과 차이 점이 보인다. 그런데 2가 3이 될 때 비로소 공통점이 보이기 시작한다. 둘만 있을 때의 같은 점은 우연일 수도 있고 비지니스의 성격일 수도 있는데 셋까지 같다면 그건 후자에 가깝다고 가정해도 무리가 아닌 것 같다. 그리고 그 때 제대로 인터페이스를 만들든 enum을 다시 만들든 해서 묶고 리팩토링 하는 작업이 필요하다. 그걸 해 둬야 3이 4가 되고 5가 될 때, 123때 만큼의 시간이 들지 아니면 그거보다 적게 들지 결정이 된다. 관리도 어떻게 공통적으로 할지 생각해 볼 수 있다. 근데 이거도 마찬가지로, 최초 사업 검토 때는 시간을 충분히 들이곤 하지만, 3번째 즈음에서 ‘이거 저번에 한거니까 금방 할 수 있죠?’라고 하지 않고 충분히 검토하고 변경할 시간을 주는 회사가 있는지. (있으면 연락주세요.)

누가 무슨 일을 하는지 알 수 있는 시스템

이직하고 나서 오히려 Hierarchy 조직의 장점을 조금 느끼고 있다. 탑다운인건 변하지 않는데 어중간한 탑다운이고 조직원들이 계속 다니면 승진한다던가 하는 개념이 아니어서, 장기적으로 어떻게 운영할까에 대한 고민을 잘 하지 않는 것 같다. 새로 만드는 사람들은 만들기만 하고 실적 보여주고 떠나고, 남아있는 사람들만 꾸역꾸역 유지해야하고, 그런 사람들의 목소리는 위에 딱히 닿지 않는 것 같고. 무엇보다 새로운 일을 해야할 때 누가할지를 못정하는 것 같다. 모두가 ‘우리 팀 일 아닌데요’라고 한다. 그야 기존에는 아얘 없던거니까 그 누구의 일도 아니겠죠. 그럼 그냥 어떤 랜덤한 팀이 ‘어쩌다가’ 그 일을 시작하게 되는거다. 이게 쌓이다보니 누가 무슨 일을 하는지 알 수 없는 시스템이 탄생하는 것 같다. 모두가 같은걸 느끼고 있다고 생각함. 우리 서비스에 A란 기능이 있다는건 알아. 내 눈앞에 그걸 굴리기 위한 B라는 절차가 있어. 근데 그 B라는 절차가 돌아가게 만드는게 어딘지 알기가 너무 힘들고 그걸 물어볼데조차 없다. 최근에 같은 업체땜에 고생중인 회계팀 분이랑 만나서 커피타임을 했는데 직군이 달라도 회사에 대해 느끼는건 똑같더라고. 그래 무슨 일을 하는지만 다를 뿐이지 조직이 같은데 크게 다른걸 느낄리가. 작년부터 중고거래 슬랙에 자꾸 담당자 찾는 글이 올라와서 이거 여기에 올리는게 해결책이 아닌 것 같다고 생각하다 any_question 이라는 채널이 있는걸 발견하고 (200-300명밖에 없어서 죽어있는 채널이었지만) 혼자 중고거래 채널에 홍보하고 열심히 아는 선에서 답변도 달고 했더니 이제 1800명짜리에 질문도 답변도 제법 잘 달리는 채널이 되었다. 그리고 여기에서도 가장 많이 나오는 질문은 어떤 기능 담당자 알 수 있을지, 어떤거 문의해야 하는데 어디에 문의하면 되는지이다. 더 근본적으로 보기 편한 조직도 같은 것으로 (일단 워크데이의 조직도는 최악이다) 담당자를 찾기 편하게 하는건 한국식 대기업의 장점인 것 같다. 근데 다른 외국계라고 다 이렇게 하나? 아닐 것 같은데. 회사를 두군데밖에 안다녀봐서 모르겠다.

그래도 주석은 필요하다.

주석이 필요하다 아니다 온갖 글을 학생때부터 보곤 했는데 경력 두자리수를 찍기 전에 내가 내린 결론은 ‘주석은 필요하다’이다. 주석 없이 코드로 모든 내용을 설명할 수 있다는건 개발자의 오만이다. 전체 회원 리스트를 수행하면서 휴면회원 여부를 갱신한다 같은 예시 코드라면 메소드명만으로도 명확하게 할 수 있다. 현실에 가까운 코드일수록 코드로는 설명할 수가 없다. 이 필드가 A 벤더에는 필수고 B 벤더에는 필수가 아님을 어떻게 다 설명할 수 있을까? 그리고 어차피 어딘가에 설명을 써야 한다면 가장 좋은건 코드 자체에 주석으로 달아놓는 것과 커밋 메세지로 작성해두는 것이다. 위치적으로도 가장 가까우니 별도의 신경을 쓸 필요가 없을 뿐더러 코드는 어쩔 수 없이 현재 최신 상태를 유지해다 한다. 별도의 문서는 이게 최신인지 아닌지 찾아본 사람이 확신할 수 없는 순간이 분명히 온다. 별도의 문서가 보관된 그 장소는 어떻게 이동되다가 주소가 변경되고 하이퍼링크가 깨지고 할지 모르는 일이다. 어떻게 변할지 내가 예측할 수 없는 곳에 꼭 필요한 정보를 놓아두는건 좋은 생각은 아닌 것 같다. 문서도 코드에서 발생되게 해야한다. 그래야 지속적으로 업데이트 할 수 있다. 하나의 라인에 대한 설명, 하나의 함수에 대한 설명은 주석이 나은 것 같고 여러 파일에 걸쳐서 구조에 대한 내용은 커밋 메세지로 작성하는게 좋은 것 같다. 어차피 시간이 한정되어 있다면 코드 한줄 변경했을 때 바꿔야 하는 포인트를 너무 많은 곳에 만들지 말자.