bill's tech log

[github] rulesets 기반 main branch를 보호하기

bill's tech log — Fri, 12 Dec 2025 22:31:12 +0900

github에 리포를 관리하다 보면 main 브랜치를 보호해야 될 때가 있다. 특히 내가 public으로 open 하고 관리하는 리소스에 누군가가 pr을 올리는 게 아니라 그냥 push를 해버린다면 끔찍할 것이다 사실 이번에 이와 관련된 일련의 사건이 있기도 했고.. 매년 깃헙 UI와 업데이트로 바뀌기도 하고 까먹어서 정리 겸 올려둔다.

1. 보호할 리포지토리에 settings로 접근

관리할 github repository의 메인에서 우측 상단 Settings를 클릭한다.

2. 좌측 사이드바에 Rulesets 클릭

좌측 사이드바에 Rules -> Rulesets을 클릭한다

3. Branch Rulset을 선택

New reuleset을 선택하고 New branch ruleset을 클릭한다. ( main 브랜치를 보호할 것이기 때문에 다음과 같이 진행한다. )

4. Rulset Name & Enforcement status 작업

Ruleset Name을 입력한다. ( 암거나 입력하면 된다. 나는 main 브랜치를 보호할 용도의 rule이기 때문에 다음과 같이 정의했다 )

Enforcement status를 Acitve로 변경해준다.

4-1. TargetBranch

Target branches의 Add target 토글을 선택하면 어느 브랜치를 타깃으로 할지 선택하는 옵션이 나온다.

나는 default 브랜치인 main브랜치를 관리할 것이기 때문에 Include default branch를 선택한다.

4-2. Rules 정의

default branch를 선택하면 Branch rule에 default로 Restrict deletions와 Block force pushes가 켜져 있다. 각 옵션은 기본 브랜치를 삭제하거나 해당 리포에 force 푸시를 방지하는 것을 의미한다. ( 그러면 당연히 안 되니까 그냥 활성화를 시켜준다 )

우리는 main 브랜치에 push를 하는것을 막아야 하기 때문에 Require a pull request before merging 옵션을 활성화해준다. Require a pull request before merging 옵션은 메인 브랜치에 직접 push 못하게 막고, PR(풀 리퀘스트)로만 변경을 머지하도록 강제하는 기능이다. 이때, Require에 approvals 인원을 선택할 수 있는데, 여러 명이서 관리하는 리포일 경우 1 이상의 숫자를 사용하면 되고, 혼자서 관리하는 Public 리포를 보호할 거면 0으로 해주면 된다. 단, 이때 반드시 Require review from Code Owners를 활성화시켜서 해당 리포를 관리하는 메인 테이너가 반드시 리뷰를 해야만 pr-merge가 되고 강제 push가 안되도록 막을 수 있다.

이렇게 완료를 하고 하단에 Create를 누르면 Ruleset Created 문구와 함께 main branch를 안전하게 보호할 수 있다.

[RealMySQL8.0] 아키텍쳐

bill's tech log — Mon, 28 Jul 2025 10:29:04 +0900

MySQL 엔진 아키텍쳐

MySQL 엔진

- 클라이언트 접속, 쿼리 요청 및 SQL 파서 및 전처리, 옵티마이저를 담당하는 부분

스토리지 엔진

- 요청된 SQL을 처리를 수행 ( 기본적인 CRUD 로직을 처리 )

- 여러 개의 스토리지 엔진을 동시에 사용하여 처리할 수 있음.

- MyISAM, InnoDB, Memory 등이 있음.

- CREATE 명령어로 테이블을 생성할 때, ENGINE={스토리지명}을 정의하면 정의된 엔진을 사용할 수 있음.

# INNODB 기반 테이블 생성 
CREATE TABLE iwant_innodb (fd1 INT, fd2 INT) ENGINE=INNODB;

# MYISAM 기반 테이블 생성 
CREATE TABLE iwant_myisam (fd1 INT, fd2 INT) ENGINE=MYISAM;

# 데이터베이스에 할당된 테이블의 정보 확인 -> 여기서 practice는 MySQL 스키마
SHOW TABLE STATUS FROM practice; 

+--------------+--------+---------+------------+------+----------------+-------------+------------------+--------------+-----------+----------------+---------------------+---------------------+------------+--------------------+----------+----------------+---------+
| Name         | Engine | Version | Row_format | Rows | Avg_row_length | Data_length | Max_data_length  | Index_length | Data_free | Auto_increment | Create_time         | Update_time         | Check_time | Collation          | Checksum | Create_options | Comment |
+--------------+--------+---------+------------+------+----------------+-------------+------------------+--------------+-----------+----------------+---------------------+---------------------+------------+--------------------+----------+----------------+---------+
| iwant_innodb | InnoDB |      10 | Dynamic    |    0 |              0 |       16384 |                0 |            0 |         0 |           NULL | 2025-07-17 02:07:31 | NULL                | NULL       | utf8mb4_general_ci |     NULL |                |         |
| iwant_myisam | MyISAM |      10 | Fixed      |    0 |              0 |           0 | 2533274790395903 |         1024 |         0 |              1 | 2025-07-17 02:07:59 | 2025-07-17 02:07:59 | NULL       | utf8mb4_general_ci |     NULL |                |         |
| test_table   | InnoDB |      10 | Dynamic    |    0 |              0 |       16384 |                0 |            0 |         0 |           NULL | 2025-07-17 02:03:13 | NULL                | NULL       | utf8mb4_general_ci |     NULL |                |         |
+--------------+--------+---------+------------+------+----------------+-------------+------------------+--------------+-----------+----------------+---------------------+---------------------+------------+--------------------+----------+----------------+---------+
3 rows in set (0.02 sec)

핸들러 API

- MySQL 엔진이 스토리지 엔진(InnoDB 등)에 데이터 읽기/쓰기 요청할 때 사용되는 API

- 작업 횟수는 SHOW GLOBAL STATUS LIKE 'Handler%'; 명령으로 확인 가능

mysql>  SHOW GLOBAL STATUS LIKE 'Handler%';
+----------------------------+-------+
| Variable_name              | Value |
+----------------------------+-------+
| Handler_commit             | 640   |
| Handler_delete             | 8     |
| Handler_discover           | 0     |
| Handler_external_lock      | 6885  |
| Handler_mrr_init           | 0     |
| Handler_prepare            | 8     |
| Handler_read_first         | 52    |
| Handler_read_key           | 1845  |
| Handler_read_last          | 0     |
| Handler_read_next          | 4101  |
| Handler_read_prev          | 0     |
| Handler_read_rnd           | 0     |
| Handler_read_rnd_next      | 212   |
| Handler_rollback           | 0     |
| Handler_savepoint          | 0     |
| Handler_savepoint_rollback | 0     |
| Handler_update             | 355   |
| Handler_write              | 42    |
+----------------------------+-------+
18 rows in set (0.02 sec)

MySQL 스레딩 구조

- 스레드 기반 구조로 포그라운드(클라이언트 연결 처리), 백그라운드(내부 작업 수행) 동작한다.

- 일반적으로 약 3개의 포그라운드, 다수의 백그라운드 스레드가 존재하며 performance_schema.threads 테이블로 스레드 정보 확인이 가능하다.

SELECT * FROM performance_schema.threads ORDER BY type, thread_id;

포그라운드 스레드

- 사용자의 요청을 처리하는 스레드로 데이터를 읽는 작업 처리.

- 클라이언트 연결당 하나씩 스레드 생성

- 디스크에 직접 데이터를 쓰거나 하는 작업은 백그라운드에서 동작함.

- 읽기는 버퍼/캐시 우선, 없을 땐 디스크 읽기

- MySQL에 접속된 클라이언트의 수 만큼 포그라운드 스레드가 존재함.

- MyISAM은 포그라운드가 디스크까지 쓰기 처리, InnoDB는 백그라운드 스레드에 위임

백그라운드 스레드

- 버퍼 병합, 로그 기록, 버퍼 풀 플러시, 읽기, 락/교착 모니터링 등등의 작업이 이루어지는 스레드.

- 디스크 자체에 데이터를 기록하는 작업은 백그라운드 스레드에서 동작함.

- 현재 로그나 버퍼풀에 있는 데이터를 디스크에 기록함.

- MySQL 5.5 에서는 읽기/쓰기 스레드 수 조정 가능: innodb_write_threads, innodb_read_threads

- InnoDB는 쓰기 지연 처리, MyISAM은 즉시 쓰기

메모리 구조

- 글로벌 메모리: 서버 시작 시 할당, 모든 스레드 공유

- 로컬 메모리: 클라이언트별로 독립 할당, 공유되지 않음

예: 정렬 버퍼, 조인 버퍼, 네트워크 버퍼 등

- 로컬 메모리는 필요할 때만 할당되며 쿼리 종료 시 해제됨

플러그인 스토리지 엔진 모델

- MySQL은 스토리지 엔진, 인증 방식, 파서 등 다양한 기능을 플러그인 형태로 확장 가능

- 핸들러는 MySQL 엔진 ↔ 스토리지 엔진의 연결 고리 역할

-기본 엔진 외에도 외부에서 개발된 플러그인 추가 가능

컴포넌트 (MySQL 8.0+ 이후 부터)

- 플러그인의 단점을 보완한 새 구조

- MySQL 플러그인들간에 통신이 안되기 때문에, 상화 의존관계 설정이 안되는 이슈가 있음.

- 컴포넌트 간 통신 가능, 캡슐화, 의존성 정의 지원

- 예: validate_password 등의 인증 컴포넌트로 설치/관리

