biz-ninza

더보기24.11 - 25.9 (ch1~ch5): 노션에서 자체사이트로커뮤니티 글과 노션으로 시작 운영하며 만족도와 리퍼럴이 높았던 1:1스터디를 누적 300명 운영. 이를 웹사이트에 옮겨 시스템화 시도 하였으나 기획-디자인-프론트엔드-백엔드 체제로 결과물을 만드는데 어려움을 겪음.일단 만들고 기능 확장을 하면서 '새로운' BM을 붙이자는 생각이 뼈아픈 패착이었음. MVP는 그 자체로 돈을 지불할 가치가 있는 최소기능이어야한다는걸 깊이 깨달음.내가 가리킨 달을 바라보지 못하고 움직이는 손가락만 바라보는 상황을 여러번 경험했음 (돌아보면 내가 명확히 달을 가리킨게 맞나. 지금 돌아보면 나 역시 뜬구름을 잡으며 멍하니 허공을 가리킨게 아닌가 싶다)또한 주1회 디스코드 비대면 기반이라는 점, 게다가 퇴근 후 비..

더보기24.11 - 25.9 (ch1~ch5): 노션에서 자체사이트로커뮤니티 글과 노션으로 시작 운영하며 만족도와 리퍼럴이 높았던 1:1스터디를 누적 300명 운영. 이를 웹사이트에 옮겨 시스템화 시도 하였으나 기획-디자인-프론트엔드-백엔드 체제로 결과물을 만드는데 어려움을 겪음.일단 만들고 기능 확장을 하면서 '새로운' BM을 붙이자는 생각이 뼈아픈 패착이었음. MVP는 그 자체로 돈을 지불할 가치가 있는 최소기능이어야한다는걸 깊이 깨달음.내가 가리킨 달을 바라보지 못하고 움직이는 손가락만 바라보는 상황을 여러번 경험했음 (돌아보면 내가 명확히 달을 가리킨게 맞나. 지금 돌아보면 나 역시 뜬구름을 잡으며 멍하니 허공을 가리킨게 아닌가 싶다)또한 주1회 디스코드 비대면 기반이라는 점, 게다가 퇴근 후 비..

1년 6개월의 여정 (24.11 - 25.5) 더보기24.11 - 25.9 (ch1~ch5): 노션에서 자체사이트로커뮤니티 글과 노션으로 시작 운영하며 만족도와 리퍼럴이 높았던 1:1스터디를 누적 300명 운영. 이를 웹사이트에 옮겨 시스템화 시도 하였으나 기획-디자인-프론트엔드-백엔드 체제로 결과물을 만드는데 어려움을 겪음.일단 만들고 기능 확장을 하면서 '새로운' BM을 붙이자는 생각이 뼈아픈 패착이었음. MVP는 그 자체로 돈을 지불할 가치가 있는 최소기능이어야한다는걸 깊이 깨달음.내가 가리킨 달을 바라보지 못하고 움직이는 손가락만 바라보는 상황을 여러번 경험했음 (돌아보면 내가 명확히 달을 가리킨게 맞나. 지금 돌아보면 나 역시 뜬구름을 잡으며 멍하니 허공을 가리킨게 아닌가 싶다)또한 주1회 디..

모바일 앱은 구현보다 빌드 배포 과정이 까다롭다. 기본적으로 안드로이드/iOS 생태계를 모두 잘 이해하고 있어야하고 React Native 를 쓴다고 해도 어떠한 아키텍쳐로 안드로이드/iOS 네이티브 코드위에서 JS 엔진을 띄워 앱 구동을하고 네이티브 모듈과 통신을 하는지 그 기본은 당연히 이해해야하며 (1편) 이마저도 복잡한 네이티브 설정없이 개발과 빌드를 진행하기 위해서 도입하는 Expo SDK 가 무엇이고 어떤 역할을 하는지 구조적으로 정확히 알아야 React Native 를 제대로 활용해 개발을 할 수 있고 (2편) 그렇게 여차저차 돌아는가게 했다해도 빌드와 서명 그리고 심사과정을 제대로 이해해야 앱을 계속 안정적으로 운영할 수 있다 (3편) 더보기1편 React Native 1편. R..

