슬기로운 회사생활

회사에서 무엇을했는지 기록하기위한 시리즈 시작

주식회사 클라운지 내부에서 돌아가는 로직 및 코어시스템에 대한 학습.B2B와 B2C등 다양한 모델을 가진 플랫폼을 가지고있으며현재 확인된것만 7개(+@) 플랫폼을 관리하고있다.다만 크게 보면 videohelp.me와 관련된 플랫폼4개 gotalk.to와 관련된 플랫폼3

주식회사 클라운지의 경우브라우저에 의존적인 webRTC를 사용하기때문에아래와 같은 상황에서 매번 이슈에 대응해야한다.google browser업데이트,apple의 정책이 변경safari업데이트규모가 큰 회사들의 webview정책 변경(naver, kakaotalk, n

tsconfig의 skipLibCheck 옵션이 false로 설정됐기때문에library까지 ts검사를 해버린다.굳이 필요성을 못느껴서 libcheck를 꺼버린 후 이외 모든 플랫폼(7개 +@)에 동기화 하여 적용했다.

frontend단에서 자체적으로 현재 접속한 기기의 ip를 파악하여해당 ip가 white list형식으로 하드코딩된 내용에 존재하지 않는다면서비스이용이 불가하게 제일앞단에서 한번 걸러주는 역할을 한다.문제는 webrtc의 경우 테스트할때 https규약이 필요한데 이것을

2021.04.14특정 모달이상 작동하는 이슈가 있어서 이것을 수정하는 내용이다.컴포넌트가 생성될때 특정한 조건에 부합하면 맨처음 한번만 실행되야 하는 내용이규칙성없이 모달창이 나타나는 현상이 있었다.내용은 전형적인 react의 side effect인 rerenderi

실시간 채팅창에서 채팅목록이 업데이트 될때마다 화면이 최하단으로 유도되는 현상을 수정해야한다.reactjs의 side effect중에 하나인 이상 rerendering문제다.사실상 설계를 잘못했기때문에 일어나는 현상이기에 코드는 잘못이 없다.이것을 Pure Compon

webrtc 이슈를 해결해야한다.몇가지 특정한 조건에서 동영상 녹화는 되지만 이것을 파일화 하는 과정에서 이상동작하는 이슈가 있는데 재수없게도 해당 몇가지 특정한 조건에 우리 프로젝트가 당첨됐다.해당 기능을 정상 동작하게 후회하여 해결해야한다.동영상 녹화하는 과정 중간

2021.07.21webRTC를 사용하기위해서는 사용자에게 비디오 및 오디오 제어권한을 요청하고 이것을 사용자가 승인해야 우리의 프로젝트를 이상없이 사용할 수 있다. 어떤이유에서인지 이것을 고객이 거절했을때 일반적으로 사용자는 해당 내용을 혼란스러워 할 확률이 높기때문

알고리즘 중요하고 깔끔한 코드 작업 이후 리팩토링 및 테스트 코드작성모든것은 정말 필요하고 다 중요하다.하지만 현실적으로 위내용을 전부 다 이루기에 스타트업이란 환경에선 쉽지않다.기본적으로 지켜야할 수칙으로 생각하되 그때그때 상황에 맞춰 타협해야겠다.시간이 없으면 스파

2021.08.13많은 회사를 경험해본것이 아니기때문에 나는 회사문화 스타트업 문화를 모른다.겪어봤자 2~3개밖에 안되면서 문화를 안다고 하는것도 웃기고아무튼 문서화라는것을 진행해야한다고 대표님께 의견제시했다.문서화는 일종의 문화라고 생각하는데,이런 문화가 전혀 형성되

2021.09개발자 및 디자이너마다 사용하는 프리티어 포맷설정이 다르던가 사용은 안하고 있어서그냥 통일해서 사용하자는 의견을 내고 해당 의견이 받아들여져서 포맷팅에 관련된 프리티어 설정 방법을 통일화했다.

webRtc와 janus.현재 회사의 컨셉의 중요한 담당을 하는 코어 기능이다.webrtc는 영상통화를 위한 화면제어 janus는 영상통화에 필요한 room 관리이렇게 구성된다.직접구현해보면 알게되겠지만 1:1영상통화는 문제없지만,n:m 영상통화의 경우 난이도가 수직상

2021.10디자이너분이랑 협업하여 영상으로 SI작업을 편안하게 진행할수 있는 기초 프로젝트? 를 구축하는 테스트 프로젝트를 담당하게 됐다. 사실 정신은 없는데 이런 잡다한 일을 많이 할수록 도움이 되는것도 사실이다. 조금 토할꺼같지만 괜찮다.

관리자 페이지를 만드는것은 숙명이다.기존에 이미 어느정도 구축이 돼있지만 미흡한 부분도 많기때문에관리자 페이지 기능 추가 및완전히 새롭게 프로젝트 리뉴얼하기로 결정됐다

회사 내부에서 관리하는 플랫폼이 8개 이상되기때문에 내부 인원들끼리 용어통일이 안돼서 많은 혼란이 있다.또한 특정 프로젝트가 어떤 인스턴스에 위치하는지도 제대로 파악이 안돼서 매번 업데이트때마다 헷갈린다. 서버작업은 매우 신중하게 해야하는데 이런 쓸때없는 이유로 사고가

계속 말하지만 회사가 관리하는 플랫폼이 많고 또한 각각 각종언어를 지원하는 파일이 별도로 저장되어 제공된다.지원하는 언어는 총 8가지이다.(많음)현재 회사의 다국어 처리 방법은 이러하다.1\. 기획자가 다국어에 필요한 문장을 리스트업하여 파일화2\. 리스트업된 다국여

2022.01우리 회사의 videohelp.me의 경우 b2b모델이기에 딱히 랜딩페이지가 중요하지 않았다.(?)근데 어쨌든 사업이 확장됨에따라 videohelp.me의 랜딩페이지또한 실 서비스와의 연동이 필요한 상황이 왔다.따라서 실서비스의 회원가입 로직 및 결제 로직

2022.02블루프린트... 기획자께서 오랜기간 삽질하고 노력하며 만들어주신 설계도하지만 추상적인 디자인 위치만 존재하고 자세한 스펙은 없다. 예컨데 데이터의 흐름이라던가어떤 데이터가 어떤타이밍에 어디에 위치해야한다던지무엇인가 기능이 추가되지만 만들어 주세요만있지 그것

ref: https://cookiepayments.com/main우리 회사는 국내결제의 경우 pay2pay api를 이용하여 결제기능을 구현하였다.지금도 물론 계속 사용가능하긴한데 현재 랜딩페이지 진행중에 결제기능이 추가돼서새롭게 구축하는김에 아예 쿠키페이로

드디어 graphql 이전작업이 이루어졌다.현 회사의 문서화 부족문서화가 기본적으로 돼있어서 api구조 설명서를 따로 쓸필요 없는점.(가장 중요)overfetching, underfetching문제 해결frontend에서 backend api에 대하여 TS적용 가능(a

우리회사의 프로젝트는 create-react-app 기반이다연식이 오래됐다(2017년)사용하는 외부 모듈이 너무 오래됐다.번들링 속도가 너무 오래걸린다.migration 하는김에 리팩토링도 함께하자.ㄴ class형식중 hook형식으로 재해석 가능하면 역공학때려서 컴포넌

디렉토리 관리가 힘들다.어떤 부분은 컨셉자체가 완전히 달라서 디렉토리 구조가 특별해질 이유가 있음에도기존 프로젝트의 디렉토리 철학에 끼워 맞춰야 하기때문에 구조가 이상해지는 경향이 있다.회사 내부 플랫폼이 여러개인데 덩치가 좀 큰편이라 매번 이슈 핸들링할때마다 찾아가는

저번엔 MSA 적용하는 내용을 다루었다.이번엔 프로젝트 최적화와 리팩토링에 관련된 내용을 다룬다번들링 도구를 webpack에서 vite로 변경하였다.구글프로젝트인 squoosh로 이미지 최적화. 퍼센테이지에따라 완급조절ref : https://squoosh.a

매번 회사 프로젝트의 api server를 instance에 배포 할때마다 압축하고...scp쏘고 압축파일 로컬에서 지우고 클라우드에서 압축풀고 이름 변경하고 패키지 설치... 서버실행... 등등등 절차가 너무 많아서 일단 급한대로 자동화를 진행해주었다

너무 감사하게도 좋은곳에서 너무좋은 오퍼를 주셔서 이직을 하게됐다.사실상 문서화는 1년전부터 하고있었기에 특별하게 더 문서화를 할것은 없었다.다만, 새롭게 진행한 관리자 프로젝트와 자잘한 것들의 인수인계 내용이 있을뿐이다.다행이도 인수인계받으시는 분께서 습득력이 뛰어나