개요한달만에 글을 쓴다, 대규모 리브랜딩 후 배포를 앞두고 있어서 사실 블로그 뿐만 아니라 축구도 못하고 있다..하지만 왜 글을 쓰냐, 그건 스터디를 해야하기 때문이지,  스타트업에 리드 개발자로 합류하면서 기존의 레거시에서 발생하는 문제점들을 인지하고 스타트업 특유의 빠른 생산성에 영향을 주지 않으면서 기존의 레거시를 개선하고 있는 경험을 공유하기 위해서이다. 모르겠고 다음주 월요일 새벽배포인데 교회 기도하면서 배포할 예정이다.. 리팩토링의 종류처음에는 정말 많은 고민을 했다, 리팩토링의 중요성을 인지하고 있었지만 당장의 기능 개발과 버그 수정 때문에 손을 못 대고 있던 상황이였다. 하지만 나는 수많은 컨퍼런스와 기술 블로그 덕후로 알고 있었다, 생산성에 영향을 주지 않은 리팩토링 방법을 리팩토링에는 ..

개요새로운 스타트업에 합류하면서 프론트 개발도 같이 하고 있는 요즘이다. React Native로 개발을 하고 있는데 사실 난 크로스 플랫폼에 대해서는 아무것도 모른다. 웹 개발도 해봤고 앱 개발도 해봤지만 크로스 플랫폼 개발은 처음이다. 그래서 모든것이 낯설지만 오히려 너무 재밌다 토스가 React Native에 많은 투자를 하고 있고 그외에도 여러 곳에서 앞으로의 좋은 전망을 예상하고 있는 기술이기 때문에 나중에 창업을 위해서라도 배워두면 좋겠다고 생각이 들었다.  열심히 GPT와 소통하며 개발을 하고 생각보다 쉽고 생산성도 빨라서 열심히 하던 중 웹에서는 괜찮은데 iOS에서 앱이 뒤져버리는 현상이 일어났다. 멘탈 펑, 매우 간단하고 짧지만 그 경험을 한번 공유해보고자 한다.크로스 플랫폼은 처음이라...

개요관계 없다 스펙이랑 개발실력이랑 상관없다, 단순히 내 경험을 풀어 쓰는 글이지 남들에게 이 기준을 적용시키거나 모두에게 적용되는 기준이 절대 아님을 먼저 밝힌다. 또한 윈도우, 맥, 리눅스 같은 OS 갈라치기 글도 절대 아니다. 제발 이 글이 개발 커뮤에 오르내리지 않기를.. 지금은 새벽 4시이다, 잠이 너무 오지 않아서 개발 공부를 하고 있었다. 요즘에는 새로운 프로젝트에 들어가면서 설계 단계에서 좀 더 폭 넓은 시야를 가지기 위해서 여러 기술 스택을 접해보고 있다. Cassandra라는 대용량 데이터 처리를 위한 NoSQL 데이터베이스를 도입해볼까 생각하여 기초를 배우기 위해 환경 구성을 하던 도중 도커가 제대로 올라오지 않는 문제를 발견하였다. exit code 137이였고 137은 대부분 메모..

개요이번시간에는 데이터베이스를 통해서 대용량 트래픽의 처리 성능을 높이는 법을 알아볼것이다.본 글에 들어가기 전에 대용량 트래픽 발생시 어떤 부분에서 성능을 향상 시킬지는 잘 판단해야한다. 예를 들어 웹 어플리케이션은 여유로운데 데이터베이스에서 처리를 못하고 있는 상황에서 웹 어플리케이션 확장만 시키면 무엇이 달라지겠는가. 그럴때는 APM을 사용해서 하나의 큰 요청 트랜젝션을 분석하여 병목 지점을 알아내야한다. 웹 어플리케이션에선 처리가 1초 내로 되는데 데이터베이스에선 5~6초가 걸린다면 데이터베이스를 최적화 해야하는 상황이라고 판단한다. 이렇게 적절한 대응 지점을 찾는것이 1순위이다.데이터베이스 Replication레플리카 라는 말은 일상에서 가끔 들을 수 있는 말이다, 무엇을 의미하냐 하면 원작을 ..

