4년 전에 적었던 글인데, 지금 봐도 별반 다를게 없어서 다시 적어봅니다.
가끔 slack을 복기한다. 이 채널에는 무슨 이야기가 오갔을까? 이 채널은 어떤 문제가 해결되었을까?
죽~ 보다보면 하나가 보이는데, 문제해결 커뮤니케이션을 slack으로 하는게 아니라 모든 사항에 대한 이야기를 모조리 다 같은 채널에 넣어두고 한다.
아마도 검색해도 못 찾을것이다.
1년 넘게 가고 있는 프로젝트의 1년전 이야기는 아무도 관심이 없을 것이다.
현재 프로젝트가 끝나는 것인지 아닌지만 관심있을 뿐 과거를 따져봐야 뭐하겠냐만은
웃긴건 1년전에 열심히 개발했던 준비사항들을 지금 안 쓰고 있는게 문제다.
트렌드가 바뀌어서 그런게 아니고,
설계 한 사람들이 나가고, 구축 했던 사람들이 나가고, 인원이 교체 되면서 교체된 인원이 좋은 방법으로 다시 구축하고 설계하고...
그러다보니 시스템이 달라져도 누구도 처음과 너무 달라졌다고 이야기 할 수가 없다.
사람은 계속 바뀔 테고, 단기간에 설명할 수 있는 시스템을 만든건 아닐테니 인수인계는 허울뿐이고.
아니면 이미 잘 갖춰진 시스템을 도입하자니 회사 규모에서 맞지 않는게 너무 많고, 인프라도 부족하고 그걸 운영할 사람도 부족하다.
이렇게 놓고 보니
개발자는 시스템 설계, 기획 분석, 인프라 구성/운영, 개발구조/라이브러리 선정, 패키지 관리, 배포 관리 , 등등을 다 해야하는 사람들인데, 전체 시스템을 놓고 해야하는데 개발자 별로 다 따로 하고 있다. 각자의 생각으로..
과연 개발자에게 저 많은 것들을 맡겨 놓는게 맞을까?
개발자가 생각하는 개발의 범위는 어디일까?
내가 저 일을 맡는다고 해서 잘 한다고 말할 수 있을까?
내가 해서 잘못된 설계의 책임을 누가 져야 하는가?
하다가 안되면 나가면 그만이긴 하지만, 솔직히 개발자는 시스템 설계를 하면 안된다고 생각한다.
사업을 어떻게 꾸려나갈지 알아야 한다.
그 안에 시스템이 어떻게 돌고, 어떤 상황이 생길지 예측을 해야하고, 그럴려면 직접 설계를 해야한다.
개발자가 다 할순 없다.
개발자는 개발을 하는 사람들이지 설계를 하는 사람들이 아니다.
이 부분이 개발자를 바보로 만드는 부분 아닌가 생각한다.
난 개발자니깐 시스템 설계도 잘 할 수 있어 하지만, 전체를 보는 눈이 없는 이상은 설계를 하면 안된다.
그러다가 당신이 나가 버리면 당신만 아는 설계는 남은 사람들의 목줄을 조일것이다.
보통 데이타 설계를 백엔드에서 하고 API 를 만드는데, 동시에 진행하게 되면 프런트에서 발생하는 문제점? 들에 대한 이슈들을, 프로젝트의 미래를 생각하지 않고 그 시점에 바로 고치게 된다.
데이타를 설계할 때 비용이 계속 올라간다.
그렇게 가다가 그 기능이 없어지기라도 하면 엄청난 비용을 그냥 버려야 한다.
백엔드 데이타 설계 이후 API 가 50% 정도 나오고 프런트가 들어가면 좋은데
이 때도 프런트는 백엔드를 연동하기 보다는 그냥 UI 작업만 하고 있는게 좋다.
그 이유는 API 50% 에 대한 완료 기준이 명확 하지 않기 때문이다.
각 모듈별로 50% 라는건 개별 모듈간에 연동이 완전히 이루어 지지 않은 상태이기 때문에
프런트가 들어가면 무조건 문제가 생긴 시스템에서 개발을 해야한다.
백엔드는 자기가 만든 API 를 시뮬레이션 할 수 있는 준비를 해야한다.
그렇지 않으면 프런트의 시간을 백엔드가 다 써버리는 아이러니한 상황이 계속 벌어진다.
백엔드의 문제를 해결하면 안된다.
백엔드는 어느 정도 시뮬레이션이 가능한 환경을 만들고 , 그 이후 데이타 검증을 해야하는데
이건 기획서(?) 를 놓고 처음부터 맞춰봐야 한다.
실제로 설계한 데이타와 화면에서 필요로 하는 데이타가 다를 수 있고, 이건 기획이랑 명확히 결론을 지어야 한다.
제발, 백엔드/프런트를 동시에 개발에 투입하지 말자.
개발은 인프라가 제대로 안되어 있으면 1시간이면 할일을 일주일 동안 해도 안 끝날 수 있다.
제발 인프라에 투자하자.