RyuK 성장 일지

[회고] 나를 조금 더 알게 된 한 해

RyuK-H — Wed, 10 Dec 2025 23:34:06 +0900

들어가며

Coldplay - Fix You

8년째 매년 회고를 쓰고 있지만, 올해만큼 무엇을 써야 할지 막막했던 적은 없었던 것 같다.

아마 인상 깊었던 일이 크게 없었고, 있었다 해도 내 삶에서 새롭지 않았기 때문일 것이다.

2025년을 돌아보니 크게 두 가지 장면이 기억에 남는다.

1) 상장 당일, 1평 남짓한 SafeRoom 공간에서 코인 전송을 대기했던 순간, 그리고 상장 하던 그날이 생각보다 기쁘지 않았던 나의 모습.

2) 여름 한국에 방문했을 때 여러 사람들을 찾아가며 "저는 어떤 것을 잘하는 사람인가요?"라고 되묻던 나의 모습

약 3년 6개월 동안 애써 만든 프로젝트가 세상에 나왔을 때, 왜 행복하지 않았을까를 생각해보면, 처음 든 감정은 '긴장'이었던 것 같다.

큰 프로젝트에서 보면 작은 부분일지 몰라도, 내가 주체적으로 설계한 부분들이 있었기에 '시장의 평가'가 긴장되었던 것 같다.

시간이 흐를수록 이 감정은 자책으로 변해갔다.

'열심히'가 아니라 '잘'했었어야 했는데, 그저 열심히만 했었던 것 같고

이전에 느꼈던 여러 성취감과 자아실현의 순간들이 어리숙한 자기합리화처럼 느껴졌다.

그렇게 여름이 왔고, 그 시점에는 내가 어떤 사람인지, 앞으로 무엇을 해야 하는지에 대한 혼란이 컸다.

한국에서 여러 사람들을 만나 피드백을 들었고, 그 말들이 다시 혼란스러운 마음을 잡아주었던 것 같다.

2025년 회고를 쓰는 일이 유난히 힘들었던 이유, 그리고 과거 회고들이 조금은 "패션 회고"처럼 느껴졌던 이유는

아마, 올해가 '성장기'에서 '성숙기'로 넘어가는 과도기였기 때문이 아닐까 생각되었다.

기억에 남기고 싶은 것

매년, 자기소개가 달라지는 사람이 되기로 했다.

면접을 보는 상상을 할 때, 작년까지만 해도 "자기소개 부탁드립니다."라는 질문을 받으면 어떤 말을 해야 할지 잘 몰랐다.

점점 현재 조직에 맞는 모습으로 변해가는 괴상한 퍼즐 조각이라고 생각되었고, 약 4년전 부터 시작 된, 이 고민은 해소되지 않았던 것 같다.

그래서 '그냥 하는 거지'라는 마음으로 최선을 다했다.

'블록체인'의 특수성으로 여러 분야에 대한 지식을 늘려야 하는 상황에서, 나는 사실 조금 '희생'이라는 단어를 마음속에 품었다.

그런데, 한국에서 피드백을 받고 나서 '그냥 하는 거지'라기보다, 매년 나의 분야가 바뀔 수 있고 이 모든 것을 잘 습득하고 활용하게 된다면 그 자체가 능력이 아닐까 하는 생각을 갖게 되었다.

이제는 어떤 분야든 블록체인으로 힘들어한다면 기쁜 마음으로 내가 그쪽 분야를 이해하면 된다는 마음을 갖게 되었다.

어린 시절부터 '제너럴리스트', '스페셜리스트'라는 말을 썼는데, 아마 지금의 나는 정말 제너럴리스트로 변해가고 있는게 아닐까 하는 생각을 하게 되었다.

그럼에도 내년에 나의 존재에 대한 고민을 하는 순간들이 있을 텐데, 그때마다 지금을 기억하길 바란다.

개방성과 학습력을 기반으로 통섭적 사고를 하자.

"간단하게 자기소개 부탁드립니다."

지금은 NEXPACE에서 Head of Blockchain Development로 개발의 우선순위와 리스크를 관리하고, 회계/감사와 같은 외부 규제 환경에 대하여 파악하고, 대응하는 업무를 주로 진행하고 싶습니다.

지금은 리스크 매니저가 저를 소개하는데, 더 어울리는 것 같네요.

'이 세상에는 가치 없는 일은 없다'고 확신한다.

매니징을 하게 된 지도 오래되었지만, 나는 항상 일감 분배에 약점이 있었다.

내가 생각해도 자기개발이 되지 않는 업무라면 부여할 때 찜찜한 기분이 들었기 때문이다.

이런 이유로 회계/감사 관련 업무도 '아, 그냥 내가 해야겠다'라는 생각을 갖게 되었고, 프로세스 구축, 감사인 소통 외에 약 116개의 절차서를 작성하고 있다.

그런데 막연하게는 알고 있었다.

어떤 업무든 어떤 마음가짐을 갖느냐에 따라 자신을 성장시킬 수 있고, 뒤돌아봤을 때에는 자신에게 큰 업적이 될 수 있다는 것을.

하지만 딱히 생각나는 예시가 없어 올해 이 예시를 만들기 위해 노력했다.

고생한 만큼 모든 것을 특허로 만들지 못해 서글픈 마음이 사그라들지는 않았지만, 여러 절차 중 한 가지 절차에 대해 특허를 신청했고, 또 이런 업무를 진행하며 '리스크 매니징'이라는 직군과 역할을 알게 되었다.

결과적으로 보았을 때 '당연히 좋은 업무니까 배울 게 있고, 무언가를 남길 수 있지'라고 말할 수 있겠지만, 초기 SafeRoom과 통제는 그렇지 않았다고 자신할 수 있다.

즉, 어떤 업무든 어떤 마음가짐으로 수행하는지가 중요하다는 것을 스스로 증명했다고 생각하고 있고, 이를 기반으로 어떤 업무든 마음 편히 요청할 수 있게 되었다고 생각한다.

나는 희망보다는 불안에 가까운 사람이다.

나는 여러 가지 불안 요소가 포착되면 감정이 나빠진다. 그리고 이런 부정적인 감정을 표출하고 싶지 않아 말을 잘 하지 않는다.

이런 감정은 모두가 인지할 수 있을 정도라고 생각하는데, 아마 감정 기복이 심해 티가 잘 나기 때문이라고 생각한다.

이 단점을 인지한 지는 꽤 시간이 흘렀던 것 같고, 책도 읽어보고 긍정적인 생각을 갖으려고 마음속으로 주문도 외워봤지만 잘 고쳐지지 않는 것 같다.

항상 인자한 어른들을 보며 동경하지만, 아직은 도달할 자신도, 방법도 모르는, 조금 오래 가지고 가야 할 단점이라고 생각한다.

'희망'과 '불안'은 모두 미래에 대한 불확실성에 기반한다고 생각하고, 나는 '희망'을 기반으로 불확실성을 이겨내는 사람이라고 생각했지만,

사실 나는 '불안'이라는 감정을 더 쉽게 느끼는 사람이라는 것을 인지하게 되었다.

미래에 대한 불확실성은 어떤 상황에든 존재할 수밖에 없으며, 나는 '불안'이라는 감정을 원동력으로 성장하는 사람이라는 생각을 하게 되었다.

덕분에 나는 벗어나기 힘든 일상적인 루틴에서도 매몰되지 않을 수 있었다고 생각한다.

즉, 내가 '불안'을 느낀다는 것에 스트레스받기보다 당연한 과정 정도로 생각하면 좋겠고, '성장할 수 있다'는 희망으로 받아들였으면 좋겠다.

내년에 다시금 불안을 느낄 때 지금 나의 생각을 기억했으면 좋겠다.

회복 속도가 아쉬웠던 한 해였다.

라이브 약 2개월 이후, '이제 나는 무엇을 해야 하지?'라는 생각이 들었다.

나의 존재 가치가 희미해졌다고 생각했고, 자존감이 떨어지기 시작하니 불안이 몰려왔고, 한동안 갈피를 잡지 못했다.

마음이 급해지니 시야가 좁아졌고, 분명 약 1~2개월의 시간은 나의 가치만큼의 업무를 보지 못했다고 생각한다.

이후 '아, 계획을 다시 세워보자'라고 인지하기까지 시간이 너무 소모되었는데,

심호흡을 한 번 하고 잠시 침착해졌다면 사실을 인지하고 제자리로 돌아오기까지 긴 시간이 걸리지 않았을 것이라는 아쉬움이 남았다.

언젠가 이런 상황이 한 번 더 온다면, 정비하는 시간을 조금 더 빨리 갖는 사람이 되었으면 좋겠다.

노동의 강도와 시간을 무기로 쓰지 않기 시작했다.

나는 언제나 '올해에도 초과근무를 꽉 채웠네, 난 이렇게 바쁜 사람이구나'를 자존감 향상과 협상의 무기로 썼었다.

하지만 올해는 이런 사고를 완전히 지웠다고 생각한다. 바빠서 힘들었지만, 그것이 내가 잘하고 있다고 생각하거나 나를 성장시키고 있다고 생각한 적이 없다.

아마 이 '인지'는 앞으로 스스로의 평가 기준이 조금 더 어려워질 수 있겠지만, 분명 더 멋지게 변화시켜줄 포인트라고 기대하고 있다.

결론적으로

2025년 잘한 일은 없다고 생각한다.

프로젝트를 시작할 때 강점으로 내세우고 싶었던 것들은 시장에 받아들여지지 못했고, 더 빛나게 하기 위한 주체적인 행동도 하지 않았다.

오히려 2022년부터 기록했던 회고들이 그저 스스로의 성장만 생각한 '유쾌한 척'하는 어리석은 회고였다는 생각이 들었다.

그럼에도 늦지 않게 이런 감정들을 느낀 점에서 다행이라는 생각이 들었고, 나도 조금은 어른이 되어가는 것 같다는 느낌도 들었다.

아마 높은 확률로 내년에도 '불안'을 느끼며 내가 무엇을 하는 사람인지, 내가 뭘 해야 하는지 평생 반복될 고민을 다시 하게 될지도 모르겠다.

그때 지금의 기록이 빠르게 제자리를 찾는 데 도움이 되었으면 좋겠다.

[회고] 죽어도 행복을 포기하지 마라

RyuK-H — Mon, 16 Dec 2024 10:29:07 +0900

들어가며

If you feel a little trepidation
Sometimes these things don't need explanation

[OST] Timothée Chalamet - Pure Imagination

사회생활을 한지 어느덧 9년이라는 세월이 흘렀다.

이 시점부터 난 항상 자신감이 넘치는 사람이었다.

어떤 일이든 '무난함' 이상으로 해냈고, 문제 인지와 문제 해결을 강점으로 가지고 있어 성장 속도가 빨랐다.

이런 성장감은 나의 자존감을 단단하게 만들어주었고, 이렇게 내 인생의 선순환이 시작 되었다.

난 사람의 성장곡선이 '상승'과 '횡보'로 이루어져있다고 믿고 있다.

새로운 환경에서 성장을 할 때, 벅차도록 힘들다가도

환경에 적응하면 이 세상이 생각보다 살만하다고 느껴진다.

하지만, 이 횡보기간에 나는 유독 불안감을 심하게 느끼는 편인데,

아마 그 불안감은 '상승'시기에 느낀 성취감과 자존감 향상을 기억해서이지 않을까 싶다.

참 신기하게도 나는 이런 횡보의 시간이 찾아왔을 때, 다음 상승을 시작할 새로운 기회를 얻었다.

그렇기에 마음만 단단히 먹는다면 횡보 기간을 단축시킬 수 있었고,

나는 이런 마음을 일상에서 "와 이 프로젝트하면서 압축 성장하는 것 같아요."라는 말로 표현했다.

그런데, 올해 난 처음으로 '성장 곡선은 상승, 횡보 뿐만 아니라 하락도 있구나.' 라는 생각을 하게 되었고,

부여받은 성장의 기회를 달성하지 못하여 창피함과 분함 그리고, 스스로의 한계점에 대하여 많은 생각 하게 되었다.

2024년을 돌아보니,

항상 제품을 만들며 설레는 마음으로 미래를 이야기하고, 무엇이든 "할 수 있다."라고 당찬 패기를 갖고 말하는 난 사라지고, 경계와 두려움을 가득 품은 내가 남아 있었다.

