얼떨결에 삼성 갤럭시 노트10을 사전예약하여 오늘 받아보게 되었다. 원래는 아우라레드 색상이 굉장히 마음에 들어서 그걸 사고 싶었는데 KT 전용 색상이어서 포기했다. 노예가 되는 건 둘째치고 5G는 데이터 쉐어링이 되지 않는다는 충격적인 소식을 듣은지라 이내 마음을 접었다.

뭔가 이번 지름은 진짜 휩쓸려서(?) 산 것 같다. 그런데 약 6년전에 노트3이 너무 잘 나왔고 이뻐서 정말 가지고 싶었던 기억이 새록새록… 언젠가는 한 번 써보고 싶다고 생각했던 터라 이참에 사봤다. S10은 지인에게 팔았다. 지인의 어머님께서 쓰실 예정이라고 한다. 반 년 정도 쓴 것 같은데 그곳에서도 잘 쓰여지길…

일단 짧은 소감으로는,

• 유심 트레이 뽑다가 폰 박살낼 뻔했다. 드럽게 안뽑힘 -_-
• 최신폰답게 빠릿빠릿하다.
• 특히 삼성페이가 굉장한 속도로 켜진다!
• S10과 다른 지문 위치 덕분에 적응이 안되고 있다.
• 크기는 비슷하지만 생각보다 크(게 느껴진)다.
• 기본 번들 케이블이 USB-C to C 인건 좀…
• S펜은 생각한 것보다 쫌… 비상용인 것 같다.

원래는 좀 참았다가 갤럭시 폴드를 사볼까 했는데 암만 생각해도 너무 비싸기도 하고… 그간의 경험으로 봤을 때 1세대는 일단 지켜보는게 ㅎㅎ; 혀튼! 이제부터 잘 써보도록 하겠다!!

여담1. 퇴근길에 간만에 안드로이드 오토+카카오 내비를 사용해보았는데 역시나 별로다. 블루링크나 카카오나 도긴개긴이긴 한데… 그래서 둘이 붙었구나?아냐

여담2. 첫번째 사진 옆에 있는 누런(?) 박스… 그렇다, 저것도 수요일에 판매 예정이다. 팔기 전에 키보드가 맛가서 20만원 깨진건 안자랑 (…)

여담3여담이 많다. 앞으로 지름(?) 글은 #Gadget 카테고리에서 다루도록 하겠다. 뭐샀는지, 왜샀는지, 첫인상이나 뭐 그런거 간단하게 써볼 생각이다. 심층(?) 분석은 #Review를 보면 되겠다.

어느덧 이 회사에 출근한지 3일이 되었다. 언제나 그렇지만 출근하는 첫 주는 굉장히 빨리 지나간다. 그리고 굉장히 피곤하다 (…) 회사 프로젝트의 코드를 파악하면서 여러 문제가 될 만한 것들을 발견했는데, 그 중 하나를 정리해볼까 한다.

이제까지 이 회사를 제외하고 4개의 회사를 다녔고, 그 중 3개의 회사에서 Unity를 사용했지만 이 회사에서 처음으로 ScriptableObject를 실전에서 꽤나 적극적으로 쓰고 있는 걸 보았다. 지난 2017년에 있었던 Unite Seoul에서의 한 세션을 들으면서 ScriptableObject가 좋다고 꼭 써보라고 했을 때만 하더라도 나와는 먼 이야기 같았고, 실제로 내가 겪었던 회사 프로젝트에서는 전혀 쓰지 않았기 때문에 제대로 마주할 기회가 없었다. 그러다가 이 회사에서 부딪히게 되었다.

