วีดีโอ

채팅의 경우 NoSql도 좋은 선택입니다. 저장하기 편하기도 합니다. 게시판 댓글이나 채팅은 NoSql을 활용하기에 정말 좋은 케이스입니다. 하지만 서비스가 제공할 기능에 따라 선택이 달라져야 합니다. 특히 게시판같은 서비스를 만드는 경우 관계형 DB로 하면 정말 복잡해 질 수 있는 내용을 NoSql로 만들면 간단히 끝나기도 하지요. 하지만 이런 DB 선정에 더 중요한 전제가 있습니다. 해당 데이터가 "관리되어야 하는 데이터"이냐 아니냐는 차이입니다. 제가 예전에 어떤 프로젝트를 갔는데 회사에서 관리하는 중요 데이터를 자신이 배운것이 몽고 DB밖에 없어 NoSql로 저장한 경우를 본적이 있습니다. 그게 가상 자산이었는데 말이죠. 다른 케이스인데 SM에서 수억을 받고 외주를 받은 회사가 코인 관련 개발에서도 몽고 DB를 사용해서 저장한다고 제안하고 있었습니다. 이건 말도 안되는 선택입니다. 그런 기본도 안되는 선정을 보고 있으면 한숨이 나옵니다. 아시다시피 NoSql의 기본 전제는 중복 허용입니다. NoSql에서 사용하기 가장 적합한 데이터는 AI 학습 데이터 수집이나 로그등의 데이터 저장입니다. 중복되도 대세에 지장없는 케이스에서 저장해야 합니다. 또한 속도가 중요한 경우에도 사용됩니다. 예전에 적용했을 경우 관계형 DB보다 20배 정도의 속도 차이를 보였습니다. 하지만 통계를 내야 하거나 주요 데이터를 저장해야 하는 경우라면 관계형 DB를 사용하세요. 속도 문제를 걱정하시지만 웬만하면 인덱스를 사용해서 속도가 나옵니다. 관계형 데이터를 사용하는데 속도가 너무 늦다면 90% 이상은 인덱스만 잘 걸어도 속도가 해결되는 경우가 많습니다. 만일 1억건의 데이터가 DB에 있다고 합시다. 이게 인덱스를 걸지 않을경우 1분이상의 속도로 검색될 수 있습니다. 하지만 인덱스를 걸면 O(n) = 10^8, 약 8번의 검색으로 검색이 될 겁니다. 실제 걸어보면 틱단위로 속도를 측정해야 할 겁니다. 혹은 많은 경우 쿼리를 잘못 작성한 경우입니다. 몇백 라인의 쿼리라도 제대로 작성된 쿼리라면 10~20ms 안에 끊습니다. 제가 서버는 아무리 느려도 20ms 를 넘기지 말라고 합니다. 이는 클라이언트가 요청해서 서버가 응답하는 전 과정에서의 속도입니다. 서버가 느린 상당히 많은 이유가 DB 응답시간 일 경우가 많고 이는 보통 인덱스와 쿼리 문제일 경우가 많습니다. 속도로 인해 DB 선택을 NoSql로 해야만 하는 경우라면 아직까지 제 경우는 만나보지 못했습니다. 이런 경우는 특수한 경우일수 있는데요. 초당 1억건의 데이터들이 밀려들어 오는 경우라면 고려해 볼수 있습니다. 그런데 그런 특수한 경우는 데이터 저장이 필요한 경우 그냥 파일로 떨굽니다. 예를들어 통신사 중간에 데이터들은 음성 데이터뿐만이 아니라 부가 장비 데이터도 밀려들어 옵니다. 여러개의 장비들이 거치는데 해당 장비들의 정보까지 밀려들어 오는데요. 이런 케이스등은 실제 속도가 중요한 케이스이긴 합니다. 하지만 일반적으로는 앞서 말했듯이 데이터의 특징에 따라 DB를 선정하는것이 맞아 보입니다. 즉, 채팅 서비스에 따라서도 채팅을 특히 중요하게 생각하지 않는 경우 몽고 DB를 활용할 수 있습니다. 가장 적합한 예시는 유튜브 실시간 채팅이 있을 수 있습니다. 유튜브 실시간 채팅의 경우 기능이 NoSql을 적용하면 상당히 편한 형태입니다. 아시겠지만 어차피 DB 사용이 파일 저장입니다. 해당 경우에는 굳이 사용하실 필요가 없습니다. 파일 시스템을 사용하는 경우는 DB보다 더 빠른 속도가 필요한 경우가 되겠습니다. 가장 좋은 케이스일 경우는 메모리 DB인 Redis의 경우 데이터베이스가 종료될때 마지막에 저장된 내용이 다시 해당 DB를 올리면 그대로 올라옵니다. 이런식으로 DB보다 더 빠른 속도로 영구적으로 저장해야 할 경우 파일로 그대로 저장하고 불러오는 방식을 취할 수 있습니다. 그리고 일반적으로 파일 시스템은 그냥 나만의 포맷으로 데이터를 만들어 저장할 때 사용하기 좋습니다. 제가 예전에 윈도우폰이 처음 나왔을때 시를 적을때 처럼 자유롭게 데이터를 저장하면 어떨까 해서 만든 다이어리 앱이 있었는데요. 그때 마이크, 손글씨, 일반적인 글, 이미지, 영상등을 한 다이어리에 저장할수 있도록 했습니다. 이때 데이터 저장 방식을 나만의 데이터 형식을 만들어 파일로 저장하는 형태였습니다. 참고로 채팅 데이터를 이미지나 첨부 파일 저장을 관계형 DB로 할경우 그대로 저장하지 않습니다. 일종의 파서 형태로 저장을 하기 때문에 결국 DB에 들어가는것은 문자열 형태입니다. 여기서 파서라고 표현한 것은 정말 간단한 예를 들어 특정 태그안에 정보를 전달하고 그걸 다르게 표시하는 방식을 말합니다. [<$$ Type : Image, Url : /images/202401042_bg.png $$>] 라는 데이터가 있다면 이 데이터로 클라이언트는 해당 이미지를 표현하는 방식을 취합니다. 이렇게 해야 어떠한 요소가 오더라도 클라이언트가 자유롭게 표시할 수 있습니다. 저런 타입이 링크, 동영상, GIF, 이모지 등이 오는 형태입니다. NoSql의 데이터 중복이 발생할수 있다는 것은 생각하신 것과는 조금 다른 내역입니다. 예로 드신 채팅을 두번 보내 저장하는 것은 정당한 요청이기 때문에 관계형 DB에서도 정당한 데이터입니다. 중복이 발생할 수 있다 함은. 예를들어서 돈이라고 한다면 관계형 데이터베이스는 자신의 자산이 한 테이블 같은 곳에 한 테이블에 존재합니다. 그것을 조인을 걸고 한 데이터를 여러 다른 테이블과 합쳐서 표현하는 식이죠. 그런데 NoSql은 여러 컬렉션에 금액이 다르게 저장할수 있다는 이야기입니다. 즉, 내 잔고가 어떤 컬렉션에서는 100만원이 남았다고 하고 어떤 컬렉션은 1원이 남았다고 저장됩니다. 이것을 기본적으로 허용하는 DB입니다. 그에따라 만일 이렇게 다르게 저장된 경우 어떤 데이터가 옳은지 해당 데이터만으로는 판단할수 없습니다. 그렇기에 DB 선정 조건은 속도가 아니라 데이터가 어떤 특징을 가지냐에 따라 선정되어야 합니다. 개인적으로는 명확한 데이터 구조를 보장하지 않는 것은 NoSql의 단점이라고 생각하지는 않습니다. 애초에 그런 DB이기 때문이죠. 명확한 데이터 구조가 필요한 경우라면 NoSql을 선택하지 말아야 합니다. NoSql의 대표적은 MongoDB의 경우 데이터를 그대로 받아서 그대로 돌려주는 목적에 적합합니다. 예를들어 내가 특정 App에서만 사용하는 데이터를 서버에 저장하는 경우에 좋을 수 있습니다. 일반적으로 NoSql만 사용하는 경우는 극히 드물고 사용한다면 관계형 DB와 같이 사용하는 경우가 많습니다. 이게 제가 한번 다른 분에게도 언급한 적이 있는 내용인데요. 중요 데이터를 다양한 데이터 형식을 저장해야 하기에 NoSql을 사용하려고 하시던 분이 있어서 비슷하게 답변을 드렸습니다. 여기서 가장 중요한 것은 다음 내역입니다. "DB를 선정할 때는 저장하는 데이터의 특징에 따라 선택하세요." 이에 일반적으로는 채팅 및 댓글등은 몽고 DB에 저장하기 좋은 데이터입니다. 그런데 제가 어떤 프로젝트에서 댓글을 분석해서 특정 작업을 하려고 하는 회사가 있었는데요. 이러한 경우는 관리되어야 하는 데이터가 되기에 관계형 DB를 사용했습니다.

