2025년 3월 23일 일요일

솔라나 재단의 블록체인 2년, 그리고 최근의 Stablecoin, RWA

처음 솔라나 재단에 입사했던 2022년만 해도, 많은 블록체인 프로젝트들이 NFT나 게임 같은 분야에 큰 기대를 걸고 있었다. 블록체인을 게임에 결합하면 혁신적인 유틸리티가 만들어질 것 같았지만, 현실은 달랐다. 사실상 이미 클라우드와 서버 기술로 비슷한 것을 하고 있었던 게임 회사들이 많았고, '웹3'라는 이름을 붙여 투자만 받으려는 회사들이 대부분이었다.

게임 엔진을 주로 다뤘던 나는 자연스럽게 게임 회사들이 블록체인과 게임 엔진을 연동하도록 지원하는 업무를 맡았다. 하지만 막상 블록체인을 게임에 적용하는 것은 기술적, 비즈니스적으로 여러 어려움이 있었고, FTX 사태와 같은 대형 사건도 터지면서 결국 나는 APAC 지역의 전반적인 비즈니스 업무, 이벤트 기획, 사무실 예산을 위한 내부/외부피칭 등 다양한 일들을 하며 2년을 보냈다. 

개인적인 이야기는 여기까지로 하고, 최근 크립토 업계는 NFT나 게임 같은 유틸리티보다는 금융 쪽으로 빠르게 옮겨가고 있다. 특히 스테이블 코인이 그 중심에 있다. 달러를 맡기고 1달러에 해당하는 스테이블 코인을 발행하면, 그 달러가 다시 미국 채권으로 투자되는 방식으로, 스테이블 코인의 규모는 계속 커지고 있다.

스테이블 코인을 기반으로 점점 더 다양한 금융 상품들이 등장하고 있다. 특히 주목받고 있는 것이 실물자산을 블록체인 상에서 토큰 형태로 거래하는 RWA(Real World Asset)다. 기존 주식시장에서 기업을 상장해 주식을 쪼개서 팔듯이, 부동산이나 미술품, 채권 등 모든 실물자산을 블록체인을 통해 쉽게 거래할 수 있게 되었다. 거래마다 수수료나 조건을 설정할 수 있는 유연성도 생겼다.

이 정도가 2년간 크립토 업계 경험으로 종종 사람들에게 들려줄 수 있는 이야기다. 크립토의 발전은 확실히 흥미롭지만, 솔직히 아직은  완전히 이해하거나 확신이 서지는 않는다. 앞으로의 방향이 기대되기도 하지만, 조금은 조심스럽게 지켜보게 된다.


추가로 더 알고 싶은 분들을 위해서 - Chatgpt의 Deep research 를 이용해 내가 생각하는 키워드를 몇개를 던져주고 시장에 대해서 조금 더 알려달라고 헀는데, 잘 정리해주네요. 추천!

2025년 3월 21일 금요일

내가 만들고 싶은 게임

MMORPG를 늘 만들고 싶었는데, 업계 사람들과 이야기를 나누다 보니 내가 진짜 원하는 게 꼭 RPG일 필요는 없겠다는 생각

내가 상상한 MMO는 마을 같은 공간에서 사람들이 모여 수다도 떨고, 길드도 만들고, 거래도 하고, 자연스럽게 함께 게임으로 이어지는 그런 분위기다. 예를 들면 로블록스 같은 게임 안에 마을이 있어서 사람들이 자유롭게 모여 게임 얘기도 하고, 길드도 만들고, 커뮤니티가 활성화되면 좋겠다는 거다. 

여기에 요즘 분위기를 생각하면 블록체인을 더해 DAO 개념까지 확장할 수도 있겠다 싶다. 또 로블록스가 AI 지원 툴을 통해 어린이들도 게임을 쉽게 만드는 것처럼, 누구나 쉽고 재미있게 게임을 만들고, 이렇게 만들어진 게임을 통해 자연스럽게 크리에이터 이코노미까지 이어지면 재미있을 것 같다.

