가끔 구글은 멀쩡하게 쓰는 서비스들이 중단된다…

솔직히 이거 좀 여러모로 열받는다.

https://www.blog.google/technology/safety-security/expediting-changes-google-plus/

구글이 구글 플러스랑 그 관련 링크를 없애고 서비스 중단하겠다는 내용이다. 워드프레스에 글 올리면서 알았다. 이 블로그 글은 규링의 구글 플러스에서도 확인할 수 있다. 그것도 뭐 올해 4월이면 중단되어서 싹 다 날아가겠지만….

뭐 회사 사정이니 어쩔 수 없다 해도… 여러모로 의존하던 서비스가 갑자기 중단한다거나 하는 것에 대해서는 별 생각도 없다가 이러면 보통은 열받는 거 아닌가…

게다가 구글을 서비스 개편하면서 이전 서비스 이용자들에게 에러를 한다발 안겨주는 꼴도 보이니깐 더더욱…(유튜브와 구글의 채팅 솔루션 쓰시던 분들 중에 좀 있을 것이다.)

나이지거나 이용자가 얼마 안되어서 없애거나 하는 거야 진짜 회사 사정이다. 이거에 토달고 싶진 않다. 내가 뭐 경영진도 아닌데…

그런데 이런 것들만 바라보다가 문제되는 그런 사람들…. 이런 것들만 보고 있다가 여러모로 문제 먹은 그런 사람들…. 그런 사람들 생각하면…. 걍 대신 열내고 싶을 뿐이다.

(잡소리다.)

광고

좀 더 쉽게 개발하기 위한 도구나 프레임워크들을 살짝 걷어내보면 결국은 정통적인 이론과 그 이해도로 통한다.

당연한 소리다. 근데 왜 이걸 이야기하냐고 묻는다면…

요즘 내가 좀 당한 게 있어서 그렇다. ㅠㅠ

현재 개발중인 응용 프로그램에는 이전 개발자가 개발한 걸 이어받았다. 그렇다보니 들어있는 프레임워크나 기술들 중에서도 여러모로 녹아있는 기술들이 있다. 그 중에서도 제일 회사 사람들을 골썩인 것이 바로 Prism이었다. WPF 하시는 분들은 잘 아실 것이다. 모듈화를 통한 유연화와 MVVM 패턴, CompositeView, Event Aggregator들을 이용하여 독립적인 컴포넌트들 간의 느슨한 결합들… 이것들을 강조하면서 철저하게 설계 중심의 어플리케이션 제작을 도와준다는 그 유명한 녀석…

결국 이것도 MVVM 디자인 패턴을 정착시키면서 동시에 추가적으로 Prism에서 제공하는 기능들을 사용하여 좀 더 쉽게 개발하기 위한 것이다.

근데 그렇게 좋은 의도대로 해서 좋게 짜여지면 좋은데….

설계에 대한 이해를 못해서 제대로 꼬으고 꼬으다 보니깐 코드가 느슨하지 않았다. 오히려 클래스간 엄청 타이트한 건 기본적인 것에 코드 비하인드를 위한 최소 5단계 이상의 상속, 테스트 불가능한 코드들, 재사용성 제로의 컴포넌트들, 컨트롤 속성에 대한 몰이해… 거기에 Prism documentation에 없으면 못하는 거라고 우겨대던 그 깡다구….

사실 앞에 지적한 부분은 Prism을 못사용한 것이 아니라 권장받은 MVVM 패턴에서 제일 일어나선 안되는 코드 유형을 다 모아놨다. 아무리 도움되는 코드 도큐먼트를 영어로 잘 읽어내고, 그리고 나서 적용해보니 오케이! 안되면 몰라! 이런 태도도 좀 그렇지만 이해도의 핵심은 Prism에 대한 이해가 아니었다.