오늘도 잘 보고 갑니다. 처음부터 만족할수는 없겠지만 그래도 이전보다는 도움이 되었으리라 생각되네요. sql은 어느정도 익숙해지면 orm 라이브러리를 써보는것도 추천드립니다. 직접 컨트롤하는 것도 공부목적으로 보면 나쁘진 않다고 봅니다만, 현업에서는 orm을 많이 쓰니까요. 그리고 저도 golang은 공부중인데 context 패키지를 잘써야 한다고 하더라구요. 특히나 handler나 여러부분에 사용을 하던데, 무지개곰님의 코드에서는 보지 못해서 한번쯤 스터디해보실 수 있을까요. 얼마전에 go언어로 배우는 웹애플리케이션 개발이라는 책도 새로 나왔던데 한번 봐보세요.

영상 잘봤습니다. 기능적인 면은 rollback과 commit도 적용 잘 한 것 같습니다. 다만 github을 봤는데 리팩토링을 한번 하고 넘어가면 어떨까요. pkg밑에 model이란 개념으로 도메인들 분리는 잘했는데 각 파일에 모든 계층이 들어가 있습니다. clean architecture를 참고해서 각모델별로 controller - service - repository로 구분지어서 분리하면 좋겠습니다. 이렇게 나누는 이유는 각각의 레이어의 구현체가 달라지는 경우를 상정해야 하기 때문인데, 이건 찾아보면 좋을 것 같네요. 앞에서 아키텍쳐 공부도 하셨기 때문에. 당장은 리포지토리 패턴과 클린 아키텍쳐만 찾아보셔도 좋겠습니다. 그리고 에러처리 구현을 했으면 꼭 테스트를 해보셔야 합니다. 정석은 단위테스트를 구현해서 노멀케이스와 에러케이스 모두 검증해봐야 하고, 그게 아니면 일부러라도 그 상황을 만들어서 회복이 가능한지 봐야 됩니다. 노멀케이스는 다들 테스트해보지만, 에러는 확인 안하고 넘어갔다가 실제 상황시에 예상대로 동작 안하는 경우가 많습니다. 이 부분은 꼭 체크하시면 좋겠네요. 공부뿐 아니라 실무에도 도움이 많이 될겁니다. 그럼 다음 영상도 기대할게요.