이런 식으로 커뮤니티와 창작이 자연스럽게 어우러지는 게임 플랫폼을 만들 수 있다면!!!

요즘 블록체인과 게임 업계 취업 분위기

요즘 블록체인과 게임 업계 취업 분위기

확실히 이전보다 더욱 '뾰족한' 실력을 갖춘 엔지니어를 찾는 느낌이다. 애매하거나 다른 인더스트리 경력은 거의 인정하지 않는 분위기인데, 이는 아마도 시장에 이미 딱 맞는 경험을 가진 엔지니어들이 많기 때문인 듯하다. PM이나 PO 역시 정확한 업계 경험을 상당히 중시하는 모습을 보였다.

크립토나 트레이딩 분야 엔지니어는 금융 경험과 최적화 및 분산 시스템에 대한 이해가 필수인 것 같고, 블록체인은 전체적으로 점점 금융 쪽으로 기우는 느낌이다. 애플리케이션이나 일반적인 백엔드 개발 회사보다는 확실히 금융 쪽 분위기가 더 강했다.

몇몇 남은 블록체인 게임은 스테이킹이나 GameFi 형태의 프로젝트들이 대부분이었다. 다만, 한국의 메이저 회사들이 오버데어 팀이나 메이플 유니버스 팀 같은 프로젝트를 활발히 진행하고 있어 개인적으로 기대가 크다. 특히 UGC(User-Generated Content) 제작을 위한 뛰어난 툴이 나오면 AI와도 좋은 시너지가 발생할 수 있지 않을까 싶다. 최근 Roblox 에디터 AI 가 도입되는 걸 보니 더더욱!

해외 취업의 경우 비자 소지 여부를 생각보다 많이 묻는다. 재택근무 옵션이 완전히 사라진 건 아니지만, 같은 지역이나 최소 같은 나라에서 빠르게 협업이 가능한 후보자를 선호하기 때문인 것으로, 과거처럼 리로케이션 비용을 지원해 해외 인력을 적극적으로 데려오려는 모습은 별로 보이지 않았다. 개인적으로 EU 국가들 사이에서 자유롭게 이동 가능한 유럽 개발자들이 조금 부러웠다.

게임 회사의 경우 생각보다 채용이 활발하지 않았고, 연봉도 높지 않은 회사들이 많았다. AI가 접목된 게임 분야가 유일하게 두각을 보이며 VC에서 올해 적극적인 투자 움직임을 보인다는 소식이 들려왔다. 실제로 최근 YC 같은 곳에서 투자를 받은 회사들이 AI+게임 쪽으로 인력을 뽑기 시작하고 있다. 대부분 미국쪽이어서 아쉬운.

2015 코드리뷰 도입기

2015년쯤, 계속 합병해 나가는 독일 회사와의 인연을 마무리하고 바이오인포매틱스를 공부하며 송도에서 대학원을 다니고 있었다. 사실 대학원에 다닌다는 핑계로 프로그래밍을 멀리하고 있다가, 운 좋게 지인의 추천으로 대기업에 입사하게 되었다. 해외에서 한참(사실..그렇게 길지 않은) 생활하다 돌아왔기 때문에 모든 것이 새롭고 낯설었고, 동료들 역시 내가 해외에서 와서 이런가 보다 하고(?) 이해해주는 분위기였다고 한다.

그중 기억에 남는 에피소드 하나는 바로 코드리뷰에 관한 것이다.

코드 ownership에 대해 다양한 생각이 있었는데, 특히 한국에서는 버그가 생기면 무조건 그 코드를 짠 사람의 잘못으로 보는 경향이 강했다. 내가 해외에서 일했던 회사들은 시스템의 문제로 함께 고쳐야 하는 것으로 보는 문화가 있었다. 아마 이런 문화 속에서 코드리뷰라는 프로세스가 자연스럽게 자리 잡지 않았나 싶다. 당시 한동안 프로그래밍을 놓고 있던 나는, 갑자기 뛰어든 회사에 코드리뷰 문화가 없다는 걸 보고 "이건 나를 위해서라도 꼭 도입해야겠다"고 결심했다.