ZERO-ONE 지난 1년 반, 톺아보기 24.11 - 25.9 (ch1~ch5): 노션에서 자체사이트로커뮤니티 글과 노션으로 시작 운영하며 만족도와 리퍼럴이 높았던 1:1스터디를 누적 300명 운영. 이를 웹사이트에 옮겨 시스템화 시도 하였으나 기획-디자인-프론트엔드-백엔드 체제로 결과물을 만드는데 어려움을 겪음.일단 만들고 기능 확장을 하면서 '새로운' BM을 붙이자는 생각이 뼈아픈 패착이었음. MVP는 그 자체로 돈을 지불할 가치가 있는 최소기능이어야한다는걸 깊이 깨달음. 내가 가리킨 달을 바라보지 못하고 움직이는 손가락만 바라보는 상황을 여러번 경험했음 (돌아보면 내가 명확히 달을 가리킨게 맞나. 지금 돌아보면 나 역시 뜬구름을 잡으며 멍하니 허공을 가리킨게 아닌가 싶다)또한 주1회 디스코드 비대..

웹과 앱은 다르다. 웹은 코드 작성후 빌드해서 브라우저에 번들파일만 서빙하면 끝나지만앱은 빌드 과정에 네이티브 코드가 추가 되고, 서명이 붙으며, 플랫폼 (App Store / Google play)에 테스트 검수를 받고 출시되는 과정이 추가된다. 그리고 각 프로세스는 플랫폼(iOS/Android) 별로 상이하므로전체 프로세스를 꿰뚫고 있어야 안정적인 대응이 가능하다. 1. 코드 작성2. 앱 빌드3. 앱 서명4. 테스트 배포5. 공개출시 나는 전체 프로세스를 위와같이 정의하고자 한다. (엄밀히는 서명까지가 빌드에 해당되지만 글 챕터를 나누기 위해...) 특히 서명과 배포과정이 웹개발 프로세스의 개념과는 완전히 달라 애를 먹고 트러블 슈팅하는 과정에서 이 글이 나왔다. Google Play Conso..

GCP 에서 MySQL 인스턴스를 운영중이었다. ERROR 1045 (28000): Access denied for user 'user'@'host' 계정도 맞고 비밀번호도 맞다. 리셋하고, 접속 IP 네트워크 재확인하고, 무슨 짓을 해도 접속이 안되어서 한나절을 삽질했는데 어이없게도 드라이버를 MariaDB를 쓰고 있어서 발생한문제였다. MariaDB는 MySQL의 창업자 중 한 명이 Fork 한 뒤 독립적인 프로젝트로 발전.따라서 나는 둘이 같은 계열의 DB라고 인지하고 있었던 것 같다. 왜 드라이버가 다르면 접속 조차 안될까?애초에 내가 드라이버를 정말 정확히 이해하고 있을까?내가 DB 차이와 장단점을 제대로 파악하고 있는걸까? 즐거운 공부 기회로 승화시켜보자. 차례1. MySQL vs Mari..

항상 무슨일이든 일단 시작하면서 개선하는게 중요하다.완벽하게 하려면 아무것도 못한다.다만 내가 잘가는지 아닌지 피드백 루프를 만들어서 개선 iteration 구조를 만드는게 중요하다. 혼자 공부하지않고 스터디를 하거나 멘토링을 받는 것이 유효한 이유도 그러하다.공부야 어떻게든 할 수 있겠지만 내가 뭘 잘하고 뭘 못하고 있는지 그것을 파악하는 것이 학습이든 일이든 모든 것의 기초다. 혼자하는 학습이라면 문제를 풀거나 시험을 보면서 이런 부족한 점을 발견할 수 있다.그러나 기획, 개발, 디자인 등 IT 직무에서는 이런 방향성 자체를 얻는 방법이 없다. 우리는 이런 IT 멤버들을 위해 지속적인 성장 피드백 루프를 만들어주는 서비스다. 서비스도 마찬가지라고 생각한다.일단 배포하고 반응보면서 아하모먼트를 발견하..

