Google Adsense Side (160x600)



Universal Windows Platform 망할 만 합니다.

윈도 버전은 외주를 주고 있었는데, 아무래도 외주 인원의 작업이 관리가 안되다보니 어떻게 해 놓았는지 한번 보자(이 친구 꿀빠는 일이었을텐데 조금 미안함)...라는 생각과 더불어 13년 넘게 계속 애플쪽(+가끔 안드로이드) 개발을 위주로 해 왔더니 정체된 느낌이 너무 들어서 색다른 경험을 하기 위해 프로젝트를 내부로 가져오게 되었는데, 우선 윈도 머신 지급을 받았습니다.

이하는 13년만에 업무를 위해 쓰게 된 윈도에 대한 느낌인데(i7 10세대+터치 스크린 장착된 HP 비지니스 랩탑 모델)...

  1. 트랙패드는 장족의 발전. 그러나...아래 언급할 HiDPI 문제로 불편해서 결국은 마우스를 하나 회사 비용으로 샀습니다.
  2. 전화기로 안드로이드를 쓴다면 좀 더 연결성이 좋을 듯 하지만, 안드로이드를 안씁니다.
  3. 느린 와이파이 속도: 스팩상으로는 Wi-Fi6인데 이상하게 느립니다. 추측은 집에서 매시 라우터를 쓰는데, 가까운 세틀라이트 쪽이 아닌 먼 메인기기에 자꾸 붙으려는 것 같습니다. (가까운 세틀라이트에서 1m도 안떨어져 있는데 신호 강도가 떨어지게 나오고 강제로 끊었다 연결하면 올라감)
  4. HiDPI 문제: 이게 일반적인 경우는 괜찮을지 몰라도 모니터를 2개 이상 쓰는데 DPI설정이 다르면 여전히 문제가 있습니다. 창을 모니터 사이에 옮길 때 떨그럭거린다는 느낌으로 부드럽지 않게 동작합니다(마우스 이벤트가 끊기는 듯). 그리고 내부적으로 더 적은 정보를 필요 이상으로 더 큰 이미지로 렌더링하게 되거나 하는 문제점이 있더군요.
  5. 성능: 특히 다수의 파일을 복사/이동/삭제할 때 준비 작업이 굉장히 느립니다.
  6. 각종 마이크로소프트 서비스/앱과의 문제: 의외인데...원드라이브 동기화 중에 에러가 나거나 해서 삭제 불가능이 되는 오류에 걸려서 아직도 일부 찌꺼기를 못지우고 있고(검색해 보니 레지스트리 등등 복잡한 작업을 요구해서 그냥 둠), 이상하게도 아웃룩에서 계정 추가가 안됩니다. 맥, 안드로이드, 아이폰, 아이패드 다 간단히 되는데 자기집(?)인 윈도10에서 안되는 건 이해 불가능. 에러 메시지(관리자에게 문의하시오 따위)도 하등 도움이 안됩니다. 뭐 찾아보면 해결책이 나오겠지만 찾기도 귀찮고(딴 플랫폼은 되니까)...

결론은 주 업무용으로는 계속 익숙해진 맥을 쓰는게 시간 낭비가 덜 하겠다는 것. 의외로 키보드는 금세 적응하지만 반대로 맥에 와서도 윈도식 키보드를 쓰려 하는 상황이 조금 발생합니다.


다음은 프로젝트 그 자체인데...

참고로 해당 프로젝트는 코드는 별로 크지 않고, 대신에 자잘한 리소스 파일들(세어보니 약 7500여개)이 많이 있습니다. 다른 플랫폼은 이것들이 한 파일로 묶여있는데, 유독 인도받은 윈도 버전의 구현은 그걸 개별 파일로 풀어놓게 구현을 해 놓았습니다. 아마도 파일로 접근하는 API들이 더 쓰기가 편해서 그런 것 같습니다. 아무튼 외부 인원 일을 짤라버리고 맡겠다고 했으니 해야겠죠. 그리고 저는...

왜 Universal Windows Platform(이하 UWP)이 시장에서 제대로 안돌아가는지 이해하게 되었습니다.

사실 이론적으로는 좋아요. 하나의 코드로 '굴지의 점유율'을 자랑하는 모든 윈도 플랫폼(엑스박스 포함)을 커버하는 앱 개발이 가능! 선진적인 앱 개발 구조! 등등 '이론적'으로는 말이죠. 일단 앱 구조는 잘 디자인되어 있다고 생각됩니다. C#으로 된 프로젝트를 인계받았는데 C#의 좋은 기능들을 보게 되었고...하지만, 큰 함정들이 도사리고 있었습니다.