쿼리 실행 흐름

1. 사용자의 쿼리 요청

2. 쿼리 파서: SQL 문법 분석 ( 쿼리 파서에서 트리형태로 쿼리를 재구성하고 문법적인 오류를 잡아줌 )

3. 전처리기: 테이블/컬럼 존재 및 권한 검증

4. 옵티마이저: 효율적인 실행 계획 선택 ( 쿼리를 어떻게 빠르게 처리할지 정함 )

5. 실행 엔진: 핸들러를 호출해 실제 데이터 조작

6. 핸들러: 스토리지 엔진 단에서 디스크 I/O 수행 (MyISAM 또는 InnoDB)

쿼리 캐시 (삭제됨)

- 이전에는 쿼리 캐시로 성능 향상을 기대했지만, 동시성 처리에 문제와 버그 많음

- MySQL 8.0에서 완전 제거됨

스레드 풀

- CPU 효율 개선 & 컨텍스트 스위치를 최소화하는 기능을 제공

- 그룹 단위 스레드 처리, thread_pool_size, thread_pool_max_threads, thread_pool_oversubscribe, thread_pool_stall_limit 등의 설정 가능

- 사용자 요청을 포워드 스레드를 CPU가 최대한 잘 처리할 수 있는 수준으로 줄여 동시 처리되는 요청이 많더라도 한정된 스레드에서 처리 될 수 있도록 처리하가능하도록 하기 위함.

트랜잭션 지원 메타데이터(8.0 버전 부터)

- 8.0 버전 부터는 테이블의 구조정보와 같은 메타데이터들이 별도 파일이 아닌, 트랜잭션을 지원하는 InnoDB 스토이지 엔진에 테이블 형태로 저장되도록 개선되었다.

- 스키마 정보가 파일로 저장되었을 경우에는 중간에 파일 쓰다가 에러나면 문제가 될수 있는데, 스키마 변경 작업중에 MySQL 서버가 비정상적으로 종료되더라도 스키마 변경이 완전한 성공 또는 완전한 실패로 정리 된다.

InnoDB 주요 특징

- 레코드 기반의 잠금을 지원하기에 높은 동시성 처리가 가능하고 이에 따른 안정성이 뛰어남.

- 프라이머리키 ( PK )에 의해서 데이터가 클러스터링이된다.

- 외래키를 지원 ( MyISAM )은 외래키 지원 X

- MVCC를 구조( InnoDB의 버퍼풀, 언두로그, 데이터 파일(디스크))를 기반으로 격리성 수준 레벨의 잠금 없이 일관된 읽기 기능을 지원.

- 자동 데드락 감지 기능과 장애 복구 기능이 들어가있음

- 디스크의 쓰기 작업을 줄이기 위한 데이터를 메모리 ( InnoDB 버퍼풀)에 두었다가 한번에 메모리에 올리기 때문에 데이터 in-out 효율성이 높고, INSERT, UPDATE, DELETE에 대해서 트랜잭션 처리를 효율적으로 처리할 수 있음.

- 언두로그 및 로그 버퍼 기능을 지원하고

- 어댑티브 해시 인덱스를 제공함.

1. 프라이머리 키 기반 클러스터링

InnoDB는 클러스터형 스토리지 엔진으로, 테이블의 모든 레코드는 프라이머리 키를 기준으로 정렬된 형태로 저장된다. 즉, 데이터가 저장되는 순서가 프라이머리 키의 값에 따라 결정된다.

여기서 클러스터링이란 비슷한 데이터를 묶어서 저장하는 방식이다. InnoDB에서는 이를 프라이머리 키 기준으로 판단한다. 따라서 숫자가 순차적으로 증가하는 PK를 사용하는 것이 성능에 유리하다.

모든 세컨더리 인덱스는 해당 레코드의 PK 값을 포함한다. 세컨더리 인덱스를 통해 검색하더라도 실제 레코드를 찾기 위해 다시 PK를 통해 클러스터링 인덱스를 조회해야 한다. 이 때문에 PK의 길이가 너무 길거나 비효율적이면 성능에 영향을 줄 수 있다.

2. 외래 키(Foreign Key) 지원

InnoDB는 MySQL에서 유일하게 외래 키를 지원하는 스토리지 엔진이다. 외래 키는 부모 테이블과 자식 테이블 간의 참조 관계를 명시하고, 이 관계를 자동으로 관리할 수 있게 한다.

외래 키가 설정되면 부모 테이블의 PK가 삭제되거나 수정될 때 자식 테이블의 관련 데이터도 자동으로 함께 삭제되거나 제한되도록 설정할 수 있다 (ON DELETE, ON UPDATE 옵션). 다만, 성능 상의 이유로 실무에서는 외래 키를 잘 사용하지 않는다. 이유는 다음과 같다.

부모/자식 테이블 양쪽 모두 인덱스가 반드시 필요하다.
데이터 변경 시 참조 무결성을 확인해야 하므로 추가적인 잠금이 발생한다.
이로 인해 데드락 발생 확률이 높아진다.
외래 키 없이도 JOIN을 통해 참조 무결성을 검증할 수 있다.

데이터 마이그레이션이나 테스트 환경에서 외래 키 제약 조건을 임시로 끌 수도 있다.

SET foreign_key_checks=OFF; -- 비활성화
SET foreign_key_checks=ON; -- 활성화

3. MVCC (Multi Version Concurrency Control)

InnoDB는 잠금 없이 일관된 읽기를 제공하기 위해 MVCC 구조를 채택한다. MVCC는 하나의 레코드에 대해 여러 버전을 유지하며, 각 트랜잭션은 자신만의 일관된 데이터 스냅샷을 읽는다.

이 구조를 통해 읽기 작업은 쓰기 작업과 충돌하지 않고 수행될 수 있다. MVCC는 언두 로그, 버퍼 풀, 트랜잭션 ID를 조합하여 구현된다.

트랜잭션 격리 수준에 따라 데이터의 가시성이 달라지며, InnoDB의 기본 격리 수준은 REPEATABLE READ다.

READ UNCOMMITTED: 커밋되지 않은 데이터도 읽을 수 있다.
READ COMMITTED: 커밋된 데이터만 읽을 수 있다.
REPEATABLE READ: 동일 트랜잭션 내에서 항상 같은 데이터를 읽는다.
SERIALIZABLE: 가장 엄격한 격리 수준으로 완전한 테이블 락이 필요하다.

MVCC의 핵심은 언두 로그다. 언두 로그에는 레코드 변경 이전의 값이 저장되며, 트랜잭션 롤백이나 과거 시점의 데이터를 읽기 위해 사용된다.

4. 자동 데드락 감지

InnoDB는 내부적으로 잠금 대기 상태를 그래프로 관리한다. 특정 트랜잭션이 잠금 획득을 기다리는 구조가 순환되면, 이를 데드락으로 간주한다.

데드락이 발생하면 InnoDB는 자동으로 감지하여 트랜잭션 중 하나를 강제로 롤백시킨다. 이때 선택 기준은 롤백 비용이다. 언두 로그의 크기가 작고 처리 비용이 적은 트랜잭션을 우선 롤백시킨다.

이러한 기능 덕분에 개발자가 직접 데드락을 감지하고 처리할 필요는 없지만, 가능한 데드락이 발생하지 않도록 트랜잭션 순서와 잠금 범위를 정리하는 것이 좋다.

5. 자동 장애 복구

InnoDB는 MySQL이 비정상적으로 종료되었을 때도 자동으로 복구할 수 있는 기능을 제공한다. 서버 재시작 시 리두 로그를 기반으로 복구 과정을 수행하고, 미완료된 트랜잭션은 롤백된다.

다만, 물리적인 디스크 손상이나 로그 파일 손상이 발생한 경우 자동 복구가 실패할 수 있다. 이 경우 innodb_force_recovery 파라미터를 사용하여 수동으로 복구 과정을 유도해야 한다.

innodb_force_recovery = 1 # 최소 단계부터 시작, 최대 6까지

복구가 불가능하다면 마지막 백업 데이터를 사용하여 복원해야 한다.

6. InnoDB 버퍼 풀(Buffer Pool)

버퍼 풀은 디스크 I/O를 줄이기 위한 핵심 메모리 캐시다. 디스크의 데이터 페이지 및 인덱스 페이지를 메모리에 캐시해두고, 이 공간에서 직접 읽고 쓸 수 있다.

쓰기 작업은 즉시 디스크에 반영되지 않고, 버퍼 풀에서 일괄 처리된다. 변경된 페이지는 "더티 페이지"로 분류되며, 나중에 플러시 작업을 통해 디스크로 저장된다.

버퍼 풀은 LRU(Latest Recently Used) 기반으로 관리되며, 실제로는 Old 리스트와 New 리스트로 구분된다. 이는 일회성 대용량 쿼리로 인해 자주 사용하는 데이터가 캐시에서 밀려나지 않도록 하기 위한 구조다.

버퍼 풀의 크기는 innodb_buffer_pool_size로 조정할 수 있으며, 보통 전체 메모리의 50~70% 수준으로 설정한다.

7. 더블 라이트 버퍼(Double Write Buffer)

디스크에 데이터를 기록할 때 일부만 기록되어 발생하는 문제를 Partial Page Write, 또는 Torn Page라고 한다. InnoDB는 이를 방지하기 위해 더블 라이트 버퍼를 사용한다.

쓰기 작업은 먼저 더블 라이트 버퍼 영역에 기록되고, 문제가 없을 경우 실제 데이터 파일로 복사된다. 문제가 생기면 버퍼에 남아있는 데이터를 사용해 복구할 수 있다. 이는 신뢰성을 높이기 위한 추가적인 보호 장치다.

