Next.js 배포

NCloud Platform

• 프로젝트 기간동안 사용할 수 있는 ncp 무료 크레딧이 있어서, 여러 설정이 용이하도록 직접 배포하였다.
• 이전에 몇 번 배포 경험이 있어서, 이번 기회에 CI / CD까지 직접해볼 수 있는 좋은 기회라는 생각이 들었다.

배포 과정

• 평소에도 배포할 때 github을 ssh key로 연결했기 때문에, CI / CD를 진행한다고 해도 큰 차이는 없었다.
• 인스턴스를 생성하고, ACG를 통해서 사용할 port를 열어준 뒤 인스턴스를 띄웠다.
• 이후에 nvm을 통해 node를 설치하고, ssh key를 통해 github을 연결하여 github에서 코드를 받아서 배포할 수 있었다.

BFF (Backend For Frontend)

• 이번 프로젝트에서 NGinx 서버가 별도로 있지만 클라이언트의 서버를 띄운 이유는 Next.js의 SSR을 위해서였다.
• Next.js에서의 SSR은 HTTP 요청이 들어왔을 때, 필요한 HTML을 서버에서 렌더링해서 응답해주는 방식인데 이를 위해서는 BFF가 필요하다.
• 이를 통해서 클라이언트 기기에 덜 의존적인 렌더링이 가능하며, 여러 보안적인 이점도 있다.

Next.js CI / CD를 위해 산넘고 물건너기

push 이벤트 감지 안됨

꿀잠 잘 기대에 가득찬 CI / CD

• 기대에 가득 차서 push를 했지만, 어림도 없지 push 이벤트는 동작하지 않았다.

이 문제는 잠시 뒤로 미룹시다.

• workflow dispatch 명령어를 yaml 파일에 추가하여 수동으로 먼저 동작했다.
• 수동으로 job 동작을 확인한 뒤, 여러가지 실험을 진행했다.

문제 해결

• 알고보니 이벤트가 발생하는 해당 브랜치에도 workflow 폴더와 yaml 파일이 있어야했다.
• 이를 통해 해결되었다.

github actions에서만 npm이 없다고 뜨는 에러

고난의 시작

• 수동으로 job 동작을 확인하는데, npm이 없다는 에러가 떴다.

원인 파악 - nvm 제거 후 nodejs 수동 설치

• 이전 트러블 때, github actions에서 nvm의 nodejs에는 접근을 할 수 없었다.
• 이를 위해 nvm의 nodejs를 삭제하고, 따로 nodejs를 직접 설치해야했다.
• 이를 통해 nodejs에 접근이 가능해지고, npm install이 정상적으로 동작하는 걸 확인하였다.

다시 찾아온 문제 - nvm 환경변수

• 갑자기 pm2가 동작하지 않았다.
• 확인해보니 클라우드 서버에서는 pm2가 npm global로 설정이 되어있었다.
• github actions에서 npm ls -g를 찍어보니 pm2가 없었다.
• 다시 조사해보니 nvm에서 설정해둔 $PATH 환경변수가 남아있었다.
• bashrc에서 $PATH 환경변수를 지우고 putty를 재실행해서 환경변수를 초기화하였다.

문제 해결

• 이후 nvm의 $PATH가 아닌 새로 설치한 nodejs의 $PATH가 되며 해결되었다.

Trie 자료구조로 자동완성 검색엔진 만들기

Problem

• 소그룹의 활성도를 위해 키워드를 등록하고자 할 때 비슷한 키워드의 중복 생성 방지하여 그룹의 인원이 분할되지 않도록 하는 작업이 필요하게 되었다.

Think

• 처음에는 정규 표현식을 통해서 검색어가 바뀔 때마다 모든 키워드를 탐색하고자 하였으나 성능적으로 비효율 적이라고 생각되어서 알고리즘의 변화가 필요했다.

Solution

• 검색 엔진에서 사용되는 알고리즘들을 조사, 비교하여 현재 프로젝트에 가장 적절한 알고리즘을 결정했다.

Process

• 정규 표현식과, 이진 탐색, 트라이 등의 방법을 고려하여 시간 복잡도를 분석하니 아래와 같은 결과가 나왔다.

Result

