아장아장거리면서 주책부리는 블로그

[잡담] 뜸한 블로그, 그리고 취업 1달차의 회고

장아장 — Sun, 28 Jul 2024 19:36:35 +0900

어이 장프로 식사는 잡쉈고?

요번 수요일에 취업한지 딱 한달이 되었다.

취업시장이 꽁꽁 얼어붙어, 나는 어떻게 해야하는가를 고민했지만,

다행이도 이런 나도(?) 개발로 입에 풀칠할 능력이 있다고

인정받은 것 같다 기분이 좋기도 했다.

??? : 야 내 동기는 취업했다고 일본 여행가고 하던데?

나는 그런거 없었다.

종강하고 딱 일주일정도 여유가 있었다.

그 기간동안 다른 할 일들을 준비해야 했다.

이제 월급이라는 고정수입이 발생한다.

하지만 월급만으로 우리가 원하는 것을 먹고, 원하는 옷을 입고, 원하는 집에 살기에는

요즘 시장이 확실히 좋지 않다

(이래서 다들 대기업가려고 하는건가)

이런 상황에서 살아남기 위해 주식, 적금, 청약등을 알아보기 시작했다.

청년 도약 뭐시기로 많던데, 월수입이 고정적이지 않아 신청이 불가능했다..

슈카월드 유튜브를 보면서 어떤 방식으로 돈을 모아야 할지,

그리고 어떻게 투자라는것이 이루어지는지 공부했다.

그는 한국인이 아닙니다. 그는 신입니다.

외의 시간에는 알고리즘을 풀고, 운동을 죽어라 했다.

취업을 하면 한동안 운동을 하기 힘들거라는 판단이 있었다.

하지만, 좋은 개발자이면서 건실한 청년으로(?!) 살고싶다는 마음이 있기에,

건강은 항상 챙기고 싶었고, 적응하는 동안 운동을 못갈 것이라고 생각했다.

6000코인으로 반팔사고, 9000코인으로 후드티를 사야한다. 갈길이 멀다

이렇게 운동, 제태크 공부, 알고리즘 공부를 했다.

그 외의 여유는 따로 가져보진 않았다.

괜히 나태해졌다가, 인간 자체가 느슨해질 것 같았다.

한달간의 생활, 그정도로 긴장감 있진 않았다..?

내 생각만큼 회사라는 곳은 엄청나게 무서운 곳은 아니었다.

객기넘치는 신입의 패기를 짓누르기보단,

해당 방식이 어떤 방향성을 가지고 있는지,

그리고 어떤 위험과 단점이 있을지 제대로 알려주는,

말 그대로 개인의 성장에 열려있다는 느낌을 받았다.

확실히 개발 이전에 내가 가져본 직업(원티드에서 이력 조회를 했을 때 나오는 것들)이라고는

산림조합에서 나무장사하고, 요식업밖에 없다.

다치기 쉬운 업종이다보니 군기가 바짝 들었었는데,

이번에 취업을 해보니 이젠 몸쓰는 직업이 아닌

확실한 개발자라는 것을 느꼈다.

그리고, 운동을 못할 것이라는 생각과 다르게 인간은 적응을 아주 잘한다(...)

매일 5시 반에 일어나 운동을 가는 것도 어느정도 하다보니 익숙해졌다.
(대신 운동용 부스터를 입에 달고살게 되었다...)

스스로 평가하는 신입으로써의 나

이 부분에서는 확실히 잘한 점과 못한 점이 있다는 생각이 있다.

잘한 점

덤벼들었다.
1. 슈카월드를 보면서 와닿은 말이 있었다.
  "트레이더는 안전하게 주식을 투자하고, 잃지 않기 위해 뽑는게 아니다. 우리는 잃더라도 덤벼들 수 있는 병사가 필요한 것이다"
  라는 의미의 말이었다.
  확실히 개발을 하면서, 공부하고 하나씩 찾아가는 개발자라기보단, 바로 투입되어 생각하고 구현할 개발자가 필요한게 회사다.
  토이 프로젝트처럼 '이게 무슨 원리일까?'나 '이런 기술이 있던데 가져다 써볼까?'를 하면서 머리속에서 시간을 쓰는 것은 회사에서 볼 때 다 비용이다.
  비용을 아끼기 위한 개발자가 되어야 했다.
2. 비용을 아끼는 개발자란 무엇일까?
  1. 빠르게 요구사항을 수행하는 개발 : 주어진 기간안에 일을 제대로 끝내야 했다.
  2. 서버의 비용을 줄이는 개발 : 최적화를 통해 시간 혹은 메모리의 사용을 줄일 수 있는 개발을 해야 했다.
3. 새로운 기술이나, 헛도는 시간을 유발하는 것이 아닌, 현재 상황에서 최적의 결과를 빠르게 생각해내 구현해낼 줄 알아야 했다.
  이걸 위해서 계속해서 덤벼든 것 같다.
공부에 시간을 계속 썼다.
1. 위에서 비용비용거려놓고(~~삐용삐용!!!!~~) 왜 여기에선 공부를 했다고 할까?
  출퇴근 시간에는 다른 공부를 하지만 회사에서는 시간이 빌 때 마다 회사의 애플리케이션의 구조와 플로우를 공부했다.
  이런 부분들을 도메인 지식이라고도 한다고 들었다.
  도메인을 계속해서 이해하고, 그 속에서 어떻게 구현이 되어있는지를 계속해서 학습했다.
2. 이를 통해서 더 잘 덤벼들고, 덤벼들 구간들을 더 잘 찾아낼 수 있었다.
  기존의 컨벤션과 개발 방향성에 맞게 덤벼들 수 있고, 그 속에서 비용이 과도하게 소비되거나 방향이 엇나간 구간들을 찾아 덤벼들 수 있었다고 생각한다.
모르는건 모르는거다.
1. 주변 다른 사람들과 항상 이야기할 때 중요하다고 느낀 것이다.
  들어본 것도 모르는거고, 기억이 가물가물해도 모르는 거고, 키보드에서 움직이는 손이 낯선 것도 모르는거다.
  그런 것들은 바로바로 피드백을 받거나, 물어보는 것이 맞다고 생각했다.
2. 확실히 그렇게 했을 때, 괜히 아는 척으로 구현한 로직들보단 나을 것이라고 생각한다.

이정도가 내가 스스로 생각한 잘한점이다.

하지만 스스로 안좋다고 생각한 점들도 존재했다.

아쉬운 점

어쩌면 난 너무 오픈되어있을지도 모른다.
1. 친구와 동료의 차이점이 무엇일까? 라는 생각이 문득 지나갔다.
  친구들과는 개인적인 이야기, 일적인 이야기, 학습의 이야기를 모두 나눌 수 있다.
  하지만 직장에서 만나는 사람들이 모두 친구일까? 그건 또 아닐 수 있다고 생각한다.
  '개발자'라는 직함으로 나는 이 회사를 다니는 거다.
  그렇다면, 다른 사람들을 '친구'가 아닌 '동료', 혹은 '개발자'로 보아야 하지 않을까 하는 생각이 들었다.
  내가 헛소리로 사람들과 소통한다는 것은, 그 사람들의 생산성을 떨어트리는 일이 아닌가라는 후회가 몰려왔다.
2. 직급이 없이 오픈되어있을지라도, '리더'와 '인사담당자'는 존재한다.
  그런 사람들이 보았을 때, 이런 모습은 너무 느슨한 사람이라는 인상을 심어줄 수 있겠다는 생각이 들었다.
한번 더 생각해야 했을까
1. 매주 회사에서 백엔드 개발자들끼리 모여 정기 세션을 가진다.
  해당 시간동안 개발적으로 어떻게 하면 좋을지,
  그리고 어떤 방향으로 함께 프로젝트를 이끌어갈지 소통을 한다.
  해당 시간동안 각자 생각하는 안건들을 가져온다.
  어떻게 하면 더 생산성이 좋을지, 더 일관적인 프로젝트를 만들지, 어떻게 기술부채를 해결할지 이야기한다.
