隣席の開発者群

오늘 할 얘기는 서버라는 말을 좀 집중적으로 파볼건데, 최근 인프라에 대해서 좀 알아보다보니, 내가 잘못 이해하고 있던 것들이 꽤나 있어서 이 부분을 제대로 정리하고 넘어갈 예정이다. 위에 있는 그림이 이제 웹 어플리케이션이 동작하는 방식을 명확히 보여주는 예시인데, 그림만 보면 그냥 골머리가 썩을거다. 웹 서버는 뭐며, 웹 어플리케이션 서버는 뭐고, 클라이언트는 무엇인가? 라는 부분에서 일단 상당한 혼란이 올 것으로 예상된다. 인프라나, NEXT.js의 SSR 기능을 잘 사용하려면 이런 부분에 대한 이해가 확실히 필요하니 한번 제대로 알아보자. 1. 용어 정리 일단 시작 전에 용어 정리를 간단히 하고 넘어가도록 하자. 사실 이 혼란들은 신입, 초급 개발자 입장에서 용어를 올바른 쓰임새로 쓰지 않기 때문..

오늘은 CSS 얘기 할거다. 솔직히 HTML은 레이아웃 잡기만 하면 그만인거라 뭐 어려운거도 없고 설명할 것도 없고 귀찮을 것도 없는데, CSS는 어려운거, 설명할건 없는데 귀찮은게 좀 있다고 생각한다. 그래도 체계만 대충 잘 알면 할만 할테니 한번 시작해보자. 1. CSS란? 일단 우선적으로 CSS는 뭐하는데 쓰는 앨까? HTML로 만든 구조들을 원하는 자리에 배치하고 예쁘게 꾸며주는 역할을 한다. 우리가 HTML만 가지고 웹을 띄워보면 진짜 이게 뭔가 싶은 구시대적 디자인이 뚝딱하고 뜨는걸 볼 수 있는데, 사람 생각은 다 똑같은지 그 모양새가 혐오스러워 만든게 CSS라고 보인다. 그럼 이 녀석을 어떻게 쓰는지 알아보기 전에 사전에 알아둘게 있는데, 이 녀석의 이름의 의미다. 왜 이걸 알아야하냐면 이름..

뭐 React니 JS니 가장 주요하게 쓰는 애들한테 심취해서 막 글을 써제꼈는데, 생각해보니 이 얘기를 좀 자세하게 풀지를 않은 것 같아서 주워왔다. 기본 내용 정리가 잘 되어있어야하는데 말이다.. 앞서 뭐 다른 얘기할 때 HTML 얘기를 아주 스리슬쩍 끼워놨었는데 그건 진짜 겉 껍데기 중에 가장 바깥에 있는 수준이고 좀 디테일하게 안써둔다고 손해볼게 뭔가 싶어서 써본다. 나중에 또 쓸 CSS 까지 얹어서 얘기하자면 이 HTML/CSS 라는게 Front를 구성하는 가장 기본적인 요소 3인방 중에 하난데, 아무래도 퍼블리셔라는 직업이 또 따로 존재하다보니 신입개발자들은 뒷전으로 미뤄두는 경향이 없잖아 있다. 근데 둘다 꼭 먼저 공부하길 권하고 싶은게, JS 로 수십 줄 써서 개발할거 CSS 한두줄로 끝나는..

오늘 가볍게 끄적여볼 이야기는 git에 대한 이야긴데, 아마 개발자라면 모르는 사람이 없을 만큼 유명한 협업툴이고, 어떤 이들은 git을 통해 블로그를 운영하거나, 또 자신이 쓴 코드들을 저장해두는 저장소로 사용하기도 한다. 하지만 생각보다 이 git 의 개념이나 사용방법 같은 것들이 상당히 추상적이고, 머릿속에 붕붕 떠 다니는 느낌으로 막연하게 사용하는 사람들도 꽤나 되기 때문에, 이 git에 대한 정리를 하고 넘어가려고 한다. (Github은 나중에 기회가 되면 건드려보자.) 1. 협업의 개념 우리는 개발이라는 과정을 할 때 물론 혼자할 때도 있겠지만, 대부분의 사람들이 협업을 통해 하나의 프로그램을 만들어 나간다. 헌데 이 협업이라는게 상당히 골치가 아프다. 학원에서 git이라는 걸 알려주지 않았다..