• 사전 생성 시간이 있고, 메모리를 많이 차지하는 단점이 있지만, 커뮤니티 접속 시 한번만 실행하면 되고, 탐색이 빈번하게 발생하는 검색 엔진 특성상 트라이가 가장 효율적이라고 결론을 내릴 수 있었다.
• 결과적으로 탐색 시간 복잡도를 O(M * N)에서 O(M)까지 감소시킬 수 있었다.(M: 문자열 길이, N: 단어의 개수)

👥 사람이라는 객체

🌐 어디까지 소프트웨어라고 할 수 있을까?

시와 코드, 변수명 짓기

• 같은 점 : 메세지를 추상화 시켜서 단어에 담는다.
• 다른 점 : 시는 의미를 각자가 다르게 느껴도 되지만, 변수명은 명확한 의미가 필요하다.

노하우가 생길 수 있는 모든 것은 소프트웨어 아닐까?

• 체계화해서 반복 사용할 수 있는 것들이 노하우가 되는데, 그렇다면 그것을 아키텍처로 생각한다면 노하우가 생길 수 있는 모든 것은 소프트웨어가 아닐까?

이름 짓기와 상수 Enum 활용

• 상담에는 이름 짓기라는 기법이 존재하는데, 내가 회피하고 있거나 구체화시키지 못하고 있는 대상에 이름을 지어서 그것을 스스로에게 분리해서 바라볼 수 있도록 한다. 이것도 상수 모듈을 분리해서 Enum을 사용하는 것 같지 않을까?
• 장점 : 식별이 편해진다. ⇒ 반복적으로 발생하는 삶의 문제에 대해 이름을 지으면, 비슷한 장점을 가질 수 있지 않을까?
• 단점 : 선언해야한다. ⇒ 삶의 문제에 이름을 지었을 때 추상화를 잘못한다면, 해당 문제가 아닌 문제들도 해당 변수명으로 합리화 할 수도 있겠다. (ex. 나는 MBTI가 ~라서 그래.)

소프트웨어는 문제 해결, 이 방법론을 삶에 적용시키면 개발도 더 빨리 늘지 않을까?

• 무언가를 통해 내 삶의 문제가 해결되면 빨리 배운다. 어른들이 말씀하시던, ‘필요하면 다 하게 되어있다.’라는 말씀이 이런 것 아니었을까-

🗣️ 프로그래밍 언어와 커뮤니케이션

여러가지 프로그래밍 언어

• 여러가지 프로그래밍 언어를 객체화해본다면 서로의 차이점을 통해 각 언어의 본질에 접근해볼 수 있지 않을까?
• 캠프동안 처음으로 JS를 접했었는데, 마구 튀어다니는 JS가 처음에는 적응이 어려웠지만 적응되니 너무 좋았다. 이제는 C언어가 사람이었다면 너무 깐깐해서 친해지기 힘들었을 것 같다. 😄

얄미운 사람, 얄미운 JS

• 사람과 JS만 암묵적인 타입변환을 하는 것 같다. 사람도 JS도 종종 야속하다.
• 반대로, 그렇기 때문에 사람간의 커뮤니케이션에 신뢰가 중요한 것처럼 JS 코드도 예측가능하게 써야겠다는 생각이 든다.

👤 사람을 소프트웨어로 접근한다면?

나를 소프트웨어로 본다면, 우리는 다들 버전업하면서 살고 있지는 않을까?

• 다들 메서드나 프로퍼티를 추가하면서 살고 있는 것 아닐까?
• 흑역사는 리팩토링하면서 새로운 나를 맞이하고, 이전에 가지고 있었던 생각들을 고쳐나가며 버전업하는 것은 아닐까? / 참고자료 https://innovative-phosphorus-e4b.notion.site/aebc9668a1f74539a477ea5f4397bf5b

인간도 머신러닝과 비슷한 것 같다.

• 우리도 많은 경험과 사례, 표본을 통해서 성장해야 좋은 방향으로 성장 할 수 있지 않을까?

여러 메서드가 의존하고 있는 프로퍼티에 큰 수정이 발생하면 여러 문제가 생긴다. 사람도 이런 경우가 있을까?