Visual Studio(이하 VS) 2019의 괴이한 점

야...진지하게 써 본것은 VS6(화석인가?)였으니 이게 얼마만인가...Xcode 3 따위와는 비교도 불허하는 최고의 툴이었는데...라는 생각은 금세 사라지게 됩니다. 처음 문제는 위에 나온 무식하게 많은 리소스 파일을 임포트 하는 과정이었는데, 그냥 7500개 선택해서 드래그하면 툴 자체가 프리징되며 망합니다. 이전 리소스 파일(수백개?)을 지울 때도 파일을 선택해서 지우면 똑같이 망합니다. 상위 '폴더'를 지우고 새로 만들어야 그나마 할만합니다. 파일 처리를 UI 스레드에서 돌리는지 일단 처리 과정에 진입하면 아무것도 할 수 없습니다. 폴더 자체를 링크하는 방법은 일단 IDE상에서는 찾을 수 없었습니다. 하지만 .vsproj 파일을 직접 수정하면 폴더 자체를 링크하는 것이 가능해서 이 문제는 해결했습니다. 왜 이게 IDE엔 없죠? 

오류 사전 차단이 가능할 것 같은데도 안해줘서 시간낭비

2020년에 아이콘 같은 이미지 사이즈에 제한을 걸어 둔 것은 대체? 더구나 그 사이즈 제한이 매우 빡빡합니다. 
외부 툴이 아니라 (iOS용은 그냥 만들어 씀) VS2019 자체에서 리사이징 툴을 제공하는 것 자체는 좋았습니다만, 그 작업은 아무 에러 없이 해 놓고 '패키징 마지막 순간'에 가서 이미지 파일 사이즈가 너무 커서 안됨! 이렇게 뜹니다. 이후 언급할 느린 개발 프로세스와 맞물려 엿을 제대로 먹여줍니다. 이 부분 개발자와 패키징 부분 사이에서 의사소통이 없었나? 싶습니다. 빡빡한 사이즈 제한 왜 걸어둔거죠?

클린 빌드? 그냥 수동으로 지워야 안전

빌드나 패키징시 알 수 없는 에러가 잘 납니다. 찾아보니 그런 경우 obj폴더를 수동으로 지우랍니다. 그 폴더의 파일 개수는...윈도의 파일 지우기 사전 작업으로 인해 한참을 멍때려야 됩니다. (그리고 이 폴더가 바로 원드라이브에서 에러가 난 폴더)



미치게 느린 개발 프로세스

처음 빌드 시도시 에러가 난 줄 알았는데, 사실은 이게 그냥 오래 걸리는 것이었습니다. 오래 걸리는 작업도 별다른 아웃풋 메시지가 없이 진행되는 구간이 많아서 이게 잘 돌아가는 건지 에러난건지 잘 모르겠었고, 그냥 실행(Run)해도 윈도 앱의 구조상 아마도 인스톨을 수행하는 듯 한데 덕분에 대략 2분동안 시동 화면을 봐야 실행되더군요. 특히 자잘한 리소스 파일들이 많아서 그걸 복사하는 시간 같은데, 뭐 덕분에 그 시간동안 포켓몬GO 포켓몬 관리할 시간이 생긴 것은 함정...

테스트 빌드를 보낼 때 패키징을 하는데 이 역시 황당할 정도로 오래걸립니다. 대략 십분 이상...대충 보면 UWP의 경우 복수의 플랫폼을 빌드/패키징을 하는데, 걍 무식하게 똑같은 리소스까지 다 복사해 넣는 것으로 보입니다. 플랫폼 하나 더해지면 딱 그만큼 파일 크기가 커지고 느려집니다. iOS로 똑같은 앱 빌드/패키징하는데...음 2분 정도 걸리려나요?

스토어에 게시할 때는 더욱 가관이었는데, 일단 위 테스트 빌드한 패키지를 제출했더니 문제 없이 게시가 되었습니다...만 나중에 보니 스토어에서 받은 파일은 설치는 되도 실행이 안되더라구요. 그래서 찾아보니 패키징 프로젝트를 솔루션에 추가해서 그걸 제출하라는 것 같았습니다(같았다는 것은 확신은 없었다는 것). 물론 그걸 빌드하는데는 또 수십분이 소요되고 디폴트로 ARM 바이너리까지 있다보니 파일 사이즈는 2배가 아니라 3배로 증가. 이걸 제출하는데 아까 언급한 랩탑의 이상한 네트워크 문제로 제출은 또 맥에서...어쨌든 우여곡절 끝에 제출을 했습니다.