8. 언두 로그(Undo Log)

언두 로그는 레코드를 변경하기 전의 상태를 기록하는 공간이다. 주요 용도는 다음과 같다.

롤백 처리: 트랜잭션 도중 오류가 발생하면 변경 전 상태로 되돌리기 위해 사용된다.
MVCC 구현: 트랜잭션 간 일관된 읽기를 제공하기 위해 과거 버전의 데이터를 조회할 수 있게 한다.

언두 로그는 트랜잭션 커밋 이후에도 일정 시간 유지되며, 사용자가 트랜잭션을 커밋했더라도 다른 트랜잭션에서 아직 해당 데이터를 읽고 있다면 삭제되지 않는다.

9. 체인지 버퍼(Change Buffer)

인덱스를 가진 테이블에 대한 INSERT, DELETE, UPDATE 작업은 인덱스 페이지에 랜덤 I/O를 발생시킨다. 이때 디스크 접근을 줄이기 위해 InnoDB는 체인지 버퍼를 사용한다.

체인지 버퍼는 보조 인덱스에 대한 변경사항을 메모리에 먼저 저장하고, 나중에 디스크에 반영한다. 이 방식은 트랜잭션 처리 성능을 크게 향상시킬 수 있다.

10. 리두 로그(Redo Log)

리두 로그는 데이터베이스의 영속성을 보장하는 핵심 로그 파일이다. 트랜잭션이 커밋되면 해당 내용은 리두 로그에 먼저 기록된다.

이후 디스크의 실제 데이터 파일에 변경사항이 반영되지 않았더라도, 리두 로그를 사용하면 장애 발생 시 작업을 복원할 수 있다.

트랜잭션 커밋 시점에 리두 로그에 기록되면 "성공"으로 간주되며, 이후의 플러시 작업은 백그라운드에서 처리된다.

11. 어댑티브 해시 인덱스

InnoDB는 자주 사용되는 인덱스 접근 패턴을 감지하여 자동으로 해시 인덱스를 생성한다. 이를 어댑티브 해시 인덱스라고 한다.

B-Tree 구조를 타지 않고 해시값으로 직접 검색할 수 있기 때문에 쿼리 처리 속도가 개선된다. 단, 해시 인덱스는 메모리 기반이며, 인덱스 생성/삭제 자체가 오버헤드가 될 수 있다. 따라서 모든 경우에 유리한 것은 아니다.

[RealMySQL8.0] 사용자 및 권한

bill's tech log — Wed, 9 Jul 2025 10:46:28 +0900

사용자 식별 (Authentication)

사용자 계정은 사용자명 + 접속 지점(IP 또는 호스트)으로 구성된다. MySQL에서는 사용자 계정을 '사용자명'@'호스트명' 형태로 지정한다. 이때 호스트명은 실제 접속 위치(IP 주소 또는 호스트 이름)를 의미하며, 계정의 일부로 간주한다. 예를 들어 다음 두 계정은 서로 다른 계정이다.

'user'@'127.0.0.1'

'user'@'%'

%는 모든 IP 주소 또는 호스트에서의 접속을 허용한다는 의미이다.

중첩 계정과 우선순위

MySQL은 동일한 사용자명에 대해 접속 지점만 다른 계정이 여러 개 존재할 수 있다. 이 경우 접속 시점에 일치하는 계정을 찾을 때 보다 구체적인 호스트명(IP 주소 등)이 우선적으로 선택된다. 예를 들어 다음과 같은 두 계정이 있다고 가정한다.

'user'@'192.1xx.xx.xx' 비밀번호: 1234
'user'@'%' 비밀번호: 5678

이때 클라이언트가 192.1xx.xx.xx에서 접속한다면 비밀번호는 1234를 사용해야 하며, 5678을 사용할 경우 인증에 실패한다.

이는 범위가 좁은 계정이 우선순위를 가지기 때문이다.

접속된 사용자 계정과 실제 인증된 계정이 다를 수 있으므로, SELECT user(), current_user(); 명령어로 현재 사용자 정보를 확인할 수 있다.

시스템 계정과 일반 계정

시스템 계정

MySQL 8.0에서는 시스템 계정의 개념이 도입되었다. 시스템 계정은 SYSTEM_USER 권한을 가지며, 일반 사용자 계정과 달리 다음과 같은 작업이 가능하다.

다른 사용자의 세션 종료
권한 변경 및 계정 관리
스토어드 프로그램 작성 시 DEFINER로 지정 가능

이러한 시스템 계정은 주로 데이터베이스 관리자(DBA)를 위한 계정이다.

내장된 시스템 계정

MySQL은 기본적으로 몇 가지 내장된 시스템 계정을 제공하며, 이들은 모두 mysql. 접두사로 시작된다. 예를 들면 다음과 같다.

SELECT user, host, account_locked 
FROM mysql.user 
WHERE user LIKE 'mysql.%';

# 결과
+------------------+-----------+----------------+
| user             | host      | account_locked |
+------------------+-----------+----------------+
| mysql.infoschema | localhost | Y              |
| mysql.session    | localhost | Y              |
| mysql.sys        | localhost | Y              |
+------------------+-----------+----------------+

이들 계정은 삭제하거나 수정하지 않는 것이 원칙이며, 모두 account_locked 상태로 생성되기 때문에 보안 위협이 되지 않는다.

사용자 계정 생성 및 조회

MySQL 5.7 이전과 8.0의 차이점

MySQL 5.7까지는 GRANT 명령어 하나로 사용자 계정을 생성하고 권한까지 부여할 수 있었다.

하지만 MySQL 8.0부터는 반드시 CREATE USER 명령어로 계정을 먼저 생성한 후, GRANT 명령어로 권한을 부여해야 한다.

# 5.7 까지 사용가능한 구문 생성과 권한 부여를 동시에 진행 
GRANT ALL PRIVILEGES ON *.* TO 'test_user'@'%' IDENTIFIED BY '12345678';

# 8.0 이후는 아래와 같은 형식으로 CREATE USER -> GRANT 형식으로 사용해야한다
CREATE USER 'test_user'@'%' IDENTIFIED WITH mysql_native_password BY 'password';
GRANT ALL PRIVILEGES ON *.* TO 'test_user'@'%';

사용자 목록은 다음과 같은 명령어로 조회할 수 있다.

SELECT user, host FROM mysql.user;

인증 플러그인

MySQL 8.0에서는 기본 인증 플러그인이 caching_sha2_password로 변경되었다. 기존의 mysql_native_password보다 보안이 강화되었으며, SSL/TLS 또는 RSA 키를 필요로 한다. 현재 기본 인증 방식을 확인하려면 다음 명령어를 사용한다.

SHOW GLOBAL VARIABLES WHERE Variable_name LIKE 'default_authentication_plugin';

해당 변수는 읽기 전용이기 때문에 런타임 중 변경이 불가하다. 특정 사용자 계정의 인증 방식을 변경하려면 아래와 같이 개별 설정을 해주어야함.

ALTER USER 'user'@'%' IDENTIFIED WITH mysql_native_password BY 'new_password';

권한 관리 (Privilege)

권한의 종류

MySQL에서는 권한을 크게 두 가지로 나눈다.

정적 권한: 서버에 기본 내장된 권한 (예: SELECT, INSERT, CREATE)
동적 권한: 서버 실행 중 플러그인이나 구성 요소가 등록하면서 생성되는 권한 (예: SYSTEM_USER, BINLOG_ADMIN)

MySQL 8.0부터는 5.7에서 하나였던 SUPER 권한이 여러 동적 권한으로 나뉘어졌다.

권한 부여는 GRANT 명령어로 수행한다. 권한 범위에 따라 다음과 같이 지정한다.

글로벌 권한

GRANT SUPER ON *.* TO 'user'@'%';

데이터베이스 권한

GRANT SELECT, INSERT ON mydb.* TO 'user'@'%';

테이블 권한

GRANT SELECT ON mydb.customers TO 'user'@'%';

현재 계정이 가진 권한 확인

SHOW GRANTS FOR 'user'@'%';

역할(Role)

MySQL 8.0부터는 역할(Role) 기능이 도입되었다. 역할은 권한 묶음을 의미하며, 여러 권한을 하나의 단위로 관리할 수 있다.

역할 생성 방법

CREATE ROLE 'role_read_only'@'localhost';

역할은 사용자 계정과 동일하게 mysql.user 테이블에 저장되며, 생성 시 account_locked = Y 상태로 설정된다.

역할에 권한 부여

GRANT SELECT ON employees.* TO 'role_read_only'@'localhost';

역할을 사용자에게 부여

GRANT 'role_read_only'@'localhost' TO 'reader'@'127.0.0.1';

세션 내에서 역할 활성화

SET ROLE 'role_read_only'@'localhost';

기본 역할 지정

SET DEFAULT ROLE 'role_read_only'@'localhost' TO 'reader'@'127.0.0.1';

기본 역할이 지정된 사용자는 로그인 시 자동으로 해당 역할이 활성화된다.

정리

MySQL 8.0은 사용자 및 권한 관리 체계가 보다 보안 중심으로 개선되었으며, 역할 기반 권한 관리와 인증 플러그인의 다양화 등으로 유연성과 안정성을 함께 갖추게 되었다. 실습 환경에서는 인증 방식의 호환성(기존 5.7을 사용하고 있다고 가정할 때 )을 고려해mysql_native_password를 사용하는 것이 편리할 수 있으며, 운영 환경에서는 보안을 위해 기본 방식인 caching_sha2_password를 사용하는 것이 바람직하다.