2025년에는 다시 꿈을 이야기하는 사람이 되고 싶다.

그리고, 과거와 달리 꿈을 실현 시킬 수 있는 능력과 깊이도 갖추고 싶다.

그렇기에 올해의 경험들을 잘 정리하여 간직하고자 한다.

"죽어도 행복을 포기하지 마라" 이것이 2025년 미래의 나에게 해주고 싶은 첫 번째 말이다.

너에게 전하는 아홉가지 바램 Song by KCM

두 번째, 작전계획서를 작성할 것

난 항상 명확한 기획서가 없어도 대략적인 일정을 파악하고, 업무를 진행했다.

운이 좋아 큰 문제가 생기지 않을 때도 있었지만, 모호한 기준으로 일정을 잡으니 일정은 틀어지게 되었다.

급해도 계획은 구체적이여야했다. 어떤 목표를 가지고 프로덕트가 탄생하는지, 이를 어떻게 세상에 알릴 것인지, 여기서 어떤 문제들이 생길 수 있는지. 등

'업무 목표'를 구체화하고, 이를 기반으로 의존성을 체크해야한다.

세 번째, 항상 겸손할 것

새로운 팀에 소속 되어 함께 생활해보니, 모두가 뛰어나고, 모두 각자의 역할에 최선을 다하고 있음을 알게 되었다.

내게 보이지 않는다고 누군가의 노력을 함부로 평가하면 안된다. 보이지 않는다면 볼 수 있게 노력하고, 항상 모두를 존중해야한다.

어느 순간 부터 '내 시간은 중요해'라는 착각에 빠졌다.

이에 어떤 일에 대한 공유에 대하여 "그래서 결론이 뭐에요?"라고 말을 하게 되었는데, 너무 오만했다고 생각 되었다.

결과를 빠르게 파악하는 것도 중요하지만, 과정을 존중하는 방법을 배워야겠다고 생각했다.

물론, 때로는 나의 시간이 중요할 수도 있다. 이 때, 정중하게 다음부터 조금 더 간결하게 말씀을 달라고 부탁해야한다.

난 효율만 추구하는 사람이 되고 싶지는 않고, 나와 어울리지 않는 모습이라고 생각이 들었다.

네 번째, 좋은 사람이 되려고 하지말 것

난 좋은 사람이 되는 것과 '예의'가 동일한 것이라고 생각했다.

그래서 모호한 업무들이 있으면 내가 해결하겠다고 나섰고, 이렇게 되면 상대방을 존중하는 것이라고 생각했다.

하지만, 부하가 발생하며 비효율이 시작 되었고, 결론적으로 몇몇 업무는 누군가에게 굉장히 좋은 경험이 될 수 있었는데, 그 기회를 줄 수 없었다.

의미 없는 업무가 될 것이라 스스로 판단한 것은 나의 실수였고,

스스로 판단하여 도움을 요청하지 않은 것도 나의 실수였다.

그리고, 프로젝트와 팀을 생각하면 나 또한, 마땅히 해야할 역할이 있는 것 같다.

나의 마음이 편하려고 한 행동에 병목이 발생하고, 이 병목은 다른 곳에서 예상하지 못한 문제를 발생시키기도 했다.

좋은 사람인 척하기보다, 더 좋은 가치를 프로젝트에 가져다주는 것이 어떨까 싶다.

다섯 번째, 유연성을 갖출 것

신규 프로젝트의 특성 중 대표적인 하나는 무엇보다 '변화'이다. 즉, '변화'에 유연하게 대처 해야한다.

변화를 최소화하기 위한 노력은 당연히 필요하지만, 이와 별개로 경우의 수를 대비할 수 있게 유연성을 갖추어야한다.

계획을 수립할 때, 시야를 넓게 펼쳐보고 많은 경우의 수를 추출해야된다.

변화됨을 탓하기보다, 변화에 대응해야겠다.

여섯 번째, 좋은 실수를 할 것

개발 실수, 배포 실수, 공유 실수 등.

실수를 하는 것은 크게 문제 되지 않는다고 생각한다.

다만, 실수 방지에 대한 생각을 하지 않았기에 반복 된 실수가 나오는 것은 큰 문제라고 생각한다.

실수를 하면, 정중하게 사과하고 멋지게 다음을 대비해야겠다.

일곱 번째, 지식은 형식지로 만들 것

"지식에는 2가지 형태가 존재한단다. 암묵지와 형식지"

암묵지는 학습과 경험을 통하여 개인에게 체화 되어 있지만, 언어나 문자로 표현하기 어려운 지식을 말한다.
(자전거를 타는 경험이라던가, 내가 회고에 썼던 흑섬, 스트라이크존, 금강불괴라던가)

형식지는 암묵지와 상대되는 개념으로 언어나 문자로 표현 되는 지식으로 우리가 문자로 배우는 지식들을 말한다.

살아가며 경험하는 지식을 짧게나마 형식지로 만드는 연습을 해야한다.

가장 좋은 것은 그것에 연결되는 단어나 문장을 기록하는 습관이다.

내가 느낀 것들을 형식지로 만들 수 있다면, 그 수 만큼 나는 성숙해질 것이다.

여덟 번째, 일기를 쓸 것

파이오니어 2차 테스트가 시작 되고, 첫 째날 동접으로 많은 감정을 느꼈다.

어떤 부분이 미흡 했었는지, 어떤 것이 아쉬웠는지 등

어렴풋이나마 느꼈던 나의 감정과 생각 같은 경험들을 기록하여 기억하지 못하면, 이 값진 경험은 휘발 될 것이다.

그리고, 아홉 번째 좋은 멘토를 구할 것

나의 좁아진 시야를 객관적으로 바로 잡아줄 수 있는 사람,

자신의 경험을 형식지로 전달해줄 수 있는 사람.

때론 내가 부정적인 감정을 쏟아내도 그 감정에 잠식 되지 않고,

다시금 나를 긍정적인 감정으로 바꾸어줄 수 있는 단단한 멘토가 있어야한다.

그리고, 나도 누군가에게는 이런 사람이 되어야겠다.

마치며

많이 부족하고, 아쉬웠던 한 해였다.

그렇지만, 발전할 수 있는 영역이 이렇게나 많이 남았음에 앞으로의 나의 성장이 기대 되기도 했다.

종종 꽤 다양한 분들에게 "우리는 성공할 수 있나요?" 라는 질문을 받곤 하는데.

사실 잘 모른다. 나 스스로 2025년에 나의 부족함을 극복 할 수 있을지도 모르겠는데~ 미래를 어찌 알 수 있을까?

하지만, 나는 언제나 그랬듯 내가 할 수 있는 영역에서 내가 할 수 있는 만큼의 최선을 다 할 것이고, 이 과정에서 웃음과 꿈을 잃지 않으려고 한다. 어짜피 해야할 것, 다시금 설렘을 가득 품고, 사무실로 향하는 내가 되길 바래본다.

"죽어도 행복을 포기하지 마라"

[회고] 나는 '악당'이 되어보기로 마음먹었다.

RyuK-H — Sun, 31 Dec 2023 19:44:42 +0900

난 네가 악당이 되었으면 좋겠다.

분사로 동료가 떠날 때, 이 메시지를 보냈었는데. 사실 그 메시지는 스스로에게 보내고 있었던 굉장히 무겁고 진지한 메시지였다.

That's Life · Frank Sinatra

여름쯤이였을까?

유튜브에서 과학자에 관련한 이야기를 보게 되었다.

"과학자들은 실패를 성공하기 위하여 끝까지 노력한다."

과학자들은 성공보다 실패가 익숙한 환경이기에 실패를 두려워하고 실패에 초점을 맞추기 보다

완성 된 실패를 하고, 완성 된 실패를 또 다른 성공의 발판으로 만드는 것이 중요하다고 했다.

듣다 보니 너무 공감되었다. 그들이 실패 하나하나에 의미를 부여한다면 끝도 없이 우울하다가 끝나지 않을까?

꽤 오랜 옛날 악당의 특징이라며 적혀있던 글을 읽었던 기억이 있다.

기억 속에서 서서히 지워지고 있었던 그때의 글이, 과학자의 이야기와 함께 다시금 떠올랐다.

악당의 다섯 가지 특징

1. 큰 꿈이 있다.

2. 연구개발을 열심히 한다.

3. 실패해도 기죽지 않는다.

4. 조직적으로 행동한다.

5. 잘 웃는다.

그저 그런 이야기들일 수 있지만, 이 이야기에는 2023년, 2024년 내가 취해야 할 태도가 명확하게 정의 되어있었다.

내가 나아가야 할 방향이 '큰 꿈을 가지고, 매사에 열심히이며, 실패해도 기죽지 않고, 조직적으로 행동하며 잘 웃는 것'이기 보다,

'악당처럼 행동하기' 라고 한 문장으로 정의할 수 있는 것만큼 좋은 것은 없는 것 같다. 목표는 단순해지고, 뚜렷해졌다.

그렇게 나는 '악당'이 되어보기로 마음먹었다.

좋았던 점

작년의 아쉬운 점이 올해의 좋았던 점이 되는 것 같다.

1) 나답게!

난 이제 어떤 태도로 내 역할에 임해야 하고, 어떤 것을 수행해야 하는지 깨달아버린 것 같다.

작년, 나 자신을 '애매모호한 포지션의 애송이'라고 생각했었다.

팀에 어떤 형태로 기여를 해야 하는지 잘 알지 못하였고, 이러한 생각과 태도는 결과적으로 모든 상황에서 썩 좋지 않게 반영되었다.

많은 분께 조언을 구해보았지만, 그 조언은 각기 달랐고 크게 와닿지 못했다.

이런 상황에서 나의 모든 생각과 태도에 대하여 확신보다는 불안이 컸고, '언제든 바뀔 수 있다.'라는 무적의 말을 꺼내며 불안정함을 합리화 해대며 시간 보내기를 반복했는데,

2023년 끝자락에서 뒤돌아보니 꽤 많은 것들이 긍정적으로 변화해 있었고 불안정하므로 시작했던 많은 것들이 오답은 아니었다고 생각한다.

협업하는 방법과 태도, 효율보다는 여러 상황에 따라 업무 분배를 하고, 파트 분리를 하는 등 내가 행하는 많은 생각과 행동들이

누군가의 기준에서는 좋은 리더라면 지양해야 할 것이었을지도 모르겠다.

다만, '팀 by 팀'이라는 말이 있듯, 리더마다 그 역할을 수행하는 방식은 달라질 수 있음을 깨달았고 내가 하는 방법들이 정답은 아니지만 오답도 아니라는 것을 느꼈다.

혹여나 나의 불안함이 전염이 될까, 걱정되었는데. 더는 이런 불안함을 갖지 않게 되어 이런 걱정을 할 필요가 없어졌다.

이 불안함을 떨쳐낸 것이 2023년 내가 가장 잘한 일이 아닐까 싶다.

2) 내가 줄 수 있는 '선물'을 찾았다.

스페셜리스트보다는 제너럴리스트에 가까운 내가 우리 팀에게 어떠한 이점을 줄 수 있을지 항상 고민해 왔다.

코드의 퀄리티에 대한 가르침을 줄 수도 없었고, 녹진한 경험을 통하여 인생의 가르침을 줄 수도 없었지만

아마 많은 리더 속에서 내가 가장 잘할 것 같고, 나이기에 줄 수 있는 선물을 생각하게 되었다.

이것이 얼마나 도움이 될지는 모르겠지만, 줄 수 있는 것이 있다는 것이 좋았다.

흑섬 쓰는 방법

그대는 흑섬을 아는가?

토도 아오이

주력을 담은 공격을 행하였을 때, 물리적 타격이 발생한 시간과 주력의 충돌이 발생한 시간 간의 오차가 0.000001초 이내였을 경우 발생하는 공간의 왜곡 현상.
흑섬이라 불리는 이유는 이때 주력이 검게 빛나기 때문이며, 타격의 위력은 평균적으로 약 2.5 제곱이 된다.
물리적 타격을 동반하는 술식의 경우, 흑섬이 발동했다면 그와 연동된 술식의 위력도 같이 상승한다.

흑섬을 한 번이라도 성공시킨 주술사와 그러지 못한 주술사의 차이는 매우 크다.

일종의 '감'을 깨우친 상태를 말하는데, 현실에서도 꽤 많은 예제가 있다.