그냥 이 정도가 있다고 알고 넘어가시면 될듯. 요즘에는 GPT등과 같은 LLM API를 다루게 되면 SSE(Server Sent Event)에 대해서도 알게 될겁니다.

오늘도 잘보고 갑니다. 프로필 사진은 구현하다 보면 생각할게 더 생길거 같네요. 데이터 전송은 좀만 더 깊이 가면, 텍스트 데이터의 경우는 한번의 송수신으로 끝나지만 용량이 큰 바이너리 데이터라든가 지속적으로 주고 받는 스트리밍의 경우 고민할 부분이 많아집니다. http 통신은 일정 패킷 단위로 잘라서 보내게 되는데, 받아서 하나로 합치려면 이 데이터에 대한 헤더라든가 메타정보가 필요하겠죠. 그 외에 지속적인 연결유지를 위한 websocket이라든가 grpc라든가 있는데, golang을 공부하신다하니 grpc쪽은 다뤄보지 않을까 생각이 드네요

몇가지 질문 드리고 싶습니다. 1. 프로필 사진은 DB에 url로 저장하는데 그럼 원본 이미지는 어떤 저장소를 사용하실건가요. 오브젝트 스토리지 혹은 볼륨 마운트? 2. 이미지 업로드 기능도 구현한다면 사이즈 제한은 어떻게 할지 3. 프로필을 보여줄때 원본 이미지를 그대로 사용하실건가요? 아니면 어느단계에서 섬네일 이미지를 만드실 건가요. 이 부분의 테이블은 어떻게 추가하실지. 4. 이미지 업로드 후 파일 이름은 새로 바꾸실건지. 아니면 폴더 식으로 구성해서 각각 유지할지. http 전송은 multipart/form-data를 보시면 좋을듯. 텍스트, 이미지, 음성, 동영상에 대해서 어떤 방식이 있는지 살펴보면 좋을거 같아요.