[RealMySQL 8.0] 역사 & 설정

bill's tech log — Tue, 8 Jul 2025 09:38:11 +0900

역사

MySQL은 1979년 스웨던의 TcX사의 터미널 인터페이스 라이브러리인 UNIREG로 부터 시작되었고, UNIREG라는 라이브러리가 1994년 웹 시스템의 테이터베이스로 사용하기 시작하면서 MySQL 1.0 버전이 완성되어 사내에서 사용되다 1996년 최초로 공개되었다.

2000년대에 TcX사에서 MySQL을 개발한 몬티와 데이빗이 MySQL AB라는 회사로 독립하여, FPL(Free Public License)정책으로 바꾸고 2006년 최종적으로 엔터프라이즈(별도의 라이선스 계약이 필요하며 추가 기능 및 지원을 제공), 커뮤니티(별도의 라이스선 계약없이 일반 사용자가 내려받아 사용하는 버전) 정책을 취하게 되었다.

MySQL은 개인 및 기업 사용자가 웹 애플리케이션을 위한 강력 하면서 비용 효율적인 데이터베이스 솔루션을 필요로 하는 시기에 탄생하였다. 초기 MySQL을 개발한 MySQL AB 사는 속도와 효율성을 최대화 하면서 사용 용이성을 제공하는 것을 목적으로 두었다.

이후 MySQL AB사는 썬 마이크로시스템즈에 인수되고, 다시 오라클로 인수됐으나, 특별한 라이센스 정책 변화는 없었고 MySQL 5.5 버전부터 5.7 버전까지 안정성과 성능 개선에 집중을 하였으며, 8.0 버전부터 상용 DBMS가 가지고 있는 기능들이 장착되기 시작하였다.

버전

버전 선택가이드
- MySQL 서버의 버전 선택시 최신 버전을 설치하는것이 좋음.
- 기존 버전에서 새로운 메이저 버전으로 업그레이드 하는 경우 최소 패치 버전이 15 ~ 20번 이상 릴리스된 버전을 선택하는 것이 서비스 안정화에 도움이 됨.
  - MySQL 버전이 8.0일 경우 MySQL 8.0.15 ~ 8.0.20 사이의 버전부터 시작하는것을 권장.
  - 단, 갓 출시된 메이저 버전 선택은 삼가하는게 좋음.
엔터프라이즈 VS 커뮤니티 에디션의 차이
- 5.5 버전 이전에는 기술지원에 차이만 있었으나, 이후에는 소스코드도 달라졌고 엔터프라이즈의 소스코드는 비공개로 처리됨.
- 5.5이후 부가적인 기능들 및 서비스들을 지원. ( 상세 내용은 추후 각 파트에서 정리 예정 )
  - Thread Pool
  - Enterprise Audit
  - Enterprise TDE
  - Enterprise Authentication
  - Enterprise Firewall
  - Enterprise Monitor
  - Enterprise Backup
  - MySQL 기술 지원

MySQL 서버의 시작과 종료

각 OS에 맞춰서 CLI로 MySQL 서버를 설치를 완료하면 systemctl 유틸리티를 사용하여 MySQL을 가동하거나 종료하는것이 가능하다. ( 유닉스 계열에서만, 윈도우는 별도로 등록을 시켜야함 )

!아래와 같이 systemctl 커맨드로 MySQL 서버의 시작 종료 상태 값등을 확인할 수 있음.

# start mysql server
$sytstemctl start mysqld

# check mysql server status 
$systemctl status mysqld

# stop mysql server 
$systemctl stop mysqld

# shutdown 권한이 있을 경우 systemctl이 아니라 직접 MySQL 서버에 접속해서 shutdown 가능 
mysql > SHUTDOWN;

MySQL 서버 연결 테스트

3가지 방식을 통해서 MySQL 서버에 접속할 수 있다.

#MySQL 소켓 파일을 통한 접속 
$mysql -u root -p --host=localhost --socket=/tmp/mysql.sock

#TCP/IP를 통해 접속 ( 원격 호스트에 접속시 반드시 TCP/IP 기반으로 접근이 필요 ) 
$mysql -u root -p --host=127.0.0.1 --port=3306

#별도의 호스트 주소와 포트를 명시하지 않는 접속 
$mysql -u root -p

위와 같은 방식으로 접근 완료 후 SHOW DATABASE 명령어를 통해서 데이터베이스 목록을 확인할 수 있다. 위와 같은 방식이 아니라 Telnet이나 Netcat 와 같은 프로그램을 통해서도 MySQL 서버의 접속 테스트를 해볼 수 있다.

MySQL 시스템 변수

MySQL 서버가 시작되면 설정파일의 내용을 읽어 메모리나 작동 방식으 초기화하고 접속된 사용자 제어를 위하여 특정한 값들을 저장하는데 이를 시스템 변수라고 한다. 아래와 같은 명령어로 확인할 수 있다.

SHOW GLOBAL VARIABLES;

시스템 변수값이 MySQL 서버 및 클라이언트에 영향을 미치는지 판단하기 위해서 각 변수가 글로벌 변수인지 세션 변수인지 구분할 수 있어야한다. 또한 시스템 변수가 가지는 속성값이 있는데 각 속성값에 대해서 정리하면 아래와 같다.

Cmd-Line: MySQL 서버의 명령행 인자로 설정될 수 있는지 여부를 나타내는 지표로 해당 값이 'YES'로 되어있으면 명령행 인자로 이 시스템 변수의 값을 변경하는것이 가능하다는 의미로 통함.
Option file: MySQL의 설정 파일인 my.cnf로 제어할 수 있는지 여부를 나타내는 지표로 옵션 파일이나 설정 파일 똔느 컨피규레이션 파일 등은 전부 my.cnf 파일을 지칭하는 것으로 같은 의미로 사용된다.
System Var: 시스템 변수인지 아닌지를 나타내는 지표로 사용된다.
Var Scope: 시스템 변수의 적용 범위를 나타내는 지표로 해당 시스템 변수가 영향을 미치는 곳이 MySQL 서버 전체를 대상으로 하는지 MySQL 서버와 클라이언트 간의 커넥션만인지 구분하는 용도로 구분하는 옵션값이다. 서버 전체를 대상으로 할 경우 Global, 세션대상은 Session, 세션과 글로벌 범위에 모두 적용(Both)로 처리되기도 한다.
Dynamic: 시스템 변수가 동적인지 정적인지 구분하는 변수이다.

글로벌 변수와 세션 변수

글로벌 변수 :

서버 전체에 적용되는 변수
모든 사용자 세션이 동일하게 영향 받음
일반적으로 SET GLOBAL 명령으로 변경
변경은 즉시 적용되지만 서버 재시작 시 초기화
SET PERSIST를 이용해 지속 가능
예시

SHOW GLOBAL VARIABLES LIKE 'max_connections';

SET GLOBAL max_connections = 300;

세션 변수 :

특정 사용자의 현재 연결 세션에만 적용
다른 사용자나 세션에는 영향을 주지 않음
SET SESSION 또는 단순 SET으로 변경 가능
세션 종료 시 사라짐 (휘발성)
기본값은 글로벌 변수를 따름
예시

SHOW SESSION VARIABLES LIKE 'sql_mode';

SET SESSION sql_mode = 'STRICT_ALL_TABLES';

정적 변수와 동적 변수

정적 변수 :

서버 시작 시에만 설정 가능
서버 실행 중에는 변경 불가
변경하려면 my.cnf 수정 후 서버 재시작

동적 변수 :

서버 실행 중에도 SET 명령으로 변경 가능
글로벌 또는 세션 단위로 변경 가능
일부는 SET PERSIST로 영구 저장도 가능
- SET 명령어로만 구동중인 MySQL 서버에서 반영을 하고, 서버를 재시작하면 반영이 안되기 때문에, SET PERSIST 명령어로 처리해야됨. MySQL 8.0 버전 이상 부터 지원.

참고문헌

Real MySQL 8.0 (1권) | 백은빈 - 교보문고

Real MySQL 8.0 (1권) | MySQL 서버를 활용하는 프로젝트에 꼭 필요한 경험과 지식을 담았습니다!《Real MySQL 8.0》은 《Real MySQL》을 정제해서 꼭 필요한 내용으로 압축하고, MySQL 8.0의 GTID와 InnoDB 클러스

product.kyobobook.co.kr

[RealMySQL 8.0] Intro

bill's tech log — Wed, 2 Jul 2025 10:45:41 +0900

Real MySQL 8.0 (1권) | 백은빈 - 교보문고

product.kyobobook.co.kr

나는 아직 저연차 개발자이지만, 정말 운이 좋게도 회사에서 많은 책임과 권한을 부여받게 되었다.
그 이유는 서비스의 초기 멤버로 합류하여, 기획 단계부터 개발, 출시까지 전 과정을 함께했기 때문이다.

초기 MVP부터 시작하여 1차, 2차 기능 개발을 거쳐 상용화까지 진행한 애플리케이션이 현재 실제 사용자에게 제공되고 있으며, 운영과 유지보수까지 전반을 맡고 있다.

현재 구성된 백엔드 애플리케이션은 일부 Lambda 함수를 제외하고는 모두 ORM 기반으로 구축되어 있다.