스포츠 'Zone' / 불교 '금강불괴' 등 결국 이것들의 공통점은 어떤 상태를 경험하면 이전과 다른 영역으로 진입한다는 것이다.

면담 때마다 난 항상 자신을 한 단어로 표현할 수 있게 그 영역을 좁혀가야한다고 말을 한적이 있는데,

보통 이것은 연차를 거듭하면서 자신의 전문분야가 구체화 되는 과정이다. (우리는 이를 스페셜리스트가 된다고 한다.)

하지만, 이것이 개발 분야에 국한 되지 않는다고 생각하고, 다양한 방면에서 자신만의 무기를 찾을 수 있다고 생각하고 있다.

그리고 그 무기를 찾고 활용할 줄 알게 되면, 이전과 다른 것들이 보이게 되고 가치를 인정 받는다고 생각한다.

사실 이 무기를 찾는다는 것은 수능 이후, 자신의 적성에 맞추어 과를 지원하는 것과도 같은 난이도라고 생각한다.

그렇지만 이런 점을 공감하고 인지한다면 찾을 수 있는 확률이 조금이라도 올라간다고 확신한다.

류기혁 무기고

1) 성실함 → 정량화 / 자기객관화 / 자기어필

나는 어려서부터 굉장히 성실한 편이였다.

이 영향은 '공부를 못해도 성실하게만 살아라'라는 아버지의 말씀에 대하여 최소한의 도리라고 생각한 나의 양심이였다.

성실함이라는 무기는 증명하기가 굉장히 힘들고, 많은 사람들이 주장할 수 있기 때문에 가치가 적다.

이런 이유 때문에 요즘은 개근상에 대한 가치가 적은 것이 아닐까 싶다.

하지만, 나는 남들보다 더 성실하다고 생각했고 이런 무기를 버리고 싶지 않았다.

그렇기에 내 성실함을 정량화하기 위해 노력했다.

사회초년생 때 부터 데일리를 작성하면서 하루하루 겪은 내용들을 기록했다.

=> 업무를 진행함에 있어, 반복하여 물어보거나 박복하여 실수하는 경우가 없었다.

=> 연봉협상 시기에 내가 잘한 일들을 적어야할 때, 나는 사소한 것 하나까지 모두 적어서 제출하곤 했다.

=> 일처리가 썩 나쁘지 않았고, 이는 나의 평판과 이어졌다.

사실 이 무기의 가치는 '성실함' 보다는, '성실함'을 사용하기 위한 정량화 과정에서 나를 어떻게 포장하고, 보여주여야하는지 깨우친 것 같다.

2) 마리오 빨리 깨는 능력 → 문제해결능력

고슴도치도 자기 자식은 이뻐보인다고 했던가, 어려서 부모님은 시험을 못봐도 내가 플레이스테이션1으로 마리오 깨는 속도를 보며 "와 진짜 기혁인 뭐라도 될 애야"라고 말씀하셨다.

나의 자아가 성숙해지는 와중에도 '아.. 엄마가 마리오 실력 보고 놀랐는데.. 이거 어디에 써먹어야 되는거지?'라고 생각했었다. 이런 고민속에서 나중에 메이플스토리GM이 되어서 버프나 뿌리고 다녀야지 마음 먹었다.

그런데 살아가면서 여러 사건이 있었다.

부모님이 TV방 문을 잠구고 외출해도 문을 따는 방법을 깨달았던 것
부모님이 컴퓨터 전원선을 빼고 외출해도 파워선을 구해서 게임을 한 것
부모님이 키보드를 빼고 외출해도 가상 키보드로 크레이지아케이드를 한 것
수학 학원에서 고학년의 문제를 이상한 방법으로 풀어서 주목 받았던 것
적성검사 수시에서 전국구 인재가 되었던 적

이렇게 난 항상 생각하지 못한 방법으로 무언가를 해결하고 있었고, '문제 해결 능력'이라는 키워드를 알게 되었을 때.

마리오 빨리 깨는 능력은 문제 해결 능력과 연관이 있음을 알게 되었다.

솔직히 나에게 '문제해결능력'이 남들 보다 얼마나 날카롭게 준비되어있는 무기인지 모르겠지만,

나한테 이런 능력이 있다고 믿고 있기 때문에 문제가 발생 되었을 때, 항상 그 환경에 들어가려고 노력했다.

대표적으로 넥슨 쇼핑에서 카카오 페이 결제 문제가 있었을 때, 해결한다고 자신하고 약 2주동안 해결을 못했었는데. 결국은 잘 되었다.

확실하지 않지만, 자신있게 써먹으려는 이유는 나에게는 '성실함'이라는 무기가 있으니 '문제해결능력'으로 못이기면 무기 교체를 하면 어떻게든 끝낼 것이라는 확신이 있어서이다.

이 무기가 가치가 있었던 것은 나에게 주어진 '문제해결능력'과 관련 된 기회를 자신있게 잡을 수 있는 명분을 주기 때문이다.

나한테 '문제해결능력' 무기가 있을 수도 없을 수도 있지만, 나에게는 굉장히 가치가 있는 무기이다.

3) 'F' → 프로덕트 오너십

내가 MBTI 중에 유일하게 변하지 않는게 공감능력 이였구나. 지금 알았다.

난 무언가 공감 능력? 감정 이입 능력?이 좀 있는 편이다. 그래서일까, 난 어떤 서비스를 만들 때. 그 서비스를 '회사 것'이라고 인지하지 않고, '나의 소중한 작품'이라고 감정 이입을 심하게 한다.

사람들은 돈 더 주는 것도 아닌데, 왜 그렇게까지 해? 라고들 했는데. 나도 그러고 싶어서 그러는 건 아니고.. 성격이다.

그래서 나는 옛날부터 "난 개발자니까, 기획서에 나와있는 것 만들께요. 기획서만 일정내로 주세요."라고 하지 않고,

"여기 이상해요! 저기 이상해요! 여기에 이거 붙여보면 어때요?" 등등을 말하고 다녔다.

누군가에게는 굉장히 귀찮은 사람이 되었겠지만, 누군가에게는 적극적이고 좋은 사람이 될 수 있었던 것 같다.

그리고, 날 좋아해주는 사람은 높은 확률로 굉장히 좋은 사람들이였다.

아마 지금 이순간 나에게 가장 강력한 무기는 이 친구가 아닐까 싶다.

결론

나는 이렇게 생각하면서 이런 과정을 통해 무기를 찾았고, 이렇게 활용하고 싶다고 말을 해주고 싶었다.

아마 모두에게 간지작살나는 무기 하나는 분명히 있다. 그걸 찾아내어 정의하고, 활용하게 된다면 당신도 흑섬을 쓴 주술사가 될 것이다.

3) 약점이 강점이 되었다.

나 이제 주방도 맡을 수 있어요.

작년에 내 역량으로 인하여 포기 했던 서비스가 부메랑 처럼 돌아왔다. '아.. 이제 우리 팀의 정체성이 점점 명확해져서 좋겠다.'라는 생각도 들었고, '근데 나 GO언어도 모르고, 백엔드도 모르는데?'라는 걱정도 들었다.

내가 모르는 영역을 리딩 한다는 부담감은 내가 생각한 것 보다 더 무거웠고, 조금만 정신줄을 놓치면 내 자존감까지 건들 수 있는 상황이였다.

하지만, 직접 겪어보니 서비스의 구현 방법까지 알지 못하더라도 내가 할 수 있는 것들은 있었고

'나 혼자 만들어야 될 수도 있으니, 의존성을 줄여야한다.'라는 생각을 놓아버리니 쉽게 극복이 가능했다.

결국 내가 해야할 역할은 서비스의 내부 시스템이라기 보다, 그 본질이 의도한 방향으로 가고 있는가를 확인하고,

이 상황속에서 개개인이 좋은 경험을 하고 있는지 그리고, 노력으로 만들어진 서비스가 올바른 가치를 인정 받고 있는지라고 생각한다.

'나의 약점이 될 수 있으니까, 의존성을 줄인다.' 보다는 계속 같이 만들어나갈 수 있게 다른 매력을 높여갈까 싶다.

지금 자신감으로는 어떤 서비스든 만들어낼 수 있을 것 같다. 으랏챠

아쉬웠던 점

1) 난 아직도 비겁한 애송이였다.

항상 '나도 처음이라..', '나도 경험이 없어서.. ㅠㅠ'를 무기 처럼 썼다.
이 자체가 사실이기에 문제라고 생각하지는 않지만, 어느 순간 부터 나의 무기 마냥 휘두르는 나의 모습을 본적이 있다. 그 점은 잘 못 되었고, 너무 아쉽다.

2) 간장 종지 류기혁

(고해성사)
여러 문제가 있을 때, "아유 괜찮습니다.", "걱정마요!" 등등의 말을 해줄 때도 있었는데. 거짓말로 했을 때도 있었다. 썩 괜찮지 않아도 짜증을 낼 수는 없으니 괜찮다고 했다.
나는 어떤 상황이든 유하게 받아들이고, 녹진하게 문제를 해결 하고 싶다. 우리가 흔히 '녹진한 어른'이라고 생각하는 그 경지에 도달하고 싶고, 그런 팀이 되었으면 좋겠다.
그렇기 때문에 뭐 거참 짜증도 낼 수 있고, 거짓말로 괜찮다고 할 수 있지. 라고 생각할 수는 없었고, 이 점이 아쉬웠다.
또 다시 마음 가짐을 바꾼지 1-2개월 된 것 같은데. 앞으로 이 마음이 유지 될지는 모르겠지만, 멋진 어른이 되고 싶다.

3) 안식처

굉장히 개인적일 수 있지만, 솔직히 올해 우울증 걸릴 것 같은 기분을 몇 번 느꼈다.
왜 그런지는 잘 알지 못하지만, 내가 느끼는 부담감을 "난 악당이 될꺼야!"라며 아무렇지 않은 척하려는 괴리 때문인가 싶기도 하고, 갱년기인가 싶기도 하다.
아무튼 이런 개인적인 피로들을 어떻게 풀어내야할 지, 아직 잘 모르겠다. 워낙 성격이 하루 자면 잊어버리기에 이런 피로에 대한 해결 방법을 생각하면서 살아오지는 않았는데.
내년에는 조금 찾아볼까 싶다.

[회고] 난 어른이 되어가고 있는 것 같다.

RyuK-H — Tue, 27 Dec 2022 01:29:19 +0900

1) 나의 2022년은 몇 퍼센트가 운이었을까?

어울리는 배경음악이랄까? 그대들은 어떤 기분이신가요 MR

내가 넥슨의 블록체인 프로젝트를 하는 것이 운일까?

난 넥슨의 블록체인 프로젝트의 초창기 멤버이다.

현재의 넥슨의 블록체인본부가 성장하는 모습을 처음부터 지켜보았고, 함께 성장도 했다.

넥슨에서 블록체인과 관련 없는 프론트웹개발팀에 있던 내가 대외비였던 블록체인 프로젝트에 호출될 수 있었던 이유는 운 때문이었을까?

올해에는 강대현 부사장님과 외부업체를 만나러 다니고, 프로젝트에 대한 이야기를 자주 하다 보니 자연스레 같이 있는 시간이 많았고, 이야기할 시간도 많았다. 아마 추웠던 금요일 점심쯤 이였던 것 같다. 강남으로 이동하는 중에 난 부사장님께 물었다.

류기혁: "부사장님 제가 프로젝트A(메이플유니버스의 초기 이름)를 하게 된 것이 순전히 운일까요?"

강대현: "왜요? 기혁님은 어떻게 생각하는데요?"

류기혁: "저는 운이 아니라고 생각해요. 넥슨에 입사한 2020년부터 이렇게 될 것이라 믿었거든요. 그래서 제가 부사장님이랑 일하고, 신규 사업에 참여하는 게 운이 좋다.라고 이야기 하면 제 노력이 없어지는 것 같아요."

남들한텐 모르겠고, 적어도 나한텐 따뜻하신 분이다.

내가 넥슨을 나가지 않은 이유

난 과거 넥슨 블록체인 자회사였던 블록체인엔터테인먼트랩(BEL)에 속해있었다.

당시 블록체인 산업이 좋지 않았고, 정확한 비전을 제시하지 못하여 우리 프로젝트는 사라지게 되었고,

나는 블록체인서비스 개발자 포지션이었기에 마땅히 이동할 수 있는 팀이 없어 포지션을 변경했어야 했다.