프로필에서 id는 query parameter보다는 path parameter가 더 나은 방식인데, /profile/:id 이런식으로요. 이부분은 path parameter vs query parameter를 찾아보면 좋을 것 같네요. 해시태그는 나중에 모아서 보여주는 역할도 하는 건가요? 같은 해시태그를 입력한 다른 사용자조회도 되는지. 테이블을 어떻게 구성할지 궁금하네요. 나중에 erd도 한번 올려주세요. 글을 쓰고 보니 이미 db도 올렸군요.

댓글을 열심히 썼는데 날아간건지 😂 상태가 변한다는 점에서 post를 주로 선호하고 대부분 사용하고 있습니다. logout은 캐시를 지우고 세션을 정리한다는 행동에서 delete여야 한다는 소수 의견도 있습니다. 보안성은 http는 get이든 post든 문제가 되니 https여야 하구요. 링크남긴 글에서처럼 get을 쓸 경우 최신의 브라우저들에서는 prefetch로 인해 logout을 실제 수행하기도 전에 prefetch단계에서 로그아웃이 된다고 합니다. 좀더 자세히 공부하려면 rest api design을 찾아봐야겠지만, crud에는 어떤 method를 쓰면 좋은지만 찾아보고 다른 서비스들의 api reference를 참조하면 좋을거 같아요. -- 링크를 첨부하면 댓글이 날아가는군요.

피드백 바로 적용하고 영상도 금방 올리셨네요. 회사에 들어가서 협업을 할때 처음 하는 작업이 컨벤션을 맞추는 일입니다. 디렉토리 구조는 어떻게 할지, 네이밍 규칙이라든지, 무슨 라이브러리를 쓸지 등이요. 혼자 작업하면 맘대로 해도 되지만 지금부터 신경쓰면 일하기 편할거에요. golangci-lint 등 스타일을 검사해주는 툴들이 있습니다. 정적 분석 도구라고 하는데 보통 ci에 연결하거나 pre-commit hook을 이용해서 커밋전에 검사하기도 합니다. 검색하면 당근마켓 테크블로그에 정리가 잘되어 있는데, 카카오나 네이버, 우형 등 각 테크회사 블로그 글들을 공부할때 참조하면 좋을 것 같아요. 저는 go 개발자는 아니지만 테크 회사에서 백엔드 개발을 하고 있습니다. go는 이번 프로젝트에 사용하게 되어서 막 시작하고 있구요.

왜 go로 하시나요?

우연히 들러보았는데 공부 기록들이 멋지네요. handler들이 모두 get으로 되어 있는데 보안상 좋지 않습니다. login, logout 모두 post로 변경하셔야 하고 이유는 찾으면 나오니 한번 찾아보세요. go는 권장되는 style guide가 확실한 편이라 폴더나 파일도 go style guide에 맞춰서 바꾸면 좋을 것 같네요.

Redirect에 localhost로 하드코딩되어 있네요. Env파일이이나 다른 방식을 도입해서 서비스별로 적용되게 구성하는게 좋을거 같습니다.

I_User interface 명을 BaseUser 처럼 접두사를 사용하지 말고 사용하시는게 좋을거 같습니다. 그리고 매서드가 하나인 인터페이스는 인터페이스를 사용하지 않는게 더 좋습니다. 왜냐하면 레이어만 늘어나고 불필요한 코드만 늘어나는 효과만 있습니다.

유튜브에서 자동재생으로 틀어주었는데, 태그에 golang이 있어서 잠깐 봤네요. 그런데 MySQL Schema가 int라서 저장에 실패되었다고 varchar로 변경하셨다고 하는데.. 리액트 profile/:id 라우터를 보니 30억이 넘어가긴 하네요 ㅎㅎ 그렇다면 MySQL 스키마 타입은 bigint로 하시면 되지 않았을까요? varchar로 하게 되면 string 타입이라 파싱을 해야하고, bigint면 uint32 같은걸로 자료형을 쓰면 될거 같은데 (profile id를 어떻게 지정하신건지는 모르겠어서...)