사실 해외에서는 코드리뷰가 이미 당연한 문화였고, 많은 책에서도 이를 당연시하고 있었다. 코드리뷰 없이는 개발의 질과 효율성을 보장하기 어렵다고 생각했다. 그래서 나는 프로젝트 내부에서 코드리뷰의 필요성과 장점을 알리기 위해 노력했다.

우선 관리자의 입장에서는 코드리뷰가 버그를 조기에 발견하고 빠르게 수정할 수 있으며, 담당자가 없을 때도 다른 팀원이 해당 코드를 이해하고 있으면 빠르게 대응할 수 있다는 점을 강조했다. 동료 프로그래머들에게는 코드리뷰를 통해 미리 버그를 잡으면 훨씬 생산적이고 스트레스가 덜하다고 설득했다. 신규 입사자들에게는 코드리뷰가 팀원들과 자연스럽게 친해지고 빨리 적응하는 수단이 될 수 있다고 이야기했다.

그렇게 작은 변화들이 모여 점차 코드리뷰 문화가 팀 내에 자리 잡기 시작했다. 팀원들이 적극적으로 코드리뷰에 참여하면서 서로의 코드를 통해 배우고, 팀 전체의 코드 품질과 협업 효율성이 눈에 띄게 좋아졌다. 내가 했던 작은 시도가 긍정적인 변화를 만들어냈다는 걸 실제로 느낄 수 있었던 소중한 경험이었다. 물론 이런 다양한 얼토당토 않은 얘기를 잘 들어준 팀장님, 동료 프로그래머분들에 다시한 번 감사를!
심지어 가끔은 코드보다는 이런 문화나 프로세스를 만들어가는 게 내 적성에 더 맞는 게 아닌가 하는 착각을 하기도 했다. 다른 건 몰라도 해외에서 뛰어난 PM들과 함께 일한 경험은 많았으니까 말이다. 

2018년 3월 9일 금요일

핀란드 라이프

어찌하다 보니, 핀란드 회사에서 일한지 10개월이 되었고, 핀란드에 오게 된지는 6개월이 되었다.

1. 시간에 대해서 생각하는 방식이 바뀌었다.
예를 들어, 하루에 9.5시간씩 일하고 4일동안 37.5 시간을 채운 후, 금요일에 쉴수도 있다. 시간이 매우 유연해서, 같은 시간을 일하지만 중요하거나 필요한 일은 자연스럽게 할 수 있다.

2. 출퇴근 시간이 거의 없다.
얼마 전에 읽은 책에서, 현재 대도시 빈부 격차는, 회사에서 얼마나 떨어져서 사는 가로 나타나는 경우가 많다고 한다. 대부분 걷기 좋은 도심 한가운데에 위치한 회사이니 만큼, 근처 집값은 상당히 비싼 경우가 많다고.
다행스럽게도 현재 사는 곳은 시골이라서 그런지, 대부분 회사 근처에 당연하다는 듯이 집을 얻어 살고 있다. 500미터 정도 걸어서 출퇴근 중인데, 집이 가깝다는 건 매우 만족스럽고 좋다.

3. '1','2'번의 이유로 아기 보는 시간이 늘었다.
한국에서는 평일에는 아침에 1시간, 저녁에 1시간  정도 볼 수 있었는데, 지금은 대략 4시간 이상은 아이와 보내게 된다. 4시간은 생각보다 길어서, 지치긴 하지만, 즐겁고 보람찬 느낌이다.









2017년 8월 13일 일요일

육아와 일, 그리고 워크라이프 밸런스

