내용이 너무 훌륭해서 공유합니다.
7개의 좋아요
우선 제가 평소에 생각했던 내용이 담겨있어서 놀랬습니다.
저는 언제나 소프트웨어 개발에 대해서는
- 일단 되는지?
- 잘~! 되는지?
를 학생 때 멘토님께 배우고 받아들이고 지금까지 그런 마인드로 개발하는데요.
일단 되는지? 에 대한 영역은 코딩을 도입함으로서 이전보다 나은 ‘자동화를’ 구축했는지 입니다.
한땀한땀 시간들인 노가다가 아니라, 노가다를 코드를 도입함으로서 나름의 시간적 비용을 절감했는지 입니다.
잘~! 되는지? 에 대한 영역은 유지보수의 영역입니다. 내가 만든 코드가 대성하여 비지니스가 확장 됨에 따라 대규모 Request에 대해 병렬처리 로직을 지니고 있는지, 자주 수정이 발생하는 지점에 대해 추상화가 적용이 되어있는지에 대한 소프트웨어의 효율에 대한 관점입니다.
여기서 1번이 2번보다 우선시 되며, 1번은 개발자/비개발자도 모두 도달할 수 있는 영역이라고 생각합니다. 왜냐하면 2번의 전제인 비지니스의 흥망성쇄 가, 1번이 없다면 올 수 없는 미래이기 때문입니다.
따라서 누가 봐도 좋은 기술인 것들(클라우드나 여러 설계 패턴 etc)이 현재 기업의 상황(인력, 비지니스의 흥행 가망성, 매출액, 순이익, 연봉, 팀원 간 지적 능력 etc)과 맞는지 항상 따져봐야하며, 좋은게 절대 좋은게 아니라는 생각을 가지고 있습니다. 그게 정말 나, 우리한테 좋은건지는 따져봐야 알 수 있다고 생각합니다.
IT 글로벌 서비스를 하는 곳에선 인력도 많을테니 소통의 비용을 줄이기 위해 여러 시스템과 효율적인 부분을 고려할 것이고, 이용자가 적은 단기 SI성 프로젝트에 그런 것들을 적용할 필요는 없을 것입니다. 그래서 전 콘웨이 법칙 이라는 것이 제 생각을 정말 잘 표현했다고 생각했습니다.
또한 글의 맨 마지막에,
한 가지 주의해야 할 점은 목표로 삼아야 하는 것은 SOLID 원칙이 아니라 '가치’가 되어야 한다는 점입니다.
라는 부분도, 글쓴이와 저와 실력 차이를 떠나 의견이 일치했는데 기술자가 너무 기술에만 포커싱하면 안된다고 생각하기 때문입니다.
기술자가 본인의 커리어를 위해 여러 효율을 항상 계산하고, 유망한 기술을 자주 접해서 커리어를 쌓아야 한다는 것을 모르는 것은 아니지만,
혼자 일하는 게 아니고 회사에서 다양한 영역의 사람들과 일을 하려면 반드시 소통 능력이 필요하며, 소통할 때 기술자의 마인드로 접근하면 기술자가 아닌 사람들과 대화가 안된다는 점입니다.
중요한 것은 도메인이고, 팀이 바라보는 방향이라고 생각합니다.
방향이 곧 가치를 만들어 낸다고 생각합니다.
그래서 그 방향(관점)을 맞춰갈 때 현재의 상황(위에서 언급했던 것들)을 공동체가 인식하게 되고 현재 상황에 맞는 기술을 적용할 수 있다고 생각합니다.
4개의 좋아요