• 사람은 누구나 ‘인간’이라는 객체에 의해 여러 메소드와 프로퍼티를 기본적으로 상속받는다.
• 객체에서 this.property를 이용해서 메서드를 작성한 경우, 해당 프로퍼티의 내용이나 자료형등이 바뀌게 되면 해당 프로퍼티에 의존하는 여러 메서드가 영향을 받게되는데 사람이 이런 경우는 없을까?
• 키가 확 자라나면, 갑자기 변한 내 삶의 환경들에 적응하기 어려웠다. 큰 변화가 생기면, 삶에서도 리팩토링이 필요했던 것 같다.
• 그럼 삶에서 했던 리팩토링을 이용해서 코드 리팩토링을 쉽게할 수 있는 방법은 없을까?

사람만 스스로 버그 수정과 리팩토링을 한다.

• 병원이나 물리치료를 받는 것이 이슈를 잡아서 리팩토링 하는 것 같다.
• 그런데 코드와 다른 점이 있다면, 인간만 직접 리팩토링을 하는 것 같다.
• 또한 이런 리팩토링의 접근도 다 달랐다. 자신의 문제를 해결하기 위해서 누군가는 공부를 하고, 누군가는 운동을 하고, 누군가는 또 다른 것들을 했다.
• 사람을 개인의 상위 객체로 표현한다면, 우리는 어떤 메서드나 프로퍼티를 오버라이딩 하면서 살고 있는건 아닐까?

💊 사람을 객체화해본다면?

사람을 객체로 접근

• 개인이 인간이라는 상위클래스에게서 상속 받는 것이 무엇이 있을까?
• 인간이라는 클래스가 동물이라는 상위클래스에게서 상속 받은 것이 아니라, 인간이라는 클래스에서 작성된 메서드가 무엇이 있을까? 이게 인간과 동물을 나눠줄 수 있지 않을까?
• 그럼 개인이 인간이라는 클래스에게서 상속 받은 것과 아닌 것은 무엇이 있을까?
• 이 고민이 고민을 위한 고민이 아니라 실제 삶에 적용할 수 있으려면 어떤 이야기를 나눠보아야할까?

아까 나왔던, 사람과 의존성으로 돌아가봅시다.

• 상위 클래스인 ‘인간’에서 새로운 메서드와 프로퍼티를 가지는 것이 개성이 만들어지는 과정 아닐까?
• 개인이 상위 클래스에서 받은 ‘상식’, ‘사회가 가지고 있는 통념’ 같은 것들에 스스로가 강하게 결합되어 있으면 개성을 가지거나 확장하기 어려워지는 것 같다.

생각 정리와 매몰

• 사회 속 상징등에 갇히게 되는 경우가 많았다. 아는 만큼 보는 것도 같은 맥락인 것 같다.
• 무언가가 인상적이었다면 그것에 끼어맞추며 생각하게 되는 경우도 있는 것 같다.
• 종종 내가 정리하고 정의한 것에 매몰되어서 합리화하는 경우도 생겼다.

내가 안다고 생각하지만 사실 상속받은 것

• 종종 개인은 상위클래스에게서 무얼 받았는지 잊고, 내가 아는 것이라고 생각하는 경우도 있는 것 같다.
• 사람은 정보은닉이 너무 잘되어 있는 것 같다. 문제는 this에서도 그 정보를 모른다는 점이다.

사람 클래스의 의존성

• 사람의 의존은 다른 사람들과 가장 크게 연관되어 있는 것 같다.
• 어디에 크게 의존하고 있는지 인지하는게 중요한 것 같다. 이것을 인지할 수 있는게, 말해보자면 의존성 주입의 가능 아닐까?
• 그럼 사람이 의존하는 관계에는 어떤게 있을까?
• 내가 소중히 생각하는 많은 것에 결합도가 높아지는 것 같다. 사람 뿐만 아니라 책임감, 사랑, 우정, 애착이 가는것까지 나라는 사람이 의존해서 결합도가 높아진 것 같다.
• 고3 때 친구들과 하는게 많았는데, 대학에 진학하며 그 분리를 겪기가 힘들었다. OOP에서 응집도를 높여야하는 것처럼, 나라는 사람도 의존성을 낮추고 스스로로서 응집도를 높이는 것이 필요하지는 않은가 생각이 든다.
• 누군가라는 외부에 의존하게 되면 나라는 객체를 수정하는게 쉽지 않아지는 것 같다. 의존성 주입이 중요한 것 같다.