ORM을 사용하면서 생산성, 마이그레이션 관리, 반복 로직 추상화 등 많은 편의성을 체감할 수 있었지만, 운영 환경에서는 ORM이 항상 이상적으로만 작동하는 것은 아니라는 점도 느꼈다. 복잡한 비즈니스 로직을 처리하는 과정에서 ORM이 예상과 다르게 동작하거나, 라이브러리에 지나치게 의존하는 구조로 인해 불편함을 겪은 적이 많았다. ( 그렇다고 ORM이 싫다는 이야기는 아니다 )
복잡한 쿼리를 작성해야 할 경우에는 결국 raw query를 작성하거나 유사한 방식으로 직접 로직을 구현해야 했기 때문이다.

또한, 마이그레이션 과정에서도 몇번의 식은땀을 흘렸던 경험도 있었는데 예를 들어, 단순한 필드 변경을 의도하여 마이그레이션을 시도했으나, ORM이 이를 ALTER가 아닌 DROP - CREATE 방식으로 처리하면서 일부 필드가 날아가는 이슈도 있었다. ( 다행히 밤 시간 때 진행을 했고 RDS에서 1분 단위로 백업을 해두고 있어서 다행히 실질적인 데이터 Loss는 없었다.. )

이러한 경험을 통해, 단순히 데이터를 CRUD하는 수준을 넘어서, 실제로 데이터를 안전하게 다루고 효율적으로 저장하는 것의 중요성을 많이 느끼게 되었다. 서비스가 성장함에 따라 대용량 이벤트 처리나 캐시 전략, 애플리케이션 구조 설계등도 중요했지만, 그보다 우선적으로 고려해야 할 것은 데이터베이스 처리 및 관리가 더 중요하다고 느꼈다. 데이터베이스 구조와 성능, 확장성, 운영 전략이 서비스 전체 안정성과 직결된다고 판단했기 때문이다.

이러한 문제의식과 필요성으로 인해 《Real MySQL 8.0》이라는 책을 읽고, 그 내용을 정리하여 블로그에 기록하려고 한다. 단순히 책 내용을 읽기만 하는 것이 아니라, 실무에서 겪은 문제들과 연결하여 실제로 어떻게 활용될 수 있는지를 고민하며 정리하고자 한다.

[TypeORM] cross-env 환경에서 마이그레이션 하기

bill's tech log — Sun, 13 Apr 2025 19:31:29 +0900

ORM을 사용하면 SQL 질의어 없이 코드로 테이블을 정의하고 관리할 수 있다. Node 진영에서 많이 사용하는 TypeORM 또한 이와 마찬가지로 편리한 기능들을 제공한다. 마이그레이션은 데이터베이스 스키마의 변경사항을 버전 관리하고 적용하는 과정으로, 개발 과정에서 데이터베이스 구조가 변경될 때마다 안전하게 업데이트할 수 있게 해준다. 특히 팀 단위 개발이나 여러 환경(개발, 스테이징, 프로덕션)에서 일관된 데이터베이스 구조를 유지하는 데 필수적이다. 오늘은 평소에 TypeORM을 사용할 때 내가 사용하는 마이그레이션 방식에 대해서 정리하고자 한다.

마이그레이션 방식 설명에 앞서 TypeORM은 0.3.20 버전을 사용중이고 NestJS는 10.x.x 버전을 기준으로 작성했다. 추가로 cross-env 환경에서 스테이징, 프로덕션으로의 마이그레이션 과정을 다룰 예정이다. 보통 스테이징은 로컬에 컨테이너나 직접 데이터베이스를 설치한 이후 synchronize: true로 관리할 수도 있지만, 현재 회사에서는 별도의 스테이징 DB와 프로덕션 DB를 클라우드에서 분리시켜서 사용하고 있기 때문에, 두가지 케이스에서 마이그레이션을 진행할 때 주의해야 되는 부분도 다룰 예정이다.

추가로 ts-node를 기반으로 마이그레이션 하는 방식을 공식문서나 여러 블로그에서 정리해둔 내용들이 많이 있는데, 이번 글에서는 ts-node를 사용한 마이그레이션 방식을 다루지 않을 예정이다. 대신 TypeORM CLI를 활용하여 컴파일된 JavaScript 파일 기반으로 마이그레이션을 진행하는 방법을 설명할 것이다.

TypeORM CLI 설치

마이그레이션을 진행하고자 하는 환경에서 TypeORM CLI를 설치한다.

# 전역 패키지로 TypeORM을 설치
$npm i -g typeorm 

# 설치 확인
$typeorm -v

패키지 및 환경설정 세팅

NestJS 프로젝트 내부 경로에 data-source.ts 파일을 생성한다. data-source.ts 파일을 기점으로 마이그레이션을 관리한다. 필자는 위에서 cross-env 환경에 맞춰서 마이그레이션을 관리한다고 했다. 그렇기 때문에, cross-env 패키지를 설치하고, data-source.ts 파일에서 현재 환경에 맞는 .env 파일을 load하고 그에 맞춰서 마이그레이션을 진행할 것이다.

data-source.ts 파일 생성

$pnpm i dotenv
$pnpm i cross-env 
$touch .env.development .env.production

위와 같이 cross-env, dotenv 패키지를 설치하고, 각각의 환경에 맞는 .env 파일을 생성 후 환경변수를 기입한다. (환경변수 기입 내용은 각각 스테이징, 프로덕션 환경에 맞춰서 기입해주면 된다.)

import { DataSource } from 'typeorm';
import * as dotenv from 'dotenv';

/** staged production 환경에 따른 마이그레이션 파일 셋업 */
if (process.env.NODE_ENV === 'development') {
  console.log('migration development environment');
  dotenv.config({ path: './.env.development' });
} else {
  console.log('migration production environment');
  dotenv.config({ path: './.env.production' });
}

export default new DataSource({
  type: process.env.DB_ENGINE as 'mysql',
  host: process.env.DB_HOST,
  port: Number(process.env.DB_PORT || '3306'),
  username: process.env.DB_USER,
  password: process.env.DB_PASSWORD,
  database: process.env.DB_NAME,
  synchronize: false,
  logging: false,
  entities: ['dist/**/*.entity.js'],
  migrations: ['dist/db/migrations/*.js'],
  migrationsTableName: 'migrations',
  migrationsRun: false,
});

패키지 설정과 환경변수 세팅이 완료되면 data-source.ts 파일에 위와 같이 작성한다.
실제 마이그레이션 진행시 cross-env 환경에 맞춰서 .env 파일을 다르게 가져와서 진행한다.

Migration 실행 스크립트 작성

package.json

"scripts": {
... 생략
	"migration:generated:dev": "NODE_ENV=development typeorm migration:generate ./src/database/migrations/init -d ./dist/database/data-source.js",
	"migration:generated:prod" : "NODE_ENV=production typeorm migration:generate ./src/database/migrations/init -d ./dist/database/data-source.js"
    }

typeorm cli를 사용하면 별도로 DDL(Data Definition Language) 없이 Entity의 변경 사항을 캐치해서 migration 파일을 생성해준다. 마이그레이션 시 매번 스크립트를 입력하기 귀찮기 때문에 프로젝트 package.json 파일에 위와 같이 generate 스크립트를 cross-env 환경에 맞춰서 생성되도록 정의한다.

이후 실제 터미널에 cross-env 환경에 맞는 generated 명령어를 입력한다.

$pnpm migration:generated:dev # 스테이징용 generated 파일 로드 
$pnpm migration:generated:prod # 프로덕션용 generated 파일 로드

generate 명령어가 정상적으로 실행되면, 아래와 같이 migrations 파일이 생성된다. 파일명은 현재 시간의 타임스탬프(UNIX 시간)를 기준으로 생성되며, 이를 통해 마이그레이션이 실행되는 순서를 보장한다.

cli 명령어로 생성된 migrations 파일

최종적으로 generated로 생성된 파일에서 정상적으로 DDL 구문이 작성이 완료되었다면, migration을 각 cross-env 환경에 맞춰서 실행 하기 위해 package.json 파일에 아래와 같이 스크립트를 작성한다.

"scripts": {
... 생략

	"build:dev": "NODE_ENV=development nest build",
	"build:prod": "NODE_ENV=production nest build",
	"migration:run:dev": "pnpm run build:dev && typeorm migration:run -d ./dist/db/data-source.js",
	"migration:run:prod": "pnpm run build:prod && typeorm migration:run -d ./dist/db/data-source.js"

    }

dist 파일에 data-source.ts 파일을 기반으로 마이그레이션이 진행되기 때문에, 스테이징 & 프로덕션 환경에 맞춰서 마이그레이션을 실행하면, 각 환경에 맞춰서 마이그레이션이 정상적으로 이루어진다. (스크립트 내부에 별도의 build 명령어로 dist 폴더 내부에 data-source.js 파일을 생성)

위와 같은 방식으로 진행하면, 좀 번거롭지만 실제 프로덕션에 변경사항을 배포하기 이전에 스테이징에서 안정적으로 체크를 하고 반영할 수 있고, CI/CD 파이프라인을 구성할 때도 유용하기 때문에 위의 방식을 선호하는 편이다.

처음 작성해보는 백엔드 개발자의 2024년 회고

bill's tech log — Mon, 6 Jan 2025 20:26:02 +0900

올해는 집 앞 바다쪽에서 새해를 맞이했다.

재작년인 2023년 10월을 기준으로 백엔드 개발자로서 커리어를 시작하였고, 벌써 2025년이 되었다. 이제 횟수로는 2년차 주니어 개발자가 되었다

평소 블로그에 개인적인 내용보다는 공부한 내용을 정리하거나 문제를 해결한 내용들에 대해서만 작성을 했기 때문에, 회고나 개인적인 내용들을 작성하는 게 조금 어색(?)하지만 오늘을 토대로 앞으로는 개인적인 내용도 가끔 작성해볼까 한다.

