들어가기 앞서...2024년 8월부터, 이전 회고들은 어디로? 이전 회고들은 일상 블로그에 있었다. 과거형으로 작성한 이유는 이제는 일상 블로그가 없기 때문. 없애버린 이유는 여러가지다. 일기를 작성할 여건도 안되고 의미가 퇴색되기도 하여 없애버렸다. 내가 일기에 올리는 내용들은 대부분 나의 사생활이다. 내가 보라고 공개한 사생활이긴 하지만 어디까지나 보라고의 의미지 보고 멋대로 판단하라는 의미는 아니었다. 하지만 내가 거기까지 막을 수 는 없기도 하고 그 판단의 영역부터는 나의 손을 벗어난 일이다. 그래서 내가 조절할 수 없는 영역들에 대해 스트레스를 느낄 바에 없애는게 맞다고 생각해서 없앴다. 없애긴 했지만 (전)일상 블로그에는 12월 까지의 회고밖에 없다. 최근 6개월간은 꽤나 바빴기 때문에 회고..

개요 프론트에서 사진이 제대로 보이지 않는 문제가 발생했다. ▼ S3에는 분명히 이미지가 업로드 되어 있고, Postman으로 요청을 날려봐도 응답이 200으로 잘 오는데, 실제 화면에서는 이미지가 보이질 않았다. 처음엔 당연히 백엔드 문제라고 생각했고, 이게 뭐지 싶어 로깅도 켜고 요청 흐름도 추적해봤지만 서버에는 이미지가 잘 올라가 있었다. 클라이언트도 요청 값에 누락하는 일 없이 보내고 있었고, URL도 뭔가 이상 없어 보였다. 그럼 도대체 어디서 잘못된 걸까? 문제 상황아래는 Postman에서 확인한 이미지 URL이다. ▼https://aws_bucket/20240413%25EF%25BC%25BF165238.jpg 하지만 url에 직접 접속해서 보려고 하면 이런 오류가 나왔다. '백엔드에서 ..

