댈엄지 둥지

고민이 많다. 회사 외적으로 게임은 만들고 싶고 원래 같이 게임 개발하던 친구는 너무 바빠서 시간이 안 나고 혼자서 하기에 리소스를 만들 미적 센스도 없고 실력도 없다. 배워볼까 하고 책이나 강의 영상을 기웃대도 막상 실제로 실행에 옮기기 직전에는 갑자기 귀찮아진다. 인터넷에 리소스를 AI로 생성해서 혼자 게임을 만들었다는 사람들이 쓴 글이 보인다. 나도 생성형 AI로 리소스를 만들어서 게임을 만들까? 하는 고민도 잠시, 이렇게 리소스를 만든다고 해도 내가 원하는 리소스가 나올 때까지 가챠를 돌려야 되고 그렇게 나온 리소스를 사용한다고 만족감이 높을 것 같지도 않다. 어디서 구해온 건지도 모를 데이터를 가지고 학습한 생성형 AI가 만든 리소스를 사용하자니 죄책감도 든다. LLM은 그나마 죄책감이 덜 해서 업무에 어느 정도 활용하고는 있지만 역시 이쪽도 어디서 구해온 건지 모를 데이터로 학습했기 때문에 죄책감이 아예 없지도 않다. 그나마 LLM이 생성한 텍스트를 직접 쓰는게 아니라 L

2000년대 후반에서 2010년대 초반 사이에 몇몇 기업들이 웹앱으로 뭔가를 만들어서 배포한 이래로 점점 많은 웹앱이 출시되어서 요즘엔 아예 GUI 툴킷이 웹 위주로만 나오는 시대가 되었다. 웹앱이 나오는 초반 시기에는 웹 방식으로 만든 앱은 반응이 느리거나 묘하게 UX가 나쁜 앱이 대부분이었는데 지금은 하드웨어 성능도 좋아지고 HTML5(CSS3)에도 점점 많은 게 들어가면서 나쁘지만은 않게 됐는데, 다른 문제가 나타나게 됐다. 웹앱은 기본적으로 메모리를 많이 사용한다. 각 프로세스마다 최소 200MB~500MB 정도를 사용한다. 웹브라우저라는게 소형 OS나 다름 없을 정도로 각종 기능이 많아서 그럴 수 밖에 없다. 모든 웹앱은 각자의 독립적인 브라우저가 열리는 것과 마찬가지라서 웹앱이 많아질 수록 사용자의 RAM도 증설을 많이해야 한다. 그냥 웹앱만 많아지는거면 모르겠지만 이젠 Microsoft까지도 Windows의 여러 부분을 웹으로 교체하고 있다. Outlook 앱을 웹으로

그동안 생각을 좀 잘 정리해서 써보려고 했는데 막 귀찮고 어쩌고 해서 계속 미뤄왔던 주제에 대해서 귀찮음을 이겨내고 정리해보기. 어쩌면 횡설수설 할 지도. 작년 하반기에 소니에서 출시한 콩코드. 야심차게 출시했지만 플레이어 수가 너무 적어 출시 2주 만에 서비스를 종료했었다. 그리고 이 게임이 망한 이유를 다들 정치적 올바름 때문이라면서 놀려댔는데 나는 커뮤니티에서의 이런 분석이 장기적으로 게임업계에 좋지 않다고 생각한다. 게임이 PC하기 때문에 망했다고 정리해버리면 게임회사는 더 재밌는 게임을 만들기 위한 뭔가를 할 수 있나? 게임회사는 실패한 게임에 대해서 자신들의 분석과 커뮤니티의 의견이 다를 때 어떻게 생각하게 될까? 그래도 소비자의 의견이라고 커뮤니티의 의견에 더 많은 가중치를 두고 차기작에 임할 것이다. 때문에 정치적 올바름만 문제삼게 되면 게임사는 어떤 부분이 재미가 없었는지, 게임의 지루한 부분을 어떻게 버텨내게 만들지 이런 고민을 적게 하게 된다. 계속 캐릭터 얼굴이

처음 SKT를 쓰게 된 시기는 2011년에 넥서스S를 사용하면서였다. 기존에는 삼성의 이름모를 휴대폰 -> LG의 KH1200 -> 팬택의 SKY WHOOO를 쓰다가 스마트폰이 뜨기 시작하면서 넥서스S로 갈아타게 됐는데, 이때 KT에서 SKT로 이주하게 되었다. SKT를 쓰면서 T멤버십으로 할인도 종종 받았었고, 집 근처에 있던 SKT 대전지사를 통해서 HTC 7 모짜르트나 노키아 루미아 550 같은 기기들도 개통했던데다 2015년에는 넥서스5X로 기기를 변경하는 김에 USIM을 티머니 교통카드가 지원되는 걸로 바꿨는데 이걸 2025년인 올해까지 썼다. 그런데 이렇게 오래 쓴 SKT를 떠나 다시 KT로 가게 됐다. 이유는 SKT 해킹 사건 때문이다. 솔직히 아무리 인트라넷을 쓴다고 해도 해킹을 아예 안 당할 수는 없기 때문에 SKT가 대처만 잘 했다면 그냥 좀 기다렸다가 USIM도 교체하고 했을 지 모른다. 오래 써온 정이 있어서. 하지만 SKT는 본인들의 잘못을 책임질 생각이 전혀