회고라는 것을 처음 해봐서 어떻게 시작할지 몰라 인터넷에 여러 글을 찾아보니 인프런 블로그에 올라온 '개발자의 공유 문화 이모저모 회고문화'라는 글과 '어쩐지 오늘은'이라는 블로그 운영자인 변성윤 님의 '회고에 대한 생각'이라는 글을 참고하였다. 나처럼 처음 회고를 시작하는 분들이라면 저 2개의 글을 참고하는 것도 좋을 것 같다.

회사

퇴사와 입사

개인적인 사유로 10월에 첫 입사한 회사를 1개월 만에 퇴사하고 지인의 소개로 현재 다니고 있는 회사에 입사했다.
현재 다니는 회사는 교육계열 스타트업이고 2인 체제로 개발을 하게 되었다. (프론트엔드 개발자 1명, 백엔드 개발자 1명) 나는 회사에서 백엔드 개발 및 인프라 개발을 담당하게 되었다.

기존에 프론트엔드 개발자분이 rawQuery + Express 기반으로 혼자서 방과후 학교 운영에 필요한 플랫폼 MVP 개발을 진행 중이었고, 시장 반응이 괜찮아서 전문 백엔드 인력으로 내가 채용이 된 것이었다. 회사에 처음 입사를 하자마자 기존 소스코드를 받았을 때, 어느 정도 예상은 했지만 정리가 안된 부분이 많이 있었다. 프론트엔드 개발자분께서 프론트엔드 개발과 더불어 백엔드 개발도 동시에 함께 진행을 했기 때문에, 그렇다고 생각이 들었다. 회사 스택은 인력이 부족했기 때문에 기존에 내가 다룰 줄 알았던 Java Spring이나 PHP은 꿈도 꾸지 못했다.

프론트엔드에 공백이 생기면 내가 프론트엔드에 투입이 되어야 했고, 담당하는 백엔드에 공백이 생길 경우 프론트엔드 개발자 분이 컨트롤할 수 있어야 했기 때문에, 백엔드 기술선정에 있어서는 크게 고민을 하지 않고 Javascript 기반으로 선택했던 것 같다.

입사와 동시에 회사에서 우리가 만들고 있는 제품을 빠르게 론칭해야 했고 정해진 기간이 있었기 때문에 매일 야근에 주말 출근은 일상이었던 거 같고, 밤도 여러 번 샜던 거 같다. 몸은 힘들었지만, 서비스 요구사항 분석 및 기획부터 쌓아 올린 프로젝트라 애정도 많이 생겼고 실시간으로 실력과 손이 빨라지는 것을 느껴서 시간 가는지 모르고 개발했던 것 같다. 회사에서도 개발팀에 거는 기대가 컸기 때문에, 그에 맞는 기대에 부응하기 위해서 더 열심히 노력했다.

서비스 출시

약 4개월간 MVP 개발부터 서비스 1차 출시까지 진행을 완료하고, 시장에 서비스를 처음 소개했을 때, 생각보다 큰 기업들과 학교들에서 반응이 좋아서 나름 뿌듯했다. 또한 고객층인 방과후 학교 운영 관리자님들을 직접 만나서 인터뷰도 진행하고 요구사항을 들으면서 부족한 점을 보완해 나가고 다양한 기획을 제시하면서 다양한 경험치를 쌓았다. 서비스 출시 후 설계한 발송 아키텍처에서 문제가 있어 실시간으로 이슈 대응도 해보고, 디자인 업체와 미팅 및 협업, 기획 전문 에이전시와 협업등 정말 스타트업이 아니면 해볼 수 있는 다양한 기회를 경험했다.
또한, 1차 출시에서 부족한 점을 보완하여 vanilajs 기반의 express 서버의 백엔드 구조를 typescript 기반의 nest.js + typeorm으로 전체 마이그레이션에도 성공적으로 구성했다. 또한, 앱 서비스 출시에 맞춰 주도적으로 ReactNative를 검토하여 기업용(android, ios) 계정을 생성하고 개발환경 구축부터 배포 + fastlane 기반 자동화까지 진행하였다. 또한 각 파트별로 형상관리가 잘 안 되고 있는 부분들도 Git Branch 전략을 사용하여 서로 다른 파트여도 리뷰 및 버전관리가 가능하도록 도입하였다. 1년 남짓한 기간 동안 시니어 없이 주도적으로 성장하기 위해서 나름에 노력을 했던 것 같다.

갈등 및 아쉬운 점

위에서는 잘한 점들만 주야장천 나열한 것 같은데, 마냥 좋지만은 않았다. 회사 & 동료와의 갈등도 있었고 개인적으로도 아쉬운 점도 많이 있었다.

우선 첫 번째로 회사일이 정말 너무 바빴다. 외주인력 관리와 개발, 미팅등 다양한 업무를 밤낮없이 주구장창 하다 보니 항상 즐겁게 일할 수만은 없었다. 프론트엔드 개발자분과 가장 많이 소통하고 일했기 때문에, 마감기한이 다가오고 업무가 쌓이면 서로가 예민해지면 상대방에 대해서 서로 배려해줄 수 있는 부분들을 놓쳤던 부분들이 꽤 있었던 것 같다. 일이 바쁘면 소통을 할 때, 더욱 신중하게 해야 되는데 서로가 너무 일에만 집중해서 놓치는 부분들이나 생각 없이 말하는 부분들도 없지 않아 있었다. 다행히 서로 대화로 잘 풀어나가서 마무리를 잘했지만, 이번일을 계기로 바쁘고 예민할 때, 더 신중하게 소통하고 더 이야기를 많이 해야 되는 것을 배웠다.

두 번째는 회사와의 소통의 부재이다.

회사에서 중간 관리자가 없이 대표님과 다이렉트로 소통을 했기 때문에, 온전히 개발뿐만 아니라 비개발자 대표님을 설득하는 부분에서도 커뮤니케이션 비용이 많이 들었다. 예를 들어 왜 온프레미스로 서비스를 구축하지 않고 클라우드에 서비스를 구축해야 하는지, 클라우드 비용이 얼마나 나오고 얼마만큼의 트래픽을 버틸 수 있는지. 그밖에 디자인이나 기획 등등 개발자로서 설명하기 모호한 부분들까지 비개발자 입장에서 설득이 되도록 설명하기 어려운 부분들이 많이 있었던 것 같다.

평소 개발자들 간의 소통, 개발 공부와 아키텍처에만 관심을 가졌지, 비개발직군과의 소통에 대해서는 크게 생각하지 않았던 거 같다. 실제 실무를 경험해 보니, 개발 실력과 더불어 유사 개발 직군 인원들과의 소통보다는 비개발직군 인원들과 소통할 일도 더러 많다는 것을 알았고 이 부분이 많이 부족하다는 것을 느꼈다.

이러한 문제들을 스스로 개선하기 위해 소통에 앞서 글로 미리 정리하고 검토하는 프로세스를 추가하기도 했고, 비개발직군의 사람들과 소통할 때 먼저 나서서 주도적으로 소통하기 위해 노력했다. 개인적으로 아직 부족하고 매끄럽지 않다고 생각되지만 최근 소통에 있어서 “덕분에 잘 이해할 수 있었다”, “설명을 친절하게 해 주니까 더 이해가 빠르다” 는 등의 피드백을 받고 있다. 요즘 들어 많이 드는 생각은 개발자로서 개발만 잘하면 안 된다라는 생각이다.

개발자에게 개발이란 도구는 하나의 수단일 뿐이지 얼마만큼 비즈니스적으로 사고하고 문제를 해결하는지가 더 중요하다고 생각한다. 이러한 부분에 있어서 소통은 기본인데 지금까지 소통이라는 단어를 너무 쉽게 생각하고 있었다는 자신을 되돌아보게 되었고 소통에 대해서 배울 수 있었다.

마지막은 속도 중심적으로 빠르게만 개발을 해서 개발적으로 놓친 부분이 많은 부분이다.

결론부터 말하면 mvp 개발은 대략 1개월 서비스 1차 출시는 2-3개월 2차 출시는 3개월이 걸렸다. 이 기간 내에 온전히 개발만 한 것이 아니라 디자인, 기획, 미팅, 채용 등을 포함해서 진행을 했다. 그러다 보니 많은 기능들을 정말 빠르게 개발을 했지만 코드적으로 todo 주석만 70-80개가 되기도 했고, 클라우드 인프라 적으로도 아쉬운 부분이 많이 있었다. 회사에서 정해진 기간과 원하는 방향성이 있었기 때문에 어쩔 수 없이 더 좋은 구조와 코드가 무엇인지 알았는데도 시도조차 해보지 못하고 그대로 출시한 것이 불안하기도 하고 아쉬운 부분이 많이 남았다. 이전에 1년 가까이 6명의 개발자 팀원들과 창업 프로젝트를 진행했을 때, 기획 - 디자인 - 개발 - 테스트 - 출시 - 유지보수 프로세스를 잘 지키면서 운영이 되었는데, 실제 프로덕트 단계에서는 온전하게 원하는 방향대로만 흘러가지 못하는 상황이 많은 것을 느꼈다.
이런 부족한 부분들을 개선하기 위해 개인적으로 노력한 부분은 회사에 강력하게 어필을 하여, 주요 api의 부하테스트를 할 수 있는 기간을 확보했고 테스트 기간 동안에 발견한 이슈들로 인한 전체 서비스 리팩토링 기간을 확보했다. 이 과정에서도 소통이 정말 중요하고 현재 부족한 부분이 정확하게 무엇이고 명확하게 전달하는 과정이 중요하다는 것을 알았다.