REST 를 설명하려다보니 HTTP에 대한 설명이 필요한 것 같아서 정리해왔다. 블로그 제대로 쓰는 것도 쉽지 않구나.. 시작해보자.. 1. 프로토콜...? HTTP란 뭘까? HyperText Transfer Protocol의 줄임말이다. 후벼파보니 더 알 수 없는 말만 있다. 일단 프로토콜을 사전에서 찾아보면 통신규약이다. 더 길긴한데, 그냥 축약하자. 더 다른 의미 없다. 뭐 Transfer 나 Protocol 같은 경우는 일반적인 단어 + 앞에서 설명하였음. 으로 퉁칠 수 있는데 그럼 HyperText는 뭔가? 그냥 대충 말하면 완전멋진초월텍스트다. 기존의 인류 문명은 책이라는 문서양식를 가지고 있었다. 특정방향으로 방향성을 가지고 선이 이어지듯 연결되는 텍스트들의 집합 = 책(선형적인 텍스트) 인..

어제의 글에 이어서 REST API / RESTful API 에 대한 이야기를 해볼까 한다. 1. REST API? 2023.04.26 - [Arch] - [REST] REST REST API는 윗 글에서 설명한 REST 의 규칙을 지켜서 만든 API를 의미한다. 해당 규칙을 적용하면서 또 명확히 제시하는 설계 지침? 같은게 있는데 한번 보도록 하자. 1) URI는 동사보다는 명사를, 대문자보다는 소문자를 사용하여야 한다. 찾아본 예시들이 "동사보다는 명사" 이 부분에 잘 안맞는 것 같은데, "동사보다는 명사" 라는 말보단 특정한 가공 없는 본래의 단어 그대로를 쓰자는 말과 같다고 느껴진다. 예를 들면 run 과 같은 단어를 진행형, 동명사, 3인칭, 과거형 이런 가공 없이 run 그대로 쓴다는 느낌이 ..

일단 서두에 하고 싶은 얘기가 있다. REST API의 목적 상 나름 쉽게 설명하려고 애썼을 것 같긴한데.. 이해가 잘 안간다. 왜냐? 우리나라 사람들 특이 영어로 아무리 쉽게 써놔도 어렵게 번역한다는 것이니까.. 대학에서 전공서적으로 번역판, 원서 둘 다 써본 사람이라면 이해할 것이다. 오히려 원서의 용어들이 훨씬 잘 와닿을 때가 많다. REST 도 말이 어려운데다 줄여놔서 그렇지. 당장 개발할 때 필요한 수준의 개념을 정립하려면 그렇게 어렵지 않다고 본다. 1. REST란? 오늘도 사전적 정의 부터 먼저 가져와봤다. "REST는 Representational State Transfer의 약자로 자원(Resource)을 이름으로 구분하여 자원의 상태를 주고 받는 모든 것" 대부분 어딜 가도 이렇게 설명..

내가 경험한 프로젝트의 아키텍처들은 경력에 비해 상당히 다양하다. 우리 회사의 특성 상 정해진 솔루션이 있고 매번 똑같은 구조의 프로젝트만 경험할 것이라고 예상했으나 고객사에 기존에 개발되어있던 Legacy 프로젝트가 있다면 꼭 그렇지 않다는 사실을 알게 되었다. 내가 경험한 프로젝트 구조들은 다음과 같다. 1. 학원프로젝트 2. (React + Redux) Monolithic Arch.(MA)를 채용한 고객사의 Legacy 프로젝트 3. (React + Mobx) MSA 를 채용한 우리회사의 솔루션이 들어간 프로젝트 4. (React + React-Query) MSA(MonoRepo)를 채용한 우리 회사의 버전업 솔루션 프로젝트 이 중 오늘은 Monolithic Arch. 와 MSA간의 차이에 대해서 ..

1) 사건의 발단 회사 동료가 질문을 해왔다. 그 질문이 뭐였냐 하면, 현재 우리가 진행하는 프로젝트 상에서 테이블을 띄워주는 library로 AGgrid를 사용하고 있다. 근데 이 AG grid의 함수들을 사용하는 방법이 두가지다. 1번이 gridRef를 통해 DOM 자체를 참조하여 해당 Grid DOM의 API를 끌어다쓰는 방법이고 2번이 해당 Grid DOM 의 gridApi 자체를 State에 set해두고 그 State를 사용하는 방법이다. 여기서 동료가 모르곘다는 부분은 DOM 이 이해가 가지 않는다는 것이었다. 그래서 설명해준 그대로 블로그 글도 써두기로 했다. 2) DOM이란? 우리는 사실 DOM이라는 말은 진짜 많이 들어봤다. React에 대한 내용을 조금이라도 들어봤다면 Virtual D..