대기업 QA 경력 FE 팀원 하나가 갑자기 지금 배포 곤란하다고 시간을 달라고 한다.믿고 승인했다.1달 가까이 지났는데도 운영준비가 안됐다.으악!!! 오버엔지니어링의 정수를 보여주고 있었다. 썰을 풀어본다. [ 1. BFF = Backend For Frontend ] 한마디로 프론트엔드에서 여러 백엔드 서비스 (MSA)에 요청해야하거나모바일/웹/데스크톱 등 프론트 애플리케이션이 다를 때 쓴다. 위와 같은 구조라면 웹 어플리케이션도 백엔드 서비스 A,B,C 에 요청 응답받을때 API 포맷이 다를 수가 있다.또 모바일의 경우에는 인터랙션이나 디스플레이 고려했을때도 백엔드에게 요구하는 사항이 다를 수 있다. 이때 인터페이스 레이어 하나 두면 프론트엔드 코드는 UI UX 에 집중할 수 있다. 한마디로 관..

버셀은 AWS 를 추상화한 서버리스 배포 플랫폼.AWS 인프라에서 돌리는 프론트 웹 코드를 Vercel에,혹은 반대로 Vercel에서 돌리던 프론트 웹 코드를 AWS 로 이전할 때 어떤 구조적 차이가 발생하는지 예상하고선제적 대응을 하기 위한 고찰 30장. 왜 요즘은 다 버셀 버셀 할까 (클라우드 인프라 정복기 3)요즘 프론트엔드 개발자들 무지성 버셀 쓰는거같다.왜 버셀 버셀하는지 싶지 않은가? 이 참에 설계철학을 알아보자. Vercel 은 2015년 설립되어 샌프란시스코 본사를 둔 유니콘 기업.전 세계 6개 대biz-ninza.tistory.com [ 1. Vercel vs AWS 구조적 차이 ] 우선 이전 글처럼 버셀에서는 Edge 서버에 캐시를 해놓음으로써 정적파일을 서빙한다.이후 ' 각 E..

요즘 프론트엔드 개발자들 무지성 버셀 쓰는거같다.왜 버셀 버셀하는지 싶지 않은가? 이 참에 설계철학을 알아보자. Vercel 은 2015년 설립되어 샌프란시스코 본사를 둔 유니콘 기업.전 세계 6개 대륙에 500~1000명 직원이 원격근무. Next.js 프레임워크를 만든 팀에서 -> 버셀이라는 플랫폼으로 묶었는데다시 말해 프레임워크 최적화 플랫폼이라고 정의한다. “버셀은 프론트엔드가 서버 책임을 회피할 수 있게 해주는 플랫폼” 가장 큰 특징으로는 서버리스. AWS/GCP/Azure 처럼 서버를 관리하지 않지.존재 자체를 숨겨서 SSH 로 접속해서 인프라 관리를 하지 않게, 즉 프론트엔드가 서버를 몰라도 되게함. (즉 cicd workflows 조차 안짬)생각해보면 브라우저를 홈구장 삼는 프론트엔드 ..

한 줄 요약 AWS로부터 서버가 React Server Components(RSC) 취약점 경고 받음.싸고 안전한 방식으로 치료보다 교체를 택함.서비스의 연속성을 지켜주는 고정 IP. 1. 인스턴스가 외부로 DoS 공격 트래픽을 쓴 흔적을 발견했다.2. 24시간내로 답장안하면 차단(mitigation)할거다. 인스턴스 들어가서 접속기록을 보니까 다양한 국적의 mohamed, wangjia, anton 같은 친구들이 ssh 계정 접속을 시도함 최근 ssh 로그인을 성공한 IP whois 로 찍어보니 aws 관련한 것들이라 ssh가 뚫린것은 아니라고 판단됨.12월 6일 Dos 로 나갔다는데, 현재는 UDP 포트보니 dns resolver 말고는 딱히 이상한건 없었음.다만 GPT좀 돌려보니 예전에 오픈한..

서비스 기업만들때 매출 발생하는 PMF 찾는 것 다음으로 중요한게 운영 즉 인프라가 아닌가 생각한다.심도한 이유가 있는데 그것은 바로... 돈이 나가기 때문. 비용 지출지점이기 때문. IT 기업을 만들때 지출 구조는 결국 인건비 / 마케팅비 / 인프라비이고내가 기획~개발~디자인~마케팅~데이터분석은 AI 에이드 받아서 어찌저찌한다해도 인프라는 어쩔수없는 고정비용이기때문에 인프라를 잘 이해하고 다룬다는건 사업리스크를 크게 줄일 수 있다는 것이 아닐까 여튼 AWS 쓰다가 GCP 가면서 자꾸 올려놓은 공개키가 사라져서 며칠 애를 먹었는데 썰을 풀어보겠다. [ 1. AWS, GCP 그리고 Azure ] 2024 기준 AWS 33%, Azure 21%, GCP 11% 점유율 (출처 : Statista) AWS..