그러나 느린 프로세스는 거기서 끝나지 않았습니다. 업로드 완료 후 인증 작업중...뭐 이딴게 뜨더니 '최하 1일에서 3일' 소요 예정이랍니다. 그리고 그거 완료 후에도 최장 1일의 서버 반영 시간 필요. 3일 소요되었는데 뭐 주말 꼈으니 그려려니 합니다. 일단 확인 결과 잘 돌아갑니다. 일단은 작업 끝.


문서와 자료의 부족

결정적으로 다가온 문제입니다. 13년 전 처음 애플 관련 개발을 시작했을 때의 그 느낌 그대로를 다시 느낍니다. 구글링 해 보면 최상단은 거의 마소 개발자 사이트의 공식 문서가 뜹니다. 이게 뭐가 문제냐? 이건 공식 문서 이외에는 별다른 정보가 없다...쓰는 사람도 없다...이 말입니다. 다른 인기(?) 플랫폼은 아마도 스택오버플로우가 제일 상단에 뜨겠죠. 그 공식 문서라는 것도 별반 도움은 안되더군요. 거의 스팩시트 처럼 써 있거나 실제로 중요한 내용은 없거나 했습니다. 이걸 보면 최소 13년 전 애플의 공식 문서는 성의를 보인 것이더군요. MSDN이 짱먹던 시절이 있었는데...물론 이것은 UWP에 국한된 것으로 다른 서비스 개발은 훨씬 나을 것입니다.

가장 시간을 잡아먹은 것은 pdf파일을 보여주는 것이었는데, 놀랍게도 추가 라이브러리 없이 자체 지원이 생겼습니다. 뭐 기능은 그냥 보여주는 정도로 빈약하기 짝이없습니다. 그런데 문제는 pdf파일의 특정 위치를 알아야 하는데 위치가 이상하게 나오는 것이었습니다. 근성의 로그찍기(...)를 통해 보니 1.33배의 차이가 난다는 것을 알게 되었고 결국 알게 된 사실은 윈도 내부적으로 96dpi를 쓰고 있어서 그런 것이었습니다. pdf는 일반적으로 72dpi를 기준으로 한 좌표계가 사용되는 것으로 알고 있는데, 공식 문서에서 그에 대한 설명은 전혀 찾을 수 없었습니다. 물론 애플쪽 문서는 그 좌표가 72dpi 기준이라고 명시되어 있습니다.



비인기 플랫폼의 비애

구글 서비스의 공식 지원이 빈약합니다. 나름 충격적인 부분. 그리고 비인기 플랫폼이라 아무도 안씀->문서와 자료 부족->유입 없음->비인기 플랫폼...즉 말라죽는 것이 거의 확정적인 운명이라 생각됩니다.


아무튼 고생했는데, 어차피 UWP 유저 수도 적을텐데 괜히 이런거 계약 조건에 넣어서 리소스 낭비하는 느낌이 큽니다. 저는 회사 내부자라서 외주 개발자보다 더 많은 정보에 접근 가능했기에 퀄리티 면에서는 나은 결과물이 나오긴 했습니다만...결국 저는 다른 프로젝트 해야 되서 또 (다른) 외주 인원을 (급히) 구하려 해서 갑갑할 뿐.

마이크로소프트도 UWP는 취미(?)정도로 집중을 안하는 느낌이고, 그냥 윈도로 타 플랫폼이나 서비스 개발을 할 수 있게 하자는 쪽으로 가려는 것 같네요. 근데 그럴거면 저는 윈도를 작업용으로 쓸 이유가 없네요. 그 다른 것들은 다른 플랫폼에서도 가능한 것이 대부분이라...

다시 말씀드리지만 이건 UWP에 한정된 이야기입니다.




덧글

  • RuBisCO 2020/09/16 13:19 #

    스티브 발머가 싸놓은 똥인 RT를 공 안들이고 대충 수습을 하려고 드니 될리가...
  • 오오 2020/09/16 13:52 #

    천하의 마소가 이정도일 줄은...
※ 로그인 사용자만 덧글을 남길 수 있습니다.