그렇게 프론트엔드 개발자를 선택했고, 나름대로 이것저것 재미있는 프로젝트들을 경험하게 되었다.

반면 과거 동료들은 "넥슨에서는 블록체인 못해"라는 말을 하고, 다른 블록체인 업계로 떠났다.

내가 넥슨을 떠나지 않은 이유는 사실 단순했던 것 같다.

직전의 나의 창업은 마치 어린애들의 장난 같았다. 조금은 성숙함을 배워보고 싶었다.

또 다른 하나는 '우리 프로젝트의 실패와 프로젝트가 접히는 것에 대한 억울함에 공감하지 못했다.'

즉, 넥슨이어서 못하는 것이 아니라 우리의 아이템이 아직 블록체인을 어떻게 사용해야 하는지 모르고 만들었고 프로젝트가 접히는 것은 꽤나 합당한 결정이라고 생각했다.

그래서 난 '넥슨에서는 블록체인 못해'라는 말에 공감할 때까지 스스로 무언가를 해보고 싶었고,

언젠가 넥슨에서 다시 한번 블록체인을 해볼 기회를 만들 수 있을 것이라 믿었다.

난 직접 경험해보지 않은 것에는 공감을 잘 못하는 편이다..

넥슨에 블록체인 하는 애

가장 먼저 시작한 것은 '류기혁 = 블록체인 하는 애'라는 인식을 퍼뜨리는 것이었다.

1) 외부 강연

당시 코로나로 외부 강연 프로세스가 정말 너무 복잡했다.

너무 귀찮아서 휴가를 내고 조용히 다녀오는 것이 편했을 것 같지만, 결재라인이 굉장히 높은 곳까지 닿아있었다.

내가 블록체인 외부강연을 다녀오면 적어도 나의 결재라인분들은 내가 블록체인 활동을 하고 있는 것을 알 수 있지 않을까? 생각했다.

그렇게 약 4번 정도의 외부강연을 했고, 이로 인하여 처음으로 부사장님과 게임디렉터님들 앞에서 블록체인에 대한 발표를 하게 되었다.

제주도가 너무 가고 싶었는데, 회사에서 비대면으로 하라고 했다.

2) 블록체인 도입 아이디어

당시 나는 현재의 메이플 월드 프로젝트를 담당하게 되었다. NFT가 적용된다면 어떨까 많이 고민하고, 아이디어를 냈다. 그 외, 넥슨플레이 / 넥슨쇼핑에 대해서도 이야기했다.

이에 대하여 당시 나의 멘토는 칭찬과 우려를 해주셨다.

'이런 아이디어 너무 좋은데, 지금은 프론트개발자로서의 역량에 집중하는 게 장기적으로 좋지 않을까?' 등

결론적으로 이 또한, '류기혁 = 블록체인 하는 애'라는 인식을 퍼뜨리는 것에 일부였다고 생각한다.

3) 사내 NFT 프로젝트

결론적으로 이 프로젝트는 프로젝트A 합류 이후 완성되었지만, 이와 같은 이벤트도 진행했다.

(퇴근 후, 새벽까지 도트를 찍다가 허리디스크가 터졌다. 이것이 2021년 회고가 없는 이유이다.)

그래서 운일까?

뭐 사실 운이고, 운이 아니고 가 크게 중요한 것은 아니다. 그럼에도 '운'을 따진 이유에 대하여 2022년 끝자락에 와서 생각해 보니.

나는 WEB3.0을 믿었고, 스스로 블록체인 도입에 대하여 사업적인 측면을 포함하여 논리적으로 설득할 수 있게 될 때, 넥슨도 블록체인을 분명 도입할 것이라고 굳게 믿었다.

아마도 난 넥슨의 WEB3.0 시작에 내가 있을 수 있게 차근차근 준비를 한 것에 대한 인정을 받고 싶었던 것 같다.

운칠기삼?

아니. 그래도 난 운삼기칠로 하고 싶다.

프로젝트 초기에 난 나만의 블록체인 도입의 이유를 정의 했었다.

2) 난 개발자일까? 리더일까?

기혁님은 아직 개발이 하고 싶으신가요?

프로젝트 초기부터 '프론트웹개발파트 파트장 -> 블록체인팀 팀장 -> 블록체인팀 개발 파트장 -> 블록체인개발팀 부팀장 -> 블록체인개발팀 팀장'을 거쳤다. '류기혁이라는 사람이 영리하고 뛰어나다.'라기보다는 그저 블록체인을 오래 했고, 넥슨에 오래 있었고, 프로젝트의 변화 과정을 파악하고 있다는 이유 때문이었다. 직책이 크게 중요하다고 생각해본 적은 없던 것 같다. 그저 팀의 구성원인 시절에도 난 내가 담당했던 프로젝트 부분 부분에 내 색을 표현할 수 있는 사람이라고 생각했기 때문이다. 그래도 언젠가 한번쯤은 팀장이라는 것을 해보고 싶긴 했다.

팀 by 팀이겠지만 막상 직책을 맡고 보니, 코드를 짤 시간은커녕 볼 시간도 없었다.

스타트업 창업을 했을 때와는 운영 난이도 자체가 틀렸고, 결정적으로 팀의 규모가 엄청 컸다.

한 사람이 운영할 수 있는 팀의 수가 8명 이하가 이상적이라고 들었는데, 우리 팀은 그 숫자를 아득히 뛰어넘었고,

블록체인이라는 신사업에 관심이 있는 개발자들이기 때문에 대부분 신입이거나, 다른 부서에서 참여한 유대감이라고는 1도 없는 사람들 뿐이었다.

팀의 규모가 커질 때로 커지니, 무언가 가슴이 답답하고 무서웠던 것 같다.

많은 상급자분들과 면담을 했고,

공통적으로 받은 질문은 '아직 개발이 하고 싶으세요?'였다.

"네. 아직은요. 지금 개발을 놓기에는 제 경력은 충분하지 않고, 아직은 제 강점을 놓고 싶지 않습니다."

난 그렇게 팀장에서 다시 파트장으로의 이동을 반복했다.

난 비겁한 애송이였던 것 같다.

이 혼란한 시기에 내가 택한 방법은 리더의 역할을 분배한 일이었다.

그렇게 얻은 시간에 나는 실무를 할 생각이었다. 개인적으로 느끼기에 이 시기에 팀의 혼란은 더 가속화되었고, 명확하게 팀 비전을 제시할 리더는 공석이었다.

출퇴근을 하는 차 안에서 가장 생각을 많이 하는 데.

이 당시 나는 기회가 찾아왔음에도 잡지 못하는 나의 역량을 매우 비관했던 것 같다.

난 리더도 실무자도 아닌 비겁한 애송이였다.

9월 17일 토요일

강대현 부사장님이 나와 친한 회사 동생에게 밥을 사주신다고 했다. 여느 때와 같이 철없는 농담을 하다가 나의 고민을 얘기했다.

전 아직 매니징을 하는 것이 무서워요. 마치 넥슨이라는 모래 늪에 점점 빠져드는 것 같아요. 어떤 계기로 이직을 하게 되었다고 가정하면 "저는 넥슨에서 블록체인개발팀장을 하던 류기혁입니다! 아차차. 근데 개발은 손 놓은 지 1년 돼서 실무 투입하려면 시간이 좀 걸려요 ㅎㅎ" 보다는 "넥슨에서 블록체인을 개발한 류기혁입니다."가 더 가치 있지 않을까요?

이 말을 듣고 부사장님은 자신이 개발자였던 과거 이야기를 해주셨다.

이 값진 이야기의 결론은 나의 마음을 결정하게 된 계기가 되었다.

"난 개발자로서 최고가 될 자신이 없었다. 그렇기에 끊임없이 강력한 무기가 될 수 있는 다른 스킬들을 늘려나갔다. 이를 기혁님에게 대입하면 매니징도 하나의 스킬이 아닐까 생각된다."

"단순히 직군으로 자신을 표현하기보다는 하나의 키워드로 자신을 표현하는 것이 중요할 것 같다. 내 생각에는 류기혁의 키워드는 넥슨의 블록체인인 것 같고, 충분히 잘해나가고 있다고 생각한다."

그리고 돌아오는 월요일에 나는 개발자보다는 매니징을 하고 싶다고 보고했다.

블록체인개발유닛 팀장

감사한 조언들이 많았다. 그중에서도 본부장님의 '팀의 리더는 아직 실무자이다.'라고 했던 조언이 기억났다.

개발자는 꼭 코드를 타이핑해야 될 수 있는 것이 아니고, 나 또한 팀원들 보다 개발 속도는 느려지고 있을 수 있지만 충분히 할 수 있고 오히려 전체적인 그림을 볼 수 있음에 감사하라고 했다.

1년이 훨씬 넘는 시간이 지나고서야, 지금 내가 집중해야 할 것이 무엇인지 알게 되었다.

2023년 난 최고의 블록체인개발팀을 만들어보려고 한다.

적어도 블록체인 게임 생태계에서는 가장 유의미한 제품을 만들고, 그 과정에서 각 구성원이 빛날 수 있는 환경을 만들 것이다.

그다음 일은 그다음에 생각할까 싶다.

3) 끝으로

2022년 한 해는 정말 많이 배웠다.

커다란 회사에서 새로운 산업에 대한 프로젝트가 어떻게 생겨나고,

어떻게 성장해나가는지에 대하여 옆에서 생생히 보았고, 아직도 보고 있다.

팀 또한 마찬가지였다.

팀이 생겨나, 성장함에 따라 어떤 요소들이 필요하고 문제가 생겼을 때 어떻게 극복하는지 배웠다.

아마 항상 그래왔듯, 2023년이 되면 또 새로운 문제가 생겨날 것이고 어김없이 이를 극복해나갈 것이다.

2023년의 끝자락에 내가 어떤 사람이 될지는 잘 모르겠다.

블록체인개발자? 프론트개발자? 아니면 다시 게임개발자? 아니, 더 나아가 개발자는 될 수 있을까?

근데 분명한 건 기존 기업의 블록체인 프로젝트 보다 더 멋진 제품을 만들 것이고, 아마 우리 팀은 선두를 달리는 팀이 될 것이라 믿어 의심치 않는다.

나의 뒤에는 든든한 백커 넥슨이 있고,

넥슨에는 조금은 비상식적인 류기혁이 있다.

난 WEB2와 WEB3의 브릿지가 되고 싶다.

ps. 이번 회고에서는 잘한 점을 적지 않았는데.. 바쁜 시간 속에 꾸역꾸역 NDC에 나가 발표를 한 것이 너무 뿌듯하다.

그리고, 2023년 9월 23일에 결혼을 하게 되었다. 조금은 더 성숙해져가고 있다.

코인원 래퍼럴 코드: MRVKXTUJ 인사 오지게 박습니다. 행님덜

RyuK-H — Fri, 9 Apr 2021 00:23:52 +0900

래퍼럴 코드 : MRVKXTUJ

안녕하십니까. 류짱 행님덜에게 인사 오지게 박습니다.

코인원에는 추천한 친구가 매수하는 수수료 중 20%를 노나 먹는 시스템이 있습니다.

저의 래퍼럴 코드 비율은 저 10%, 행님 10% 이며, 행님의 매수를 응원합니다.

아래 스크린샷은 행님덜이 절 추천해주시고 신나게 매수하고 있으신 코인 목록입니다.

고래 행님이 절 추천하신듯 보입니다.

그럼 성투하십쇼 사랑합니다.

[기혁이의 아장아장 백엔드 도전기] 3화, 언어와 프레임워크

RyuK-H — Fri, 18 Dec 2020 14:28:14 +0900

첫 번째 스텝으로 백엔드 직군의 역할은 무엇인지에 대하여 파악해야할 것이며

두 번째 스텝으로 백엔드의 전체적인 구조에 대하여 알고 있어야 하며

세 번째 스텝으로 어떤 언어들이 있고 각 언어, 프레임워크들이 어떤 특징을 갖고 있는지 알아야 하며

마지막으로 내게 필요한 언어와 프레임워크를 통하여 실습하며 점점 고도화를 진행하면 좋을 것 같다.

두 번째 스텝으로 백엔드의 전체적인 구조를 살펴보며, 백엔드에는 웹서버, WAS, 데이터베이스가 있다는 것을 알 수 있었다. 그렇다면, 백엔드 개발자가 되기 위해서는 어떤 언어들을 선택할 수 있으며 어떤 프레임워크를 다룰 수 있어야하는지 알아보자.

