2donny

새로운 회사에서 1주일이 지났다. 첫날은 컬쳐 팀의 코디네이터분이 회사의 설립 역사부터 시작하여 복지까지 상당히 많은 정보를 전달하였다. 사실 난 첫날부터 일 해야 하는 줄 알고 살짝 긴장하고 맥북까지 챙겨갔는데 그냥 진짜 편하고 재밌게 보냈었다. 같은 날 입사하신 분들이 계열사 통틀어 XY명이었다. 동기 문화가 있어서 같은 계열사 분들과 쉽게 친해졌다. We're here to make history 이 문구를 보고 비로소 내가 진짜 여기 왔구나하고 실감했다. 가슴이 두근두근 뛰었다. 역시 난 평생 이런 일을 해야하는 사람인가보다. 일하는 방식은 타이트하지 않고 자율과 책임하에서 느슨하지만, 응집력있게 그루핑된 인상을 받았다. 특이한 점 한 가지는 온보딩을 도와주는 메이트분이 계시는데 챕터 리더분이신데..

지난 1년 8개월 동안 몸 담았던 첫 회사의 이력을 오늘부로 매듭짓게 되었다. 소중한 동료들과 작별 인사를 마치고 대표님과 판교역 부근에서 저녁 식사를 했다. 평소에는 절대 하지 못했던 진솔한 이야기들을 서로 허심탄회하게 얘기할 수 있었다. 비즈니스 관계뿐만 아니라 인간적인 유대감이 형성된 신뢰 관계였기에 평소 서로에게 했어야 했지만 굳이 하지 않았던 이야기들을 오늘에서야 할 수 있었다. 그때의 울컥하는 마음, 고마운 마음, 미안한 마음을 숨기기 어려웠다. 서로가 서로에게 비슷한 감정을 가지고 있었던 것 같다. 게임듀오에서 일하면서 가장 크게 배웠던 것은 기술과 비즈니스 그 사이에서 현재 조직의 규모와 상황에 맞는 올바른 의사결정을 하는 방법이었다. 비즈니스가 중요한 조직에서 해볼 수 있는 건 충분히 경..

거의 5월이 다와 가는데 2022년 회고라는 제목으로 짓는 것이 조금 이상해서 1년차 개발자의 회고라고 적어보았다. 2022년 그리고 2023년 4월 까지의 경험은 나에게 큰 의미가 있는 해이기 때문에 늦게나마 글을 남기게 되었다. 게임 회사 사실 나는 재작년까지만 하더라도 내가 살면서 게임 회사에서 일을 하게 될 것이라고 상상도 못했다. 현 회사에 합류하기 전까지 모바일 게임을 한번도 해본 적이 없었으니 말이다. 어쩌다보니 창업을 하게되고, 백엔드 개발을 공부하였고, 게임 회사의 서버 개발자로 일을 하게되었다. 당시 나의 회사 선택의 기준은 성장이었는데 운 좋게도 빠르게 성장하는 회사에 합류하게 되었다. Start kit 첫 회사 합류와 동시에 게임 서버 start kit를 만드는 프로젝트를 맡았었다...

사용동기 서비스를 하다보면 기획이 추가돼서 Production 환경의 Database 테이블을 추가/변경 해야하는 상황이 정말 많다. 이 때 서버 개발자인 나는 운영 환경과, 개발 환경의 DB 모델을 동기화해야 하는데 어떤 것이 Best practice 인지 잘 몰라서 직접 Postico로 쿼리를 날려 변경했었다. 근데 컬럼이 추가되거나 수정될 때마다 일일히 쿼리를 날리다보니 수정 사항이 많아질 때, 개발 환경과 운영 환경의 모델이 동기화되어 있는지 확신이 들지 않았다. 그러던 도중 TypeORM CLI로 운영 환경의 DB 모델을 코드로써 변경할 수 있다는 것을 알게 되었고, 현 시스템에 적용하게 되었다. 뼈 아픈 기억들 이전에도 TypeORM의 Synchronize: true 옵션으로 데이터를 날려먹은..

"우리는 왜 Dependency injection를 쓰나요?" 위 같은 질문은 대답하기 참 어려웠다. 면접 자리라면 그래도 말은 해야하니 아래와 같이 말하곤했다 "객체의 생성과 사용의 관심사를 분리하기 위함이죠. 또한 객체 생성의 책임을 IoC 컨테이너에게 전가함으로써 프레임워크 단에서 디자인 패턴을 만드는데에도 의의가 있습니다." 다시 보니까, 위 두 이유가 되게 비슷한 맥락이라서 거의 같은 말 같기도하다. 아무리 찾아봐도 당시 저 상황에서 공감이 잘 안됐고 그나마 저게 가장 공감됐던 DI를 사용하는 이유였다. 물론 위 근거도 충분히 이유가 될 수 있다. 근데, 오늘 Spring의 컴포넌트 스캔을 배우게 되면서 DI를 사용하는 또하나의 이유를 알게되어 정리하고자 한다. Spring의 Layered 아키..