개요최근 새로운 프로젝트를 시작하게 되면서 드디어 원하는 기술들을 써볼 기회가 왔다. 그동안 슬축생 프로젝트를 개발하느라 바빴고 슬축생 프로젝트는 당장 서비스가 시급한 프로젝트였기 때문에 오버 엔지니어링을 절대 지양하는 방향으로 개발을 했다. 그러다보니 정말 최대한 단순하고 안정성 있고 빠르게 도메인 개발에만 초점이 맞춰졌고 공부의 목적은 전혀 없었다. 하지만 이번에도 서비스를 목적으로 하는 프로젝트긴 하지만 슬축생처럼 필요에 의한 서비스가 아니라 천천히 만들어가자는 프로젝트기 때문에 그동안 못해본 기술들을 많이 시도해볼 생각이다.  최근에 Spring WebFlux를 공부하며 Reactive Stream을 이용한 비동기처리를 공부하고 있다. 정말 어려운 내용이지만 다행이도 전에 회사에서 iOS를 개발할..

개요새로운 사이드 프로젝트를 시작하면서 여러 고민을 하게 되었다, 바로 전의 사이드 프로젝트인 슬축생은 공부가 목적이 아닌 필요로 의해서 개발된 프로젝트기 때문에 최대한 비즈니스 요구사항에 맞추며 배포까지 시간이 많이 없었기에 개발쪽 리소스를 줄여서 개발을 하였다. 하지만 이번에 하는 사이드 프로젝트는 비즈니스적인 부분도 꽤 크고 복잡할뿐더러 공부의 목적도 함께 있는 프로젝트이기 때문에 정말 작은 부분에서도 신경을 많이 쓰게 되었다. 정말 많은 고민중에 가장 첫번째로 결정한 주제가 바로 Response Entity의 필요성이다. Response Entity의 존재에 대해서는 예전부터 알고 있었다. 본격적으로 공부하기전에 알던 사전 지식으로는 http 상태 코드 및 헤더 등 여러 상세한 부분을 설정할 수 ..

개요오늘은 기술적인 얘기가 아닌 실제 서비스에서 나오는 얘기를 들고 왔다, 분명 새로운 프로젝트인 오아시스의 글을 준비하고 있었는데 정말 마지막이란 생각으로 슬축생 프로젝트를 한번 더 연재한다. 어느덧 슬축생 프로젝트를 배포한지 1년이 지났고 약 500명의 유저가 1년동안 다녀갔다, 물론 일반 사용자를 타겟으로 한 서비스가 아닌 동아리 부원들을 위한 내부 서비스이기 때문에 운영중의 이슈는 크게 없었다. 하지만 얼마전부터 내 메일함이 바빠지기 시작했다, 바로 도메인과 ssl 인증서를 연장해야한다는 알림들이 오기 시작한것이다.보통 다른 서비스들은 1년전에 접어서 정말로 1년 후 필요에 의해 연장을 하는 케이스가 처음이여서 기분이 굉장히 신기했다. 나는 도메인과 ssl을 클라우드 업체에서 제공해주거나 자동으로..

개요슬축생 프로젝트 시리즈는 이제 끝날줄 알았다, 개발 후 문제 없이 운영한지 1년이 되어 가는 서비스였고 더 이상 개선점이 없다고 생각했다.그렇게 1년이 지나가는 사이에 나는 많이 성장하였다, 영한님의 강의를 들으면서 여러 성능 최적화와 프레임워크의 내부 동작 방식에서 오는 문제점을 해결하는 법등을 배워나갔다. 그러다가 문득 생각이 들었다, 내가 슬축생을 개발할 당시에는 N+1에 대한 지식이 없이 개발을 하였는데 과연 N+1이 발생되고 있지 않을까라는 의문이 들었다. 그런데 발생 안 할 가능성이 거의 없다고 생각했다, 왜냐면 엔티티끼리 긴밀하게 연결되어 있고 서로 LazyLoading 전략으로 데이터를 끌어온다는 것을 개발한지 1년이 지난 지금도 명확하게 기억하고 있기 때문이다. 그래서 다급하게 오랜만..