프론트엔드의 언어 & 프레임워크

프론트엔드는 언어가 매우 한정적이다. 웹 브라우저가 해석할 수 있는 언어는 Javascript에 한정 되기 때문이다. 물론, Typescript와 같은 JS의 단점을 보완하기 위한 언어도 있다. 대신, 프로젝트에서 자체적으로 TS를 JS로 컴파일 해야한다. 위와 같은 이유로 프론트엔드에서는 HTML, CSS 그리고, JS를 습득한다면 React, Vue, Angular와 같은 프레임워크를 선택하여 프론트엔드 개발자에 도전해볼 수 있다.

또, React-Native(모바일), Electron(데스크탑)과 같은 프레임워크들을 통하여 웹 개발 환경과 비슷하게 모바일 앱, 데스크탑 앱 또한 만들 수 있다. 접근성이 낮은 것 같지만 빠르게 변화되고 있는 프론트에 맞추어 발전해야하고, 다른 디바이스에 대한 기술 스텍도 비슷하기에 여러가지를 다루어야하는 상황이 나올 수 있다. 언어와 개발 환경은 같지만 더 넓은 지식을 요구함은 분명하다.

백엔드의 언어 & 프레임워크

백엔드의 언어는 단순히 내 기억만 되짚어 보아도 자바, 파이썬, 루비, 자바스크립트, C, C++, C#, Go, PHP 등이 있고, 프레임워크로는 express, flask, spring, django, ruby on rails 등이 있다. 각각 장단점은 아직 모르겠지만 프론트엔드와 달리 언어에 선택지가 다양하다는 것을 알 수 있다.

웹 서버

2화에서 웹 서버에는 Nginx, Apache 등이 있다고 알 수 있었다. 그렇다면 이것을 다루기 위해서는 어떤 준비를 해야할까?

Nginx(엔진x)

어떤 웹페이지를 들어가다 오류가 나타날 때, 우리는 아래와 같은 에러 페이지를 본 적이 분명 있다. (그리고 그 밑에 nginx가 적혀 있었다.) 정확히 이 친구가 어떤일을 하는지 까지는 단순히 이론 공부에서 알기 힘드니. Nginx 예제를 검색하여 이 친구를 다루기 위해 어떤 일을 해야하는 지 알아보자.

Niginx 특징

Nginx는 C언어로 만들어졌다.
Nginx는 아파치와 다르게 오픈소스 웹 서버이다.
이벤트 기반으로 설계 되어 있다.

Nginx는 설정 파일을 수정하여 이벤트를 설정하는 정도로 사용 된다. 그러므로 별도의 언어 학습은 필요 없다고 판단 되고, 그저 사용 경험이 있느냐에 따라 차이가 생길 것 같다.(물론, 내부 로직을 수정해야한다면 C언어를 학습해야겠지만 프레임워크를 손대는 것은 일반적인 개발자가 하는 일은 아니기 때문에 여기 까지만 알아보자.)

server {
    location / {
        root /data/RyuK;
    }
 
    location /images/ {
        root /data;
    }
}

실제 nginx에 대한 키워드로 채용공고를 찾아보면, 경험 & 이해라는 것이 우대사항에 들어가있는 정도이다.

AWS 등 클라우드 서버와 웹서버에 대한 이해도가 높은 분(Apache/Nginx/Tomcat)
Nginx 사용 경험
nginx 또는 guniconrn 환경 개발 및 운영 경험

Apache(아파치)

nginx 에러페이지는 꽤나 받지만 nginx와 다르게 아파치 에러페이지는 기억이 없는 것 같다.

Apache 특징

아파치는 아파치 소프트웨어 재단에서 관리한다.
2012년 부터 점유율은 꾸준히 하락해 왔다.
하지만 오래된 역사가 보여주듯. 트러블슈팅에 관련 된 팁들이 많이 누적되어 있기 때문에 선호하는 사람이 많다.
C언어로 구성 되어있다.

nginx와 마찬가지로 설정파일을 수정하는 방식으로 사용되기 때문에 언어에 대한 이해도 보다는 경험을 필요로 하는 것 같다.

간단히 살펴 보는 둘의 차이점

Apache는 MPM(Multi-Process Module)방식으로 요청을 처리한다. 동시 접속 요청이 들어오면 CPU와 메모리 사용이 증가한다. (동시 접속 요청에 약점)
Nginx는 Event-Driven 방식으로 요청을 처리한다. 동시접속 요청이 늘어나도 비동기 방식으로 처리되기 때문에 추가적인 생성비용이 들어가지 않는다. (Apache와 다르게 동적 콘텐츠를 기본적으로 처리 할 수 없다.)
Apache는 Nginx에 비해 모듈이 다양하다.
Apache는 안정성, 확장성, 호환성에 강점이 있고, Nginx는 성능이 우세한 강점이 있다.
Apache는 동적인 콘텐츠를 기본적으로 다룰 수 있고, 다양한 모듈이 지원되기 때문에 동적인 콘텐츠를 다루는 웹 서버일 경우 강점을 갖는다.
Ngnix는 트래픽이 많은 정적 콘텐츠 및 미디어 스트림이 제공 되야하는 곳에 조금 더 어울린다.

WAS(Web Application Server)

백엔드의 주요 업무가 진행 되는 WAS의 기술 스텍은 어떻게 될까? 아래 스택오버플로우의 2020년 설문을 보면 프론트, 백엔드에 관계 없이 Web Frameworks 카테고리에 나타나있다. 참고해보자.

아직 2020년이 다 가지는 않았지만 stackoverflow의 2020 survey

언어

Java
Python
Scala
Node.js (Javascript)
Ruby
Go
C#
PHP

프레임워크

