패턴은 시스템용인가, 아키텍쳐용인가, 모듈용인가 구분해서 썼으면 한다.

이 글은 정말 내가 주변 사람들에게 일일이 설명하기 귀찮아서 적어두는 썰이다.

모든 것을 제대로 예상한 설계 이 후 추가되는 요구사항 때문에 폴링을 써야 한다면 결국 타이머를 돌려야 한다. 타이머를 돌린다는 것은 스케쥴러는 만든다는 뜻. 즉, 스케쥴러와 큐가 필요한 시기가 온다.

작년 4월에는 facebook의 리액트로 프로젝트를 한다는 이야기를 들었는데 하드웨어 제어가 들어간다고 하길래 분명 망할거라고 했다. facebook 이 만드는 wrapping API 덩어리 프레임웍이 제대로 될리가 없다. 왜냐면 페이스북 폰이 망했었기에.

내 예상대로 수천만원의 비용을 쓰고 해당 프로젝트는 결국 망했다. 

작년 9월에 특정 프로젝트를 담당하면서 RxJAVA 고수가 RESTFUL API 와 BLE를 쓰기 때문에 Reactive 방식으로 하면 안되냐길래 리액트 기본은 스케쥴러와 큐인데 꼭 동시성을 그렇게 맞추지 않는다고 해도 콜백 지옥을 벗어날 수 있다고 했다. 그리고 별 어렵지 않게 프로젝트를 진행하였다. 그리고 최근 다른 프로젝트를 진행하는 스타트업 회사의 지인에게 리액트 쓰다가 소켓 통신이 들어가고 나서는 디버깅이 어려워졌다는 말을 들었다.

프레임웍에서 올라온 API wrapping 하는 것은 편리함만 있으면 된다. Alamofire나 Snapkit이 그렇다. 작년 리액트와 리액티브를 공부하면서 RxSwift 소스도 보게 되었는데 역시나 wrapping. 그런데 MVC 패턴이 아닌 나름이 패턴을 제창하는데 나는 그게 도저히 새로운 개념이라고 보기가 참 힘들었다. 그럴거면 iOS 프레임웍단을 새로 만들지... 하는 생각. 쿠팡과 같이 하드웨어 제어가 전혀 없는 프로젝트라면 모르겠는데. 하드웨어 제어, 혹은 3D 그래픽 기술이 들어가는 프로젝트에 적용하지 못하는 것을 마치 일반화가 가능한 패턴이라고 말하는 것 자체가...

그런 소스를 보다가 전수열씨의 프로젝트도 보게되고 그 중에는 국내 swift 개발자로 많은 스타를 받은 프로젝트도 있었는데. 그 중 하나가 then 이었다. 나 역시 snapkit 을 자주 쓰기 때문에 lazy var를 많이 쓰는 편인데 then을 쓰면 snippet이 먹지 않는다. snippet을 적용하려면 closure 파라미터에 s : UIButton 처럼 다시 또 써줘야 snippet이 먹는다. 한 단어만 더 들어가도 해당 프로젝트는 쓸 이유가 없어진다. 더군다나 다른 포스팅에서 밝혔듯이 내부적으로 한번 더 생성해서 return 하는 녀석은 attribute를 펑션 설정으로 뺄 수 있기 때문에 더 편리하다. 나는 여러 프로젝트를 하며 IB를 거의 안쓰기 때문에 모두 코드로 UI를 짜는데도 snippet이 안 먹히면 불편함을 느낀다. 그리고 Swift 특성상 클로저 파라미터에 상속을 먹일 수는 없는 제약이 있기 때문에 autocompletion을 할 수 도 없다. 내 동료들도 내 블로그를 보기 때문에 왜 내가 해당 프로젝트들을 안 쓰는지 일일이 변명하기 귀찮아서 이렇게 써 둔다. 그냥 위치만 가르쳐 주면 되니까.

그리고 새로운 언어나 개념이 나오면 다 거기 달라붙는 이유를 이번에 확실히 알 것 같았다. 최근 특정 회사를 옹호하는 개발자들 말처럼 뭘 더 해보라고는 안하겠다. OS 만들어 보고 firmware도 해보고 다양한 OS 환경에서 앱과 프레임웍도 만들어 보라고는 안하겠다. 그런 경험을 할 수 있거나 했던 사람중에 개발자로 계속 남아 있기도 힘드니까.

애플이 특정 개념을 만들었기에 무조건 신봉할 필요도 없고. 최대한 규칙을 지키며 프로그래밍 하다 대세가 되면 애플에서 밀어줄 수도 있겠으나. wrapping을 하면 할 수록 성능은 떨어지고. 수억이 사용하는 검증된 프레임웍을 수천명의 개발자가 쓴다고 해서 바꿔줄 수도 없다. 적어도 수십만은 되어야 바꿀 수 있다. 일반화는 그 정도로 어렵다. 리액티브 개념을 시스템, 아키텍쳐 수준으로 올리지 말았으면 좋겠다. 모듈 정도는 괜찮다.

시스템 설계는 패턴이 존재할 수 없다. 뭔가 예측하기 위한 최소 샘플링 개수도 얻을 수 없다. 삼성, LG, 애플, 중국폰의 SW 시스템에서 공통점을 뽑아내고 패턴화 해서 그것을 새로운 제품에 적용할 수 있을까? 불가능하다. 그럴 필요도 없다. 그 안에 속에 있는 수많은 기술이 업그레이드 되니가.

꿍하고 공개 안하는 개발자보다 뭔가를 공개해서 도움을 주고 논란거리를 만들어 주는 개발자가 더 좋다. 그러나 개발 방법은 천차만별이고, 우리가 계속해서 공부해야 할 것은 새로운 테크닉이 아니라 기초다. 공부할게 너무 많은데? 만약 따라가다보면 그게 틀렸다면 어쩔 것인가?

그만 써야 겠다.

결혼식 가서 마신 맥주가 기억나 맥주를 좀 마셨다. 술은 정말 좋은 친구인 것 같다.