2. 매번 세션에 들어가기 전에, 내가 생각하는 소통해보고 싶은 부분들을 준비하고,
  해당 부분들에 대한 내 개인적인 생각과 근거들을 가져간다.
  해당 부분들에 대한 레퍼런스나 장점들도 생각해간다.
  하지만, 내가 생각해내지 못한 단점들이 항상 보인다.
  이런 부분들을 볼 때 마다, 나의 부족이 다른 사람들의 시간을 뺏는건 아닐지 걱정이 크다.
  (INFP라고 이런거 밖으로 이야기 못하고 속에만 쌓아둔다. 안좋은건 알지만 입이 안떨어지는 편인가보다)
3. 이런 부분에서 근래에 학습에 대한 강박이 더 커지는 느낌을 받는다.

앞으로는 어때야 할까?

"진행시켜!!"

이 말밖에 떠오르진 않는다.

대기업이건 스타트업이건

시니어건 주니어건

프론트엔드건 백엔드건

결국 개발자가 하는 일은 항상 같다는 생각이 들었다.

개발하는 거지 뭐겠어요?!?!

회사에서 거창한 뭔가를 생각하기보단,

똑같은 개발을 해나가는 것이다.

물론 그 속에 더 큰 책임감과 더 복잡한 요구사항이 존재하겠지만

결국 개발이라는 본질은 변하질 않는 것 같다.

계속 개발합시다.

이제 토이프로젝트도 개인적으로 하나씩 만들어야 겠다.

기존에는 취업에 이득이 될만한, 더 많은 기술과 더 복잡한 나만의 요구사항을 찾았었다면,

앞으로는 내가 필요한 무언가를 만들어봐야겠다.

그래서 프론트엔드 공부, AI 관련 공부도 시작해보려고 한다.

개인적으로 운동관련 서비스와 제태크 관련 서비스가 필요하다.

나의 운동을 기록하고, 타이머를 측정해주며, 재생하던 음악을 끊지 않으면서

녹화를 해줄 앱이 필요했다.

또한, 내가 사려고 하는 주식들을 크롤링해서

현재의 가격이 어떤지, 그리고 앞으로는 어떨지 경우의 수를 그려주는 무언가가 필요하다.

이걸 하나하나 찾아보면서, 모의투자로 가능성을 계산하기에는

나에게 주어진 시간이 한정적이다.

회사의 일 외적으로는 내가 필요한 것들을 만들어가는 DIY 개발을 해야겠다.

(심지어 회사에서 쓸 키보드와, 집에 둘 미니PC도 자체제작이나 조립식으로 만들기 시작했다)

매일 캐드와 목재 그라인더를 쓰면서 내가 하는 생각이다.

기존의 블로그 포스팅을 보면 알고리즘, 자바, nestjs에 집중되어있었는데,

앞으로는 포스팅할 내용들이 좀 더 복작복작해질 것 같다.

벌써 재밌다

그럼...twenty thousand...

[LeetCode] 1442. Count Triplets That Can Form Two Arrays of Equal XOR

장아장 — Thu, 30 May 2024 15:40:20 +0900

https://leetcode.com/problems/count-triplets-that-can-form-two-arrays-of-equal-xor/description/?envType=daily-question&envId=2024-05-30

문제 출처

비트연산자, 그 중에서도 XOR의 특성을 알면 쉽게 풀 수 있는 문제였다.

요즘 리트코드 데일리 문제를 하나씩 푸는 재미에 꽂혔다.

작년 이맘 때 즈음엔 비트연산자 문제가 나오면 스트레스를 받았는데,

요즘엔 오히려 비트연산자가 더 재미있다는 느낌을 받았다.

이 문제를 이해한 바로는 아래와 같다.

전체 배열에서 시작 인덱스 i, 끝 인덱스 j를 정한다.
그리고 그 끝 인덱스의 다음인 j+1에서, 또다른 끝 인덱스 k를 정한다.
이 때 i부터 j까지 XOR한 값과 j+1부터 k까지 XOR한 값이 같을 경우 그 경우를 센다.
그렇게 센 모든 경우의 수를 반환한다.

이걸 풀기 위한 접근은 XOR의 특성을 가지고 설명해야 한다.

XOR를 이용한 아이디어 구상하기

XOR 연산은 두 비트가 다르면 1, 같으면 0을 반환한다.

즉, 아래와 같은 기본 식이 성립된다.

x ^ x = 0, x ^ 0 = x

그렇다면 i~j까지를 a라고, j+1부터 k까지를 b라고 한다면, a ^ b는 어떻게 될까?

i~(j-1) = a, j~k = b일 때, a ^ b = 0

이러한 식이 성립한다.

즉, 우리가 세어야 할 경우의 수는 다음과 같다.

i^(i+1)^...^k = 0인 i와 k를 구하고 그 속에서 j

여기까지 x ^ x = 0이라는 식 하나만을 가지고 만들 수 있는 아이디어였다.

이제 x ^ 0 = x를 같이 이용해 아이디어를 계속 해나갈 것이다.

i~k를 XOR한 값은 아까 말했듯이 0이어야 한다. from 부터 to 까지 XOR한 값을 XOR(from, to)라고 하겠다.

이전의 x ^ 0 = x라는 식과, x ^ x = 0이라는 두 식을 이용할 것이다.

XOR(from, to)  = 0

이런 식에서 양쪽에 from을 XOR해주자.

XOR(from, to) ^ from  = 0 ^ from = from

여기에서 왼 쪽에는 이미 from이 XOR연산으로 추가되어있다. 그렇기에 x ^ x = 0으로 소거된다.

그렇게 식은 다음과 같이 바뀐다.

XOR(from + 1 , to) = from

그런데, 아무것도 없는 상태에서 from인덱스의 값만을 XOR해주어도 from이 나온다.

그 다음 경우를 생각해볼까?

XOR(from + 1 , to) ^ (from+1) = from ^ (from+1)
XOR(from + 2, to) = XOR(from, from+1)

이렇게 계산할 수 있다. 이전의 소거와 추가를 생각하면 된다.

그렇기에 도달할 수 있는 결론이 생긴다.

j는 셀 필요 없다. XOR(i, j)에서 j의 범위만 구해주면 된다.

위의 조건에서 보면 i < j <= k라고 되어있다.

즉, i와 k의 범위를 안다면, k - i를 해주면 그게 해당 범위 내에 존재하는 Triplets이 된다.

코드로 만들기(JAVA)

i의 범위는 조건을 보았을 때, arr.length-1로 잡아주면 된다.

왜냐하면 조건상 k도 arr.length보다 작아야 하는데, i < k기 때문이다.

k는 i+1부터 arr.length보다 작은 동안 반복시켜주면 된다. 그 동안 하나씩 XOR해주면 된다.

i부터 하나씩 XOR할 때, XOR한 값이 0이면 그 때 마다 k - i를 구해 누적해주면 된다.

public int countTriplets(int[] arr) {
    int count = 0;
    for(int from = 0; from < arr.length-1; from++) {
        int xorValue = arr[from];
        for(int to = from+1; to < arr.length; to++) {
            xorValue ^= arr[to];
            if(xorValue == 0) {
                count += to - from;
            }
        }
    }
    return count;
}

그렇게 이런 답을 만들었다.

그럼...twenty thousand...

[냉메추] 이제 언어가 늘어갑니다!!! JS도 씁니다!!

장아장 — Mon, 20 May 2024 20:24:02 +0900

ts로 툴을 만들어볼까 했지만 어차피 컴파일 및 인터프리팅 하느니 인터프리팅만 하는게 나을 것 같아서 js로 툴을 만들었다.

Kotlin/Spring으로 WAS(Web Application Server)를 만들었다.

그런데, 우리 서비스는 기능들을 만든다고 바로 사용할 수 있는 서비스가 아니다.

많은 데이터가 필요하다.

데이터를 어떻게 구할 것인가?

냉메추에서 필요한 데이터가 무엇일까?