거의 1년 내내 AMD Ryzen AI 9 HX 370 노트북에 눈이 꽂혀서 이걸 살까 저걸 살까 고민을 진짜 많이 했다가 ASUS의 ZenBook S 16 OLED를 사게 됐다. 원래 AMD Ryzen AI Max 395+까지 나오는 걸 기다렸다가 그걸 살까 했는데 나오는 제품들이 하나같이 나사가 빠져서 어차피 나사가 빠진걸 산다면 그냥 좀 더 전력 소모가 적은 걸 사자 싶어가지고 그냥 370으로 가기로 했다. 근데 370으로 간다면 GPD Win Max 4 (2025)로 가는게 좋지 않을까 하고 알아보고 있었는데 64GB짜리가 갑자기 말도 없이 단종돼서 그냥 GPD 알아보던거 전부 취소. 요걸로 갔다면 Oculink를 쓸 수 있어서 참 좋았겠지만 그냥 기분이 나빠짐. 거기에 환율이 자꾸 파도를 타고 있어서 지금 사는게 나을지 기다렸다 사는게 나을지 너무 고민을 많이 하게 됐다. 어쨌든 우여곡절 끝에 ASUS ZenBook S 16 OLED를 주문했다. 산지 한달 됐는데 지금 각종

SFF에 대한 환상이 있어서 데스크톱을 SFF로 전환한지 거진 1년이 넘어가는 시점에SFF 전환 후 남은 데스크톱을 방치해둔게 아까워서 기존에 쓰던 M1 맥미니를 대체해서 서버로 굴려볼까 하고 IoT 소비전력 측정기로 측정을 좀 해봤었는데 다음과 같은 결과를 얻었다. 7700X + RTX 3070 + Windows유휴: 80W (이후 바이오스에서 P-State 설정을 변경하고 내장그래픽을 적

2024년 10월 25일, JetBrains에서 Rider를 비영리적으로 사용하는 사람들을 위해 비영리 라이센스를 추가했다. 30일 내로는 라이센스 결제 환불이 가능한데 딱 10월 21일에 40% 할인 된 구독 결제비가 나갔었기 때문에 환불 신청을 했다. (2020년부터 꾸준하게 써온 만큼 의리로 결제를 유지하는 게 좋았겠지만 요새 지갑 사정이 안 좋아서... 나중에 다시 결제하긴 할 거다)

sudo를 사용하면 간단하게 docker로 1024포트 이하를 매핑할 수 있겠지만 sudo 권한은 어지간하면 쓰고 싶지 않았다. docker로 nginx를 실행하고 싶었는데 80포트를 매핑하려면 root 권한이 필요했다. 아래 명령어를 사용하면 sudo 없이 매핑이 가능하다. 이제 찾아야 하는 건 --net=host 옵션을 rootless로 사용할 수 있는 방법...

최근에 서버에서 패킷을 파싱하는 코드를 수정하고 있다. 수정하는 이유는 가끔 클라이언트와 서버 사이에 접속이 종료되는 이유를 찾는건데, 그런 과정에서 패킷 파서를 재작성 해서 시험 삼아 적용해보는 중. 수정하면서 패킷 데이터를 복사 하는 코드를 좀 수정했는데 기존 코드와 비교해서 프로파일링 상 성능은 좀 더 잘 나오게 됐지만 드라마틱한 성능 향상은 아니길래 패킷 복사 코드를 좀 손대보려고 .NET 내 복사 메서드들의 성능을 확인해보는 것으로.

이 포스트는 Elixir 컴파일 시간을 단축하는 방법 세 포스트(Part 1, Part 2, Part 3)를 구글 번역하여 다듬은 포스트입니다. 1부. Elixir 컴파일 과정에 대한 이해 느린 Elixir 컴파일 시간으로 인해 어려움을 겪고 계십니까? 대규모 Elixir 코드베이스에서 작업하는 경우 컴파일 시간이 느려지기 시작할 수 있습니다. 파일 하나만 변경하고 테스트를 다시 하면 수십개의 파일이 컴파일되고 시간이 오래 걸립니다. 이 게시물

우리 서비스에서는 로그인에 Firebase를 사용하고 있는데 iOS 앱은 4월 30일 이후부터는 iOS 17 타겟 빌드 필수여서 Xcode 14로 빌드하던 앱을 Xcode 15로 시험 빌드해서 알파 빌드로 테스트 후 라이브 배포를 했는데 점검주에 간헐적으로 크래시 발생하는 문제를 발견했다. Firebase 내 Protobuf decode 기능에서 크래시가 발생하고 있는데, Xcode 15.3으로 빌드하면 10번 실행하면 9번 크래시가 발생하고

이 포스트는 RFC4180 문서를 Google 번역기로 번역하여 다듬은 포스트입니다. 쉼표로 구분된 값 (CSV) 파일의 일반 형식 및 MIME 유형 이 메모의 상태 이 메모는 인터넷 커뮤니티를 위한 정보를 제공합니다. 어떤 종류의 인터넷 표준도 지정하지 않습니다. 이 메모의 배포는 제한되지 않습니다. 저작권 공지 Copyright (C) The Internet Society (2005). 초록