사용 동기 웹 사이트 속도의 첫 인상을 결정하는 것은 아마도 첫 이미지 로딩 시간일 것이다. 50x50 사이즈의 이미지를 로딩하는데 10MB 짜리 400x400 사이즈 이미지를 로딩하며, 심지어 페이지에 다시 돌아왔을 때 캐싱도 되어있지 않다면 유저는 그 사이트가 느리다고 생각할지도 모른다. 이를 해결하기 위해 리사이징(Resizing)기술을 제공하는 모듈(sharp)이 나오게 되었고, 이미지 용량을 줄여 로딩 속도를 빠르게하는 Best practice로서 널리 통용되어 사용되고 있다. 이 글에서는 1 편에서 소개했듯이 AWS Lambda 함수로 썸네일을 생성하는 방법을 소개한다. 근데 만약 Lambda를 한번이라도 써본적이 있다면, 여기서 이런 의문점이 생길 수도 있다. 굳이 Serverless 서비스..

사용 동기 할로윈 이벤트 같이 트래픽이 몰릴 때 메인 피드 이미지 로딩이 느려지는 현상이 발생했다. 정적 이미지 서버로서 AWS S3 버킷을 사용했었는데, 모든 트래픽이 하나의 S3 origin 서버로 몰리면서 병목이 생긴 것이다. 그래서 이미지 서버 다중화를 생각하게 되었고 AWS에서 제공하는 CloudFront로 CDN을 붙이기로 했다. CDN 란? content delivery network의 약어이다. 여기서 content란 html, css, js, image files와 같은 정적 파일들을 말하고, 이 파일들을 전 세계에 위치해 있는 데이터 센터 network를 통해서 content를 deliver 한다. 장점 1. 물리적인 거리를 좁힌다. S3 origin 서버를 대한민국 리전으로 생성했다고..

문제 상황 데이터가 정상적으로 마이그레이션됐는데 예약이 안 되는 버그가 발생했다. > eb logs --debug eb cli인 위 커맨드로 로그를 확인했다. 그리고 다음과 같은 SQL failed 에러를 발견했다. id가 default로 생성되지 않아서 생긴 500번 에러였다. 좀 이상했다 users.id는 원래 아래 TypeORM 데코레이터에 의해 Auto generated 돼야 하는데 말이다. @Entity({ name: 'users' }) export class User { @PrimaryGeneratedColumn('uuid') id: string; } 그래서 postico로 DDL을 찾아보기 시작했다. 그리고 머지않아 정답을 발견했다. Table DDL 관찰 원본 RDS의 Reservation..

사용 동기 지난 2주 동안 Heroku 기반으로 돌아가는 서버를 AWS 인프라로 완전히 migration하기 위해 열심히 삽질을 하였다. 어떤 AWS 인프라를 사용하여 배포할지 자료도 많이 찾아봤는데, 그 중 고민됐던 서비스들은 ECS Fargate과 Elastic Beanstalk이었다. 최종적으로는 Elastic Beanstalk Node.js 플랫폼을 사용하여 배포하기로 하였다. 그 이유는 ECS Fargate와 Beanstalk(docker 플랫폼) 서비스들은 로컬에서는 분명 실행이되는데, Production 환경에서만 실행하면 컨테이너들끼리 depends_on이 잘 되지 않아 항상 Node.js 프로세스가 죽었다. 그래서 Docker를 프로덕션에서 사용하는 것은 조금 미루기로했다. 무튼 그래서 ..

사용 동기 클라이언트 웹사이트를 가비아에서 도메인을 구입하여 사용중이었다. 근데 Beanstalk 환경으로 생성한 서버 URL도 깔끔하게 보이기 위해 도메인을 붙이고자 했는데 도메인을 또 사기에는 돈이 아까워서 서브 도메인을 적용하게 되었다. 서브 도메인 적용 해보기 > 도메인 하나가 등록됐다고 가정하고 진행 > Bean stalk으로 환경을 생성했다고 가정하고 진행 1. Route 53 호스팅 영역에 들어간다 2. 등록한 도메인을 클릭 3. 레코드 생성 클릭 - '레코드 이름'은 서브 도메인 이름이다. - '레코드 유형'은 CNAME을 사용하자. 이는 서브 도메인을 다른 도메인으로 트래픽을 전달할 때 쓰인다. - 값에는 트래픽을 보낼 도메인을 넣어주자. 위 경우에서는 Beanstalk 환경으로 생성한 ..