일단 레시피를 보여줄 수 있어야 하며, 레시피에 대한 각 재료들의 데이터도 있어야 한다.

이걸 어떻게 해결할지 방안을 모색해야한다.

이런 데이터가 존재하는 것을 보았다.

여기에서 데이터를 전처리해서 재료들을 빼내고, 데이터를 가져오는 것을 1차적으로 생각했다.

그런데 여러 이슈들이 동시적으로 발생했다.

우리 서비스는 각 음식 사진에 대한 썸네일이 필요하다.
우리 서비스는 각 레시피에 대한 재료 데이터를 가져와 ingredients테이블에 넣어둘 것이다.
이걸 이용해 레시피는 각 재료의 문자열이 아닌, 비트연산자와 같은 문자열을 가져야 한다.

이걸 모두 해소하면서 csv파일의 데이터를 전처리해 저장하는 것에 이슈가 있었다.

일단 재료들이 제 1정규형의 구조도 가지지 못한, 속성값을 문자열로 둔 ','로 연결된 재료들의 문자열 컬럼이 존재했던 것이다.

이 문자열들을 전부 전처리해 저장하자니 경우의 수가 너무 많았다.

그래서 웹 크롤링을 이용해보기로 했다.

생각해보기

크롤링을 해서 가져올 데이터가 무엇인지, 어디에 있는지를 알아야 한다.

그래서 만개의 레시피의 화면을 개발자도구로 띄워보았다.

우리에게 필요한 것은 이렇게 두 가지였다.

실제 레시피 세부사항은 해당 url를 그대로 가지고 있다가 보내주는 식으로 해서,

실제 레시피는 만개의 레시피를 보게 할 계획 이었다.

그러면 이 url은 어떻게 볼까?

여기에서 앞에 있는 RCP_SNO의 값을 뒤에 붙여서

`https://m.10000recipe.com/recipe/${RCP_SNO}`

이런식으로 사용해주면 모든 url을 정규화시킬 수 있다.

해당 url에서 위의 컴포넌트들을 뽑아내주었다.

나는 axios, cheerio를 가져와 사용했다.

어케생겼누?

이런식으로 데이터가 들어오는 것을 볼 수 있다.

이걸 크롤링해서 데이터에 넣어주는 방식으로 진행했다.

근데 아까 말했듯이 비트연산으로 처리해야했다.

그러기 위해서 가져온 재료들을 모두 저장해주어야 하는데, 이 때 내가 구상한 로직은 아래와 같다.

Map을 이용해서 각 재료의 이름과 이름이 작성된 횟수를 센다.
이름들을 횟수순서로 정렬한 배열을 만든다.
배열의 인덱스 순서로 기본키를 가지게 저장한다.

를 처리해야했다.

addIngredients(ingredientIndex) { // ingredientIndex <- Map을 Object로 가져왔다. 속성명을 재료명으로, 값을 인덱스로 담았다. 
    const names = Object.keys(ingredientIndex);
    names.sort((a, b) => ingredientIndex[a] - ingredientIndex[b]);
    const data = [];
    names.forEach((name) => data.push([name, ingredientIndex[name]]));
    const batchSize = 1000; // 일괄 단위의 크기 설정
    this.connection.query("DELETE FROM ingredient", () => {});

    // 데이터를 일괄 단위로 분할하여 처리
    for (let i = 0; i < data.length; i += batchSize) {
      const batchData = data.slice(i, i + batchSize);
      const query = "INSERT INTO ingredient (name, id) VALUES ?";
      this.connection.query(query, [batchData], (err, result) => {
        if (err) {
          console.log(err);
        }
        console.log(result);
      });
    }
  }

이런식으로 데이터를 저장하는 로직을 만들어주었다.

레시피는 아까 말했듯이 각 재료의 값을 비트로 가지게 했다.

이렇게 레시피 데이터도 성공적으로 저장했다.

그러면 이제 끝일까?

아니다.

실제로 웹 크롤링 툴을 만드시는 많은 분들을 보면 파이썬으로 만드신 경우가 많았다.

사실 파이썬을 제대로 쓸 줄 모르고 만드는 것 보단,

제대로 만들 줄 아는 js를 쓰는 것이 더 효율적이라고 판단했기에 js로 크롤링 툴을 만든 것이다.

하지만, 이제는 진짜로 파이썬도 써야한다.

이전의 인트로 때에도 이야기했지만, 우리 졸업 프로젝트 담당 교수님은 ML과 빅데이터 관련 연구를 많이 하신 분이다.

이전에 MemberRecipe라는 객체로 조회한 회원의 성별, 나이를 기준으로 데이터를 저장하게 해두었다.

이걸 더 손봐서 어떤 재료들인지 확인하게 하고

이런 것들을 토대로 데이터의 군집화에 대해 학습하고

적용해야 한다.

아직 갈 길이 멀다.

그래도 해야지 개발잔데

그럼...twenty thousand...

[잡담] 꽁꽁 얼어붙은 취업시장 위로 이장희가 걸어다닙니다.

장아장 — Mon, 20 May 2024 19:53:40 +0900

이거보세요오오옹!

부스트캠프가 끝난지도 5개월이 다되어간다.

근래들어 생각도 많아지고, 바빠지기도 해서 포스팅을 자주 못했었는데,

밀린 일상에 대한 일기처럼 써두어야겠다.

(이 남자가 리프레싱 하는 방법)

취업시장이 꽁꽁 얼었다...나도 행선지가 얼어붙은 취업시장 위다...ㅠ

취업을 위해서 이곳 저곳 이력서를 쓰기 시작했다.

다른사람들의 취준 기록들을 보면 내가 쓸 자격이 있으면, 쓸 수 있다면 다 써보라고 했지만

내 성격은 그러질 못해서인지

기업에 대해서 찾아보고 실제 서비스를 써보고, 기업 관련 뉴스나 분위기들도 다 찾아보면서 이력서를 넣었다.

내가 이력서를 넣는 기준은 크게 두 가지였다.

이 회사의 서비스를 써보았을 때 좋았는가
이 회사의 분위기가 내가 일하고 싶어하던 곳인가

이렇게 두 가지만 보았다.

실제로 사용해보았을 때 확실히 좋았고, 그 속에서 내가 해낼 수 있는 무언가가 있겠다 싶은 기업들을 찾았고

그 기업의 분위기가 어떤지, 그리고 나는 그것을 따라갈 자신이 있는지 스스로 생각해보고 이력서를 넣었다.

그러다보니, 이력서의 마감일자 직전즈음에 하나씩 서류를 제출한 것 같다.

얼른 취업해서 부모님께 도움을 받는 것에서 벗어나

스스로 자립을 하고싶다는 욕구가 제일 크지만

그렇게 너무 기대하고 사니까

하나하나 떨어졌다는 답변이 오면 세상이 침울해지는 기분을 받았다.

그래서 취업시장 말고 내 머리속을 얼려야 한다는 생각이 들었다(?)

머리 얼리기 1. 말 그대로 머리를 얼린다!

그래서 생각한 첫 번째 방법은 말 그대로 머리가 어는 행위를 더 자주하게 했다.

'워라밸'이라는 단어를 내 생각과 머리에 대입했을 때,

머리에게 '워크'란 개발일 수도, 취업에 대한 고민과 생각일 수도 있다는 생각이 들었다.

이걸 멈추기 위해서 운동을 더 열심히했다(?)

원래도 꾸준하게 하려고 했던 것이지만, 더 꾸준하게 했다.

매일 일어나서 물 두컵을 먹고 바로 헬스장으로 갔다. 아침 6시 30분즘인거 같다.

확실히 워크타임(10~19시)동안 개발이나 공부를 할 때

다른 것에 매몰되지 않고 온전히 집중할 수 있었다.

취업을 한다해도 아마 꾸준하게 하지 않을까 싶다.

주변에서 다른 개발자분들은 운동할 시간이 없다고도 이야기하시는데

오히려 다른 휴식을 운동에 할애할 때 머리가 효율이라는 것을 뽑는 기분이었다.