작년 그러니 2016년 11월 13일, 귀여운 아기가 태어나 육아라이프를 시작! 대한민국 공통 코스인 조리원을 거쳐 아이 돌보미 이모님까지 하고나니, 이제 좀 알겠군 하며 시작했는데, 무엇보다도 남는 시간이 없었네요. 이후 1주일의 휴가를 조리원 시절에 사용하고 나니 더 이상 휴가가 없어 바로 업무로 복귀 하고 나니 불과 몇주만에 둘다 아마도 번아웃이라는 불리는 그것이 왔습니다.

와이프는 다시 강의 일을 시작했고, 저도 부랴부랴 회사와 얘기해서 육아기 단축근무를 시작했습니다. 팀에 감사합니다!! 무조건 되는거라고 해서 편하게 신청했는데, 생각해보면 한정된 TO 와 인원압박속에서 쉽지 않았을거라 생각합니다.

주 30시간 근무는 생각보다 많이 달랐습니다. 제법 에너지가 남아 있어서, 오전에 아기 보면서, 집안일을 하기도 하고, 밖에서 한탐 일하고 온 와이프도 생각보다 많이 충전되어 오후에 편하게 교대할 수 있었습니다. 10시간만 줄였을 뿐인데, 생각보다 너무 많이 달랐습니다. 4개월 후에 다시 40시간 근무(+출퇴근 총 2시간*5 = 10시간 소요) 를 시작하니, 아이보는 시간도 줄어들고, 집에 와서 지쳐서 누워있다가 와이프의 잔소리를 듣는 시간도 늘었습니다.

육아기 단축근무 하면서 느낌 점은,
1. 근무시간이 줄어들고, 집에 오래 있으면 아이와도 좀 친해지고, 집안일 할 에너지도 생기더라
2. 남들 출퇴근할 때만 피하면 출퇴근 피로가 반이상 줄어들더라, 서서 힘겹게 가던 버스시간이 즐거운 게임타임으로 ><
3. 아이하고 일정시간 보내지 않으면, 당연하지만 아이보는 스킬 + 집안 일 스킬이 줄더라.
4. 사실 시간 만큼 월급이 줄어드는 거라 회사에서 큰 손해는 없을 거라 생각했는데, 팀 차원에서는 한정된 TO 및 대체 인력 부족등의 이유로 쉽지만은 않더라~

회사 차원의 배려를 통해 남자들도 육아기 단축근무를 자연스럽게 할 수 있으면 좋겠습니다. 이런 걸 보면 요즘 유럽은 부부가 사용할 수 있는 육아휴직 기간이 있고, 남편이 보통 특정기간 동안 무조건 사용해야 된다고 합니다. 이 일정기간동안 많은 걸 배울 수 있을텐데, 이런 제도가 한국에도 있으면 좋겠습니다!

2016년 6월 19일 일요일

언리얼 엔진 4 의 check 매크로 VS ensure 매크로


언리얼 엔진 4를 하다보면, 특별한 이유없이 엔진 내부 크래쉬로 툴이 죽을 때가 많습니다. 문제는 도대체 무슨 문제인지는 모르겠고, check('조건문') 만 있는 경우가 많습니다. 내부를 조금 더 살펴본 결과, 문제가 생기면 최대한 빨리 크래쉬를 내고, 리포트를 받는 게 목적이지 않을까 싶습니다. 그럼 엄청난 리포트가 쌓이고 순식간에 고쳐질 거 같지만, 에러는 계속되고 있으니,,, 일단 어떻게든 크래시를 건너 뛰어야 겠습니다.

1. Visual Studio 에서 F5를 실행한 경우(즉 debugger 가 붙어 있는 경우)
   - 간단하게는 실행 스텝을 앞으로 옮겨서 가능 합니다. 즉 check 조건문이 걸리면 일단 visual studio break point 가 걸리는데, 이 때 왼쪽의 노란 막대를 실제 툴을 끝내는 루틴 뒤로 넘겨주면 됩니다...