회사 프로젝트에서는 순수 데이터로만 쓰는 것들은 DB(SQLite)로, Unity Asset과 연관된 데이터들은 ScriptableObject로 관리하고 있었다. 이는 내가 이 회사에 오기 전에 있었던 다른 프로그래머가 했던 코드인데, 이런 식의 쓰임새는 처음이었기에 꽤나 흥미로웠다. 게다가 이 ScriptableObject를 처음 커밋한 로그에는 무려 로딩 개선이라는 문구가 있었다. 실제로 그런 효과가 있었는지는 잘 모르겠지만, 아마 ScriptableObject를 쓰면 게임이 실행됨과 동시에 메모리에 올려버리기 때문에 처음에만 불러오는 데 시간을 쓰고 추후에는 로딩이 없으니 효과가 있었을 지도 모른다. 나도 첫 회사 프로젝트에서 그런식으로 했었으니까. 문제는 게임의 규모가 커지면 항상 들고 있어야 하는 메모리의 양이 장난이 아니기 때문에 가면 갈수록 상황이 나빠진다. 그래서 나도 첫 회사 때 분산으로 로딩하도록 바꾼 기억이 있다. 우리 게임의 런타임 메모리 용량이 꽤나 큰 것으로 알고 있어서 ScriptableObject에서 불러오는 것 중에서 바로 메모리에 올리지 않아도 될만한 것들을 추릴 수만 있다면 꽤나 큰 개선이 되지 않을까 싶었다.

혀튼 ScriptableObject로 관리되는 데이터들을 훑어보았다. 눈에 띄는게 하나 있었다. audiotable… 오디오를 ScriptableObject로 관리한다고? 그럴수도 있다…라고 잠시 생각했지만 압축을 푼 오디오, 특히 배경음들은 굉장한 몸집을 자랑한다. 아직은 회사 저장소에 커밋할 용기(…)가 나지 않아서 새 프로젝트를 만든 후, 게임에서 쓰는 배경음 몇 개를 불러다가 ScriptableObject에 넣고 불러오는 코드를 만들어서 프로파일링을 해보니…

42MB라는 아름다운 숫자가 등장했다. 허허… 재생하고 있지 않아도, 일부만 테스트했는데도 저정도면 대충 어떨지 상상이 된다. 이 시스템을 걷어내고 싶어도 라이브 중인지라 사이드 이펙트가 굉장히 신경쓰였다. 그렇다고 냅둘수도 없는 노릇… 그래서 혹시나 배경음으로 쓰이는 AudioClip들이 Streaming으로 되어있는지 살펴보았는데, 아니나 다를까 Decompress On Load로 설정되어 있었다. 이를 Streaming으로 변경하고 하니까

재생하지 않으니 299B씩만 차지하고 있다. 42MB를 1.4KB 수준으로 낮췄으니 엄청난 성과가 아닐까? 실제 Streaming 상태에서는 얼마가 나오는지는 테스트를 해보아야 겠지만 그리 크지는 않을 것이다. 문제는 Streaming 시 저사양 기기에서 제대로 동작하는지, 다른 문제는 없는지 고려되야 할 것 같다. AudioClip 설정에 대해서 다른 사이트에서 더 자세히 설명 되어 있으니 한번쯤 정독하는 것을 추천한다. 이것 외에는 대부분 Prefab들을 설정해두고 있었다. Prefab들은 그렇게 큰 공간을 차지하지 않고 있었다.

회사를 옮기면서 가장 힘든 것은 적응이다. 하지만 다른 사람이 작업했던 코드를 보는 것도 재미있다. 길지 않은 경력에 여러 회사를 다니게 되었지만 가는 곳마다 코드가 제각각이라 참 재미있다. 물론 그걸 다 파악해야 하는 건 굉장히 힘들고 고된 일이다 (…) 이렇게 새 회사에 와서 새로운 것을 하나하나 경험하고 배워가는 것도 나쁘지 않은 것 같다. 너무 잦으면 피곤하지만 말이다; 일단 정리가 대충 끝났으니 다시 코드의 바다로…ㅠㅠ

작년 한 해는 다녔던 회사만큼이나 노트북도 엄청나게(…) 갈아 치웠던 해였다. 작년에 소유했던 노트북만 해도 Apple의 MacBook Pro 13” (2017), Dell의 XPS 13 9370, XPS 15 9570, 그리고 오늘 리뷰할 Lenovo의 ThinkPad T480이다. 작년에 포스팅했던 나의 노트북 연대기가 정리되어 있으니 흥미가 있다면 살펴보는 것도 좋을 것 같다.

일단 의식의 흐름대로 장단점을 나열해보겠다. 1년동안 사용해보고 글을 남기는 것이기 때문에 짧게 쓴 것과는 좀 다를 것 같기도 하다.

장점

1. 확장성