머리 얼리기 2. 집중을 분산⭐️

특히 불합격 통지가 오는 날에는 계속 그 생각에 매몰되지 않기 위해 다른 것에 더 집중하려 했었다.

그렇지만, 그러지 못한 경우가 대부분이다.

집중 안된다. 오히려 그 생각만 더 난다.

그래서 불합격에 대한 회고가 아닌, 걱정과 근심을 이겨내기 위해서 더 분주한 환경에 있거나 한번에 여러 할 일을 진행시켰다.

면접에서 떨어졌을 땐 해당 면접에서 어떤 방안들이 있었을지 학교 앞에서 커피챗만 거의 3시간을 한 것 같다.

그 외에도 다른 이야기도 하면서, 학교 졸업 프로젝트는 어떻게 할지 이야기하면서

시간을 소비할 때, 손해는 안보지만 불합격 생각은 안나고 내 혼을 쏙 뺐다.

그 이후에도 서류 자체가 불합격이라는 통보를 받은 날이었다.

집에서 있으니, 집 밖에서 일도 못하는 내가 너무 처참하다는 생각이 들어서

짐싸서 밖에 나갔다. (본인은 카페에서 코딩 잘 안한다)

밖에서 크롤링 툴을 만들면서 입으로는 여자친구의 남사친의 건축 사무소 취준 관련 썰들을 들었다.

(개발 이야기 그 다음으로 건축 이야기를 주변에서 많이 듣는 것 같다)

이 글을 쓰는 지금도 웹 크롤링 및 DB에 저장하기 위한 데이터 파싱을 돌려두고 포스트를 쓰고있다.

그래서 편안함에 이르렀는가?

사실 그렇다고 편안하진 않다.

아직도 이런 불안한 상황에 시달리면서

욕도 나오고 화도 나온다.

근데, 욕하고 화낸다고 내가 갑자기 뽑힐리는 없고

생각이 많아봐야 힘든건 나다.

애초에 지금 시즌에 취업이 힘들다는 것도 금리때문에

기업들도 힘드니까 우리도 힘든거니까...

그냥 버티는게 답인 것 같다.

학교에서 취업 관련 교양을 들은 적이 있다.

그 때 교수님께서 해주신 말씀이

채용시장은 맨날 힘들대요

생각해보면 IMF때도 힘들었어요

매 시기마다 사회 초년생들은

각자 나름의 이유로 힘들다고 해요

IMF 이후에 취업 호황이었다고 하지만

그때도 그때 나름으로 힘들고

여러분도 여러분 나름으로 힘듭니다.

그냥 누가 아파도 덤벼드냐의 차이에요.

라고 하셨다

크으...쌈뽕하다 교수님!!!

나도 더 버티면서

더 열심히 갈고 닦아봐야겠다.

그래도 글로 한번 정리하니 그래도 머리가 좀 개운해진다.

제발 다음 개발생각은 취업 성공 후가 되길 빌면서...

그럼...twent thousand...

[냉메추] 서버가 터진 건에 관하여...(자원관리를 잘하자)

장아장 — Wed, 1 May 2024 18:21:17 +0900

자원 관리...자원 고나리...자원 고라니...ㅋㅋㅋㅋㅋㅋㅋㅋ

사건의 발단

서버가 중간에 죽는 문제가 있었다.

전체적으로 메모리 누수와

동작중인 3개의 컨테이너간의 메모리 할당량을 체크해봤지만 아무런 문제가 없었다.

기본적으로 스왑 메모리를 많이 달아도

너무 많은 컨테이너를 무료 인스턴스에서 돌리려고 한 것이고,

스왑 메모리 자체가 성능적이 저하를 일으킬 것이 문제였다.

(심지어 HDD로 이루어진 스왑 메모리이기 때문에 더 느릴 것으로 추산했다. 자세한 내용은 이 글 참조)

이제 고민을 해야했다.

스케일 업인가, 스케일 아웃인가

스케일 업 vs 스케일 아웃

서버의 자원 한계점 도달이라는 현 상황에서 사용 가능한 대안을 생각해보자.

크게 스케일 업과 스케일 아웃이라는 경우의 수가 존재한다.

스케일 업이라는 것은 서버의 자원(CPU, RAM)을 더 좋은 성능의 부품으로 바꾸는 작업을 말한다.

이를 통해 서버가 더 많은 부하를 견딜 수 있도록 해주는 것이다.

서버가 멈춰버리는 이전과 같은 상황이 생긴다면 스케일 업을 통해 더 강한놈으로 재탄생시킬 수 있지만

그만큼 비용이 부과되고, 현 상황에서 스케일업을 한다면 모든 api가 동작하지 않을 수 있다는 문제가 있다.

스케일 아웃이라는 것은 다른 서버들을 중복으로 두어 부하를 분산하는 작업을 말한다.

이를 위해 부하를 균등하고 분배시킬 로드 밸런서를 이용해 각 서버별 부하를 체크하고 부하를 일정하게 분산시켜줄 수 있다.

이중에 나는 스케일 아웃을 선택했다.

왜? 극한의 이득충이니까...

나는 같은 동작을 처리해주는 컨테이너들을 복수로 두는 것이 아니다.

간단한 토이프로젝트를 배포해보는 입장에서,

멀티 모듈로 구현된 프로젝트를 모듈단위로 컨테이너화 시키고

모듈당 하나의 컨테이너만이라도 실행시키면 된다는 것이다.

(즉, 모듈당 하나씩 뽑은 컨테이너를 다 모아서 한 서버에서 실행시킬 수 없다는 뜻...)

이득충이 어떻게 스케일 아웃을 함?ㅋㅋㅋㅋㅋ

할 수 있다.

이번에는 오라클 클라우드가 아닌, 구글 클라우드에서 인스턴스를 가져올 생각이다.

여기 요금표를 보면 딱 하나의 e2-micro vm까지는 사용을 해도 무료로 쓸 수 있다는 이야기가 있다.

이를 이용해 다른 서버를 사용해보려고 한다.

그렇다면 어떻게 서버를 나눌지 생각해야 한다.

현재 내 모듈들을 그려보고, 이 모듈이 어떻게 서로 동작하는지 확인해야 한다.

현재 OCI 무료 인스턴스 내부에서 동작하고 있는 컨테이너(모듈)이다.

Fridge모듈에서 재료를 추가했을 경우 회원의 정보에서도 데이터를 수정해주기 위해 Redis Pub/Sub을 이용한 이벤트 핸들링을 하고있다.

모듈간의 다른 이벤트가 존재하지 않는다.

Redis 또한 현재 OCI 인스턴스 안에서 동작하고 있기 때문에, OCI 인스턴스에 Auth와 Fridge만을 동작시키고, Member와 Recipe를 다른 모듈로 두면 될 것 같다는 생각이 들었다.

OCI가 이미 있으니까 GCP 인스턴스를 만들어보자.

이전에 보여준 가격표에 맞게 GCP 인스턴스를 무료로 만들었다.

보통은 ssh로 터미널을 이용한 접근을 하는데, 구글은 인스턴스를 만들 때 pem키를 주질 않았다.

여기에 있는 ssh를 클릭하면 브라우저에서 터미널을 열어준다.

브라우저 상으로 ssh접속을 시켜주는 것이다.

참 신기했다.

이제 도커를 받아야 한다.

리눅스 배포판은 데비안이라고 한다.

이걸 왜 말하냐고?

이제 apt인지 yum인지 명령어를 다 두들겨보고 정하지 않아도 된다.

https://jangsarchive.tistory.com/169

[운영체제] 리눅스 패키지(내가 맨날 헷갈린 apt쓸 때와 yum을 쓸 때)