2. 그냥 실행한 경우
   - 사실 이 경우 어떻게 할 수는 없지만, 지속적으로 튕긴다면 다음 번 튕기는 부분은 '일단' 막을 수 있습니다. 방법은,
      check(false) 부분을 뺍니다...네 그냥 빼는 건 기분이 좋지 않으므로, ensure(보통 메시지가 있는 ensureMsgF) 로 바꿔줍니다. 이 경우 디버거가 붙어 있을 경우 여전히 break point 는 걸리지만, 없을 경우에 바로 튕기지 않습니다. 물론 이 실행 이후는 상황에 따라 undefined?...이겠지만요. 요즘 Widget 쪽에서 이유없이 튕기는 경우가 많아서 이렇게라도 해야 되지 않을까 싶습니다.



2016년 5월 19일 목요일

언리얼 엔진 블루프린트와 버전 컨트롤(Perforce)

블루프린트 특성상,
1. (게임) 데이터
2. (게임) 로직
의 정보가 모두 들어있는데,

기존 작업 방식을 생각해보면 게임 데이터는 엑셀이나 테이블 형태로, 게임로직은 스크립트나 C++로 모두 텍스트 또는 머지가 가능한 데이타기반이다.

하지만 블루프린트는 머지 기능이나 디프 기능을 일부 지원하지만 기본적으로 바이너리 데이타 형태이고, 현재까지 완벽한 머지나 디프가 되지 않는다.

디프는 언리얼 툴 내에서 프로퍼티와 핀 연결성을 통해서 보여 주긴 하지만, 머지는 아직까지 거의 불가능인 줄 알았는데, 언리얼 내부에서 블루프린트를 사용하고 있고, 머지 툴을 사용한다고 하네요.=_=


2016년 4월 19일 화요일

언리얼 엔진 4 - 블루프린트에 대한 단상


블루프린트에 대한 단상


장점

  • 비프로그래머 직군이 이해하기 쉽다.(많은 로직 부분을 자연스럽게 직접 하시고 있더라!!!!)


스크립트언어에서 컴파일이 필요없다는 당연한 얘기인지도 모르겠지만, 비주얼 프로그래밍으로 가니 더 나아가서,,, 비프로그래머자리로 가서 고쳐 달라고 하면 거기서 슥슥 바로 고쳐주고, 고치는 과정을 눈으로 보고는 나중에 비슷한 문제는 직접 고치기 까지 함. 쉽게 배우고 이해가능한듯..(스크립트 언어와는 여기서 큰 차이가).

  • 인풋,아웃풋 컨버팅이 자동으로 된다.

가끔 내가 짠 함수도 뭘 넣어야 될지 헷갈릴 때가 많은데, 블루프린트에서는 그럴 핀으로 연결되고 안되고가 바로 보여좋다. 연결 가능한 자동 컨버터 노드도 만들어주니. 행복


  • 실행 중인 플로우를 바로 확인할 수 있다.

비주얼 스튜디오에서 실제 여기에 값이 들어오는 지 확인 하려면, 디버그로 켜고(사실 거의 디버그로 실행하겠지만) 브레이크 포인트 걸거나, 로그를 출력하거나 해서 확인하게 될텐데, 블루프린트에서는 왠만한 플로우를 바로 볼 수 있다.(큼지막한 화살표로 표시...해줌)
  • 오브젝트를 골라서 디버깅 가능

컴포넌트 방식의 최대 난관이 특정 액터에서만 디버깅하고 싶을 때 인데, 그냥 되더라….