썬더볼트3은 물론이고 USB-A도 2개나 들어있다. 그리고 무려 풀사이즈 LAN 포트가 있다. SD 슬롯은 덤이다. 이전에는 eGPU(Razer Core)에 꽂아서 쓰면 대부분은 해결되었지만 최근에 고장나는 바람에 새삼스럽게 T480의 확장성이 좋다는 것을 깨달았다.

그리고 T480에는 선택 사양이긴 하지만 LTE도 탑재할 수 있다. 그래서 이녀석을 작년에 수령하자마자 회사 근처의 KT지점에서 데이터 쉐어링 유심을 바로 개통하여 사용했다. 다른 사람들이 카페에서 Wi-Fi를 찾을 때 나는 그저 노트북 뚜껑을 열고 거리낌없이 바로 인터넷을 사용했다. 속도도 나쁘지 않고 100GB 요금제를 사용 중이기 때문에 용량에도 크게 부담이 없다. ~앞으로는 LTE 모듈이 없는 노트북은 쓰기 힘들 것 같다.~

2. 발열/소음

발열이 장점으로 온 이유는 전적으로 언더볼팅을 했기 때문이다. 나는 아주 보수적으로 -0.100V로 설정해두었다. 평소에 개발하면서 앵간하면 70도를 넘지 않는다. 평균 50~60을 왔다갔다 한다.

발열이 줄어들면서 자연스레 소음도 줄어들었다.

3. 퍼포먼스

CPU는 XPS 13 9370과 같은 녀석이라 완전히 같다. CPU 성능은 큰 불만이 없다. 위에서 언급했던 언더볼팅을 한 덕분에 발열이 크게 줄어서 스로틀링이 걸릴 일이 없다. 제 성능을 잘 낸다.

4. 배터리

사실 단점으로 넣을까도 고민했다. 왜냐하면 제조사에서 배터리 시간을 뻥카(?)쳤기 때문이다. 그들이 주장하기로는 내장 배터리와 대용량 외장 배터리를 쓰면 최대 30시간까지 가능하다고 했는데 실사용 시간은 10시간 내외였다. 내 입장에서 실사용이란, 웹 서핑을 하면서 음악을 듣고 가끔 동영상도 보면서 Unity로 게임 개발도 하는 것이다. 뻥친건 괘씸하지만 그래도 많이 오래 가서 좋다.

5. Lenovo Vantage

Lenovo에서 제공하는 유지보수 프로그램이다. 꽤나 심플하면서도 잘 챙겨준다. Dell도 그렇고 다른 제조사도 그런진 모르겠지만 Windows 내에서 BIOS 업데이트가 가능하다는 것이 마음에 든다.

단점

1. 키보드

나는 여전히 7열 키보드를 원한다.

This is NOT ThinkPad Keyboard.

그래도 키감 하난 쫄깃하니 찰지다. 그런데 하나 단점이 있다. 바로 자동으로 백라이트의 밝기가 조절되지 않는다는 점이다. 이정도 가격의 노트북에 없다는 것이 좀 충격이었다.

2. HiDPI 지원

이건 이 노트북의 문제라기보단 윈도우의 문제라서… 그래도 노트북 단독으로 쓸 때는 문제가 없지만 노트북 모니터와 DPI가 다른 외부 모니터를 연결했을 때 문제가 생긴다. 현재 쓰는 32인치 모니터가 다행(?)이도 노트북과 DPI가 맞아서 큰 불편없이 썼다.

사실 적고 보니까 이렇다할 단점은 없었다. 이렇다할 뚜렷한 단점이 없어서 좋은 기기가 아닐까 싶기도. 어느 한 곳으로 크게 치우치지 않아서 밸런스가 굉장히 좋다. 명기라 불릴만 하다. 그런데… 아쉽지만 이별을 해야할 것 같다. 지금까지 노트북을 극으로 맞춰본 적이 없어서 그런지 뭔가 하고 싶은 걸 해야할 때 제 성능을 제대로 발휘하지 못하는 경우가 있었다. 이번 백수 기간이 딱 그렇다. 그래서 취직이 결정된 김에 화끈하게 질렀다. 마침 20개월 무이자 행사를 하기도 했고 ~자본주의의 노예~ 금요일에 방문 수령으로 찾아올 예정이다. 뭘 샀냐면…

Razer Blade 15 9Gen R80

3,990,000원… 셀프 생일 선물 겸 취직 축하 겸 겸사겸사…ㅠㅠ… 회사 열심히 다니겠습니다 ㅎ…