그래서 좀 여러모로 코드를 스파게티로 하더라도 어느 정도 걷어내고 수정하고 덮어씌우고 갈아엎으면서 여러 요령을 피우면서 이전 개발자가 못한다 못한다 노래부르고 퇴사하면서 남긴 것들을 전부 다 구현해냈다. (그리고 프로그램 출시 얼마 안남았다. 글 쓰는 시점으로는 말이지..ㅇㅅㅇ)

난 WPF를 하면서 Prism을 대충 보기만 하고 무시했던 지라 솔직히 보면 좀 알겠지 하다가 전 개발자의 잘못된 코드를 보고 아우 썅 그랬었다. 그러다가 MVVM만 일단 좀 보고 싶어서 지금 취미로 만들고 있는 머드게임에 MVVM 설계를 이용한 방식을 적용해봤다. Prism? 안쓰고도 솔직히 할 수 있다. 요즘 MVC 패턴에 대해서 다들 잘 이애하고 하다보니 프레임워크 없이도 맨땅에 다 구현할 수 있듯, 패턴이기 때문에 패턴에서 필요한 요소만 구현할 수 있다면 맨땅에도 맞춰서 구현할 수 있다. 프레임워크는 그걸 그냥 도와주는 녀석일뿐….

이렇게 해보고 나니깐 전 개발자의 코드에 대해서 여러모로 잘못된 이론정보와 이해도가 여실히 보였다. 가뜩이나 다른 곳에 디자인 패턴을 잘못 쓴 것이 보였기 때문에 프로그램 전반적인 부분에 영향이 가는 패턴이 문제가 심각하다는 걸 보고는 좀 속이 많이 끓었다만…. 그건 내가 나중에 바로잡아가면 되는 거고….

이걸 통해서도 역시 전통적인 이론과 그 이해는 어디 가지 않는구나라는 생각을 엄청 하게 되었다. 하도 프레임워크들이 넘쳐나는 세상에 살다보니 그쪽에 휩쓸리는 신입 개발자들도 좀 많이 보고 하는데… 나중에 중요하게 남거나 실력으로써 남아나는 부분에 대해서는 변함없다는 걸 여러모로 느끼게 해줬다.

p.s. 그냥 한국에서처럼 만들어서 완성만 하면 되는 것에서 좀 더 늦춰가다보니 이런 것들도 생각을 좀 해보게 되네…

노트북 C: SSD를 압축해봤습니다.

여러 일이 있긴 했는데… 일단 이 먼 미국땅에서 이용하는 노트북의 SSD가 용량에 허덕이고 있더군요…ㅠㅠ

그래서 여러모로 알아보니 SSD를 압축해서 이용하는 내용이 공유되어 있어서 한번 읽어봤습니다. 사실 드라이브 압축은 진짜 용량만 필요한 경우에나 이용하는 거 아닌가 싶었는데…

일단 검색하다 보니 저 위에 글들을 먼저 읽어보고 나서 든 생각이 ‘에라, 걍 해보자.’ 라고 해서 해봤습니다.

압축 전 이미지…
압축 후 이미지…

일단 용량은 늘었습니다. 그리고 성능은 전 아직 느려졌다고는 체감 못하겠군요. 드라이브에 들어있는 파일들도 그냥 윈도우랑 개발 프로그램들이 전부였고…. 놋북으로 게임도 안하고 있고 요즘…

참고로 들고있는 놋북은 i3에 램 12기가인 녀석입니다. 이녀석으로도 별 차이 못느끼겠다면 진짜 라이트한 유저들은 차이 모를꺼란 거죠.

의외로 좋은 정보 알았다고 해서 일단 적용은 해봤는데… 이걸로 문제 생긴 일은 아직 없습니다. 부팅도 문제 없이 잘 되고.. 윈도우 부트로더하고는 상관 없이 이용할 수 있어서 그런 걸지도 모르려나….

일단 용량으로 고민하시는 분들은 쓰시는 것도 나쁘지 않다고 보여집니다. ㅇㅂㅇ