(패키지라는 것이 무엇인지 알고 보는게 편하다. 이전 포스트를 보고오자. 리눅스에서는 리눅스 패키지라는 것이 존재한다. 리눅스 패키지란 리눅스 시스템에서 소프트웨어를 실행하는데 필요

jangsarchive.tistory.com

이미 한번 찾아봤거든!!!

데비안이기 때문에 apt로 명령을 해주면 된다.

update와 upgrade를 해주고 도커를 다운받자

Docker를 다운받는 방법은 도커 공식 홈페이지에 존재한다.

잘 보면 도커는 sudo 권한으로만 실행시킬 수 있는데, 이 권한을 바꿔주자.

sudo gpasswd -a $USER docker

혹은

sudo usermod -aG docker $USER

라는 명령어를 이용해 도커에 현재 사용자 권한을 추가해주자.

이후 다시 해당 사용자로 접근하면 정상적으로 동작이 수행된다.

이제 해당 도커 허브에 접근해 도커 컨테이너를 가져올 수 있다.

이제 스왑메모리를 위한 노가다를 시작했다.

Sudo하는데 왜 비밀번호가 필요해?

나는 브라우저상에서 ssh를 접속해 사용을 했는데, 계속해서 비밀번호를 물어봤다.

찾아보니 브라우저 상에서 비밀번호를 등록하는 것이 아닌, rsa키를 직접 만들어 GCP 인스턴스에 공개키를 주고 내 개인키로 접근해야 하는 것이었다.

다시 돌아가서 키 세팅을 해주자.

ssh-keygen -t rsa -b 4096 -C "janghee5395@gmail.com"

이렇게 터미널에 입력해 공개키/개인키를 받아주었다.

ssh키가 모인 곳들로 이동해

이걸 열어보면 공개키가 나온다. 이걸 복사해서 등록해주어야 한다.

여기에 가보면 ssh키를 등록하는 곳이 있고, 여기에 공개키를 복사해서 넣어주었다.

이렇게 해서 ssh로 접속을 해보았다.

이제 정상적으로 루트 권한으로 사용할 수 있고, 이 상태에서 스왑메모리를 추가해주었다.

(스왑 메모리 추가 방법은 이 포스팅을 참고하자!)

https://jangsarchive.tistory.com/153

[Infra] 스왑메모리 딥다이빙(1. 서버 메모리 부족이 쏘아올린 작은 공)

서론 스왑메모리은 영상 인코딩을 하다가 서버가 부하를 버티지 못하는 문제로 사용해야겠다는 생각이 들었다. 이전에 사용을 위해서 스왑메모리라는 것이 단순하게 서버가 가지는 저장공간(

jangsarchive.tistory.com

도커 로그인 & 컨테이너 가져와 실행시키기

비밀번호는 같이 붙여넣지 않겠다. 들키면 x되니까.

이렇게 도커로 로그인을 해서 사용할 컨테이너들을 불러오자.

두 개의 컨테이너를 불러왔다. 이제 실행만 시키면 된다.

docker run~~~의 명령어인데 사람에 맞게 사용하면 된다고 생각한다.

이 포스팅을 참고하자

https://jangsarchive.tistory.com/146

[Infra] git clone의 문제점, 그리고 어떻게 하는 것이 좋을까?

이전에 git clone을 통해 프로젝트를 받는 방식을 알아보았다. 이 방식의 문제가 무엇일까? 직접 npm install을 해주어야 한다. nestjs : npm run start, java : java -jar의 방식으로 프로젝트를 실행시켜야 한다

jangsarchive.tistory.com

이렇게 GCP에서 두 개의 컨테이너를 열었다.

기존의 OCI에 존재하던 컨테이너 3개 중 Member를 지우기로 했다.

(확실히 레디스와 펍섭때문인지 메모리를 많이 먹는 OCI다)

이렇게 스케일아웃이 아닌 스케일아웃(?)이 끝났다.

원래는 2Gi정도가 더 좋다고는 하는데 안전하게 3Gi씩 넣었는데 다행히 동작을 잘 될 것 같다는 기대를 해본다(?)

이제 뭐할꺼임?

인스턴스가 두 개가 되었기때문에, 무중단 배포를 해주어야 하며, 무중단 배포를 위한 스크립트에 대한 학습을 더 해야할 것 같다.

그리고 두 개의 다른 ip로 되어있는 주소때문에, 이를 위한 포워딩을 해주어야 할 것 같다.

1차 MVP에 대한 구현이 전부 끝난 상황에서,

앞으로 냉메추 서비스에서 내가 해야할 일은 다음과 같다.

MemberRecipe(사용자 레시피 조회 내역)을 군집화시켜 레시피 추천 로직 만들어주기
레시피 데이터 크롤링 & 크롤링 된 레시피에 따른 재료 및 레시피 데이터 주입해주기
ip와 포트를 포워딩시켜주기
CI/CD 추가로 달아주기

초기엔 구현을 빠르게 하고 싶다는 욕구가 들어 구현부터 했지만,

늦었더라도 인프라적인 부분들과 ML에 관련된 부분에 더 힘써야겠다.

그럼...twenty thousand...

[코틀린 + 스프링] 코틀린? 이거 왜 익숙한데..?

장아장 — Mon, 29 Apr 2024 17:39:43 +0900

본 포스팅은 이 책과는 무관합니다. 저는 코틀린 책을 읽고 구현을 하지 않았습니다.

이번 넹매추라는 프로젝트를 코틀린으로 한 달동안 구현을 해보며 느낀 부분들을 정리해보았다.

코틀린에 대한 지식적인 부분이라기보단, 경험적으로 정리하는 글이라는 점을 알아두면 좋을 것 같다.

하와와...너무 무서운 거시에요!

처음에 내가 코틀린이라는 것을 이야기들었을 때 이런 생각이 들었다.

당시의 나는 NestJS, 자바 스프링만을 써본 상황이었다.

자바 스프링 독학과 네이버 부스트캠프에서 곰터뷰를 만들어보며 NestJS를 공부했었다.

이런 나에게 같이 프로그래밍 공부를 시작했던 동기(그 친구는 우아한 테크코스에 있었다)가 말해준 것이,

우리 취업하면 코틀린 써야할껄?

이었다

진짜 개무서웠다.

여기에서 새로운 것을 또 공부해서 써야한다고?

내가 공부한 것들도 완벽까지는 아닐것이다, 분명 더 깊은 무언가가 있을 것이다 라는 생각으로 살고있는데,

새로운 것도 공부하면 더 깊어질 것 같아 무서웠다.

일단 맞아보자!!

근데 그렇게 겁을 먹으니 궁금하긴 했다.

내가 뭔데 쫄을 쳤을까?

도대체 어떻게 생긴 놈이길래?

그래서 냉메추라는 프로젝트에 대한 인트로에서 이야기했듯,

코틀린으로 프로젝트를 만들어보기 시작했다.

Kotest라는 것도 다시 써봐야했고, 스프링이 안본새에 Swagger대신에 Spring Docs라는 라이브러리로 RestDocs라는게 추가되어있었다.

마치 대학교 새내기가 첫 학기에 풀전공을 때린것처럼

해야할 과제가 산더미처럼 떨어지는 기분이었다.

생각보다 할만하다...?

일단 다시 한번 이야기하지만, 나는 NestJS를 써본 사람이다.

그런 나의 입장에서 코틀린은 매우 익숙한 냄새가 났다.

함수의 리턴 타입을 뒤에 :를 찍고 넣어야 하는 것 부터,

모든 것들이 늘 먹던 맛이라는 생각이 들었다.

생성자도 public ${클래스명}()에서 constructor()로 바뀐 것이, 아주 타입스크립트를 쓰는 맛이 났다.

그래서 너무 좋기도 했다.

내가 새롭게 써본 것은 이 사진 하나로 처리되는 기분이었다.

클래스명 바로 뒤에 인스턴스들을 괄호안에 넣어 생성자까지 만들어주는 이러한 꿀같은 놈과 var, val이었다

(근데 val, var도 마치 let, const와 같은 것이어서 어렵지 않았다)

(아 open도 있었다)

해봐야 찍먹 아니냐, 너가 코틀린을 공부 안해봐서 그래.

찍먹으로 보일 수 있다.

그래도 간단한 토이프로젝트를 만들고

시작하는 정도로는 부족하지 않다고 생각한다.

또한, 코틀린은 코틀린만의 매력이 있다고 생각한다.

Null-safety가 너무 머리아프지 않냐고 이야기하는 사람도 있었지만,

오히려 타입스크립트에서 물음표와 이를 위한 validation 로직으로 점칠된

나의 지난, 그리고 앞으로의 곰터뷰 라이프가 있기에 그렇게 어렵지 않았다.

그래서 사 먹어 말아

나는 한번 경험삼아 써보는 것도 좋다고 생각한다.

생각보다 코틀린이라는 친구가 그렇게 무섭지 않다는 것,

그리고 많은 백엔드 학생, 개발자들이 다 써봤다는 스프링에서 약간의 언어차이(?)만 존재하니까 부담도 없다.

인프런에 호돌맨의 요절복통 개발쇼라는 강의가 있다.

거기에 보면, 그냥 안써본거 써보면서 공부해보라는 이야기도 있다.

내 주변에 개발을 공부하는, 공부하려는 사람들이 종종 물어보는 질문중에,

개발이 생각보다 되게 공부할게 많은데 언제 다 공부하고 개발하냐

라는 이야기였다.

다 공부하고 시작하지 않았으면 좋겠다는 생각이 든다.

몇 사람들이 김영한님 강의를 JPA까지 들었다, QueryDSL까지 들었다. 등의 이야기를 하는데

개발도 크게보면 공학이다.

공학과 기술은 필요에 따라 발전한다.

우리도 필요에 따라 우리를 발전시키면 되지 않을까?

어떤 상황에서는 어떤 문제가 있으니 이걸 공부해보고,

이런식이라고 생각한다.

너무 어렵게 다가가지 말자.

그럼...twenty thousand...

[냉메추] 멀티모듈로 구현을 한다는 것. 서버가 많이 필요하다는 것.

장아장 — Mon, 29 Apr 2024 17:16:25 +0900

돈돈! 더 많은 돈!! 내가 싼 똥이다!!!!! 하하하하하하하하하하하ㅏ하하하하하하하하

이전에 이야기한 대로, 멀티모듈로 프로젝트를 만들기로 했다.

멀티 모듈을 어떻게 배포하는 건지, 처음부터 다시 정리해보기 시작했다.

settings.gradle, build.gradle설정해주기

물론 IDE 등에서 내부에 모듈을 추가하게 하면 자동으로 추가되지만, 그래도 알고 지나가는 것은 중요하다고 생각한다.

우리가 가지고 있는 모듈 내부에 이런 모듈들이 존재한다는 것을 명시해주었다.

또한, build.gradle에서 이렇게 내부에 include된 모듈들에 대한 공통적인 dependencies를 추가해줄 수 있었다.

subprojects {
    apply plugin: 'java'
    apply plugin: 'org.springframework.boot'
    apply plugin: 'io.spring.dependency-management'
    apply plugin: 'org.asciidoctor.jvm.convert'

    group = 'org.capstone'
    version = '0.0.1-SNAPSHOT'
    sourceCompatibility = '17'

    repositories {
        mavenCentral()
    }

    configurations {
        compileOnly {
            extendsFrom annotationProcessor
        }
        asciidoctorExt
    }

    ext {
        set('snippetsDir', file("build/generated-snippets"))
    }

    dependencies {
        ....
    }

    tasks.named('test') {
        outputs.dir snippetsDir
        useJUnitPlatform()
    }
    ...
}

이렇게 내부 모듈들이 공통적으로 가질 의존성과 다른 build.gradle에 대한 설정들을 명시해줄 수 있었다.

Common 모듈이 필요했다.

jwt 토큰에 대한 인증/인가를 확인하는 로직과, 공통적으로 설정해야 하는 CORS를 꾹꾹 눌러담은 모듈을 만들었다.

common이라고 명명하기 전에 auth 모듈이라고 명명해두고 시작해둔 상태이다.

이 모듈에서는 JPA와 OAuth2, jwt를 위한 데이터들을 yml파일에 담아두었다.

로그인/로그아웃/토큰 재발행/토큰 인증&인가 등에 대한 로직도 담아둔 상태이다.

(1차 MVP가 끝나면 로그인등의 로직은 분리해서 다른 모듈로 배포해야겠다는 생각이 든다. 이걸 모든 모듈이 가져가 사용하는것은 비효율적인 것 같다)

JPA등의 application.yml외에 이 모듈이 가장 중요한 이유는 이 어노테이션 하나다.

이번에 Spring Security의 많은 시큐리티 체인 대신에, 간단하게 토큰을 복호화해 검증하는 로직 하나만을 쓰고싶었다.

그래서 이런 어노테이션을 만들어, 다른 모듈에서 사용할 수 있게 하고 싶었다.

Common 모듈을 가져다 썼다.

auth 모듈을 가져다 쓰는 다른 모듈의 build.gradle속의 dependencies이다. (미리 스포된 것 같지만 코틀린으로 만들어져있다...이 고생도 블로깅해야지)

이렇게 세팅을 해주고 해당 모듈의 로직들이 import된 것 처럼 사용할 수 있었다.

이렇게 하면 다른 모듈에서 auth 모듈의 코드를 사용할 수 있었고, 배포를 모듈 단위로 할 수 있었다.

여기서 문제. 나는 몇 개의 모듈을 쓸까?

여기에서 커다란 문제에 봉착했다.

생각해보니, 모듈 단위로 컨테이너를 분리해서 배포를 한다고 했을 때,

내가 만들어야 할 모듈은 Auth, Member, Fridge, Recipe가 있었다.

후에 머신러닝을 위한 모듈 또한 만들어야 하고, 컨테이너 외부에서는 레디스가 동작하는 중이다.(이것도 스포다)

이런 수많은 컨테이너를 서버에서 버틸 수 있을까가 가장 큰 문제였다.

그래서 스왑을 늘려버렸다.

서버비를 더 내기엔, 직업도 없는 학생의 신분에서 너무 어려운 일이었다.

현재 Auth, Member, Fridge가 올라가 있는 상태이고, 3개의 모듈과 Redis가 켜져있다.

스왑까지 총 4Gi를 가질 수 있는 서버의 현 상황에서, 1.6Gi만 남은 상태이다. 딱 컨테이너 두 개 정도 올릴 수 있는 수준이라고 판단했다.

(돈 굳었다...!)

그래서, 이렇게 하면 좋음?

확실하게 멀티 모듈로 프로젝트를 진행해보면서 느낀점은,

상황에 따라 이게 안좋게 보일 수 있겠다는 느낌이 들었다.

나처럼 서버를 여러 대 사용할 수 없는 상황이라면 멀티 모듈로 인해 오히려 싱글모듈로 배포하는 것이 더 비용적으로 효율적일것이라는 생각이 들었다.

나는 도메인 단위로 모듈이 간섭되지 않게 구현해 이정도지만, 각 도메인간의 이벤트로 연결이 많다면 오히려 멀티모듈 사용시 kafka나 Redis Pub/Sub을 사용해야 하는 소요가 발생할 수 있다는 생각이 든다.

(하지만, 나도 Redis Pub/Sub을 사용하고 있다. 이벤트를 이용해야 할 상황이 있었다)

오늘의 키워드 : 체신기술, 고오급 기술이라고 다 막 쓰지는 말자.

주변에서 멀티모듈, MSA, kafka/Redis pubsub등이 트렌드라는 이야기를 듣고 이를 적용해보고 있지만,

이런 것들이 마냥 좋겠다는 생각이 들지는 않았다.

더 많은 서버와 같은 자원이 충분하다면 이를 통한 경험은 무시할 수 없을 것 같다.

하지만, 현재 나의 상황을 알고 이를 활용해야 한다는 생각이 들었다.

[냉메추] Oracle Cloud를 이용한 서버 환경 구축하기(1. 인스턴스 생성, Docker 설치, 젠킨스 컨테이너 가져오기)

장아장 — Wed, 3 Apr 2024 20:02:39 +0900

생각보다 할 일이 늘어나는 느낌이지만, 왜 OCI인지부터 모든걸 정리해보자.

Why OCI?

이번에는 왜 AWS(항상 쓰는 것)이 아닌 OCI일까?

이는 두 인스턴스의 pricing을 찾아보면 알 수 있다.

https://hoing.io/archives/10446 <- 여기에서 모든 비용이 어떻게 계산되는지 알 수 있었다.

여기에 존재하는 평생 무료 플랜을 이용해서

앞으로의 학습이나, 추가적인 학습을 계속해서 하나의 서버로 할 수 있겠다는 생각이 들었다.

이번 프로젝트에서는

자바/스프링에 대한 딥다이빙
군집화 알고리즘을 이용한 내가 선택한 레시피와 같은 군집의 레시피 추천

을 주로 다룰 계획이다.

이에 대한 학습이 계속되어야 할 것 같다는 느낌이 들었다.

매번 학습을 할 때 새로운 프로젝트를 통해 기술을 도입해보기보단,

하나의 프로젝트를 더욱 제대로 만들어봐야겠다는 생각이 들었다.

(이게 개발자지!)

인스턴스는 완전 무료/기본 옵션을 전부 가져왔다.

(EC2와 동일 스펙을 가져오기보단, OCI 자체가 제공하는 옵션이 달라서 그대로 쓰기로 했다)

1. 부족한 메모리 해결해주기

이 부분은 이전에 정리했던 스왑 메모리를 이용해 메모리를 해결해주었다.

이 두 개의 포스트로 스왑 메모리에 대한 학습을 진행했었다.

메모리가 과도하게 사용되는 포인트에서 스왑을 단 (11:05)이후로 메모리 사용량이 줄어드는 것을 볼 수 있었다.

이번엔 2GB의 스왑 메모리를 사용했다.

2. 인스턴스 업데이트 시켜주기

위의 그래프에서 나온 메모리가 100%를 찍고 멈추던 상황은 sudo yum update를 하면서 멈춘 상황이었다.

성공적으로 sudo yum update & sudo yum upgrade를 할 수 있었다.

그런데 궁금해졌다.

이전에는 sudo apt update를 했던 것 같은데, 왜 이번에는 yum이라는 명령어를 사용할까?

업데이트를 기다리면서 이 부분을 찾아보았다.

다들 업데이트 시켜놓고 같이 읽어보자.

업데이트가 끝나면 이렇게 뜨고, upgrade를 추가로 진행시켜주었다.

update는 최신 버전의 설치를 주로 진행해준다고 하지만,

upgrade를 통해 모든 패키지들의 의존성을 체크해주는 것이다.

성공하면 이렇게 뜬다. Dependencies resolved가 다르다.

3. 도커 설치해주기

curl -fsSL https://get.docker.com/ | sudo sh

를 시도했는데 실패했다.

https://oracle-base.com/articles/linux/docker-install-docker-on-oracle-linux-ol8 에서 어떻게 하는 찾아보았다.
Oracle Linux 8이 CentOS기반이라 ubuntu기반과는 다르게 설치해야 하는 것 같았다. - `docker -v`를 하니 정상적으로 도커가 설치됨을 확인할 수 있었다.

dnf install -y dnf-utils zip unzip # dnf 유틸, 압축, 압축해제 패키지 설치
dnf config-manager --add-repo=https://download.docker.com/linux/centos/docker-ce.repo # 도커 공식 레포지토리 주소를 나의 레포지토리에 추가
dnf remove -y runc # Docker의 런타임에 사용되는 실행 담당 프로그램 삭제
dnf install -y docker-ce --nobest # Docker community edition을 설치한다. nobest는 최신 버전이 아니더라도 현재의 운영체제에 맞는 적합한 버전을 찾게 해준다.

이렇게 명령어들을 순차적으로 사용해 도커를 설치했다.

docker -v를 통해 도커 버전을 확인할 수 있었다.

4. 젠킨스 컨테이너 만들기

docker pull jenkins/jenkins:jdk17

jdk17버전의 젠킨스를 가져온다.

jdk17버전인 이유는 내가 이번 스프링을 자바 17로 진행하려고 해서 그렇다.

docker run -d -p 8180:8180 -v /var/jenkins_home --name jenkins -u root jenkins/jenkins:jdk17

이렇게 8180 포트에서 젠킨스를 실행시켰다.

8180포트로 접근을 하면 젠킨스는 adminPassword가 필요하다고 뜬다.

(이걸 하기 전에 인스턴스의 인바운드 규칙도 설정해주고 가면 된다)

이는 로그를 통해 보거나, 사진에 적혀있는 주소에서 볼 수 있다고 한다.

docker logs jenkins

나는 이런 명령어를 통해서 비밀번호를 가져왔다.

이렇게 들어가면 suggested plugin을 설치하는 것과, 추천받는 플러그인을 받는 것으로 선택할 수 있다.
나는 suggested plugin을 받아주었다.

5. 다음 계획 짜기

블루/그린이라면, 도커 컨테이너를 그 때 마다 8081, 8082로 뽑아주어야 하고, 이를 NginX가 8080으로 연결해 외부에서 8080으로 요청을 받고 내부에서 8081/8082포트로 받게 설정해주어야한다.
해당 NginX의 로드 밸런싱은 블루/그린마다 다르게 설정되어야한다.
젠킨스 CI/CD를 어떻게 설정할것인가? (파이프라인은 어떻게 만드는 것인가?)
멀티모듈을 어떻게 설정할 것인가?
docker-compose를 어떻게 사용할 것인가?

이러한 과정을 추가적으로 진행해야 한다.

하나씩 공부해서 다 정복해내봐야 겠다.

그럼...twenty thousand...

[운영체제] 리눅스 패키지(내가 맨날 헷갈린 apt쓸 때와 yum을 쓸 때)

장아장 — Wed, 3 Apr 2024 17:16:33 +0900

(패키지라는 것이 무엇인지 알고 보는게 편하다. 이전 포스트를 보고오자.

리눅스에서는 리눅스 패키지라는 것이 존재한다.

리눅스 패키지란 리눅스 시스템에서 소프트웨어를 실행하는데 필요한 파일들(실행 파일, 설정 파일, 라이브러리 등)이 담겨 있는 설치 파일 묶음이다.

리눅스는 배포판에 따라 다른 패키지 형식을 지원한다.

여기에서 yum을 사용하는 경우와 apt를 사용하는 경우가 달라지게 된다.

debian : ec2에서 사용하던 apt가 들어있다. 패키지는 .deb파일로 되어있다.
레드헷 : yum이 들어있다. 패키지는 .rpm파일로 되어있다.
openSUSE : zypper이 들어있다고 한다. openSUSE를 위해 특별히 빌드된 패키지 형식이다. .rpm파일로 되어있다.

if(rpm(레드헷) === rpm(openSUSE)) 배표판_공유하기();

내가 스스로 해본 생각이다.

둘의 리눅스 배포판 패키지가 같은 확장자라면, 둘을 혼용할 수 있지 않을까? 라는 생각이 들었다.

openSUSE는 zypper이 들어있고, 특별히 빌드된 패키지라지만, 레드헷 배보판에서 같은 패키지 확장자니까

그래도 읽고 사용할 수 있긴 하지 않을까?

라는 생각을 해보았다.

하지만!

두 배포판이 각각 고유한 라이브러리 버전, 컴파일 옵션 및 시스템 구성을 가지고 있기 때문에 둘의 리눅스 패키지를 공유할 수 없다고 한다.

이에 대한 더 자세한 이유는 아래에서 더 풀어보자.

패키지 관리 툴

일반적으로 운영체제에서는 패키지 관리 툴이라는 것이 존재한다.

패키지 관리 툴은 크게 저수준 툴, 고수준 툴로 나뉜다.

이 중에서 리눅스에 관해서 조금 더 깊게 찾아보자.

저수준 툴
- 리눅스 커널 (Linux Kernel)
  - 리눅스의 핵심 부분으로, 하드웨어와의 통신을 관리하고 프로세스 간의 자원을 분배한다
- GNU Core Utilities
  - 리눅스 시스템에서 핵심적인 유틸리티를 제공한다
  - 이에는 파일 및 디렉토리 관리, 텍스트 처리, 셸 스크립팅 등을 위한 명령어들이 포함된다
- 시스템 라이브러리 (System Libraries)
  - C 라이브러리 (libc) 등의 저수준 라이브러리는 시스템 호출 및 다양한 하드웨어 기능에 대한 접근을 한다
- 디바이스 드라이버 (Device Drivers)
  - 하드웨어와 통신하기 위한 인터페이스를 제공한다
  - 디스크, 네트워크, 그래픽 카드 등의 하드웨어를 제어한다
고수준 툴
- 커맨드 라인 인터페이스 (CLI) 도구
  - 터미널을 통해 사용자가 명령어를 입력하여 시스템을 제어한다
  - 예를 들어, ls, grep, sed, awk 등의 명령어들이 있다
- 패키지 관리자 (Package Manager)
  - 리눅스 시스템에서 소프트웨어를 설치, 업데이트, 제거하는 데 사용된다
  - 예를 들어, apt, yum, dnf 등이 있다
- 그래픽 사용자 인터페이스 (GUI) 도구
  - 리눅스의 그래픽 환경에서 작동하며, 시스템 설정, 파일 관리, 응용 프로그램 실행 등을 위한 도구들을 제공한다
  - GNOME, KDE, Xfce 등의 데스크톱 환경은 이러한 GUI 도구들이 있다
- 개발 도구 (Development Tools)
  - 리눅스에서 소프트웨어 개발을 위한 도구들은 고수준 툴이다
  - 통합 개발 환경 (IDE)인 Visual Studio Code, Vim, Emacs 등의 텍스트 편집기, 컴파일러, 디버거 등이 포함된다

고수준 툴은 사용자 편의성을 높이기 위해 설계되었으며, CLI 도구와 GUI 도구를 통해 사용자가 리눅스 시스템을 더 효과적으로 관리할 수 있도록 도와준다.

리눅스 배포판 패키지의 종류는 패키지 관리자에서 크게 차이가 존재하게 된다.

배포판 이름	저수준 툴(설치, 업데이트, 삭제 등을 수행)	고수준 툴(의존성의 해결, 패키지 검색 등의 기능)
데비안	dpkg	apt/apt-get
레드헷	rpm	yum
openSUSE	rpm	zypper

이렇게 보면 아까 말했던 두 rpm파일이 같이 공유될 수 없는 이유를 느낄 수 있었다.
패키지 설치/업데이트/삭제등은 같은 툴을 사용하지만, 고수준 툴이 다르다. 즉, 설치는 같게 해도 둘의 의존성 해결등의 문제는 서로 다른 로직을 사용해 해결한다는 것이다.

호기심. 그래서 뭐가 더 좋은데?

이에 대해 몇몇 게시물들을 찾아보았지만,

정확히 어떤게 더 좋다 라고 말하는 게시물은 찾지 못했다.

또한, 상황에 따라 혹은 환경에 따라 달라진다고 하는데,

그렇다면 일반적인 사용자의 입장에서는

이게 더 좋으니 뭐 써라

그럴바엔~~ 써라 같은 사유가 발생하기 힘들어진다는 느낌을 받았다.

리눅스 명령어가 왜 다를까 부터 시작해서

패키지의 구조 및 차이점을 찾아보고

리눅스 패키지의 배포판마다의 차이점을 다시 찾아보았다.

역시 궁금한건 그때그때 파보는게 재밌다.

다른 궁금해지는 것들이 있으면 찾아서 또 정리해야겠다.

그럼...twenty thousand...

[운영체제] 패키지(리눅스 배포 패키지, npm)

장아장 — Wed, 3 Apr 2024 16:08:07 +0900

개발을 하는 우리는 항상 리눅스를 사용한다.

그런데, 사람들의 블로그 포스팅을 보면 항상 이해되지 않는 한 가지가 존재했다.

왜 어떤 사람은 yum을 쓰고 어떤 사람은 apt를 쓸까?

이 질문에서 패키지라는 것을 학습해봐야겠다는 생각이 들었다.

What is Package?

패키지는 소스코드 패키지, 바이너리 패키지로 분류된다. (저급언어/고급언어에 대해 안다면 이해가 쉬울 것 같다)

소스 패키지는 소스 코드로 이루어져 있는 패키지이다.

이를 읽고 실제로 컴퓨터에 적용시키려면 컴파일을 한 후 바이너리 코드를 컴퓨터에서 실행시켜야 한다.

그래서 설치가 더 오래걸린다는 단점이 존재한다.

또한, 하드웨어의 더 많은 저장공간을 차지한다고 한다.

그리고, 컴파일 에러가 발생할 수 있다는 단점이 있다.

바이너리 패키지는 반대로 이진 파일로 이루어져 있다.

컴퓨터에 바로 적용할 수 있고 더 가볍다고 한다.

더 빠른 운영체제의 설치를 위해 리눅스는 바이너리 패키지를 이용한 배포를 한다.

궁금증. NPM

https://www.gomterview.com/

곰터뷰

www.gomterview.com

(아직도 곰터뷰를 안가봤다고?)

네이버 부스트캠프에서 진행했던, 지금은 같이 하던 팀원들과 계속해서 진행중인 곰터뷰 서비스이다.

해당 프로젝트는 내가 살면서 처음으로 nest.js를 이용해 만든 서비스이다.

프론트엔드/백엔드를 막론하고 js는 수많은 라이브러리를 사용한다.

그리고 이런 라이브러리들을 npm을 이용해 가져와 사용한다.

npm을 통해 nodejs, nest말고도 수많은 라이브러리 패키지를 가져온다.

그리고 이런 라이브러리들을 사용하다가 모르는 부분이 있으면 cmd+클릭을 이용해 사용하고 있는

라이브러리의 코드들을 볼 수 있다.

그렇다면 이런 라이브러리들, 그리고 npm은 고급 언어로 되어있는 소스 패키지일까?

이 부분이 궁금해졌다.

yes

어찌보면 당연하다.

소스코드로 이루어져있는 패키지니까.

그리고 이런 소스 패키지도 모두 소스코드로 이루어져있진 않다고 한다.

npm이나 yarn과 같은 것들로 다운로드해 사용할 때 일부 라이브러리는 미리 빌드된 바이너리 파일이 포함될 수 있다.

이를 통해 직접 수정해서 조금 느리더라도 자유롭게 사용할 수 있는 것들과, 미리 빌드되어 소스코드를 추가 빌드하지 않고 쉽게 사용할 수 있게 해준다.

각자의 장점이 있을 것이다.

소스 코드로 이루어진 패키지
- 이 경우에는 소스 코드가 직접 제공된다.
- 개발자는 이 소스 코드를 자유롭게 수정하고 커스터마이징할 수 있다.
- 수정이 가능하기 때문에 특정한 요구 사항에 맞게 소프트웨어를 사용할 수 있다.
- 하지만 이 소스 코드를 컴파일하고 빌드하는 과정이 필요하기 때문에 설치 과정이 느릴 수 있다.
바이너리 파일로 줄 경우 : 빠르게 적용되고 사용하기 쉽다. 하지만 수정은 못한다.
- 이 경우에는 라이브러리의 빌드된 실행 파일이 제공된다.
- 따라서 컴파일이나 빌드 과정이 필요하지 않다.
- 설치가 빠르고 사용하기 편리하며 수정이 불가능하다.
- 일반적으로 사용자는 해당 라이브러리를 그대로 사용하거나 설정 파일을 조정하여 사용한다.

아직 한발 남았다...

패키지라는 것에 대한 호기심은 풀었지만,

내 스스로의 요구사항에서는 조금 벗어난 학습이다.

나는 리눅스 yum, apt를 혼용하며 생긴 이슈에 대한 원인을 찾고싶은 것이었다.

이를 위한 학습을 추가로 진행해야겠다.

그럼...twenty thousand...