지난 6월에 회사를 그만두고 나서 지금까지 여러번 면접을 보았다. 면접 본 회수만 따지면 이번에 가장 많이 봤던 것 같다. 정작 입사 지원한 회사보다 지원당한(?) 회사로부터의 면접이 많았다. 지원했던 회사중에서는 단 한 곳에서만 연락이 왔다 (…) 은근히 상처받았지만 그 회사는 내가 필요하지 않을 수도 있으니… 회사에서도 이왕이면 회사에 맞는 인재를 뽑는 것이 좋을 것이고, 구직자도 자신과 맞는 회사를 들어가는 것이 좋을 것이다.

혀튼 그렇게 실컷 면접을 보고 나니까 어느덧 한 달이 넘게 지나갔다. 일 할 때 시간은 빨리 안가더니 놀 때는 왜이렇게 빨리가는지… 사실 이번 구직 기간 동안에는 직전 두 번의 이직 때보다는 훨씬 느긋하게 있었던 것 같다. 30대의 아들이 집구석에서 놈팽이(?)마냥 놀고 앉아 있는 걸 두고 볼 수 없었는지 지난 주부터 부모님께서 한마디씩 거들고 계신다. 그래서 나도 적당히(?) 놀고 기어 들어가야겠다고 생각하던 찰나에, 마지막으로 면접을 보았던 회사의 결과가 나와서 선택의 기로에 서게 되었다. 합격한 여러 회사 중에서 지인의 추천으로 지원했던 O사에 가는 것으로 결론지었다. 처음에는 연봉이 맞지 않아서 보류를 했다가 이번에 재협상을 해서 원하는 연봉으로 입사하게 되었다. 그쪽에서도 많이 기다려주고 양보한 만큼 들어가서 열심히 해야지 않을까 싶다.

그렇게 나의 길다면 길었고 짧다면 짧았을 백수 생활이 끝났다. 사실 이번에 구직 활동을 하면서 가장 많이 들었던 질문은

왜 이렇게 회사를 자주 옮기셨나요?

였다. 그래서 될 수 있으면 오래다닐 수 있는 회사로 가고자 했으나… 이 회사를 오래다닐 수 있었으면 좋겠다. 아니, 적어도 즐겁게 개발할 수 있었으면 좋겠다. 다음주 월요일에 첫 출근을 하기로 했다. 어쩌다보니 생일에 첫 출근이 되버렸다… 이제 시한부(?) 백수 생활동안 정말로 못해봤던 일을 하나하나 해봐야겠다. 내일은 오전 중에 입사를 위한 서류 준비를 하고 오후에 강릉 카페거리를 혼자서 가볼까 한다. 동해 바다를 보면서 생각을 정리할 필요도 있을 것 같아서 ㅎㅎ…

요즘 백수 생활을 하다보니 개인 프로젝트에 투자할 시간이 굉장히 많아졌다. 그렇다고 매일매일 하는 것은 아니지만 (…) 어쨌든 최근에는 부쩍 늘은 건 사실이다. 퇴사하고 나서는 노느라 정신이 팔렸지만 지금은 놀 것도 없고(?) 다시 코드를 붙잡고 있는 시간이 많아졌다. 슬슬 다시 회사로 기어 들어가야 하는 시기가 온 것 같다. 안그래도 부모님께서 슬슬 일하라고 하시니까 ㅠㅠ…

어쨌든 게임 포켓에서 진행 중인 공주의 탄생이라는 프로젝트를 작업하고 있다. 현재 Alpha Milestone이긴 하지만 나의 작업 분량은 끝나서 먼저 Beta Feature를 작업하고 있다. 그 중 하나인 Screenshot 공유 기능이 간단해 보이고 다른 기능들과 크게 연관이 없어서 먼저 해보고 있는데 이게 생각보다… 진행이 잘 안되어서 작업(이라고 쓰고 삽질이라고 읽는다) 일지를 기록해보는 것이 좋겠다 싶어서 그동안의 삽질 절차를 써내려가보고자 한다.

실질적인 작업은 3일전부터 시작했다. 원래는 게임 내의 버튼을 누르면 Screenshot이 찍히고 별도의 공유하기 버튼을 통해서 SNS로 공유할 수 있는 그런 시스템이다. 그런데 생각해보면 모바일 OS들은 Native에서 공유하는 기능을 제공하고 있으니까 그 기능만 호출하면 따로 JNI를 통해서 뭔가 작업하지 않아도 되지 않을까 싶어서 그 방향으로 진행했다.