❤️ 소감

• 다들 코딩에 미쳐있다. 광기가 눈에 보인다.
• 다들 광기가 있었다. 다른데에서는 하지 못하는 말들을 할 수 있어서 좋았다.
• 언어유희가 많아서 재미있었고, 다들 비유를 잘했다. 앞으로 많이 배우고 싶다.
• 처음에는 긴가민가 했는데, 재미있었다. ‘어디서 나라는 사람이 추상화가 잘되어있어.’ 같은 말을 할까
• 재미있었습니다. (이후 관계와 의존성 주제 발제)
• 일상에서 얻을 수 있는 영감과, 응집도 있는 집단 속 광기에서 얻을 수 있는 영감이 다르다고 생각한다. 광기 속 많은 영감을 얻을 수 있어서 너무 좋았다.

[09장. 타입 변환과 단축 평가]

</br>

✏️ 자바스크립트의 알아서 잘하는 타입변환

  근데 알아서 하는건 종종 오해를 낳는다. 그러니 자바스크립트가 어떤 때에 알아서 잘하는지 하는지 아는게 필요하다.

자바스크립트에는 두 가지의 타입 변환이 있다.

1. 명시적 타입 변환 (타입 캐스팅)
2. 암묵적 타입 변환 (타입 강제 변환)

명시적 타입변환은 toString() 메서드와 같이, 타입을 변환하는 것을 명시적으로 명령하는 것이다.

반대로 암묵적 타입 변환은, 명시적으로 명령하지 않지만 자바스크립트 엔진이 맥락을 평가하고 타입을 변환하는 것을 말한다.

예를 들어, ‘1’ + 1;이라는 문장은 ‘1’이 암묵적으로 숫자형으로 변환되어서 2라고 평가되어진다.

각각의 타입변환에는 장단점이 존재한다.

앞의 내용에서 언급했듯이 암묵적이고, 맥락에 의한 처리는 종종 오해를 발생시킨다. 다만, 가독성이 좋아질 수 있다.

암묵적 타입변환을 효과적으로 사용하기 위해서, 각각의 타입에서 암묵적 타입변환이 어떻게 발생하는지 아는 것이 도움된다.

</br>

✏️ 반복되는건 짧게 쓸 수 있도록 합의합시다.

  타입이나 논리를 확인 후 그에 따라 명령을 실행하는 문에 매번 같은 조건문에서 값을 비교하는 것은 효율적이지 못할 것이다. 이를 위해서 자바스크립트는 미리 합의를 통해 몇가지 단축평가 문법을 제안하여 개발자로 하여금 코드를 작성하기 쉽게 돕는다.

[13장. 스코프]

</br>

✏️ 말이 쓰일 범위를 모르면 오해가 생깁니다.

  pr이라는 단어를 듣는다면 뭐가 떠오를까?

1. 마케팅에서는 PR을 Public Relations로 말하며, 대중과의 긍정적인 관계를 형성하기 위해 하는 활동을 말한다.
2. 헬스에서는 PR을 Personal Record라고해서 개인 기록을 말한다.
3. 개발에서는 PR을 Pull Request의 의미로 사용하며, 깃허브에서 내 작업물이 브랜치로의 병합될 수 있도록 요청하는 것을 말한다.

사람은 편의를 위해 축약어나 단어를 사용하고, 범위가 넓어지게 되면 동음이의어가 생기게 된다.

코드도 똑같다. 코드에서도 변수의 사용범위가 뒤죽박죽이고 변수를 읽는 순서가 다르다면 오해가 생길 수 있을 것이다.

</br>

✏️ 이를 위해 스코프(Scope)가 있어요.

  이러한 오해를 막기위해서 스코프가 존재한다.

변수를 선언하면 해당 변수가 사용될 수 있는 스코프 내의 객체에 식별자로 등록되게 되며, 변수를 호출했을 때 호출한 스코프에 해당 변수가 없다면 하나씩 상위 스코프를 탐색하게 된다.

이러한 이유로 사용상의 편의를 위해 무턱대로 전역변수에 변수를 선언하는 것은 좋지 않다. 이는 14장. 전역 변수의 문제점에서 다뤄진다.