DB에 대해서 잠시 이야기 해 보겠습니다. 사소한 일일 수 있지만 테이블 명과 컬럼명의 규칙이 제각각인것 같습니다. 일반적으로 DB에서는 언더바 및 소문자를 많이 사용하기는 합니다. 사소한 것일 수는 있지만 해당 규약 하나가 다르게 적용되었을 때, 해당 작명으로 인한 버그가 유발될 수 있습니다. 두번째는 profile_userinfo_id를 많이 사용하고 있는데 왜 userinfo_id를 직접 참고하지 않는지에 대한 의문 사항입니다. 즉, profile 테이블이 주 키가 따로 id를 가진것이 아니라 주 키가 userinfo 의 id를 래퍼런스로 가지기 때문인 것이 맞을까요? 만일 관계도가 profile이 주로 다른 테이블의 키로서 사용된다면 userinfo와 profile 관계가 1:1 이더라도 profile의 id를 생성하고 이 id를 다른 테이블에 사용할 것 같습니다. 이렇게 해야 userinfo 테이블과 다른 테이블이 연결이 느슨하게 되는 것이며, 작성한 것처럼 사용한다면 ERD 상에서는 userinfo와 projct hashtaglist_has_profile, tech_has_profile등의 테이블의 연결이 없는 것처럼 보이지만. 실제는 userinfo와 다른 테이블 관계가 연결된 상태입니다. profile 1 - n project 관계에서 혹시 여러명이 한개의 프로젝트를 하는 경우는 어떻게 처리되는지 궁금하네요. 그리고 hashtaglist에는 id를 가져야 하지 않을까 합니다. id가 없다면 hashtaglist_has_profile 에서 hashtaglist_hashtag 필드는 중복이라 괜히 데이터 관리도 어려울 뿐더러 중복된 데이터가 되지 않을까 합니다. 그리고 제가 설명을 들었음에도 tech와 techcategory는 명확히 어떤 역할인지 구분을 잘 못하겠네요. code또한 컬럼명이 같고... 왜 테이블이 나누어져야 하는지도 잘 모르겠습니다. 백엔드와 프론트엔드, fullstack의 구분은 언어가 아니라 profile에서 해당 사용자가 어떤 역할을 주로 담당하는지로 구분하면 되지 tech쪽하고는 상관 없지 않는지라는 생각이 드네요. tech_has_profile에는 사용자의 레벨을 기록하는 컬럼이 하나 있어야 하지 않나 싶습니다. 참고로 R_UserInfo에서 아스테리크로 * 가져오는 것은 개인적으로는 실 프로젝트에서는 한번도 사용한적이 없습니다. 이에 약간은 불편하긴 했습니다. 또한 R과 C로 구분하시긴 했지만 리턴 포맷이 동일한것이 좀 더 좋다고 생각합니다. 종종 insert후에 생성한 데이터의 id를 반환값으로 반환하기도 하거든요. 예를들어 글을 작성한후 해당 글을 바로 확인하려고 상세 페이지로 이동할때 생성한 id를 반환받아 이동하기도 합니다. 위와 같은 요청이 들어와서 처리한다면 어떤 insert는 error만 반환하고 어떤 insert는 info, error를 반환하게 되어 이 또한 오류를 발생시키기 쉽습니다. 그리고 inset, update 쿼리등은 transaction 처리가 되고 있는 것이 맞나요? rollback, commit등이 없고 exec로 되어 있는데 해당 사항이 바로 적용이 된다면 위험하다는 생각이 듭니다. 그리고 로그인시 정보를 왜 쿠키로 전달하는지는 이해를 하지 못하겠네요. 해당 사항은 현재 서버에서 엑세스 토큰 관리하는 모듈을 만드는 시간을 절약하기 위해서 사용자 정보를 쿠키에 저장하고 클라이언트가 전달해주는 쿠키의 정보를 믿고 사용한다. 라는 것이 맞나요? 일단 당연히? 서버는 클라이언트를 믿으면 안됩니다. 클라이언트는 신용 불량자거든요.

머싯서요 ~~!

혼자 하시나요? 응원합니다!

응원합니다. 그런데 솔직히 신입 입장에서 당장 배워야할 것들이 많을텐데 개념을 잡고 go를 하신다는 걸 보니 물음표가 많이 생기네요. 적어도 구인자 입장에선 매력적이진 않을 거 같아요.

그래픽스 ㄱㄱ