개요 Next.js로 웹 프로젝트를 시작하면서 구조를 어떻게 설계할지 많은 고민이 있었다. 그동안의 프로젝트들은 빠르게 기능을 만드는 데에 집중했었다. 배우면서 작업한 것도 있었고, React와 Next.js의 기능들을 빠르게 다 훑어보기 위함도 컸다. 그러나 프로젝트를 거듭할 수록, 점차 규모가 커지면서 유지보수가 어려워졌다. 의존성과 흐름을 파악하는 데 시간이 많이 들고, 테스트나 기능 추가에도 부담이 커졌다. 유지보수적으로 좋지 않아서 한 번 쓰고 버릴 그런 사이트가 되었고, 더 이상은 그런 사이트들을 만들고 싶지 않았다. 그래서 이 문제를 해결하기 위해 클린 아키텍처를 도입했고, 이 글에서는 그 구조를 어떻게 구성했고, 실제 코드에서 어떻게 활용하고 있는지를 적어보려고 한다. (클린 아키텍쳐 ..

개요 프로그래밍을 하다 보면 반드시 한 번쯤은 "모델 검증 코드를 어디에 둘 것인가?"라는 질문을 마주하게 된다. 처음에는 대수롭지 않아 보이지만, 프로젝트 규모가 조금만 커져도 코드의 유지보수와 팀 내부의 합의에 직접적인 영향을 주는 논쟁거리로 떠오른다. 현업 개발을 시작한 지 얼마 되지 않았지만, 각종 프로젝트들을 경험해보며 여러 아키텍처 글과 실전 코드들을 뒤적이다가 "내가 정말 제대로 이해하고 있나?", "지금 선택이 과연 최선일까?"라는 의문을 반복해서 던지곤 한다. 그래서 이번 글에서는 모델 검증 코드를 모델 내부에 둘지, 아니면 외부의 별도 Validator로 뺄지를 결론부터 단순히 내려버리기보다, 흐름의 주권, 즉 책임이 어디에 머무르고 언제 이동하는가라는 관점에서 보려고 한다. 그전에...

개요 티스토리로 블로그를 옮긴 지는 1년밖에 되지 않았지만, 나는 블로그 활동을 2021년도부터 시작했다. 블로그 유목 생활이라는 글에도 적혀있지만 꽤나 많은 블로그들을 옮겨다녔다. 회사에 들어가고 나서부터 글 작성 빈도가 꽤나 많이 줄어들었는데, 글을 작성하지 않은 게 아니라 작성하지 않는 동안에는 자료를 만들고 글을 정돈하는 시간을 갖는다. 새롭게 알게 된 내용들은 처음 블로그에 글을 작성할 때 보다 더 고도화된 내용들이기도 하고, 보다 정확한 정보를 전달하면서도 단순히 그 주제에 대한 정보만 전달하는 게 아니라 나 스스로가 그 주제에 대해 어떻게 생각하는지도 작성하다 보니 시간이 꽤 걸리게 됐다. 최근 적고 있는 BLoC 패턴에 대하여라는 글이 있는데, 나의 생각이 정돈이 되지 않아 거의 한 달이 ..

포트폴리오 NOGUEN noguen-portfolio.com

개요다이얼로그를 보여주거나 바텀시트를 보여준 뒤, 다시 닫으면 가정 이전 포커스로 돌아가는 현상이 있었다. ▼문제의 상황 전체적인 기능으로는 문제가 없지만, 사용자 입장에서는 꽤나 거슬리는 문제다. 아래로 자동 스크롤이 되는 것도 아니고 오히려 뒤로 돌아가버린다면 사용자의 입장에서는 당황스러울 것이다. 원인 탐색FoucsScope의 기본로직? Flutter의 `FocusScope`는 서브트리 내의 포커스 히스토리를 관리하여, 페이지를 팝할 때(Navigator.pop) 이전에 포커싱된 위젯으로 자동으로 포커스를 복원한다. Flutter 3.22.3 버전에서는 포커싱을 해제하고 다음 페이지로 가도, 이 동작이 버그로 재발생한다는 이슈도 있으며, 텍스트 필드가 의도치 않게 자동 포커싱되는 문제가 있다고 한..

개요이전에 Flutter글에서 async/ await 개념에 대해 공부하면서 아래의 글을 작성한 적이 있었다. ▼ [Flutter] 동기와 비동기 개론개요 동기와 비동기, 프로그래밍을 공부하다보면 항상 등장하는 개념이다. 중요한 개념이고 꼭 알아야한다고 하지만 이게 왜 중요한 개념인지 잘 이해하지 못하고 넘어간 적이 많다.▼ 하지만noguen.com 해당 글의 내용이 잘못된건 아니지만 (다시 읽어봤을 때는 아직까지는 잘못된 점을 못찾았다) 동기와 비동기를 다르게 보는 시각이 있다는 이야기가 있어서 이에 대해 정리하려고 한다. 제어 흐름으로 본 동기와 비동기동기와 비동기의 개념 동기는 Synchronous, 비동기는 Asynchronous로 한국어로 봤을 때는 약간 헷갈리는 면도 조금 있다. 동기라는 말..

문제 상황카카오 로그인이 제대로 수행되지 않는다는 버그 리포트를 받았다. 그러나 그 버그 리포트가 너무나도 부실했기에 (무작정 카카오 로그인이 안된다고 하고 당시의 상황에 대해 설명이 없었다.) 우선은 더 급한 업데이트 부터 처리를 하고 심사를 넣었다.그런데 카카오 로그인 버튼이 눌리지 않는다고 애플에서 리뷰를 해주어 버그 픽스에 들어갔다. ▼ 다시 확인해보니 카카오 로그인이 아래와 같이 팝업만 잠깐 나오고 진행이 안되고 있었다. 운좋게? 팝업이 안사라지고 남아있다고 해도 로그인 페이지로 넘어가지지 않는 문제가 있었다. ▼카카오 로그인이 수행되지 않음 원인 탐색 클라이언트 로직의 문제?초기에 테스트를 했을 때는 백엔드 통신도 잘 마무리 했었는데 갑자기 문제가 발생했다는 이야기를 들으니, 약간은 갈피가..

문제 상황구글 맵을 사용중에 엄청나게 렉이 걸리는 상황이 발생했다. 지도 정보가 패칭되고, 핀이 렌더링 되는 순간 엄청나게 렉이 발생한다. 영상에서는 아이폰 16 Pro로 테스트를 해서 그런지 성능으로 커버가 됐지만, 아이폰 12 mini로 테스틀 했을 때는 사용이 어려울 정도로 버벅이는게 눈에 보였다. ▼ 원인 탐색Debouncer와 Throttler의 부재?첫번째로 생각난 원인은 Debouncer와 Throttler의 부재. 지도가 움직일 때 마다 API 호출을 하는 것이 버벅임의 주요 원인이 아닐까 생각했다.하지만 `onCameraIdle` 상태에서만 API를 호출하기에 디바운서도 잘 적용되어있고, 혹시나 구글 맵 패키지의 문제일 수 있기에 로그를 찍어보면서 확인도 다 ..