최신순, 이름순, 인기순 등 다양한 상황에서 정렬(Sorting)을 해야하는 상황이 생김. 데이터가 몇 개 없으니 지금은 뭘 어떻게 하든 상관없지만 많다면 페이징이나 정렬에 대한 고민이 바로 따라붙을 것. 섞여있는 데이터를 가져와 최신순으로 정렬하는 상황 고찰해서 미리 리스크 관리를 해보자. [1. 프론트 최신순 정렬] 서버에서 모든 데이터를 받아서 브라우저 메모리에서 정렬할 수 있겠다. 브라우저에서 데이터는 배열형태, JS Array Object 의 정렬 메소드를 쓰게 될 것이고 이 때 사용하는 TimSort 는 병합정렬+삽입정렬을 혼합한 방식이라고 함. TimSort 는 작은 구간을 삽입정렬 방식으로 정렬하고 그 구간들을 병합하는 방식. (이 부분을 딥다이브할 생각없지만 '어느정도 정렬되어있는..

지금까지는 사실상 무엇을 만들어야겠다 목표를 가지고 기간만 쪼개는, 사실상 워터폴 스타일로 팀을 운영해왔다. 워터폴이 잘못됐다는게 아니다. 나는 우리는 왜 에자일을 추구하는가. 린 스타트업을 하기 위해서다. 내가 만들고 싶은 서비스와 시장이 원하는 서비스 사이에는 간극이 있다. 창업자가 큰 비젼 미션을 가지고 아이디어를 냈으면 이를 타겟과 기능을 날카롭게 만들어 시장을 쪼개고 반응을 보며 확장해 나가야한다. 에자일의 핵심이란 무엇인가? 나는 결국 피드백 루프라고 생각한다. 유저와 팀간의 피드백, 그리고 팀 내에서 팀원간의 피드백. 그렇게 만들어진 순환 고리를 통해 지속적으로 디자인이든 코드든 유지보수를 해나가면서 시장성을 확보하기 위해서 Agile(민첩한) 프로세스를 적극 활용하는 것이고 결국 ..

누구나 스프링 시큐리티를 쓸 줄은 안다. 그러나 권한에는 어떤 종류가 있고 요청 흐름상 처리되는 레벨은 어떤 것들이 있으며방법론에 따라 어떤 트레이드오프가 있을지 생각해보자 팀에 권한설계 AOP방식 제안하기 이전정리한 내용 - 4일 소요 - 목차1. 권한과 레벨2. 스프링 시큐리티 리뷰3. @PreAuthorize vs 비지니스로직 vs @PostAuthorize4. 권한을 enum 으로 관리 vs DB 로 관리5. 팀에 제안한 사항 (=URL 필터에 의존하지말고 AOP도 쓰자) 1. 권한과 레벨 인증(Authentication): 사용자가 누구인가를 확인. (ex. 로그인 → Authentication 토큰 생성)인가(Authorization): 인증된 사용자가 어떤 행동을 할 수 있는가. (ex..

드디어 운영을 올렸다. 아직은 가입자가 수십명 수준으로 미약하지만 첫걸음을 뗐다는데 의미가 있다. 돌아보면 올해초 정말 기획이 뭔지, 협업을 위한 문서가 뭐가 필요한지, 개발 절차는 어떤지 뭐가 뭔지도 모르는 상황에서 팀원들에게 의지해 여기까지 왔다. 뜻이 있는 곳에 길이 있다고, 누구나 뭔가에 확신을 가지고 계속 두드리다보면 문은 열리고 길은 반드시 찾게 될거라 믿는다. 그게 인간 세상이 돌아가는 메커니즘이다. 인간 사회는 그런 강한 의지를 가진 인간을 지지하고 끌어주는 집단적인 무언가가 있다. 그것이 무엇이든간에. 나는 그렇게 믿는다. 여하튼, 돌아보니 바보같았던 점이 많은데 오늘은 이 부분을 회고하며 개선점을 찾아보려고 한다. 1. 런칭이 예상보다 2배이상 늘어진 이유 당초 계획은 팀빌딩 ..

프로필이미지 업로드시 일단은 S3, fireabase 없이 스프링 백엔드 서버에서 자체 DB에 받으며 개발하고 있다. 일단은 최대한 간단하게 시작해서 필요한 경우 분리하자는게 팀 철학이다. 프로필이미지 업로드 API 응답에 저장 url을 받아서 추후 presigned url 등을 사용할 경우를 대비하며 확장성을 대비한 설계는 해놓고 있다. 처음엔 octet-stream 으로 이미지를 건네주면 백엔드 서버에서는 InputStream 으로 바이너리를 통째로 받고 있었으나 image/png, image/jpeg 같은 구체적인 파일 타입 명시로 분기 처리를 하려고 했다. 그러다보니 프론트엔드에선 백엔드에서 요구사항이 변할 때마다 그에 맞게 코드를 분기해줘야했고 전달할 content-Type 을 알려주고 그..

1. 프론트엔드팀 동기부여 최근 두 달 동안 프론트팀원 3명이 나갔고 1명을 내보냈다.3명은 '바빠서' 였고 1명은 참여태도도 안좋고 회의 내용과 컨벤션이 전혀 반영이 안되어 팀원들이 고통스러워해서 헤어지게 되었다. 왜 유독 프론트팀원들만 이탈이 잦을까? 다른 프로젝트를 했을 때도 백엔드팀은 똘똘 뭉쳐서 코드품질과 아키텍쳐를 고민해나가는데 프론트팀만 그런 부분이 약하다. 한창 고찰한 결과는 '주도권' 이 없기 때문이 아닐까 싶다.사용성은 기획 디자인팀에서, 성능은 백엔드팀에서 initiative 를 가지고 주도하지만 프론트팀에서는 기획과 디자인이 다 나오고 백엔드에서 API 까지 만들어진 상태에서 UI 와 데이터들을 뿌려준다. 이것이 단순노동으로 여겨질 수도 있지 않을까? 기술적 성장을 체감하지못해 자기..

어쩌다보니 급하게 프론트엔드 개발을 진행하게 되었다. tailwind, shadcn, storybook 등 전혀 모르던 상황에서 2,3일만에 UI를 만들어내긴 했는데 붕 뜬 느낌이다. 이 참에 디자인시스템이 뭔지 그리고 왜 이런 기술스택들을 도입했을지 생각해보자 약 일주일가까이 틈틈히 공부하하고 작성하며 만들어진 글이다 목차1. 디자이너가 만들어줄 디자인 시스템 디자인 원칙스타일 가이드컴포넌트기본 패턴 및 서비스 패턴2. 디자인 시스템 적용 (전통적인 방식)3. 디자인 시스템 적용 (Tailwind 프레임워크)Tailwind 를 쓰는 이유전역변수는 tailwind.config.tstailwind.config.ts 보단 global.css?Tailwind 는 프레임워크다4. 디자인 시스템 적용 (컴포..

실유저가 대기중인 MVP를 만들고 있는중이고 마케팅 비용에 몇 백만원씩 태울 수 없는 상황. SNS 를 만들어 키우고도 있지만, 가장 효율적이고 확실한 방법은 SEO 통해 자연유입을 시키는 것. SSR을 위해 Next 를 도입했다. 나는 이 프로젝트에서 포지션은 개발팀이 아니지만 일정을 맞추기 위해 긴급하게 프론트엔드쪽을 맡기로 했다. 문제는 Next.js , React Query 를 써본 적도 없고 개념만 흐릿하게 알고 있다는 것이다. 긴장되는 마음으로 하루이틀 배워서 감잡아서 API 1차 개발을 완료했다. 이제는 전체적으로 리팩토링하며 코드품질을 높여놓고 빠지려고 하는 과정에서 배운 것을 정리하게 되었다. React 는 UI를 만들기 위한 라이브러리이고 Next.js 는 React 기반의 프레..

현 시점에서 JPA 를 쓰지 않고 Java Spring 개발하는 것은 상상하기 어렵다. JPA를 사용해 데이터 저장을 하는경우, 만약 A 서비스에서 A dto 를 받는다면 이들을 A entity 로 변환후 (JPA 를 상속받은 레포지토리) repository.save 를 하면 영속성 컨텍스트에 A entity 가 등록이 되며 트렌젝션 종료시점에 JPA가 입력쿼리를 쏴준다. 그런데 A entity가 B entity 와 연관관계를 맺고 있어서 A 저장시 B도 영속성 컨텍스트에 반드시 들어와야한다면? 나는 도메인 분리 철학을 중요하게 생각하기 때문에 A 서비스에서는 B 레포지토리를 부르지 않고 B 서비스를 불러 B의 역할을 존중해주기로 했다. (19장 참고) B 서비스는 Dto 를 반환하고 있다. (..

서비스간 순환 참조가 일어났다. 고민을 많이했는데 결과적으로는 도메인만 잘 나누면 되는 것 19장에서 서비스는 다른 레포지토리가 아니라 서비스를 부르도록 하자고 결론낸것도 최대한 도메인 존중하며 설계를 하기 위해서였음. 리액트 컴포넌트도 그렇고 스프링 서버 클래스 분리 혹은 DB모델링도 그렇고 얼마나 확장성있고 누가봐도 수긍할 수 밖에 없는 구조를 만들어가는 것. 이것이 예술이 아닌가 싶다. 목차1. 문제상황2. 해결방법3. Facade 패턴과 CQRS 철학 1. 문제상황 [ Like Service ] : 좋아요 프로필 목록조회 수행Like 서비스에서 '나를 좋아요' 했거나 '내가 좋아요' 한 사람들의 프로필 목록을 반환한다.이후 좋아요 데이터 에서 UserId 를 뽑은 후 Profil..

초기에는 백엔드 개발자들이 '도메인' 별로 조악하게 기능명세서와 화면을 만들어보고, 프론트엔드 개발자들이 이를 컨펌하고 디벨롭해놓고 ERD, API 명세를 잡아 개발하자는, 지금 와서 생각해보면 어처구니 없는 생각을 했다. 이미 서비스가 노션과 카톡으로 돌아가고 있고 팀원들이 그것을 경험해봤기 때문에 따로 문서나 화면을 디테일하게 정의하지 않아도 서로 논의하면서 만들어갈 수 있을 것이라고 믿었다. 또한 각자 도메인에 대한 설계권한을 주어서 자율성과 책임을 만들어 주고 싶었다. 지금은 생각이 많이 달라졌는데 일단 Userflow 와 화면정의는 확실히 있어야한다. 추상적으로 말하면 백엔드 프론트 디자인 기획 마케팅 어떤 팀원들이 봐도 이해할 수 있는 '시각화' 된 그림과 이들의 '흐름' 이 있어야한다는 ..

좋아요 매칭 디버깅을 하려고 로그를 본다. 서비스 메서드 하나실행시키는데 무슨 쿼리를 4번을 날리고 라인 수도 어마어마하다. row가 3개여서 91줄이지, 10개만 됐어도 라인이 200줄은 넘어갔을듯 AOP 에 레포지토리 레벨까지 로그 찍어놔서 문제 파악이 바로 된 것은 뿌듯한 일 지금 MVP 단계에 서버 최적화를 고민할 이유는 없는데 일단 쿼리를 저렇게 무지막지하게 날리니 디버깅도 어렵고 일단 직관적으로 뭔가가 잘못된다는 감이 온다. 최적화를 해보자 목차1. 상황설명 (단방향 매핑 UserLike -> Profile -> User)2. 최적화이전 - 전형적인 N+1 문제 발생 O(2N+1)3. 최적화 시도1. UserLike 의 Profile 에 Lazy Loading 을 걸어보자 O(N+1) 4..

사람이든 기계든 코드든 그 대상의 사상 철학을 이해하는게 중요하다. 이 언어는, 이 프레임워크는 어떤 사상을 가지고 만들었는지를 이해하면 빠르게 시스템을 이해할 수 있고 해당 시스템에 최적화된 코드를 작성할 수 있기 때문이다. 또한 협업시에도 모든 기준은 해당 시스템의 철학에 얼마나 맞는가가 되어야한다.(만약, 뭔가 삐걱거린다면 목적에 안맞는 언어나 프레임워크 자체를 잘못 선택한 것) 자바는 객체지향, 그리고 스프링은 DI 가 핵심철학이라고 본다.사물과 행위를 최대한 객체지향적으로 풀어내고 DI를 통해 객체 생성과 주입을 외부에서 담당시켜 결합도도 낮추고 높은 확장성 가져가기. 즉, '명확한 책임분리' 가 기본이되어야 가독성이 좋아지고 커플링이 줄어들어 유지보수성이 높아진다고 믿는다. 3Layered ..

17장 백엔드에서 성공/실패시 응답을 통일감있게 내려준다. 프론트에서는 이걸 어떻게 받아줘야 디버깅시 편하고 또 유저에게 안정감있게 화면을 보여줄 수 있을까? 버튼을 눌렀는데 아무 동작이 없거나 빈화면이 뜨면 유저는 불편함을 넘어서 사업자체를 의심한다. 사람은 이성적으로 결정하는게 별로 없다. 프론트엔드 개발자는 본질적으로 데이터를 뿌려주는게 아니라 유저의 무의식을 설계하고 행동을 유도하는 임무를 수행한다고 생각한다. 프론트엔드 성공/실패 분기 처리전략일단 서버 개발자가 공감지능이 높아 배려를 잘해줘서 아래와 같이 성공/실패 응답을 잘 주고 있는 상태 { "success": true, "status": 201, "message": "회원가입이 완료되었습니다.", "data": { "use..

15장 요청 본문 로깅에서는 클라이언트에서 서버에 어떤 Body 데이터를 가지고 서버에 들어오는지를 로그를 찍어서 추적하고 싶었다. 지금까지 개발할 때 @ControllerAdvice 나 @RestControllerAdivce 로 프론트 백사이 응답구조를 맞춰주는것을 정석으로 알고 맞춰했음. 혼자서 기능개발 한다고 포맷을 신경쓰지않고 그냥 하다보니 왜 그렇게 해왔는지 참의미가 이해되어서 파고들다보니 만들어진 글 목차1. 요청 응답시 서버 개발자의 배려가 부족하다면...2. @Controller Advice 와 @ExceptionHandler3. 백엔드 응답 전략 (코드 구현)4. 프론트엔드 응답별 성공/실패 분기 처리전략 1. 요청 응답시 서버 개발자의 배려가 부족하다면... 어차피 HTTP 표준..

이미지를 바이너리 형태로 DB에 넣는건 말이 안되는 일 비정형 고용량 데이터를 넣어 CRUD 하게 되면 쿼리 I/O 나 백업복원 속도은 둘째치고, RDS 같은 클라우드 DB를 쓴다면 스토리지나 트래픽 요금폭탄이 기대가 된다. DB에는 이미지 링크만 저장하고 이 이미지를 어딘가 올려두어야하는데 서버 인스턴스는 좀 아닌 것 같고 파이어베이스와 S3 중에 고민이 시작됨 다만 파이어베이스 스토리지 대비 S3이 presigned URL 등의 접근제어를 포함해 좀 더 유연하고 확장성있다고들 하는데 각각 어떤 철학이나 아키텍쳐를 갖고 있을까 살펴보다 만들어진 글 "이미지 CRUD에 대한 권한처리는 어떻게 처리하지. 클라우드에서? 혹은 백엔드 서버에서?" 목차1. 이미지를 클라우드에 두는 이유2. 이미지는 백..

React Native CLI 에서 프로필 사진업로드를 위해 카메라 권한을 획득하려다보니 iOS, Android 네이티브 코드를 건드려야 했다.(Info.plist, Podfile - iOS혹은 AndroidManifest.xml - Android) Window 에서는 Xcode 를 사용하지 못하기 때문에 iOS 빌드를 못한다. 결과 확인을 못한다. 크로스플랫폼을 사용하는 의미가 없어지는 것이다. Expo 로 전환하기로 했다. 둘이 아키텍쳐적으로 어떤 차이가 있는걸까 가벼운 마음으로 글을 썼지만 어쩌다보니 4일동안 작성하게 되었고 20page 가 넘는 문서가 되어버렸다 4일을 헤엄치다보니 그냥 한마디로 표현하자면 Expo 는 누군가 만들어놓은 브라우저위에 HTML 만 올리면 되는거고, CLI는 브라..