개인적으로는 개인 시간에 회사 아키텍처 설계(푸시 알림 아키텍처 개선 발송 예약 아키텍쳐 등..) 및 부족한 공부(테스트 코드 작성, 모니터링 방식 설계..)를 진행했다.

개인 활동 및 프로젝트

스터디 및 개인 공부

회사 업무 외에도 개인적으로 스터디 운영과 개인 공부를 꾸준히 하였다. 회사에 입사하고 javascript에 대해서 아직 많이 모르고 부족하다고 느꼈다. 백엔드 개발자라고 하면 java 나 kotlin, go 등의 언어를 더 봐야 되지 않을까 생각할 수도 있지만, 현재 상황에 맞는 공부를 조금 더 집중적으로 하는 게 중요하다고 생각했다.

아무래도 주변에 백엔드 개발을 하는 사람들 중에서 node를 메인 스택으로 잡고 하는 사람보다 java를 메인으로 하는 사람들이 많이 있었기 때문에, 프론트엔드 개발자 2분을 구해서 modern javascript deepdive 책을 바탕으로 스터디를 운영했다.

9월말 부터 시작해서 느리더라도 꾸준하게 기록하면서 운영중이다

각자 격주에 한 번 하나의 chapter에 대해서 책을 위주로 공부하고 정리 후 한 명씩 돌아가면서 발표하는 시간을 가졌다. 정해진 틀없이 정리하고 이야기를 나누는 것보다 확실히 돌아가면서 발표를 진행하고 서로 피드백을 하는 것이 더 몰입도 잘 되고 팀원들이 준비해 오는 내용이 좋았다. 현재 딥다이브 스터디는 순조롭게 잘 진행되고 있고, 올해 초중순까지 모든 챕터를 1 회독하고 정리하는 것을 목표로 하고 있다.

중간중간 빵꾸(?)가 보이지만 커밋도 꾸준히 하려고 노력했다.

스터디 운영뿐만 아니라, 개인 공부도 꾸준하게 하였다. 적어도 하루에 알고리즘은 1문제 이상 풀려고 노력했고, NestJS와 ORM, 클라우드와 데이터베이스를 집중적으로 공부했다. 개인 공부는 미래에 대한 준비이기도 하지만 현재에 업무를 더 잘 수행하고 실무를 하면서 부족했던 부분들을 채워나가기 위한 생각이 있었기 때문에, 실무에서 고려해야 되는 내용들을 위주로 공부하였다.

개인 공부를 하면서 연습했던 Lambda 기반 이미지 리사이징 방식이나 AWS SNS-SQS 등을 활용한 Event-Driven 아키텍처를 회사 서비스에 적용해보기도 했다. 공부한 내용을 직접 만들어 보고 직접 실무에 적용까지 해보면서 느낀 점은 무엇이 되었건 겁먹고 보수적으로 검토만 하는 것보다, 뭐가 되었든 간에 일단 만들어서 적용시켜보고 부족한 점은 그때그때 보완해 나가면서 개선하는 게 중요하다는 생각이 들었다. 이전에는 기술 검토에 있어서 조금 보수적이고 검토만 주구장창 했었는데, 과감하게 시도해 보고 적용을 해보니, 부족한 부분을 빠르게 피드백받을 수 있었고 더 괜찮은 방향으로 나아가는 것을 알 수 있었다.

사이드 프로젝트 운영

개인 공부뿐만 아니라 프론트엔드 개발자 2명과 디자이너 2명을 구해서 사이드 프로젝트도 진행했다.( Node 직군의 백엔드 개발자는 구하지 못해서 함께 협업하지 못하고 혼자 진행을 했다 )

프로젝트 주제는 모든 팀원들이 관심 있고 재밌어하는 주제를 기반으로 선정하여 진행했다. 이전에 기획만 많고 기능 개발만 주구장창 했을 때, 프로젝트가 오래 유지되지 못한 경험이 있었기 때문에, 어려운 기능 구현 위주의 개발보다는 애정을 가지고 재밌게 만들 수 있는 프로젝트를 진행하는 게 좋을 것이라고 판단했다.

우리가 선정한 주제는 요즘 본인이 좋아하는 맛집들을 구글이나 네이버 맵과 같은 플랫폼에 좌표를 찍어서 개별로 저장하고 서로 공유하는 경우가 많이 있었는데, 이를 바탕으로 지도를 이용하여 개인의 다녀왔던 맛집에 대한 내용을 기록하고, 분류하여 내가 좋아하는 음식점을 기록하고, 음식 취향에 대해서 그래픽으로 표현하고 공유하는 형태의 내용으로 프로젝트를 진행하면 재밌을 것 같다는 생각이 들었다. 앱을 사용하는 유저가 음식점을 기록하는 공룡이라는 컨셉을 잡고, 기획부터 디자인까지 진행 중이다. 회사 업무와 공부도 함께 병행하면서 진행하고 있어서 속도가 조금 더디긴 하지만, 같이 작업하는 분들과 재밌게 소통하고 개발하고 있어서 올해 초중순 출시를 목표로 개발 중에 있다.

아직 개발 초기 단계에 있지만 캐릭터나 디자인이 아기자기 하고 귀여워서 애정이간다!

건강

올해는 건강이 많이 안 좋아졌다. 목 디스크나 허리 디스크가 좀 심해진 것 같고, 회사 다니기 전에는 운동도 열심히 했는데.. 일주일에 1~2회 정도밖에 운동을 하지 못했다. 올해는 공부나 개인 성장도 중요하지만 건강을 우선적으로 챙겨야겠다는 생각이 든다.

맺음말

회고라는 것을 작성하다 보니, 작년 한 해에 대해서 다시 돌아보게 되었고, 잘한 점과 못 한점 개선해야 될 점에 대해서 다시 한번 상기하고, 정리할 수 있는 시간이었다. 평소 기록은 개인 노션에 열심히 했지만 블로그에 각 잡고 작성하는 부분에 있어서는 취미가 크게 없었는데, 막상 회고록을 작성하다 보니 글 쓰는 것에 대한 흥미가 조금씩 생기는 것 같다. 앞으로는 연단위 회고 뿐 아니라 크고 작은 이슈가 있을 때, 자주 회고하는 습관을 가지는 것도 좋을듯하다. 그리고 올해는 꼭 블로그에 공부한 내용을 시리즈 형식으로 업로드 해보겠다

[Devops]내도메인한국에서 무료 도메인 발급 및 AWS ACM 인증받기

bill's tech log — Sun, 15 Dec 2024 15:29:28 +0900

이전에 ZeroSSL을 사용하여 도메인 없이 Elastic IP를 기반으로 단일 인스턴스(EC2)에 SSL 인증서를 발급받아서 간단하게 테스트하는 과정을 다뤘었다.

[AWS] 도메인 구매 없이 Node 환경에서 TLS(SSL) 빠르게 인증하기 (EC2+ Open SSL)

오늘은 AWS 의 EC2 인스턴스에서 빠르게 TLS(SSL) 인증을 하는 방식에 대해서 소개하겠다. 도메인 없이 Public IP 를 발급받은 EC2 인스턴스에서 간단한 테스트를 위한 개발을 할 때, 주로 사용하는 방

billtech.tistory.com

오늘은 내도메인한국 이라는 한글 무료 도메인 업체에서 무료로 도메인을 발급받고, AWS ACM 인증을 받는 과정에 대해서 소개하려고 한다. 추가로 발급받은 ACM 인증서를 통해서 ALB에 HTTPS(SSL/TLS) 설정하는 방법에 대해서 소개하겠다.

(이전 OpenSSL에서 소개했던 방식과 동일하게 내도메인한국에서 발급받은 도메인은 무료로 3개월까지만 이용이 가능하고, 제공되는 도메인의 형태가 실서비스에 적합한 도메인의 형태(?)는 아니기 때문에 테스트 환경에 SSL 인증을 하는 경우나 간단한 사이드 프로젝트에 이용하면 좋을 것 같다!)

등록에 앞서 사전에 필요한 내용은 아래와 같다. (aws 계정을 만드는 방식에 대한 내용은 생략하겠다)

- AWS 계정
- 내도메인한국 계정

1. 회원가입

내도메인한국 로 이동후에 상단의 회원가입 탭을 눌러서 가입을 진행한다. 반드시 가입을 해야만 도메인을 발급받을 수 있다.

2. 발급받을 도메인 네임을 검색

도메인검색 및 사용 가능한 도메인 리스트 출력

본인이 원하는 발급받을 도메인을 검색한다. 여기서 일반(일반적인 영어도메인)이나 특이하게 한국어 기반의 도메인을 검색해서 발급받을 수 있다.이때, 일반적으로 많이 사용되는 최상위 도메인(.com, .co.kr, .net, .ai..) 값이 아닌, p-e.kr, o-r.kr 등 을 제공한다.사용하고자 하는 도메인에 등록하기 버튼을 클릭한다.

3. AWS ACM 인증

AWS 로그인을 진행한 이후 Certificate Manager를 입력한다 - 첨부1

ACM 인증서 요청 선택 - 첨부 2

AWS에 로그인을 진행한 이후 상단 검색창에 Certificate Manager라고(첨부1)과 같이 입력을 한다. 이후, SSL/TLS 발급을 위해서 인증서 요청 버튼을 첨부 2와 같이 클릭한다.

4. 인증서 요청에 필요한 항목 추가

퍼블릭 인증서 요청 - 첨부1