Spring (Java)
Django (Python)
Flask (Python)
Express (Node.js)
Koa (Node.js)
Play Framework (Scala)
.Net Framework (C#)
Laravel (PHP)
Ruby On Rails (Ruby)
Revel (Go)
Gin (Go)

이 외 더 다양한 프레임워크들이 존재한다. 채용 시장과 2020 Survey를 참고 했을 때, NodeJS와 Django가 조금 우세하다는 것을 알 수 있었다.

이런 다양한 환경에 대하여 차이점을 운운하는 것을 적절하지 않다고 생각 된다. 자신이 선호하는 언어가 있다면 그에 따른 프레임워크를 선택하면 좋을 것 같고, 딱히 선호하는 언어가 없다면 취업시장에서 강세인 express, django 혹은 요즘 대세라고 불리우는 Go언어 관련 웹 프레임워크를 사용해도 좋을 것 같다.

DataBase

서버에 대하여 알아보았다면 서버를 통하여 데이터를 저장하는 데이터베이스에 대하여 알아보아야한다.

stackoverflow의 2020 survey & stackoverflow의 2020 survey

위 DB 트랜드에서 MySQL, MongoDB를 많이 들어보았던 것 같다. 각 DB에는 어떤 차이가 있을 까?

MySQL

MySQL은 Oracle이 소유하고, 관리하는 관계형 데이터베이스(RDBMS)이다.
데이터를 Table에 저장 한다.
SQL(Structured Query Language)을 이용하여 DB에 접근한다.
데이터베이스 스키마를 먼저 정의해야하고, 테이블에 들어갈 필드들에 대한 규칙을 규정하여 사용한다.

MongoDB (No SQL)

NoSQL로 JSON과 비슷한 형태의 document로 데이터를 저장한다.
documnet는 관련된 데이터를 한 번에 저장한다.
MQL(MongoDB Query Language)을 이용하여 DB에 접근한다.
document는 정해진 스키마를 사용하지 않기 때문에 각 필드는 항상 달라질 수 있다. 만약 스키마에 대한 검증이 필요하다면 Collection에 대한 데이터의 조건을 선택하여 추가할 수 있다.

{
	Name : "면봉",
	Tags : ["생활용품"],
	Price : 2000
}
{
	Name : "다람쥐 인형",
	Tags : ["ETC"],
	Price : 15000
}
{
	Name : "양말",
	Tags : ["생활용품", "의류"],
	Price : 2000
}

내 생각

어떨 때 무엇을 쓰면 좋은지 짧게나마 알고 싶었는데. 아직 잘 모르겠다. MySQL과 모든 관계형 데이터 베이스의 태생적 약점인 확장성과 관련되서 MongoDB와 같은 NoSQL 형태의 DB과 관심을 받고 있다고 한다. (이마저도 수년 전의 글이지만) 하지만, 아직 까지 MySQL의 점유율이 굳건한 것은 트랜잭션 데이터는 행과 열로 구성 된 테이블 형태와 잘 맞기 때문이라고 한다. 하지만 MySQL, NoSQL에 대한 경험은 한 번씩 사이좋게 쌓아보는 것이 내 인생에 도움이 될 것 같다.

[기혁이의 아장아장 백엔드 도전기] 2화, 어떤 것을 어떻게 만들게 될까?

RyuK-H — Wed, 16 Dec 2020 16:19:07 +0900

첫 번째 스텝으로 백엔드 직군의 역할은 무엇인지에 대하여 파악해야할 것이며

두 번째 스텝으로 백엔드의 전체적인 구조에 대하여 알고 있어야 하며

세 번째 스텝으로 어떤 언어들이 있고 각 언어, 프레임워크들이 어떤 특징을 갖고 있는지 알아야 하며

마지막으로 내게 필요한 언어와 프레임워크를 통하여 실습하며 점점 고도화를 진행하면 좋을 것 같다.

첫 번째 스텝으로 백엔드 직군은 무엇을 의미하는지와 역할에 대하여 알아보았다.

오늘은 백엔드의 전체적인 구조를 파악하며, 어떤 작업들을 진행해야하는지 전체적인 그림을 그려보자.

다행히 리서치 하는 중 리디북스 서버 스택 소개라는 좋은 글이 있었다. 이 글을 기반으로 힌트를 얻어가보면 좋을 것 같다.

Proxy, Apache, Ngnix, Node.js, ElasticSearch, MariaDB, Redis 정도는 어디서 들어본 적이 있는 것들이였다.

2번 째 레이어는 서버를 의미하는 것 같고, 3번째 레이어는 MariaDB도 그렇고 전체적으로 DB로써의 역할을 수행하는 것 같다.

서버

웹서버 (참고)

하드웨어 측면

웹사이트의 컴포넌트 파일들을 저장하는 컴퓨터이다. (HTML, CSS, JS 등)
웹서버는 인터넷에 연결되어 웹에 연결된 다른 기기들이 웹 서버의 데이터를 주고 받을 수 있도록 한다.

소프트웨어 측면

사용자가 파일들에 어떻게 접근하는지 관리한다.
HTTP서버는 URL과 HTTP의 소프트웨어 일부이다.

출처 : https://developer.mozilla.org/

간단하게 현재 수준에서 정리하고 넘어가자면, 웹 서버는 웹 페이지를 클라이언트로 전달하는 역할을 수행한다. 물론, 이런 공통 기능 외 여러가지 기능들이 지원 되고 사용 되고 있는 것으로 보인다. 하지만, 나 같은 뉴비는 모두 챙기려다 아무것도 챙기지 못하게 될 수 있으니 여기까지만 알아보자.

출처 : netcraft Web-Survey 2020-11

위키를 보니 웹서버의 시장 구조 자료가 2013년 것이여서 직접 찾아보았다. 과거에는 아파치 50% 이상 IIS 16%, nginx 15% 점유율을 갖고 있었는데. 현재는 ngnix가 34%의 점유율로 1위를 달리고 있었다. 추후, nginx가 어떻게 점유율을 늘려갔는지에 대하여 조사해볼 필요가 있을 것 같다.

+ 이후 추가 (참고)

웹서버

웹서버는 기능은 두 가지 정도로 나누어 볼 수 있다.

[정적]

정적인 콘텐츠 제공
WAS(Web Application Server)를 거치지 않고 바로 자원을 제공한다.

[동적]

동적인 콘텐츠 제공을 위한 요청을 전달 하는 역할
클라이언트 요청(Reqeust)을 WAS에게 보내고, WAS가 처리한 결과를 다시 클라이언트에게 응답(Response)한다.

처음 웹서버를 이해할 때는 단순히 웹페이지에 대한 자원을 저장하고, 반환하는 역할을 수행하는줄 알았는데. 이렇게 이해하기 보다는 전달자로 이해하는 것이 좋을 것 같다. 결국 정적 페이지도 DB에서 꺼내주는 역할을 수행하고, 정적인 것 외, 동적 콘텐츠의 경우 WAS에게 이 사실을 알려주는 역할을 한달까?

WAS

WAS란 우리가 흔히 알고 있는 백엔드의 업무가 담겨 있는 곳 같다. 사전적 정의로는 DB조회나 다양한 로직 처리를 요구하는 동적인 콘텐츠를 제공하기 위한 서버를 뜻한다.

HTTP를 통하여 컴퓨터나 장치에 애플리케이션을 수행해주는 미들웨어이다.
웹 컨테이너, 서블릿 컨테이너라고도 불리운다.
WAS = Web Server + Web Container
웹 서버의 기능들을 구조적으로 분리하여 처리하고자하는 목적으로 제시 되었다.
- 분산 트랜잭션, 보안, 메시징, 쓰레드 처리 등의 기능을 처리하는 분산 환경에서 사용 된다.
- 결국 웹서버의 효율을 위해 생겨난 개념 같다. (웹서버가 먼저 나오고 그 다음 WAS 라는 개념이 나왔겠지?)
현재는 WAS가 갖고 있는 웹서버도 정적인 콘텐츠를 처리하는데 성능상 큰 문제가 없다.
DB 접속 기능, 여러 개의 트랜잭션 관리 기능, 비즈니스 로직 수행이 주 업무이다.
Tomcat, JBoss, Jeus, Web Sphere 등이 있다.

웹 API (참고)

API(Application Programming Interface)는 프로그램들이 서로 상호작용하는 것을 도와주는 매개체 역할을 수행한다. 비슷한 맥락이지만 웹 서비스에서 API란 서버에 어떠한 요청을 하였을 때, 그에 맞는 응답을 줄 수 있는 Endpoint를 Web을 통하여 노출한 것이다. 여기서 EndPoint를 관리하는 API 서버로 이해하면 될 것 같다.

프리모아 API 요약 : '기본적으로 API를 사용하면 어플리케이션을 통한 쌍방 통신이 가능합니다. 사람들이 API에 대해 정의를 내릴 때 종종 일반화하는 듯하는 모습도 많이 보여줍니다. API의 실질적 정의는 공공 웹 기반 API는 데이터 반환 시스템으로 JSON이나 XML과 유사한데 API는 데이터베이스나 서버로 분류되지 않으며 서버의 접근 포인트를 관리하는 코드입니다.'

출처 : 프리모아

그렇다면 웹 API는 어떤 역할을 수행하게 될까?

(1) API는 서버와 데이터베이스에 대한 출입구 역할을 한다

접근 권한에 따라 데이터를 제공해줄 수 있다.

(2) API는 모든 접속을 표준화한다.

API는 모든 접속을 표준화하기 때문에 디바이스, 환경에 관계 없이 동일한 응답 값을 얻을 수 있다.

대표적인 방법론으로 SOAP API, REST API가 있다.

출처 : 위시켓

express(node.js)를 활용하여 구성할 수도 있고, spring(Java)를 활용할 수 있다. 딱히, 언어의 제약이 있지 않고 방법론만 추구한다면 되는 것 같다. 다만, express, spring, flask(python)등이 친숙한 것을 보니 대중적인 것은 이것들인 것 같다.

데이터베이스

사전적 의미 (참고)

데이터베이스란 일반적으로 컴퓨터 시스템에 전자 방식으로 저장된 구조화된 정보 또는 데이터의 체계적인 집합을 의미합니다. 데이터베이스는 보통 데이터베이스 관리 시스템(DBMS)에 의해 제어됩니다. 데이터와 DBMS는 연관된 어플리케이션들과 함께 '데이터베이스 시스템'으로 일컬어지며, 더 짧게는 '데이터베이스'라고 통칭되기도 합니다.

오늘날 운용되는 가장 공통적인 유형의 데이터베이스 내 데이터는 일반적으로 일련의 표 안에 행과 열로 모델링되며, 이는 프로세싱과 데이터 쿼리 작업을 더 효율적으로 실행하기 위함입니다. 이로써 데이터는 쉽게 액세스, 관리, 수정, 업데이트, 제어, 체계화될 수 있습니다. 대부분의 데이터베이스는 데이터 작성 및 쿼리 작업에 구조화 질의 언어(SQL)를 사용합니다.

데이터 베이스의 종류

데이터 베이스는 크게 관계형 데이터베이스(RDB)와 NoSQL로 나누어진다.

관계형 데이터베이스(RDB)

가장 많이 사용 되는 데이터베이스로 행과 열로 표현되는 테이블간의 관계를 나타낼 때 사용된다. SQL을 통하여 관리 및 접근이 가능하다.
RDB의 종류로 Oracle, MySQL(Oracle) / MS-SQL(Microsoft) / DB2, Infomix(IBM) / Maria DB(Sun Microsystems) / Derby(Apache) / SQLite(Opensource)등이 있다.

NoSQL(Not Only SQL)

NoSQL은 RDB의 특성 뿐만 아니라 다른 특성도 지원하는 데이터베이스를 의미한다.
대용량, 데이터 분산 처리에 용이하고, 유여한 데이터 모델링이 가능하다.
NoSQL Document방식에는 MongoDB(MongoDB Inc.), CouchDB(Apache)가 있다.
NoSQL Key-Value방식에는 Redis, Memchached등이 있다.
NoSQL Big Table DB에는 HBase, Cassandra, Hypertable, ScyllaDB등이 있다.

결론

이번에는 커다란 백엔드의 구조에 대한 그림을 머리속에 넣고 싶었다. 그래서 처음 잡은 공부 방향에서 이해가 되지 않아 해매다가 결국 WAS라는 개념을 알게 되면서 어느정도 정리가 된 것 같다.

예상과 같이 웹 서버는 다양한 구조를 갖을 수 있다.

하지만, 대부분 Client → Web Server → WAS → DB형태를 나타내게 되며, 보통 서비스 로직을 작성하는 부분을 WAS라 말한다. 그리고 Web Server에서는 보통 정적인 페이지에 대한 응답을 해주게 된다. WAS에 Web Server 기능도 함께 포함 시킬 수 있다. 하지만, 기능을 분리 하기 위하여 그렇게 하지 않았다. (최근에는 성능은 비슷하다고 한다.)

아무쪼록 이정도의 그림만 그리고, 다음 스텝으로 남어가야겠다.

[기혁이의 아장아장 백엔드 도전기] 1화, 무엇을 어떻게 습득해야할까?

RyuK-H — Mon, 14 Dec 2020 18:43:48 +0900

백엔드 개발자가 되기 위해서는 어떻게 해야할까?

ㅗㅜㅑ..

음.. 이야...

일단 위의 엄청난 커리큘럼을 따라가기 전에 기반을 닦아보자.

첫 번째 스텝으로 백엔드 직군의 역할은 무엇인지에 대하여 파악해야할 것이며

두 번째 스텝으로 백엔드의 전체적인 구조에 대하여 알고 있어야 하며

세 번째 스텝으로 어떤 언어들이 있고 각 언어, 프레임워크들이 어떤 특징을 갖고 있는지 알아야 하며

마지막으로 내게 필요한 언어와 프레임워크를 통하여 실습하며 점점 고도화를 진행하면 좋을 것 같다.

잔잔하게 앞에서 뒤로 침투해보자.

1. 백엔드란?

위키에 따르면 백엔드란 서버개발자와 같은 말이라기 보다 프론트엔드, 백엔드의 완전한 분리 구조를 지향하는 업무 스타일의 개발 방식에서 나온 단어이다. 백엔드 개발자는 DB와 API 서버를 개발 하고, M(odel)V(iew)C(ontroller)패턴에 빗대어 생각하면 Model과 Controller가 백엔드의 소관이다.

위와 같은 업무 스타일에서는 웹퍼블리셔(UI 개발자)와 개발자(서버 개발자)의 업무가 분리 되는데. 이 경우 주로 서버사이드가 클라이언트를 감싸는 방식이고, 전반적인 비지니스 로직은 개발자(서버 개발자)가 맡게 된다. 하지만 웹 개발의 트렌드가 Single Page Application으로 바뀌고 여러 UI 라이브러리가 출시 되면서 프론트엔드 개발영역의 변화가 생기게 되었다. 그로 인하여 서버사이드의 개념이 예전 같지 않고 비즈니스 로직 또한 프론트엔드 업무로 넘어가기도 했다. (프로젝트 성격에 따라 천차만별이다.)

결국, 웹 개발 형식에 따라 프론트엔드, 백엔드의 업무가 유동적으로 바뀌고 있지만 변하지 않는 것은 백엔드 개발은 DB와 API 서버를 다루는 것이다.

프론트엔드, 백엔드 개발의 정의는 개인별로 모두 다르다. 하지만, 내가 경험한 웹 개발에서는 프론트엔드는 View를 만들고, 서버에서 받아온 데이터를 View에 맞추어 가공하는 일을 하고 백엔드는 데이터를 안전하게 저장하고, 필요에 따라 데이터를 새로 가공하는 일을 하는 것 같다.

Naver D2 글(링크)에서 프론트를 보컬에 빗대었고, 백엔드는 드럼이나 베이스로 빗대었다. 이 말이 적절 한 것 같다. 누구를 위해 일을 하느냐에 따라 차이가 있지만 음악을 한다는 공통점이있다. (프론트는 유저를 위해 일을 하고, 백엔드는 팀을 위해 일한다 생각한다.)

2. 무슨 일을 할까?

위에서 백엔드의 뜻을 찾다가 백엔드는 DB와 API서버를 개발한다.라는 문장을 찾게 되었다. 추상적인 것 말고, 조금 더 자세히 그들의 역할에 대해 알아보자. 그들의 역할에 대하여 가장 쉽게 단서를 찾는 방법은 채용 공고를 찾아보면 좋다. 백엔드가 무엇을 해야할지 가장 잘 아는 사람 중 하나는 백엔드를 채용하고 싶어하는 기업이 아닐까?

(몇몇 채용 공고를 재구성 해보았다.)

직무 내용

서비스 백엔드 시스템 개발

자격 요건

AWS 및 클라우드 환경에서 서비스 구축, 운영 경험
REST API에 대한 설계 및 개발 경험
Spring 프레임워크 사용 경험
데이터 베이스 설계 및 SQL에 대한 이해도
DBMS, NoSQL 운영
RDBMS 또는 Elasticsearch 등을 활용한 시스템 구축
Docker 기반 환경의 서비스 구축 경험

우대 사항

(대충 기타 여러 언어, 프레임 워크 개발 경험)
대용량 트래픽 경험 (분산처리에 대한 이해)
서버리스 및 마이크로 아키텍쳐에 대한 이해
리눅스 환경에 친숙
빌드/테스트/배포 자동화(CI/CD) 경험이 있으신 분

무언가 굉장히 요구 사항이 많아 보이지만 결국 주 된 업무는 DB를 구축하고 그것을 보다 효율적으로 관리하기 위해 설계하고 이를 프론트에서 사용할 수 있게 API서버를 구성하는 것이 주된 업무라는 것을 추측해볼 수 있다. 아직 확실한 개념이 있는 것은 아닌 상태이지만 나머지 기술은 주된 업무를 좀 더 고도화 시키기 위한 것들로 생각 되고, 기타 업무들은 Devops라는 직군의 역할이 포함 되어있는 것 같다. (Devops는 개발 방법론 중 한 가지 이지만 하나의 직군이기도 하다. 주 된 업무에는 반복적인 일을 자동화 하는 것이고 CI,CD 자동 배포 혹은 서비스,인프라 모니터링이 있다.)

프론트엔드를 세세하게 나누어 보면, 전체적인 서비스 로직이나 최적화를 신경쓰는 업무가 있고 스타일을 담당하는 업무가 있듯. 백엔드 또한, 세세하게 나누어 보면 클라우드 서버 혹은 자체 서버 구축 업무와 DB 설계, API 서버 구성 업무가 있는 것 같다.

3. 실제 서비스에서 빗대어 보는 역할

암호화화폐 거래소 업비트를 예로 들어보자. 내가 알고 있는 프론트엔드 지식으로 프론트의 역할을 생각 해보면 아래와 같다.

[프론트]

(1) API를 통하여 받아온 정보를 필요에 따라 프론트에서 사용할 수 있도록 재가공 한다.

Orderbook은 소수점 4자리까지만 표현 한다.
거래 내역들을 통하여 차트를 표현 한다.
하나의 코인 정보를 별도로 저장하지 않고, 통합하여 관리한다.

(2) 서비스에 필요한 로직을 작성한다.

각 코인별 거래 대금, 이름, 현재 가격 등을 통하여 정렬 할 수 있게 기능을 만든다.
각 코인 별 검색이 가능하도록 한글 초성을 저장하고, 검색할 수 있도록 한다.
매수, 매도 주문 입력시 유저가 사용하기 편하게 10%, 25%, 50%, 100% 등 현재 보유 수량에 따른 개수 계산이 가능하도록 한다.
수치를 조작하여 입력을 넣어도 API를 보내지 않게 예외처리를 한다. (ex. 잔액이 없지만 n개를 구매하려고 요청 하는 등)

(3) 스타일 작업

현재 가격이 변경 되면 유저가 인식할 수 있게 깜빡이는 효과를 넣어 준다.
어떤 디바이스로 접근해도 동일한 기능을 체험할 수 있게 반응형으로 설계한다.
상승, 보합, 하락에 따른 색 표현
재사용 가능 하도록 컴포넌트 설계

(4) 유저 경험, 성능 최적화

유저 경험 상승을 위하여 적절한 로딩 기법 활용
성능 최적화를 위한 각 라우트 별 번들 파일 묶기

간략하게 4가지의 분류로 생각해볼 수 있을 것 같다. 프론트엔드는 백엔드의 부하를 최소화 하기 위해 불필요 요청을 줄이고, 컴포넌트의 재사용과 유저 경험 상승에 최선을 다해야한다.

오늘 찾아본 백엔드의 역할을 생각해보면 아래와 같다.

[백엔드]

(1) API Interface 설계 및 작성

어떤 정보를 어떻게 요청해야 하며, 어떻게 반환 하는지 설계한다.

(2) DataBase 설계

어떤 데이터를 어디에 저장할지 설계 한다. 중복 되는 데이터가 없고, 효율 적으로 꺼내 쓸 수 있게 한다. (여기서 많은 방법론이 등장할 것 같다.)

(3) 서비스 로직 작성

매칭 알고리즘을 도입 하여 매도 물량, 매수 물량이 체결 되게 하고, 데이터 변동 사항을 수정 하고 체결 내역을 생성하여 DB에 기록한다.
UTC+9 시점 마다 전날 대비 변동성을 갱신한다. (전날 대비 상승, 보합, 하락)
일정시간 거래 체결이 없으면 candle(n분 봉) 데이터에 체결 없음을 저장한다.

(4) 성능 최적화 그리고 안정성

백엔드가 추구해야할 것은 유저 경험 보단 서버의 안정화인 것 같다.
요즘 많은 회사들이 자체 어플을 홍보 하는데. 유튜브 네고왕에서 나온 대부분의 홍보들이 제대로 이루어지지 못했다. (트래픽이 몰려 서버가 터져서 광고 효율이 제대로 나오지 않았다.)

4. 결론

백엔드의 의미와 역할에 대하여 알아보았다. 어렴풋이 짐작은 하고 있었던 것을 정리하고 글로 쓰니 한결 이해가 쉬웠다. 이런 식으로 차근 차근 접근 한다면 어떤 궁금증도 해결할 수 있지 않을 까 생각 되었다. 같은 듯 다른 역할이지만 난 어떤 대상을 위해 개발하느냐에 차이가 있다고 생각하려한다.

[TMI]

UTC+9 시점 마다 전날 대비 변동성을 갱신한다.
일정시간 거래 체결이 없으면 candle(n분 봉) 데이터에 체결 없음을 저장한다.

이 부분에 대해서 난 데몬이라는 표현을 썼다. 이게 맞는 표현인가 궁금 했는데.

스케줄러, 크론, 데몬 등의 표현이 있는 것 같다.

스케줄러, 크론은 일정 주기로 실행 되는 것을 말하고,

데몬은 특정 이벤트가 발생 되면 실행 되는 것을 의미한다고 한다.

개발자 분들께 여쭈어 본 것이고, 팩트체크는 하지 않았으니. 그냥 흘러가는 정도로만..

[회고] 안녕 나의 20대 (부제: 특별할게 없다고 믿는 나와 같은 사람들에게)

RyuK-H — Sun, 13 Dec 2020 22:31:55 +0900

2020년이 마무리 되고 있는 지금 내 자신은 변하지 않았고, 나의 시간은 멈추어있다고 생각했다. 하지만 시간은 야속하게 흘렀고, 나의 20대는 이렇게 막을 내리게 되었다. 과거를 돌아보면 10대는 기초를 다지는 시기였고, 20대는 그 기초로 나의 전문적인 힘을 기르는 시간이라고 생각 한다. 하지만 이것을 깨닫게 되니, 나의 20대는 끝났고 알 수 없는 30대가 찾아왔다.

20대를 마무리하는 지금의 나는 만기 제대를 했고, 지방 4년제를 졸업했으며, 회사 경력으로 만 4년 6개월이 된 5년차 개발자이며, 넥슨이라는 대기업에 속해있고, 석사 학위를 취득하게 되었다.

내가 걸어온 이 길이 절대 대단하다고 생각하지 않지만

감히 나는 나의 20대를 '역량 대비 최고의 성과를 거둔 시간'이라고 자신한다.

그렇기에 20대의 마지막 회고록은 10대의 내가 던진 꽤나 무거운 짐을 20대의 내가 어떻게 처리하게 되었는지 회고 해보려 한다.

난 나의 회고록을 통하여, 혹시나 나와 같이 인생 초반부에 집중 하지 못하여 좌절하거나,

자신이 특별한 능력을 가지고 있지 않다고 생각하는 사람들을 위해 나의 경험을 공유하고자 한다.

부디 나의 길이 평범한 누군가에게 도움이 되길 바란다.

나의 강점을 찾고, 무기로 만들었다.

수능 평균 3.7등급

말이 좋아 '3'이라는 숫자가 붙었지만, 사실 온통 4등급 투성이였다. 이런 결과에도 철 없게 찍은 문제가 꽤나 맞았다고 어머니께 이야기하며 좋아하던 모습이 눈에 선하다. 아득하게 나의 미래가 보이긴 했다. '어찌저찌 중소기업에 들어가고 못해도 월급 300만원 정도는 받으며, 사랑하는 사람과 살아가겠지.'라고 생각하며 입학까지 그저 좋아하는 게임을 했다.

하지만 입학하고 1학기 성적 장학금을 타게 될 때 부터 '잘못됨'을 느꼈다. 왜 나는 학창시절 장난끼 넘치고, 성적은 중간도 못갔는데. 이런 결과를 맞이하게 되었는지 진지하게 고민하게 되었다. 그 때 처음으로 나의 첫 번째 강점을 알게 되었다.

성실함

어릴 적 좋지 않은 성적표를 들고 갈 때마다 아버지께선 나에게 "성실하기만 해라"라는 말씀을 해주셨다. 그 때 부터 였을까? 난 성실함이 나의 최소한의 도리라고 생각하고 성실하기 위해 노력했다.

이 도리를 지키기 위해 별다른 노력은 없었던 것 같다. 그저 나를 믿지 않았다. 자취생활을 시작하게 되었을 때 부터 약속 장소에는 30분 전에 도착하려고 노력했고, 혹 늦잠을 잘까 걱정 되어 알람은 10개 이상 2분 단위로 맞추었다. 공부는 하지 않았다고 자신하지만, 출석은 무조건 했다.

물론 성실함이라는 강점은 대부분의 사람이 내세우는 측정 불가능한 강점 중 하나라고 생각한다.

하지만 난 이 강점을 단순히 주변 사람들에게 신뢰를 주는 용도로만 활용하지 않았다.

부족한 나의 뇌 성능을 커버하기 위해 단순 작업도 어떻게 해야하는지 메모장에 적었다.

처음에는 "이걸 적어?"라는 비웃음을 샀을 지 몰라도 이를 통해 의미 없이 같은 질문은 하지 않았다.

어디 파일로 들어가서 어떤 것을 수정해야하는지 다 적었었다.

20대의 끝에서 과거를 돌아보니, 난 남에게 보여지는 것을 중요시여기기 때문에 자연스레 측정 불가능한 것에 대하여 어떻게든 정량화하기 위해 노력했던 것 같다. 보잘 것 없는 메모였지만 난 나의 강점을 남들에게 보여줄 수 있게 준비하고, 포장했다. 그리고 이런 행동 하나, 기록 하나가 모여 날 남들 보다 조금은 가치있는 사람으로 만들었던 것 같다.

누구든 강점은 존재한다. 적어도 난 그렇게 믿는다.

그 강점이 또 다른 누군가와 비교하면 보잘 것 없을 수 있다.

하지만 그 강점이라는 무기를 어떻게 활용하는 지에 따라 가치는 충분히 차별화 될 수 있다.

자신의 능력을 찾아보면 분명 그 능력은 이미 어디서인가 자신의 삶에서 발휘 되고 있을 것이다.

그것을 정량화하여, 세상에 보여주면 좋을 것 같다.

난 나의 강점이 어디에서 발휘되고 있었는지에 대한 퍼즐을 약 2년전인 27살에서야 깨닫게 되었다.

그러니 '그걸 어떻게 찾아?'라고 조급해하지 말고 차분히 생각해보자. 다만, 작심삼일로 끝나지 않기를.

냉정한 자신의 가치평가

대학교 4학년이 시작 되었을 때, 하나 둘 대기업 공채를 준비하기 시작했다. 난 학과에서 성적이 꽤 좋았지만 개발에 대한 이해도가 전혀 없었다. 그래서 나는 좋은 기업을 노리는 것은 객기라고 판단 했고, 일절 고민 없이 빠르게 경력을 쌓는 전략을 세웠다. 무엇을 해야할 지 잘 모를 때는 미래에 무엇을 해야할지 깨달았을 때의 시간을 벌어주는 것이 이득이라고 생각했다. (말은 그럴 듯 하지만, 그냥 시간 낭비 하고 싶지 않았다.)

선배가 기회를 주셨고 한 중소기업에 입사 했다. 연봉에 대해 물어보는 것이 실례인줄 알았고 입사 후, 한달이 되기 까지 내 연봉을 모르고 다녔다. 이후, 내 연봉을 알게 되었을 때 아직 대학생이라는 이유로 2200만원을 받게 되었다. `크런치모드`라며 야근은 물론이고 주말 출근을 하고 억울하고 힘들어서 가끔 울기도 했지만 나름 만족했던 것 같다.

난 아직도 그 시절 CTO님이 너무 무섭다.

나는 호구가 아니다. 하지만 내가 어떻게 만족 하면서 다닐 수 있었을까? 기업이 나를 사용하기에 얼마가 적절할까?

최소 아래와 같이 나의 연봉과 기타 유지비용이 회사가 나에게 지불해주는 연봉 보다 높아야 회사는 이익을 창출 할 수 있을 것이고 나를 채용할 메리트가 생길 것이다.

나의 가치(회사에게 돈을 벌어줄 능력) > 나의 연봉(2200만원) + 4대 보험 비용 + 그 외 유지비

(창업을 했을 때, 기억으로는 한 사람당 연봉 외 비용이 약 40-50만원은 족히 들었던 것으로 기억한다.)

당시에 난 나의 가치가 최저 시급만 넘기면 된다고 생각했고, 그 이후에 내 능력을 증명하며 나아갈 수 있다고 믿었다.

또, 기약 없는 취업 준비 보다 경력을 쌓는 것이 더 중요하다 믿었기에 어쩌면 나의 연봉은 과대측정 된 것일 수도 있다.

꼰대스러운 생각일 수도 있겠지만 나의 강점 중 하나인 '빠른 시간안에 많은 경험'을 만들어낸 결정적인 선택이였다.

기술 면접 때, 간단한 포인터나 기타 기초 질문에도 당당히 "모르겠습니다. 하지만 개같이 일하겠습니다."라고 말하고

정말 개처럼 일하다 퇴사 했지만 보잘 것 없는 나를 받아주고 키워주셔서 감사하다.

소중하지 않은 사람은 없다. 하지만, 같은 능력이라면 어떤 방식으로든 경쟁력을 만들어야한다.

기회는 언제나 나에게 왔었다

대학교 3학년 때, 게임 고등학교에 진학을 원하시는 학부모님에게 과외 문의가 들어왔다. 난 과외 경험도 없고, '고작 내가?'라는 생각에 거절 할까 생각 했지만 무의식 속에 어떻게든 이 경험을 끝마치면 내가 모르는 무언가를 얻어 갈 수 있겠다라고 생각했다. 과외를 성공적으로 끝마쳤고 그 경험을 통해 학창시절 나의 과외 선생님들의 무책임에 대하여 깨달았고, 누군가를 가르쳐준다는 것은 나에게 굉장한 도움이 되었다.

그 다음부터 비슷한 경험들은 지속적으로 있었다. 어쩌면 굉장히 오래전 부터 있었지만 당연하게 거절했을 수도 있다. 하지만 두려워 하지 않고 기회를 잡다보니 대학교에서 강의하고, 여러 컨퍼런스에서 발표를 하는 나의 모습을 볼 수 있었다. 난 항상 부담스러운 선택을 해야할 때, '다 사람 하는 일인데 어떻게든 되겠지.'라는 마음으로 임하는 것 같다. 무책임한 생각일 수 있지만, 이 선택만 하게 된다면 '성실함'을 갖고 있는 내가 어떻게든 해결할 것이라고 믿었다.

용기 내어 하나의 기회를 잡으면, 또 다른 기회들은 연속적으로 찾아오는 것 같다.

그렇게 하나 하나의 경험으로 자존감이 높아지게 되면 자연스레 욕심도 생기고 멋진 선순환을 만들어준다.

'하늘은 스스로 돕는 자를 돕는다.' 어떤 핑계로든 기회를 잡지 않는 다면 그에 따른 보상을 기대해서는 안된다.

마스크 사기 당하고 인터뷰 기회가 찾아와 그 기회도 잡았다.. 이제 검색창에 `류기혁` 치면 나오는게 늘었다.. 피해자.. 류.. 기.. 혁...

인생은 게임과 같았다.

난 인생의 많은 부분을 게임에서 느낀 경험에 빗대어 생각한다.

최근에 생각한 '게임 개발자 2년, 웹-앱 프론트 개발 2년, 이제는 백엔드.. 이렇게 잡다한 경력이 이제 막 주니어 딱지를 땐 나에게 도움이 될까? 그리고, 내가 원하는 길을 갈 수 있을 까?'라는 고민도 한 캐릭터에 집중하지 못하고 여러 캐릭터를 육성 시키며 게임을 즐기는 나의 모습과 비슷했다. 과거의 나는 여러 캐릭터를 육성 하며 '난 참 끈기 없는 사람이구나.. 현실에서도 이런 모습이 나오면 어떻게 하지?'라고 생각했었다. 하지만 결과적으로 난 이런 방식으로 게임 전반적인 시스템을 이해했고 남들보다 다른 방식으로 게임을 잘했던 것 같다. 그러니 지금의 넓고 얕은 경험들도 추후, 다양한 개발을 하게 될 때 더 없이 좋은 경험이 될 것이라 믿으며 만족하고 있다.

과거 대학교 시절 대기업에 재직하는 선배들이 찾아와 강연을 해주셨다. 그 때마다 내가 느낀 건 '뭐야.. 그냥 태어나길 똑똑하게 태어나셨으니 좋은 곳에 간 것 같은데.. 왜 저게 팁이지? 그래서 난 어떻게 해야하는거지..'라는 부정적인 마음 뿐이였다. 사실 지금도 이 마음은 같다. 슬프지만 태어나길 똑똑하게 태어난 사람이 존재하고 그렇지 않은 사람이 존재한다. 하지만 이 차이를 받아들이고 다른 전략을 세워보니 나도 그들과는 다른 형태로 비슷한 위치에 설 수 있었다.

게임에서 처럼 사람은 각자 다른 고유한 특성을 갖는다. 하지만 현재 대부분의 사람들은 평판이 마치 '지능'에 의해 절대적으로 측정 된다고 믿고 그로인하여 자신의 특성이 '지능'이 아니여도 모두 그것을 추구하려고 하는 것 같다. 하지만, 법사는 지능을 찍어야하고 전사는 힘을 찍어야한다. 둘은 다르지만 추후 파티를 맺어 서로의 부족함을 채워준다. 서로에게 서로는 필요한 존재다.

가끔 돌연변이들도 있긴 하다.

나의 20대는 '알고리즘? 자료구조? 토익? 남들이 가는 방향으로 빛날 자신이 없다면 또 다른 방법으로 충분히 빛날 수 있다.'를 증명하기 위해 노력했다. 그리고 나의 전략은 성공적이였다. 나는 어쩌면 대기업 신입 공채를 준비하는 분들 보다 컴퓨터 공학 지식이 떨어질 수 있다. 하지만, 난 내 자신을 잘 파악하고 있고 나의 강점을 계속해서 멋지게 다듬고 있다.

나와 같은 사람들도 `평판은 절대적으로 지능에 의해 결정 된다.`라는 함정에서 벗어나 각자만의 특성을 멋지게 뽐내었으면 좋겠다.

아직 2020년 12월이 보름 정도 남았지만 2020년 그리고 20대의 회고를 빠르게 마무리 하고, 편안하게 연말을 즐겨야겠다.

안녕 나의 20대.

웹팩(Webpack)

RyuK-H — Wed, 9 Dec 2020 13:21:34 +0900

웹팩 너란 녀석

프로젝트를 진행 하다 보면 어떤 이유에서인지 결국 webpack(이후 웹팩)을 만나게 된다. 웹팩이 파일들을 bundle.js로 export해주는 것은 이해하고 있지만 정확한 개념과 동작방식을 알아볼 필요가 있을 것 같다.

내가 너를 만나게 된 이유

파일 압축은 방법에 따라 달라지지만 우리가 흔히 사용하는 기본 압축은 파일 용량을 줄이는 압축이 아니다. 파일 이동, 다운로드를 경험한적 있는가? 3만개의 파일을 이동하는 것과 압축 된 1개의 파일을 이동하는 것은 같은 용량이여도 큰 시간 차이를 만들어낸다.

서비스를 개발 하며 확장성, 재사용성을 위하여 각 기능별로 파일을 분리하고 성격에 따라 경로도 달라진다. 하지만 위의 압축의 예시와 같이 여러개의 파일을 서버에서 내려 받고 로딩하는 것은 그만큼의 비용이 들어간다.

위와 같은 문제를 해결할 방법이 필요했고, 그 해결책이 각각의 모듈을 번들링 해주는 웹팩이다.

그래서 웹팩 이란

웹팩이란 최신 프론트엔드 프레임워크에서 가장 많이 사용되는 모듈 번들러(Module Bundler)이다. 모듈 번들러란 웹 애플리케이션을 구성하는 자원(HTML, CSS, Javscript, Images 등)을 모두 각각의 모듈로 보고 이를 조합해서 병합된 하나의 결과물을 만드는 도구를 의미한다. (참고: 웹팩 핸드북)

모듈 (참고)

모듈이란 프로그래밍 관점에서 특정 기능을 갖는 작은 코드 단위를 의미한다. 웹팩에서의 모듈은 해당 애플리케이션을 구성하는 HTML, CSS, Javascript, Images, Font 등 모든 파일들을 모듈이라 의미한다.

모듈 번들링

아래 그림과 같이 웹 애플리케이션을 구성하는 수 많은 파일들을 하나의 파일로 병합 및 압축 해주는 것을 모듈 번들링이라 한다.

정리

파일을 하나 하나 다운 받는 것은 비용이 너무 많이 들어가니, 그것을 좀 더 깔끔하게 정리하여 압축하는 것을 모듈 번들링이라고 하고 그것을 세팅하는 것이 웹팩이다.

주요 속성

웹팩의 번들링 과정을 이해하기 위해서는 4가지의 속성을 알아야 한다. 그것을 차근차근 살펴 보자.

[1] entry

[2] output

[3] loader

[4] plugin

entry

entry는 아래의 의존성 그래프의 시작점을 의미한다.

애플리케이션에서 사용 될 자바스크립트의 시작점은 ./path/to/my/entry/file.js이다.

// webpack.config.js
// Usage: entry: { <entryChunkName> string | [string] } | {}
module.exports = {
  entry: {
    app: './src/app.js',
    adminApp: './src/adminApp.js'
  }
};

entry는 환경, 빌드 대상 및 런타임별로 확장 가능하다.

// webpack.config.js
// Usage: entry: { <entryChunkName> string | [string] } | {}
module.exports = {
  entry: {
    app: './src/app.js',
    adminApp: './src/adminApp.js'
  }
};

output

output은 웹팩에서 번들링 된 번들 파일의 경로를 의미 한다.

아래 Product와 같이 해시값을 지정해주는 이유는 동일한 콘텐츠 해시일 경우 브라우저가 캐시를 유지 시켜주므로 성능 향상에 도움이 되기 때문이다. (이는 단일 entry를 갖고 있을 때는 의미가 없을 것이다. 단일 시작점을 가지고 있고 번들링을 한다는 자체가 파일이 수정 되었음을 의미할테니. 그러므로 여러 번들러가 존재할 때, 의미 있는 것 같다.)

// webpack.prod.js
module.exports = {
  output: {
    filename: '[name].[contenthash].bundle.js'
  }
};

// webpack.dev.js
module.exports = {
  output: {
    filename: '[name].bundle.js'
  }
};

loader

loader는 웹팩이 번들링을 할 때, 자바스크립트 파일 외 다른 파일(HTML, CSS, Images, 폰트 등)들을 변환할 수 있도록 도와주는 속성이다.

- test : 로더를 적용할 파일 유형

- use : 해당 파일에 적용할 로더의 이름

// webpack.config.js
module.exports = {
  module: {
    rules: [
      {
        test: /\.css$/,
        use: [
          // [style-loader](/loaders/style-loader)
          { loader: 'style-loader' },
          // [css-loader](/loaders/css-loader)
          {
            loader: 'css-loader',
            options: {
              modules: true
            }
          },
          // [sass-loader](/loaders/sass-loader)
          { loader: 'sass-loader' }
        ]
      },
			{ test: /\.ts$/, use: 'ts-loader' }
    ]
  }
};

로더는 오른쪽에서 왼쪽순으로 적용 된다.

(1) scss를 로드

(2) scss를 css로 변환

// 배열 방식
module: {
  rules: [
    {
      test: /\.scss$/,
      use: ['css-loader', 'sass-loader']
    }
  ]
}

// 옵션을 표기하고 싶으면 아래와 같은 방식
module: {
  rules: [
    {
      test: /\.css$/,
      use: [
        { loader: 'style-loader' },
        {
          loader: 'css-loader',
          options: { modules: true }
        },
        { loader: 'sass-loader' }
      ]
    }
  ]
}

plugin

plugin은 웹팩의 기본적인 동작에 추가적인 기능을 제공하는 속성이다. 로더는 파일을 해석하고 변화한다면 plugin은 결과물의 형태를 바꾸는 역할을 수행 한다.

사용법은 굉장히 쉽다. (하단)

const HtmlWebpackPlugin = require('html-webpack-plugin'); //installed via npm
const webpack = require('webpack'); //to access built-in plugins
const path = require('path');

module.exports = {
  entry: './path/to/my/entry/file.js',
  output: {
    filename: 'my-first-webpack.bundle.js',
    path: path.resolve(__dirname, 'dist')
  },
  module: {
    rules: [
      {
        test: /\.(js|jsx)$/,
        use: 'babel-loader'
      }
    ]
  },
  plugins: [
    new webpack.ProgressPlugin(),
    new HtmlWebpackPlugin({template: './src/index.html'})
  ]
};

플러그인 종류

Plugins | webpack

webpack is a module bundler. Its main purpose is to bundle JavaScript files for usage in a browser, yet it is also capable of transforming, bundling, or packaging just about any resource or asset.

webpack.js.org

생각

생각보다 웹팩의 구성요소는 간단했다. 하지만 구성요소와 다르게 그 요소 안에 숨어있는 여러 loader들과 plugin들은 너무나도 다양한 것 같다. 하지만 언제나 그렇듯 필요할 때 마다 잘 찾아서 꺼내 사용하면 될 것 같다. 확실히 차근차근 docs를 보며 이해하고 글을 쓰니 정리가 되어 좋다.

다음은 babel을 알아보고 babel과 eslint에서 가끔 중복되는 옵션들이 있었던 것 같은데 그것에 대하여 알아보아야겠다.