단점
  • 복잡한 수학식을 계산하거나, 뭔가 다양한 작업을 한곳에서 진행하면(물론 잘 나누면 이럴일이 적겠지만) 알아보기 힘듦..

  • 가끔 C++에서 해야 할지, 블루프린트에서 해야 할지 몰라서 왔다갔다 할때가 있는데, 이부분은 노하우와 경험이 좀 필요한듯, 언리언은 에디트&컨티뉴가 잘 안되니, 왠만한 건 일단 블루프린트에서 작성하고 나중에 필요하면 옮기는 방식이 좀 더 편하더라
  
  • 아직 상속이나 인스턴싱 기능이 완벽하지 않아서, 짜증 날때가 있음..(옛날 컴파일러 쓰는 느낌(!)인데, 차츰 좋아지는듯)

  • 카피 & 페이스트의 죄책감이 적어져서…...음….

2015년 7월 21일 화요일

노드 기반(VIsual) 프로그래밍




2001년쯤 처음 프로그래밍을 시작하고 게임 개발을 시작했는데, 이때 사용한 언어는 아직 'C' 였다. 사실 학교에서 배운 건 C++ 뿐이었는데,


절차적 프로그래밍이라고 부르는 것인데, 그냥 컴퓨터가 일을 할 수 있도록, 컴퓨터야 너 이거 하고, 그거 끝나면 이거 하고, 등등등 순차적으로 계속 일을 시키는 형태였다.

그러다가 2004년쯤 부터, 드디어, C++ 을 사용하게 되었다, 우와 객체다. 하지만 회사코드는 class1, class2, class3 같이 생긴 legacy 코드였다... 객체지향 프로그래밍은 아차하면 늙은? 코드들이.


객체지향은 게임에서는, 
캐릭터
   - 플레이어
   - 몬스터
         - 늑대 - 약함, 걸어다님
         - 용 - 쏌, 날아다님

같이 특정한 객체를 서술하는 형태로 진행되었는데,
나중에 기획자가, 늑대도 날게 해주세요...라고 하면 멘붕이 오는, 그런 시스템이었다.

그러다가, 2008년쯤 부터, 게임 업계에도 컴포넌트 프로그래밍이 유행하기 시작했는데,
늑대  - [걸아다님], [약함], [플레이어를 공격함]
용 - [쏌],[날아다님]

그러다가, 오 늑대도 날게 해주세요 라고 하면, 날아다님 컴포넌트만 붙여주면 됨(이상적으로는) 하며, 아래와 같이 되었다.
늑대  - [걸아다님], [약함], [플레이어를 공격함], [날아다님]

사실 이렇게 하고 나니, 디버깅이 어렵고, 뭔가 멀티스레드 환경 처럼 되어버리는 문제가 있어서, 점점 겍체와 컴포넌트를 적절히 섞어 쓰자라는 형태로 되어버렸고, 현재 언리얼 같은 엔진들도 꽤 그런 느낌?

이제 더 이상 새로운게 없겠지 했는데, 몇년 단위로 바뀌는 것인가?
이번에 언리얼이 블루프린트를 발표해버렸다.
눈으로 보면서 프로그래밍 하세요! 이제!

사살 Visual Programming 자체는 요즘 유행이긴 했다. 아래는 Scracth

LLVM 같은 오픈소스 컴파일러도 나오고 하면서, 직접 프로그래밍 언어를 만들기 쉬운 환경이 된 거 같기도 하고,

게임에서는 Visual Shader 등에서 한정적으로 이미 쓰이기도 했었고,

하지만 게임 로직은 어렵지 않겠어? 최적화가 중요한 데 했었는데,


하지만 이번에 언리얼 4에 들어간 블루프린트는 뭐랄까,

이걸로 다 할 수 있어요?(프로그래머 없이도...)

라지만, 사실 최적화 된, 또는 기획자나 디자이너가 쓰는 좋은? 노드들을 프로그래머가 제공하도록 되었다. 즉 위와 같은 툴에서 데이타를 넣고, 로직을 짤 수 있도록 최적화된 노드와 컴포넌트를 만들게 됨. 그리고 이것이 현재 내가 하는 일!