일단 iOS는 빌드조차 하지 못하고 있으니까 Android 부터 기능을 만들어가고자 했다. 다행히도 전세계에는 나와 같은 고민을 하는 사람이 많기 때문에 Android의 공유 기능을 호출하는 코드는 쉽게 구할 수 있었다. 문제는 이 코드가 최신 Android에서는 정책상의 이유로 막히게 되었다는 것. 왜 안되는지는 다른 분들의 블로그에 신나게 쓰여 있으니 여기에서는 따로 쓰진 않겠다. 그래서 우회를 해야 하는데 여기서부터는 결국 이전보다 훨씬 복잡한 과정이 펼쳐질 것만 같았다. 순간 뇌절하면서 하루 정도는 그냥 아무것도 하지 않았다 (…)

다음 날에 정신차리고 위에서도 말했던 것처럼 나와 같은 고민을 한 전세계인들의 지식(?)을 찾아보았다. 역시 Asset Store에 Android와 iOS 둘 다 지원하는 NativeShare라는 Asset이 무료로 있었다. 받아서 사용해보니 공유 기능이 잘 된다! 하지만 문제가 있었으니…

두번째 공유 이후에는 화면이 멈춘다!

하… 왜일까? 일단 처음에 생각이 든 것은 약 5년 전에 친구네 회사에서 알바할 때 결재 후에 화면이 멈추는 문제가 있었던 것이 떠올랐다. 게임→결제 액티비티→게임 순으로 진행 될 때 화면이 전환될 당시의 화면으로 멈추면서 아무 것도 되지 않는 문제가 있었다. 당시에 Logcat을 통해 로그들을 세밀히 살펴보면서 발견한 것은 액티비티가 전환될 때 렌더해야할 것이 굉장히(?) 많으면 그리다가 멈춰버리는 것으로 보였다. 그래서 그 때는 NGUI로 개발중이었는데, UI Layer의 최상단에 최대값이 255를 기준으로 1로 설정한 전체화면을 덮는 흰 패널을 넣었더니 해결되었다. 지금 개발중인 게임은 uGUI로 만들고 있지만 뿌리는 같다(…)고 생각하여 한번 시도해보았으나 실패했다.

혹여나 완전히 불투명해야 하는게 아닐까 싶어서 가림막을 완전히 까맣게 하고 또 하나 의심되는 구문이 있었으니

private IEnumerator _DoScreenshotAndShare()
{
    yield return new WaitForEndOfFrame();

    var fileName = System.DateTime.Now.ToString("yyyy-MM-dd-HHmmss");
    string filePath = Path.Combine(Application.temporaryCachePath, $"{fileName}.png");
    var ss = ScreenCapture.CaptureScreenshotAsTexture();
    var bytes = ss.EncodeToPNG();
    File.WriteAllBytes(filePath, bytes);

    yield return new WaitForSecondsRealtime(0.5f); // <- 바로 여기

    Destroy(ss);

    DialogBlank dialog = App.ui.Generate<DialogBlank>();

    new NativeShare().AddFile(filePath).Share();

    yield return new WaitForSecondsRealtime(1.0f); // <- 바로 여기

    yield return new WaitUntil(() => _isFocus);

    dialog.CloseAction();
}

WaitForSecondsRealtime은 왠지 게임 액티비티가 비활성화 상태여도 동작을 했을 것 같아서 WaitForSeconds로 변경했더니 되었다. 불투명한 것은 아무 상관이 없었다 (…) 제대로 헛다리 짚은 것. 그런데 왜 WaitForSecondsRealtime에서는 렌더링이 멈춰버렸던 것일까? 비슷한 사례는 있었지만 미묘하게 내가 겪었던 것과는 다른 문제였다. 이와 관련된 문제는 조만간 로그를 자세히 살펴보면서 알아보아야겠다. 어쩌면 그저 이 버전에서만 간헐적으로 나오던 문제일 수도 있으니…

일단 Screenshot에 대한 작업은 마무리했다. 저 문제의 원인은 나머지 Feature가 마무리되면 살펴봐야겠다.