퍼블릭 인증서에 필요한 항목들을 내도메인 한국에서 발급받은 정보를 바탕으로 기입한다. - 첨부2

그림 첨부 1의 이미지처럼 퍼블릭 인증서 요청을 클릭하고 다음 버튼을 클릭한다. 그림 첨부2의 내용과 같이 앞선 2번에서 내도메인한국에서 발급받은 도메인명을 추가한다. 검증 방식은 DNS 검증, 이메일 검증이 있는데 이번에 진행할 방식은 DNS 검증으로 진행할것이기 때문에 DNS검증을 선택하고 키 알고리즘은 본인이 원하는 알고리즘 방식을 선택하면 된다

5. CNAME 등록

4번의 항목들을 모두 입력하고 나면 CNAME 및 인증서 요청을 하기 위한 준비가 완료된다. - 첨부1

내도메인 한국에서 발급받은 ACM의 CNAME 이름 & CNAME 값을 입력한다. - 첨부2

4번을 완료하면 첨부 1과 같이 해당 도메인에 대한 CNAME 값이 발급된다.이때, CNAME 이름과, CNAME 값이 발행된다.

발급된 CNAME 이름, 값을 바탕으로 내도메인한국에서 발급한 도메인 -> 고급설정(DNS) 부분에서 별칭(CNAME) 탭에서 발급받은 CNAME 이름과 CNAME 값을 위와 같이 입력을 해준다.

(해당 값을 입력할 때의 주의사항은 내도메인한국의 고급설정 부분에서 ACM에서 발급한 이름을 입력할 때, 도메인값을 제외한 값을 입력해야 하고, CNAME값을 입력할 때, ~~ aws. 부분에서.(점)을 제외하고 입력을 해주고 저장을 해야만 정상적으로 등록이 된다)

6. ACM 인증

ACM 인증 대기

ACM 발급 완료

1~5번 과정을 완료했다면 위와 같이 성공적으로 ACM 인증을 완료할 수 있다.

7. ALB에 ACM 인증서 연결

기존에 생성해둔 로드밸런서에 HTTPS 리스너를 생성 - 첨부 1

6번에서 발급한 ACM 인증서를 선택 - 첨부 2

로드밸런서의 DNS 이름을 복사 - 첨부3

내도메인 한국에 로드밸런서 DNS 이름을 추가 - 첨부 4

(이번 포스팅에서는 ALB에 관한 설명은 생략하겠다.) 기존에 생성한 애플리케이션 로드밸런서에 HTTPS(443) 리스너를 추가하기 위해 첨부 1과 같이 설정을 해준다.

이후첨부 2와 같이 6번 과정에서 발급한 ACM 인증서를 선택 후 저장 버튼을 클릭한다. 리스너 규칙은 본인이 원하는 옵션을 넣어주면 된다.(타깃 그룹 기반 라우팅, URL 기반 라우팅 등등..)

이후 로드밸런서의 DNS이름을 첨부 3에서 확인 후에 내도메인한국의 고급설정(DNS) 탭에서 기존에 CNAME 탭에서 (+) 버튼을 클릭하고 로드밸런서 DNS 이름을 추가로 입력 후 수정하기 버튼을 클릭해 주면 로드밸런서와 발급한 도메인의 연결이 마무리된다.

위와 같은 과정을 진행하면 내도메인한국에서 무료로 도메인을 발급받을 수 있고, ACM인증과 더불어 로드밸런서에 HTTPS 등을 적용시켜서 간단한 테스트 환경을 무료로 구축할 수 있다.

위의 내용을 프로덕트 환경에서 적용시켜서 운영하는 데에는 무리가 있고, 나와 같이 위 방식을 통해서 프로덕트 환경과 유사한 스테이징 환경을 구성하거나 간단한 사이드 프로젝트를 진행할 때, 적용시키면 유용할 것 같다.(참고로 내도메인 한국에서 발급받은 도메인 주소는 3개월만 사용할 수 있으니 주의하기 바란다)

[AWS] ElasticBeanstalk - ERROR: Service:AmazonCloudFormation, Message:Resource AWSEBAutoScalingGroup does not exist for stack awseb-e-xxxxxxx-stack 에러 해결

bill's tech log — Sun, 13 Oct 2024 23:04:08 +0900

문제

AWS계정을 새롭게 생성 후 간단한 테스트를 위해 Beanstalk 환경을 구성하는 과정에서 아래와 같은 에러가 발생했다. 에러로그는 아래와 같다.

ERROR Creating Auto Scaling launch configuration failed Reason: Resource handler returned message: "The Launch Configuration creation operation is not available in your account. Use launch templates to create configuration templates for your Auto Scaling groups. (Service: AutoScaling, Status Code: 400, Request ID: c727xxx-xxxx-xxxxxx-xxxx86xxxxxxxxxxx2)" (RequestToken: xxxxxxxxxxxxxxxxxxx, HandlerErrorCode: GeneralServiceException)

ERROR: Service:AmazonCloudFormation, Message:Resource AWSEBAutoScalingGroup does not exist for stack awseb-e-xxxxxxx-stack

CloudFormation 내용을 확인해보니 인스턴스를 AutoScaling Group을 생성하는 인스턴스 생성 영역에 EBS 쪽에 문제가 있는 것 같았다. 그냥 기본적인 단일 세팅만 진행을 했었는데 왜 이런 이슈가 발생하는지 몰랐는데, Beanstalk을 생성하는 과정에서 아래와 같은 안내문구가 나와 있는 것을 확인했다.

위 안내 문구는 Auto Scaling 그룹에서 더 이상 Launch Configuration 생성을 지원하지 않으므로 Launch Template을 사용하라는 메시지가 포함되어 있었다. 솔직히 이 문구만 보고 잘 이해가 안되서 Beanstalk을 사용하기 전에 AutoScaling 시작 템플릿을 미리 생성하라는 건가? 싶어서 그렇게 해도 동일한 에러가 나왔다.

해결

이후 Launch Templates 관련 문서를 확인해보니, AWS 정책이 변경되면서 Beanstalk 인스턴스를 구성할 때 몇 가지 옵션을 반드시 설정해야 한다는 사실을 알게 되었다. AWS에서는 2024년 10월 1일부터 새로 생성한 계정에 대해 기존 Launch Configuration 대신 Launch Templates만을 지원하게 되었다고 한다. 문제 해결을 위해 Beanstalk 설정 과정에서 4단계인 인스턴스 트래픽 및 크기 조정 구성 단계에서 아래와 같은 옵션을 설정하면 된다.

위의 내용을 요약하면 아래와 같다.

- RootVolumeType 옵션을 gp3로 설정
- BlockDeviceMappings에 gp3를 포함
- DisableIMDSv1 옵션을 true로 설정
- EnableSpot 옵션을 true로 설정

BeanStalk 세팅 과정에 4단계인 인스턴스 트래픽 및 크기 조정 구성 단계에서 위의 내용에 나와 있는 옵션을 선택해서 구성하면 된다고 나와 있다. 나는 아래와 같이 EBS 볼륨 유형을 디폴트인 컨테이너 기본값에서 범용 3(SSD) gp3로 변경하여서 문제를 해결했다.

참고

Launch Templates - AWS Elastic Beanstalk

Once an environment is using launch templates, Elastic Beanstalk will never move it back to launch configurations. This is the case even if any these option settings that prompted the original use of launch templates are removed.

docs.aws.amazon.com

Creating an Elastic Beanstalk without success

Hello, I am new to using Elastic Beanstalk. I am trying to create an environment but i get these errors > Creating Auto Scaling launch configuration failed Reason: Resource handler returned messa...

repost.aws

MacOS에서 Jenkins 빌드시 npm, yarn, pnpm 패키지를 못 찾는 경우 해결법

bill's tech log — Tue, 17 Sep 2024 20:59:59 +0900

연휴기간에 회사에 적용시킬 Jenkins 세팅을 위해 로컬에서 테스트를 하던 도중 계속 빌드에 실패하는 이슈가있어 로그를 뜯어보니 아래와 같은 내용을 확인 할 수 있었다.

로그의 주요 이슈 항목

line 3: yarn: command not found

yarn 패키지를 못 찾는 이슈였다.

이때, 본인이 nodejs 패키지를 설치 및 기본 환경 세팅을 마무리한 상황이면 대부분 본인의 Mac의 HomeBrew 경로 세팅을 하지 않아서 발생하는 이슈일 가능성이 높다.

해결

젠킨스 시스템 관리로 접속

Jenkins 관리 탭에서 System 설정으로 접근한다.

환경변수 설정

Global properties 라는 환경 변수를 설정하는 탭에 이동해 homebrew 경로를 넣어준다. 이때 본인의 Mac OS의 homebrew 경로값을 위와 같이 추가하고 변경사항을 저장하면 정상적으로 빌드에 성공하는것을 확인할 수 있다.

환경 설정값 이후 빌드 성공

마무리

위의 방식으로 진행하면 yarn 뿐만 아니라 pnpm 패키지를 찾지 못하는 이슈도 동일하게 해결가능하다. 필자는 Free Style 프로젝트에서 적용한 사례이기 때문에 별도의 Pipeline을 구축하면서 해당 이슈가 발생했다면 위와 같은 방식으로 해결이 안될 수 있느니 아래의 링크를 참고하면 좋을것 같다.

Jenkins Pipeline "yarn install" command not found

This is my first Jenkins script, it currently operates well on Linux but I migrate to MacOS (High Sierra) with the result of getting shell script error. Node and yarn packages are installed on local

stackoverflow.com