나는 내 좌절에 값어치를 매긴다.

[길벗 26차 개발자 리뷰어] 쉽게 시작하는 Next.js 를 읽고

TLOWAC — Wed, 5 Feb 2025 04:12:29 +0900

0) 들어가며

읽고 싶은 IT 기술 도서는 길벗과 한빛에서 많이 나오는데,
매번 신청할 때마다 경쟁이 치열했다.

그런데 이번에는 마침 좋은 기회가 찾아왔다!!!

이번에 리뷰하게될 기술 도서는 쉽게 시작하는 Next.js 입니다!

1) 어떻게 리뷰를 작성할까..

어떻게하면 Next.js 를 배우기 위해 공부자료를 찾는 사람들에게 책의 내용을 재밌고 깔쌈하게 풀어줄 수 있을까.. 고민하다가

크게 4가지로 와꾸를 잡아보았다.

1) 챕터별 시작 ~ 완독까지 걸린 시간 정리

2) 책을 읽고 난 뒤의 소감 정리

3) 책의 아쉬운 점 정리

4) 해당 책을 읽을 만한 독자의 범위 정리 및 추천

2) 챕터별 시작 ~ 완독까지 걸린 시간 정리

쉽게 시작하는 Next.js 기술도서의 챕터는 부록을 포함하여 총 9개의 챕터로 이루어져있다.

총 217분.. 3시간 37분 정도 걸렸다.

퇴근하고 집에 와서 3일에 걸쳐 읽었다.

CHAPTER 1 Next.js 기초 지식 - 27분
CHAPTER 2 리액트 컴포넌트 학습 - 36분
CHAPTER 3 Next.js 페이지 만들기 - 15분
CHAPTER 4 페이지 라우터 애플리케이션 - 20분
CHAPTER 5 페이지 렌더링 - 40분
CHAPTER 6 데이터 액세스 - 27분
CHAPTER 7 API 작성과 이용 - 28분
CHAPTER 8 OpenAI API 이용하기 - 13분
부록 A 타입스크립트 입문 - 11분

나는 보통 개발 도서를 기반으로 공부를 할때는 3단계에 걸쳐서 책을 읽는다.

첫번째로는 일정 시간을 정해두고 책의 내용을 훑어본다.
책의 전반적인 내용과 목차를 확인하며 어떤 내용으로 구성되었는지 흐름을 보며 읽는다.

두번째로는 책을 정독한다.
첫번째 방식을 통해 잡은 흐름을 염두에 두고, 책의 내용을 이해하기 위해 노력하며 읽는다.

세번째로는 책의 예시를 따라칙거나 프로젝트를 따라한다.
이 과정에서 추상적인 개념, 텍스트만으로 이해되지 않았던 부분을 다시 본다.

이번에 책을 읽을 때는 첫번째, 두번째 방법을 사용했다.
217분이라는 시간은 두번째 읽을 때 걸릴 시간이다.

만약 별도의 실습을 진행한다면 곱하기 1.5 ~ 2.5 까지 늘어날 수 있을것 같다.

3) 책을 읽고 난 뒤의 소감 정리

쉽게 시작하는 Next.js 라는 책의 이름대로 실제 모든 스크립트 명령어에 대해

실행 결과 화면의 이미지가 책에 같이 나와 있어

각 단계별 진행상황을 별도의 실습 없이 책에 있는 이미지로 확인 할 수 있어 편리하고 이해하기 쉬웠다.

<이미지: >

쌩짜배기 Next.js 공식문서로 시작해서

앱 라우터, 페이지 라우터 / CSR, SSG, ISR, SSR 등의
개념을 이해하려고 하면 여러차례의 헛발질이 요구된다.

간단한 예시지만 앱라우터, 페이지 라우터에 대한 내용을
기능 케이스 별로 구분하여 설명해줘서 이해하기 좋았다.

더불어, CSR, SSG, ISR, SSR 은 다이어그램을 통해
각 단계별 전반적인 흐름의 차이점을 한눈에 알 수 있었다.

프론트와 백엔트 두 파트의 업무를 다 하는 입장에서는 목업 데이터보다 간단하더라도
Supabase, MySQL Docker Container 등을 활용한 DB 연동에 대한 내용이 있었으면 어땠을까 하는 아쉬움이 남는다.

책을 읽으며 각 챕터에서 인상 깊었던 부분등을 메모한 내용이다.

[1장] Next.js 기초 지식

WEB IDE를 기반으로 설명을 진행하여 초보자가 개발 환경 구성 시 발생할 수 있는 다양한 예외 사항을 방지함.
npm 명령어 실행 결과 화면을 이미지로 제공하는 점이 좋았음.
Metadata 작성 및 표현 방식에 대한 예제 이미지가 추가되었으면 좋았을 것 같음.
Next.js에 대한 기본 개념을 설명하기 전에 먼저 배포를 진행하는 점이 인상적이었음. 이는 새로운 프레임워크를 배울 때 배포 시 발생할 수 있는 문제를 미리 해결할 수 있도록 도와줌.

[2장] 리액트 컴포넌트 학습

onClick={doClick}과 같이 초보자가 실수할 수 있는 부분을 여러 사례를 들어 설명한 점이 좋았음.
스타일 객체를 설명하면서 빈 화면을 클릭하면 빨간색 반투명 원이 추가되는 예제는 직관적이었음.
실행별 결과 이미지를 첨부하여 이해를 돕지만, 코드 라인별 주석이 추가되었다면 더욱 도움이 되었을 것 같음.

[3장] Next.js 페이지 만들기

Tailwind 색상 설정을 설명하면서 숫자만 나열하기보다 색상의 그라데이션을 함께 보여주었다면 더욱 직관적이었을 것 같음.
<img> 태그 대신 Next.js <Image>를 사용하면 WebP 형식 변환을 통해 이미지 품질을 유지하면서 파일 크기를 줄일 수 있다는 점을 새롭게 알게 되었음.

[4장] 페이지 라우터 애플리케이션

앱 라우터와 페이지 라우터의 차이점을 명확하게 설명함.
페이지 라우터에서만 지원하는 정적 페이지 생성 개념을 배우는 데 도움이 되었음.

[5장] 페이지 렌더링

SSR, CSR, SSG, ISR 개념을 보다 깊이 이해하는 계기가 되었음.
최신 버전의 Next.js를 사용한 예시와 단계별 작업 변화 이미지를 제공하여 지식의 빈틈을 메우는 데 효과적이었음.

[6장] 데이터 액세스

6.2 서버 액션 부분이 특히 유용했음.
예전에는 없던 기능으로, 단순한 폼 예제부터 fs 모듈을 이용한 파일 예제까지 포함되어 있음.

[7장] API 작성과 이용

앱 라우터와 페이지 라우터의 API 차이를 명확하게 구분해 설명함.

[8장] OpenAI API 이용하기

실습 중심으로 진행되어 이해하기 쉬웠음.

4) 누구에게 권할것인가?

이런 분들에게 추천합니다!

✅ Next.js를 처음 접하는 입문자
✅ React는 해봤지만 Next.js가 생소한 개발자
✅ CSR, SSR, SSG, ISR 개념이 헷갈리는 분
✅ 공식 문서만으로 공부하기 막막했던 분
✅ 빠르게 Next.js의 핵심을 익히고 싶은 분

개발을 처음 시작하는 분들에게는 내용이 다소 복잡할 수 있다.

[생각정리] Testdome 을 사용한 온라인 테스트 후기

TLOWAC — Wed, 27 Nov 2024 16:47:16 +0900

들어가며

이번에 취업 준비를 하면서 다양한 유형의 온라인 테스트를 진행했다.

그중에서 대다수는 프로그래머스를 사용했고, 일부는 프로젝트 구현을 했었다.

서류 합격 메일을 받고 진행하게 된 온라인 테스트에서 TestDome 플랫폼을 쓴 회사는 여기가 처음이었다.

뭔가 UI 와 전체적인 맥락은 프로그래머스와 유사해보였다.

바로 테스트를 시작하며 한가지 간과했던것은 출제 되는 문제의 유형과 TestDome 만의 문제별 시간 할당 방식이었다.

여기서 부터 꼬이기 시작했고, 결과적으로는 떨어졌다.

✅ 좋은점

1) 실무에서 볼법한 문제 유형

실제 업무에 사용하는 스택과 기업에서 중점적으로 보는 문제 해결 역량이 어떤것인지 확인 할 수 있었다.

특히, node.js 구현 문제와 SQL 문제의 경우 실무에서 접할만한 유형의 문제가 나와 재밌었다.

✅ 아쉬운점

1) 문제별 시간 설정

문제별 시간을 자유롭게 설정 할 수 없었다. 프로그래머스와 같은 플랫폼과는 다르게 문제별로 할당되는 시간이 다르며, 응시자가 전체 시간을 배분해서 문제를 푸는 방식이 아니다. 그렇기 때문에 문제풀이에 반복 숙달이 되어 있어야 한다는 느낌이 강하다.

2) 처음 보는 유형의 문제들

SQL, 알고리즘, 기능 구현등은 다른 플랫폼에서도 찾아 볼 수 있다. 하지만, 빈칸 채우기, 5지선다와 같은 문제 유형이 다소 어색했다.

[Github 1% 이해하기] collaborator 로 초대받은 repo 확인하기 (feat. fork 하기)

TLOWAC — Tue, 26 Nov 2024 18:42:03 +0900

들어가며

사람들과 토이 프로젝트를 진행하다보면 여러가지 사정으로 인해 "repo fork 는 나중에 해야지" 라며 넘어가는 경우가 있습니다.

이럴때 github 대시보드에서 내가 초대 받은 repo 를 찾을 수 없어 당황했던 경험이 있습니다.

저와 같이 나중에 작업하는 경우 당황하지 않기 위해 이에 대한 방법을 정리해보았습니다.

✅ 초대 받은 repo 확인하기 및 repo fork 하기

1) 초대 받은 repo 확인하기

초대 받은 repo 를 한눈에 보기 위해서는 아래와 같은 방법을 사용 할 수 있습니다.

github 메인 페이징에서 제일 오른쪽 위의 아이콘을 클릭한다.
"Settings" 페이지로 이동한다.
Repositories 를 클릭한다.

Repositories 를 클릭하게 되면, 아래의 이미지와 같은 페이지로 이동하게 됩니다.

해당 페이지에서 초대 받은 repo 를 확인 할 수 있습니다.

( 만약, 내가 만든 repo 라면 collaborator 들도 확인 할 수 있습니다. )

2) repo fork 하기

이제는 repo 를 fork 하는것만 남았습니다. 해당 repo 로 이동한뒤에 star 옆에 있는 "Fork" 버튼을 통해 자신의 계정으로 해당 프로젝트를 fork 할 수 있습니다.

마무리하며

초대 받은 repo 를 확인하고 repo 를 fork 하는 방법까지 정리해보았습니다.

나중에 해야지 하다가 당황했던 분들에게 도움이 되었으면 좋겠습니다.

감사합니다.

구글 엔지니어는 이렇게 일한다 #12장 단위테스트를 읽고

TLOWAC — Mon, 25 Nov 2024 16:47:38 +0900

#12 단위 테스트

| 일부 내용
첫째, 버그도 없고 자신의 검증 대상과 관련 없는 변경 때문에 실패하는 '깨지기 쉬운' 테스트들이 도사리고 있었습니다. 둘째, 무엇이 잘못되어 실패했는지, 어떻게 고쳐야 하는지를 파악하기 어려운 '불명확한' 테스트들이었습니다. 애초에 무슨 기능을 어떻게 검사하려고 했는지조차 이해하기 쉽지 않았습니다.

책에서는 '깨지기 쉬운 테스트' 와 '불명확한 테스트' 를 예시로 맹목적인 테스트로 인해 발생 할 수 있는 생산성 저하 케이스에 대해 설명해주고 있다. 실제 개발을 진행하며 이런 상황을 빈번히 마주치게 된다. 그럴때마다 어떤것이 올바른 테스트 작성 방향성인지 헷갈릴 경우가 많다. 지금도 일부분에 대해서는 혼동이 오고는 한다. 이건 좀 더 경험 / 역량이 쌓이면 해결될것이라고 생각한다.

| 일부 내용
테스트의 추상화 수준이 적절하지 않다는뜻입니다.
------
단위의 범위를 잘 정해서 어디까지가 공개 API 인가를 정하는 일에 과학적인 정답은 없습니다.
------
또한 테스트를 더 명확하게 만들 수 있다면 DRY (Don't Repeat Yourself) 원칙을 거스르는 게 나을 떄도 많습니다.

테스트 작성에 대한 적절한 선을 찾는것이 아직은 모호하게 느껴진다.

| 일부 내용
Cucumber 와 Spork 처럼 given/when/then 을 직접 지원하는 테스트 프레임워크까지 생겨났습니다.

실제 given/when/then 을 사용하게 되면 테스트 코드 작성이 명확해지고, 추가적인 주석 작성을 통해 코드 뿐만 아니라 실행 흐름을 파악하는데 도움이 되었다.

하나의 테스트 케이스를 작성하는 과정에서 when/then 이 교차되며 테스트 케이스의 크기가 비대해지는것을 주의해야 한다.

책에서는 블록이 하나씩이면 충분하다고 안내되어 있다. 나도 이에 동의한다.

| 일부 내용
DRY 를 고집하는 대신 테스트 코드는 DAMP 가 되도록 노력해야 합니다. DAMP는 '서술적이고 의미 있는 문구' 를 뜻합니다. 단순하고 명료하게만 만들어준다면 테스트에서 다소의 중복은 괜찮습니다.
------
DAMP 가 DRY 를 대체하지는 않습니다. 보완해주는 개념 입니다.

DAMP 라는 새로운 개념도 신기했지만, DRY 를 신봉하지 말고 DAMP 를 보완제로 사용한다는것도 신기했다.

실제로 책에서 JAVA 코드를 예제로 설명해주었을때, 테스트 코드의 가독성이 많이 향상되는것을 눈으로 확인 할 수 있었다.

구글 엔지니어는 이렇게 일한다 #11장 테스트 개요를 읽고

TLOWAC — Sun, 24 Nov 2024 14:23:15 +0900

#11 테스트 개요

| 일부 내용
최고의 팀은 팀원들의 집단 지성을 팀 전체의 이익을 환원하는 방법을 찾아냅니다. 바로 자동 테스트가 하는일이죠.

어쩌면 단순하다고 볼 수 있는 테스트 케이스 작성을 이런 관점에서 생각해볼 수 있다는것이 놀랍다.

| 일부 내용
더 나아가 하루에도 몇 번씩 새로운 버전을 릴리스해야 합죠. 일 년에 고작 한두 번만 업데이트되던 과거의 소프트웨어 세상과는 완전 딴판 입니다.

애자일, 스프린트 방식이 전반적으로 도입되기 시작하면서 프로그램의 배포주기는 더욱 더 짧아지기 시작하는것 같다.

그만큼 배포, 롤백, 각종 트러블 슈팅의 빈도 수도 올라갔기 때문에 테스트의 중요성이 더 대두된다.

| 일부 내용
테스트 문화가 확실하게 뿌리 내린 조직을 경험해보지 못한 개발자는 테스트를 작성하면 생산 성과 속도가 높아진다고는 생각하기 어려울 것입니다. 오히려 반대로 생각할 가능성도 크죠. 어쨌든 처음에는 기능 구현에 드는 시간만큼을 혹은 그 이상을 테스트 작성에 써야 하니까요. 하지만 구글은 테스트에 투자하는 게 개발자 생산성 향상시키는 중요한 이유를 몇 가지 발견했습니다.

나도 개발을 처음 접하는 과정에서는 테스트 코드의 존재를 알지 못했을뿐더러 프로젝트를 진행할때도 "써야한다니까" 의식적으로 썼었다.

하지만, 신입 개발자로 취업을 하고 현업을 경험하면서 스프린트 방식 ( 2주 간격으로 배포 ) 으로 프로젝트를 진행하며 테스트 코드 작성으로 인한 심리적 / 실질적 안정감을 경험하고 나서는 테스트 코드를 작성하는 이유에 대해서 인식하게 되는 계기가 되었다.

추가로 책에서는 1) 디버깅 감소, 2) 자신 있게 변경, 3) 더 나은 문서자료, 4) 더 단순한 리뷰, 5) 사려 깊은 설계, 6) 고품질의 릴리스를 빠르게 총 6가지를 이유로 들었다.

테스트 코드를 업무에 적용하여 사용하게 되면 깊이 공감되는 내용들이다. 특히, 테스트 코드 작성을 위한 코드간 의존성을 의도적으로 나누는 경우도 있고, PR 을 리뷰하면서 테스트 코드를 통해 해당 코드 작업의 컨텍스트를 먼저 파악하는 경우도 있다.

구글 엔지니어는 이렇게 일한다 #10장 문서자료를 읽고

TLOWAC — Sat, 23 Nov 2024 20:15:25 +0900

#10 문서자료

| 일부 내용
대부분의 엔지니어가 코드를 작성하고, 이용하고, 유지보수하며 토로하는 대표적인 불만이 양질의 문서자료가 부족하다는 점 입니다.

지금까지의 경험에 한해서는 어디를 가서도 문서자료의 부족함이 없다는 이야기는 못들어 봤다.

항상 문서 자료가 부족하다는 이야기 뿐이었다.

| 일부 내용
구글에서 문서자료를 개선하고자 해본 시도 중 가장 성공적이었던 방법은 문서자료를 코드처럼 취급하여 엔지니어링 워크플로에 통합하는 것이었습니다. 그 결과 엔지니어들이 간단한 문서자료를 작성하고 유지보수하는 일이 한결 수월해졌습니다.

swagger, jsdoc, postman, redoc 등 이를 활용할 수 있는 도구들이 많이 다양해졌다.

대다수의 사람들이 최소한 API 명세에 한해서는 문서화의 중요성을 인지하고 있다.

| 일부 내용
하지만, 테스트에 대한 투자와 마찬가지로 문서자료에 들인 노력도 날이 갈수록 가치가 커집니다. 문서자료는 단 한번만 작성하면 되지만 결국 수백 번, 수천 번 읽히게 됩니다. 초기 비용은 미래의 모든 독자에게 혜택으로 돌아 갑니다.

길을 가다보면 신문을 찍어 내는 곳이 있다. 명확한 회사명은 기억이 나지 않지만 동아일보였던것으로 기억한다.

거기에는 이런 문구가 적혀 있다. "오늘의 기록이 내일의 역사가 된다."

테스트 / 문서자료 또한 번거로울지라도 내일을 위해, 후에 이를 통해 이득을 볼 사람들을 위해 작성해야 한다.

| 일부 내용
문서자료가 기존 코드를 유지보수하기 더 쉽게 해준다고 생각하기보다는 유지보수할 대상이 하나 더 늘어난다고 생각합니다.

처음에는 나도 이런 생각을 안가졌던것은 아니다. 실제로 현업을 진행하며, 신입때는 작업을 우선적으로 수행하는 경우가 많았다.

하지만, 어느 정도 시간이 지나고 작업한 내역을 건드려야하는 상황이 왔을때, 내가 작업한 부분임에도 일부만 기억이 나는 경험을 했었다.

당혹스러우면서도 느낀 한가지는 작업 전/후 문서 자료를 만들어 놓아야 겠다는 생각이었다.

이런 습관이 들고 난뒤에, 시간이 지나 비슷한 상황을 경험했을때 과거의 내가 작성한 문서 자료는 작업의 컨텍스트나 흐름을 파악하는데 도움이 되었다.

구글 엔지니어는 이렇게 일한다 #9장 코드 리뷰를 읽고

TLOWAC — Fri, 22 Nov 2024 13:25:52 +0900

#9 코드 리뷰

| 일부 내용
지식과 책임을 '소유권' 이라 부르고, 소유권을 행사하는 사람을 소유자 라고 합니다. 단순히 해당 영역의 소스 코드가 소유자의 것이라는 뜻이 아니라 회사가 추구하는 가치가 지켜지도록 관리한다는 의미의 소유 입니다.

'회사가 추구하는 가치가 지켜지도록 관리한다'

코드 리뷰를 하면서 이런식으로 방향을 정의한적이 있던가. 단순히 팀의 컨벤션, 회사의 컨벤션, 코드의 효율성 및 가독성만을 탐독하지 않았나 반성하게 된다.

| 일부 내용
구글은 아무리 작더라도 코드베이스를 수정하는 거의 모든 변경에 코드 리뷰를 요구합니다. 이러한 강제적인 규제는 비용을 유발하고 엔지니어링 속도에도 영향을 줍니다. 코드 베이스에 새로운 코드를 추가하는 속도를 늦추고 필요한 변경을 제때 반영하기 어렵게 할 수도 있습니다.

책에서는 위의 설명과 더불어 그럼에도 불구하고 코드 리뷰가 필요한 몇가지 이유들에 대해서 설명한다.

그중에서 나는 3가지에 깊이 공감한다. '1)변경된 코드를 다른 엔지니어도 잘 이해합니다.' , '2)지식이 공유 됩니다.' , '3)팀이 소유권(주인의식)을 더 강하게 느낍니다.'

이것은 3장의 '지식 공유' 에서 나온 '단일 장애점 (SPOF)' 문제를 풀어나가는데도 영향을 주기 때문이다.

| 일부 내용
코드 리뷰를 필수라고 못박으면 작성자들에게 자신의 코드를 한번 더 들여다보게 하는 효과가 생깁니다.
-----
사소한 결함은 나중에 해결하겠다는 안이함으로 말이죠.

이따금 테스트코드를 작성하는것을 까먹고 Commit 하여, PR 에서 반려 당했던 나의 과거가 떠오른다.

하지만, 확실히 코드 리뷰를 필수적으로 하게 되면 나의 코드를 한번 더 읽어 보며, 해당 PR 을 리뷰해줄 리뷰어를 위해 코드의 가독성 작업의 필요성, 변경사항들을 좀 더 자세히 작성하게 된다.

| 일부 내용
리뷰를 통한 지식 공유는 지역, 국가, 프로젝트 경계에 구애받지 않고 코드베이스 구석구석의 모든 엔지니어에게 빠르게 전파됩니다. 코드 리뷰야말로 지식을 퍼뜨리기에 완벽한 기회입니다.

생각을 해보면 서로 다른 도메인의 업무를 진행중이더라도, 코드 리뷰를 통해 서로 담당하고 있는 업무의 도메인과 더불어 해당 프로젝트의 전반적인 진행 사항을 알 수 있다.

하지만, 염려되는 한가지는 코드 리뷰 작업으로 인한 업무 지연이다. 이를 현명하게 대처할수만 있다면 코드 리뷰는 실보다 득이 더 많은것은 분명 하다.

| 일부 내용
코드 리뷰는 작성자와 리뷰어 모두에게 배움의 기회임을 기억하세요. 이 점만 잊지 않으면 어떤 의견 충돌도 감정싸움으로 번지지 않을 것입니다.

책에서 이러한 내용이 언급되듯이 현실에서도 코드 리뷰가 자칫 감정 싸움으로 전환되는 케이스가 존재한다.

코드 리뷰가 감정 싸움으로 전환되는것을 인지했다면, 토의를 잠시 멈추고 상황을 멀리서 돌아볼 필요가 있다.

항상 상대를 존중하고 겸손해야한다.

| 일부 내용
코드 리뷰는 지금 당장만이 아니라 후대를 위해 현재 하고 있는 일을 기록하는 행위 입니다.

키야........ 사장님 여기 소주 하나요..!

개발자가 코드 리뷰라는 행위를 바라보는 관점을 엿볼 수 있었다. 더욱이 이런 마인드로 코드 리뷰에 임한다니 감탄만이 나온다.

| 일부 내용
구글은 조직이 매우 거대하고 거의 모든 코드를 모노리포에서 투명하게 관리하기 때문에 코드를 새로 추가하면 얼마 지나지 않아 누군가 이용하기 시작합니다. 따라서 롤백은 그 사이에 코드를 이용하기 시작한 엔지니어들의 작업에 지장을 주게 됩니다. 작은 변경은 원자적이라서, 또 빠르게 리뷰 할 수 있어서 이런 피해를 줄여줍니다.

PR 을 작게 만들어 코드 리뷰를 진행하는게 단순히 리뷰어가 해당 PR 을 리뷰하기 편하게 하기 위함 뿐만 아니라, 이슈 발생시 '롤백' 을 용이하게 하기 위함이라는점에서 신기하게 다가 왔다. 막상 경험을 퇴고해보면 배포 후 이슈가 발생하여 특정 commit 을 기준으로 롤백을 했던 경험이 있었기 때문이다.

[오픈소스 기여하기] gautamkrishnar/blog-post-workflow 프로젝트에 기여하기

TLOWAC — Thu, 21 Nov 2024 09:09:10 +0900

들어가며

오픈소스인 gautamkrishnar/blog-post-workflow 프로젝트에 기여한 과정에 대해서 정리해 보았습니다 :)

해당 프로젝트는 profile readme 파일에서 자신의 블로그 rss 를 기반으로 포스팅 목록을 보여주는 workflow 입니다.

( profie readme 를 꾸밀때 사용하기 좋습니다. )

✅ Issue & Pull Request 만들기

1) Contribute 하고자 하는 내용을 issue 로 정리하기

비교적 간단한 기여인 해당 오픈소스의 workflow 를 사용해 티스토리 블로그의 rss 도 적용할 수 있다는것을 해당 오픈소스의 readme 에 표시하고자 했습니다.

저의 profile readme 에 해당 workflow 를 적용하여 실제로 티스토리 rss 를 통해 포스팅 목록이 로딩 되는지 테스트하고 PR 을 날리기 위해 Issue 를 생성하였습니다.

그 과정에서 다소 신기했던 경험은 해당 오픈소스의 관리자가 채 몇분도 되지 않아 "해당 이슈에 관심 있으면 PR 을 만들어줘" 라는 답변을 달아 주었다는것이었습니다. 관리자에게 PR 답변 받은것은 이때가 처음이었어서 당황해하면서도 신기했습니다 :)

저도 얼른 답변을 달고 사전에 작성해둔 commit 을 날리고 PR 을 만들었습니다.

2) PR 제작 하기

commit 의 내용은 비교적 간단했기 때문에, 해당 오픈소스의 PR 가이드를 꼼꼼히 확인하고 가이드라인을 기반으로 PR 을 작성하였습니다.

채 1시간이 되지 않아 저의 PR 은 merged 되었습니다.

이렇게 빠르게 티키타카가 되어 오픈소스에 기여 할 수 있다는것이 신기한 경험이었습니다.

마무리하며

거창한 PR 이 아니더라도 오픈소스에 기여하는 경험을 공유하고 싶었습니다.

여러분도 너무 고민하지 마시고 오탈자, 문서, 참조, 버그 픽스등 다양한 PR 을 통해 오픈소스에 기여해보는것은 어떨까요...

저도 티스토리 rss 문서 내용 추가로 오픈소스에 기여했습니다 :)

[Prisma 99% 에러 잡기] P3018 : A migration failed to apply. |

TLOWAC — Wed, 20 Nov 2024 17:15:45 +0900

에러 및 발생 원인 분석

1) Error 메시지

2) Error 발생 원인 분석

migration filename | 20240211055424_update_room_id_type_to_string_uuid

/*
  Warnings:

  - The primary key for the `Room` table will be changed. If it partially fails, the table could be left without primary key constraint.

*/
-- DropForeignKey
ALTER TABLE `Invite` DROP FOREIGN KEY `Invite_roomId_fkey`;

-- DropForeignKey
ALTER TABLE `User` DROP FOREIGN KEY `User_roomId_fkey`;

-- AlterTable
ALTER TABLE `Invite` MODIFY `roomId` VARCHAR(191) NOT NULL;

-- AlterTable
ALTER TABLE `Room` DROP PRIMARY KEY,
    MODIFY `id` VARCHAR(191) NOT NULL,
    ADD PRIMARY KEY (`id`);

-- AlterTable
ALTER TABLE `User` MODIFY `roomId` VARCHAR(191) NOT NULL;

-- AddForeignKey
ALTER TABLE `User` ADD CONSTRAINT `User_roomId_fkey` FOREIGN KEY (`roomId`) REFERENCES `Room`(`id`) ON DELETE RESTRICT ON UPDATE CASCADE;

-- AddForeignKey
ALTER TABLE `Invite` ADD CONSTRAINT `Invite_roomId_fkey` FOREIGN KEY (`roomId`) REFERENCES `Room`(`id`) ON DELETE RESTRICT ON UPDATE CASCADE;

Table[Room] 의 PK 가 기존 number 에서 string ( number -> string ) 으로 변경됨에 따라 해당 작업을 위한 마이그레이션 파일 또한 신규로 생성되었습니다. 하지만, 로컬 환경에서 마이그레이션 후 데이터 확인 과정에서 실반영이 안되는점을 확인하였습니다.

← String 타입의 경우 “123” 이 아닌 “ABC” 로 표시 되어야 합니다.

해당 파트를 제거 후 20240203154156_db_schema_init 마이그레이션 파일에 Table[Room] 의 PK 타입 변환 DDL 을 업데이트 하였으며, 로컬에서 작업한 마이그레이션을 적용하는 과정에서 에러가 발생하였습니다.

✅ 해결 방법 정리

Prisma 의 마이그레이션 관리 방식은 shadow database 를 사용하기 때문에 기존에 남아 있는 마이그레이션 파일 내역을 제거하고 다시 로컬 마이그레이션을 진행하는 방식으로 문제를 해결하였습니다.

( DEV/PROD 환경에서 이와 같은 방법은 지양 합니다. )

마무리하며

prisma migrate failed 과정에서 shadow database 내역을 수정함으로써 resolve 하는 방법을 통해 에러를 해결한 내용을 정리해 보았습니다. 추가로 도움이 될만한 prisma docs 링크를 남겨놓습니다!

https://www.prisma.io/docs/orm/prisma-migrate/workflows/patching-and-hotfixing#failed-migration

Patching & hotfixing | Prisma Documentation

How to reconcile the migration history after applying a hotfix or patch to a production environment.

www.prisma.io

https://www.prisma.io/docs/orm/prisma-migrate/getting-started

Getting started with Prisma Migrate | Prisma Documentation

Learn how to migrate your schema in a development environment using Prisma Migrate.

www.prisma.io

구글 엔지니어는 이렇게 일한다 #8장 스타일 가이드와 규칙을 읽고

TLOWAC — Tue, 19 Nov 2024 03:31:44 +0900

#8 스타일 가이드와 규칙

| 일부 내용
규칙을 관리하는 목표는 '좋은' 행동을 장려하고 '나쁜' 행동을 억제하기 위함입니다.

좋은 말이다. 하지만, 구성원 전부가 이에 대한 취지를 이해하고 지키고자 노력할때 진정한 효과가 발휘되는것 같다.

프로그래밍 과정에서의 규칙에 있어서도 하나의 예외가 발생하기 시작하면 규칙이 그대로 무너져 지키는 사람만 지키는 유명무실한 규칙이 되는 경우도 보았다.

| 일부 내용
규칙 모음을 정의할 때 반드시 던져야 하는 질문은 '무슨 규칙이 필요하지?' 가 아니라 '어떤 목표를 이루려 하지?' 입니다.

지금까지 규칙은 '나쁜' 행동을 억제하기 위한 용도 였다. 예를 들면 '지각 하지 마라' 와 같이 말이다.

하지만, 이에 대한 관점을 '어떤 목표를 이루려 하지?' 에 두어보지는 않았다.

사이드 프로젝트에서 프로그래밍 규칙을 만들때도, "이건 안티 패턴" 와 같이 제약을 걸기만 했었다.

최종적인 목표를 인식하고 그에 맞춰 규칙을 세우는 연습을 해봐야겠다.

| 일부 내용
구글은 엔지니어만 3만 명이 넘고, 그 숫자 만큼이나 엔지니어들의 기술 수준과 배경 역시 다양합니다.
수십 년을 더 존재할 가능성이 큰 20억 라인 이상의 코드베이스에 매일 약 6만건의 코드가 서브밋 됩니다.

상상조차 되지 않는 코드 규모다.

이런 환경이라면 프로그래밍 규칙은 거의 필수적이지 않을까.

20억 라인을 파악하려면 이번 생에 다할 수 있을까....

| 일부 내용
C++ 스타일 중재자 그룹의 멤버는 4명 입니다.
다수결이 되려면 인원이 홀수여야 유리한데 왜 짝수인 걸까요? 스타일 가이드 수정은 투표가 아니라 합의로 이루엊지기 때문입니다.

놀라웠다. 보통은 하나의 규칙 또는 논의를 하는 과정에서 의견이 수립되지 않으면, 기존에 나온 의견들을 기반으로 투표가 진행되고 최종적으로 하나의 의견이 정립되는게 대부분이었기 때문이다. 하지만, 투표가 아닌 합의로 이러한 가이드를 구축해나간다는 점에서 정말 놀라웠다.

구글 엔지니어는 이렇게 일한다 #6장 성장하는 조직 이끌기를 읽고

TLOWAC — Mon, 18 Nov 2024 04:59:34 +0900

#6 성장하는 조직 이끌기

| 일부 내용
과제를 던져준 후, 실패하고 다시 시도하고 또 도전하도록 놔두세요.
'빠르게 실패하고 반복하라.' 실리콘 밸리에서 통용되는 격언 입니다.
-----
다른 리더에게 성장할 기회를 마련해줘야 합니다. 그들은 '레벨업' 하는 방법을 배우고 스스로 일을 완수해내야 하고요. 그리하여 업무 크리티컬 패스상에서 여러분의 이름이 사라지게 해야 합니다.

직책이 변경되고 이슈 채널방의 새로운 모든 이슈에 내 이름이 태그 되는 경험은 이로 말할 수 없는 충격이 밀려온다.

더 이상 이에 대해 의논하거나 이슈 해결을 도와줄 상급자는 없었기 때문이다.

연차가 쌓일수록 책임은 비례한다.

반복적으로 터지는 이슈, 새롭게 인입된 CS등 다양한 형태로 도전 과제가 생겨난다.

책에서는 팀을 믿고 자신이 20분만에 해결 할 수 있는 이슈더라도 팀에게 맡김으로써 또 다른 리더를 성장 시킴으로써 자신의 업무 과중을 낮추기를 독려하고 있다. 실무를 하다보면 그런 딜레마에 빠지게 된다. 새로운 인력(신입) 이 추가되더라도 해당 인력에게 이슈 트러블 슈팅을 맞기면 n 시간, 직접하면 20분이라면 해당 인력에게 이슈를 맞길것인가 하는것이다.

이런 내용을 인지한 상태에서 업무를 해본적이 없었기에 나는 어땠을까를 돌아보면 사이드 프로젝트를 진행할때는 보통 내가 하는것은 70% 맡기는건 30% 였었다. 그리고 막힐때면 과중해진 업무에 몸서리치곤 했다. 참 바보 같았던것 같다.

| 일부 내용
마침내 자생력을 갖춘 조직을 만들어냈다고 가정해봅시다. 여러분은 더 이상 단일 장애점이 아닙니다.
축하드려요! 그런데 이제부터는 무슨 일을 해야 할까요?
대답하기 전에 여러분은 스스로를 해방시켰다는 사실을 떠올리세요. '늘 떠라나'를 실천할 수 있는 자유가 주어진 것이죠.

더 이상 '단일 장애점' 이 아니라니.

많은 기업에서 좋은 팀문화와 최고의 복지는 팀원 이라는 타이틀을 강조하는 이유를 알겠다.

| 일부 내용
'늘 떠나라' 는 매크로 매니징의 다른 이름 입니다.

허허... 마이크로 매니징이라는 말은 많이 들어보았어도, 매크로 매니징이라는 말을 이책에서 처음 보았다.

자생력 있는 팀을 만들어 언제든 '늘 떠나라' 는 상태가 가능한게 매크로 매니징이며, 이에 반대되는것은 '단일 장애점' 이 될 수 있는 마이크로 매니징이다.

| 일부 내용
리더로서 여러분에게 주어진 가장 값진 자원은 '자신의 제한된 시간, 집중력, 에너지' 입니다.
스스로의 내면을 보호할 방법을 익히지 못한 채 팀의 책임과 영향력만 공격적으로 키워버리면 확장은 오히려 파멸로 가는 지름길로 돌변 합니다.

비록 리더는 아니지만, 이말에 진정으로 공감 한다.

때로는 시간이 때로는 집중력이 때로는 에너지가 무한한 것인것 처럼 살고 있지만, 이것의 총량은 정해져 있고 쓰면 쓸 수록 소비된다는것을 인지해야 한다.

이번 6장에서는 '성장하는 조직 이끌기' 를 주제로 한다. 팀을 이끄는 위치에 있는 사람이 읽으면 많은 도움이 되는 장이라고 생각한다.

더욱이 마이크로매니징, 매크로 매니징, 단일 장애점 등의 개념과 더불어 이야기하는 예시는 생각의 폭을 훨씬 넓혀주는데 도움이 된다.

구글 엔지니어는 이렇게 일한다. | #5장 팀 이끌기를 읽고

TLOWAC — Sun, 17 Nov 2024 01:56:01 +0900

#5 팀 이끌기를 읽고

| 일부 내용
엔지니어링 관리자는 자신이 관리하는 팀의 구성원 모두의 성과, 생산성, 행복을 책임져야 합니다.
그와 동시에 팀에서 만드는 제품의 사업적 요구까지 충족시켜야 하죠. 하지만 사업적 요구와 개별 팀원의 요구가 항상 일치하는 것은 아니라서 이따금 관리자를 난처한 상황에 놓이게 합니다.

진짜 어려운 주제이고, 완벽한 정답을 찾기란 불가능하지 않을까 라는 생각이 든다.

실제 업무, 사이드 프로젝트 진행 과정에서도 각각의 팀원들의 니즈에 맞춘 업무 분배는 쉽지 않다.

누구나 반복적인 일이 아닌 커리어에 도움이 되는 성능 개선, 비용절감, 지표 개선등과 연관된 업무를 할당 받고 싶어 할것 이기 때문이다.

소규모의 팀에서도 이런 목소리가 나왔었는데, 구글과 같은 대규모의 팀은 어떨지 짐작이 되지 않는다.

더욱이 개발팀과 경영팀이 서로 다른 목소리를 내기 시작하면 '사업적 요구와 개별 팀원의 요구' 를 맞추기란 더 어려워진다.

그중 대표적인 예로는 기술부채의 처리 vs 신규 기능 개발이 있다.

내가 경험한 실무에서는 대부분 "신규 기능 개발 진행 및 잔여 시간 기술 부채 처리" 로 진행 되었다.

즉, 신규 기능 개발이 일찍 마무리 되면 남는 시간에 기술 부채 처리를 하는 방식으로 병렬 수행하는것이었다.

팀 구성원의 성과, 생산성, 행복, 사업적 요구까지 충족 시키는곳이 있다면... 거기가 개발자의 천국이 아닐까...

| 일부 내용
팀의 역량

뭔가 뼈맞은 느낌이었다.

여태까지 내가 몰두했던것은 팀원 개개인의 역량이었지, 팀의 역량이라고 생각해본적이 없기 때문이다.

한편으로는 부끄러워진다.

개발 기획 / 트러블 슈팅 & 이슈 문서 작성 / ERD 테이블 설계 문서 작성 / 개발 기획 프로세스 점검 / 세미나 진행등 행동 자체만을 놓고보면 팀의 역량을 위한다고 볼 수 있지만, 그것을 명시적으로 생각하고 의도하지는 않았던것 같았다.

이 책에서 얻어가는것이 또 하나 생겼다.

| 일부 내용
완전히 번아웃 되지 않고서 두 역할을 동시에 수행하기란 너무도 어렵기 때문이죠.

여기까지 인지하고 실제로 행동한다는 점에서 정말 놀라웠다.

대부분은 한명에게 두 역할을 기대하거나 일 잘하는 한명에게 일감을 몰아주는 경우가 많았다.

| 일부 내용
TLM (Tech Lead Manager) 역할을 만만치 않아서 자신의 일, 위임, 사람 관리 사이에서 균형을 잡는 요령을 배워야 합니다.
그래서 백전노장 TLM 으로 부터 고차원적인 멘토링과 지원을 받아야 하는 게 보통이죠.

놀라움의 연속이다.

멘토가 필요한건 신입사원 뿐만 아니라 파트장, 팀장도 멘토가 필요하다는 말이기 때문이다.

나도 직책이 변경되었을때, 갑작스레 늘어난 책임과 업무에 갈팡질팡 했었기에 더욱이 공감이 갔다.

그 시절의 나에게 멘토가 있었다면 어땠을까. 지난날의 과거지만 반추해보게 된다.

| 일부 내용
자존심 버리기의 마지막은 간단하지만 많은 엔지니어가 실천하지 못하는 일입니다.
바로 '실수 했다면 사과하기' 입니다.

나는 그렇게 생각한다. 살면서 진심으로 사과할 '기회' 가 몇번이나 있을까.

때로는 잘못을 인지했음에도 시간이 흘러버리거나, 때로는 형식적인 사과를 한다. 하지만, 실수를 인지하고 이를 사과할 수 있는 기회가 주어진다는건 과거와 현재는 바꾸지 못하더라도 미래의 태도는 바꿀 수 있을것이다.

나는 사이드 프로젝트를 진행하며 중간 점검 단계에서 잘못을 지적 받은적이 있다. 팀 중간 피드백(문서) 이었었는데 다소 직설적인 단어 사용으로 팀원들에게 의도치 않은 상처를 주었다. 이 과정에서 잘못을 지적 받고 작성 의도를 해명하고 용서를 구하는 일례의 과정이 나를 한단계 더 성장 시켰다고 생각하며, 실무를 하며 겪었던 수많은 상황들이 머리속을 스쳐갔다. 처음이었던것 같다. 어떤 경험을 통해 실무를 하며 쌓여있던 마음속 응어리가 풀어졌던것은.

그렇기에 나는 이것을 기회라고 생각한다.

( 감사하게도 팀원분들은 너그럽게 이해해주시고 사과를 받아주셨다. )

| 일부 내용
테크 리드로서 가장 실천하기 어려운 일을 뽑으라면 '내가 하면 20분이면 끝날 일을 세 시간씩 메달려 있는 주니어 팀원 지켜보기' 를 빼놓을 수 없습니다. 스스로 배울 기회를 주는 일은 훌륭한 리더십에서 빠질 수 없는 요소이지만 특히 처음에는 매우 고통스럽습니다.

윽... 뼈가... 부서진것 같다.

( 나는 아직도 주니어다... )

| 일부 내용
행복한지 확인하기
리더로서 팀의 생산성을 장기적으로 더욱 끌어올리려면 팀원들이 행복해하는지를 확인하는 데도 시간을 써야 합니다.

당연하게 생각하면서도, 막상 일을 시작하면 기대하지 않는것 같다.

팀원일때는 '행복은 각자가 챙기자' 가 주였다.

다음에 실무에서든 사이드 프로젝트에서든 팀을 이끌 기회가 있다면, 번아웃과 피로 누적을 피하는 방법과 팀원들의 심리적 안정감 그리고 행복한지 확인하기 를 머리속에 인지한 상태에서 여러가지 방법을 시도해 봐야겠다.

책에서는 1 on 1 면담, 지저분 하고 표 안나는 일을 고르게 분배, 대체 휴가등 많은 방법을 소개해줬다.

| 일부 내용
처음 관리자가 되었을때 조직 차원에서 벌어지는 무질서와 뭐 하나 계획대로 돌아가는게 없는 모습에 몸서리 쳤습니다.
그래서 이 조용하던 회사에 갑자기 무슨일이 벌어진 것인지 다른 관리자에게 물었죠.
어리숙했던 저에게 신경질적인 웃음과 함께 돌아온 대답은 이랬습니다. 회사는 원래부터 혼란스러웠다고, 다만 전임 관리자가 팀원들을 혼란으로부터 보호해주고 있었을 뿐이라고 말이죠.

갑작스러원 관리 인원의 퇴사와 동시에 파트장으로 승진하고 들어간 첫 회의가 기억난다.

아무 준비 없이 들어간 회의에서 나는 심연을 보았다...

이번 5장에서는 '팀 이끌기' 를 주제로 한다. 실제 실무를 경험하거나 사이드 프로젝트를 경험한 사람이라면 누구나 공감이 가고 도움이 될만한 내용들이 적혀있다. 더불어, 내가 생각한 선 밖의 새로운 생각들 또한 책을 통해 읽어 볼 수 있어 적용해볼 기회가 있다면 시도해보고 싶다.

구글 엔지니어는 이렇게 일한다 #4장 공정 사회를 위한 엔지니어링을 읽고

TLOWAC — Sat, 16 Nov 2024 08:14:01 +0900

#4 공정 사회를 위한 엔지니어링 읽고

| 일부 내용
그렇지만 학위가 있다고 해서 자동으로 좋은 엔지니어가 되는것은 아닙니다.
학위가 있는 사람만이 제품을 설계하고 구축 할 수 있다는 믿음도 깨야 합니다.

지금까지 스타트업에서의 회사 생활을 돌이켜보면, 자기의 전공이 아닌 일을 하는 사람이 많았다.

하지만, 그럼에도 불구하고 뛰어나 실력과 그 베이스가 돋보이는 경우를 많이 보았다.

대학교 졸업전에는 당연하게 전공과 관련된 일을 하게 될것이라 믿어 의심치 않았지만, 실제 사회에 나와보니 자신의 전공을 살리는것이 쉬운편은 아니라는것을 알게 되었다. 그렇기에 다른 분야의 직무에 도전하는 사람들의 용기와 도전에 응원을 보낸다.

| 일부 내용
엔지니어가 되려면 기술이 적성에 맞아야 함은 당연하고, 무언가를 만들어야 할 때와 아닐 때를 구분하는 안목도 갖춰야 합니다.

실제로 사이드 프로젝트를 진행하면서 기획을 하다보면 주어진 기간내 개발 가능한 역량보다 많은 기능들을 추가하게 된다.

이 상태에서 개발을 시작하게 되면, 개발 막바지에 기능을 축소하는 해프닝이 발생한다.

그래서, 기획 회의를 한뒤에는 우리가 기획한 기능들을 1차 개발 기간내 개발을 완료할 수 있는지 판단하고 덜어내는 작업을 하게 된다.

기능별 우선순위를 설정하고 중요한 기능을 상단에 배치하고, 우선순위가 낮은 것들을 2차 개발로 넘기거나 다시 기획 회의를 하여 조율하는 작업을 진행한다.

참 어려운것 같다.

바꿔 말하면, 내 실력을 파악하고 예상 개발 기간을 설정하고 그에 맞게 사이드 프로젝트 기능을 추려야 하기 때문이다.

[short-term] prisma/prisma-example 기여하기

TLOWAC — Fri, 15 Nov 2024 22:57:40 +0900

들어가며

이번 글에서 prisma/prisma-example 프로젝트에 기여한 과정에 대해서 정리해 보았습니다.

prisma-example 프로젝트에서 prisma 예시를 살펴 보는 과정에서 unused import 를 발견하게 되었고, 이를 기반으로 코드를 수정하는 issue 와 pr 을 만들었습니다. 처음에는 반응이 없어 필요치 않은 작업을 한것인가 라는 생각이 들었었는데, 어느날 github profile 에 prisma 로고가 떠있길래 확인해보았더니 운이 좋게도 PR 이 정상적으로 merged 된것을 확인 할 수 있었습니다 :)

특정 프로젝트에 Contribute 할때의 방식은 아래와 같이 정리할 수 있습니다.

1. 기여할 내용을 찾는다.

2. 해당 내용을 어떻게 수정할지 정리하여 issue 를 남긴다.

3. 해당 내용을 수정한 Pull Request 를 만든다.

4. Reviewer 의 답변을 기다린다.

5. Merge 또는 Reviewer 의 요청 사항을 반영한다.

✅ Issue & Pull Request 만들기

1) Contribute 하고자 하는 내용을 issue 로 정리하기

issue 에서는 내가 어느 부분의 코드를 어떻게 수정할것인지 대략적인 설명을 작성하였습니다.

prisma 예제에서 import { INestApplication } from '@nestjs/common' 코드는 더 이상 사용되지 않기에 해당 코드를 제거하기 위해 실제 예제 코드와 수정할 부분의 코드를 하이라이트하여 설명을 작성하였습니다.

해당 issue 는 추후에 PR 에서 history 를 파악하기 위해 링크로 첨부될 예정 입니다.

2) PR 제작 하기

PR 에서는 AS-IS (수정전) / TO-BE (수정후) 코드 모습을 통해 Reviewer 가 한눈에 수정 사항을 파악 할 수 있도록 설명을 작성하였습니다.

추가로, 왜 해당 PR 을 만들게 되었는지 history 내역을 알려주기 위해서 사전에 만들어 놓았던 issue 의 링크또한 첨부하였습니다.

마무리하며

운이 좋게도 매번 사용하는 prisma-orm 의 Contributer 가 될 수 있었습니다.

자칫 어렵게만 느껴졌던 Contribute 도 이제는 한결 편안하게 다가오는것 같습니다.

[책 정리] 구글 엔지니어는 이렇게 일한다 #3 지식 공유를 읽고

TLOWAC — Thu, 14 Nov 2024 00:45:23 +0900

#3 지식 공유를 읽고

| 일부 내용
지식을 전파할 메커니즘

나도 프로그래밍을 이제 막 시작하는 시기에는 질문을 잘하지 못했다. 그렇기 때문에 내가 원하는 답을 얻기도 쉽지 않았고, 이를 기반으로 문제를 해결할 실마리를 마주하는것도 어려웠던때가 있었다. 더불어, 안그래도 초보인데 질문을 잘못해서 질책을 받으면 어떻게 하지? 이걸 물어봐도 되나? 라는 의문을 항상 품고 있었다.

책에서도 질문는 하는 과정에서의 심리적 안정성에 대해서 말해주고 있다.

물론, 지금은 실무를 겪으며, 이러한 생각들은 나은 방향으로 변화했다. 내가 부족해보일까 두려워 질문을 주저하지 않고 질문을 하려고 한다.

더불어, 문서화의 중요성 또한 이야기 하고자 하는것을 느꼈다.

정보의 중복과 파편화, 전달의 왜곡은 질문 / 답변 / 지식 / 경험을 문서로 만들지 않으면, 흔하게 발생하기 때문이다.

| 일부 내용
단일 장애점 (Single point of fauilre, SPOF)
좋은 의도에서 단일 장애점이 시작되기도 합니다.
"여러분을 위해 내가 다 처리하지" 같은 마음에서 말이죠.
하지만, 단기 효율은 높여주는 대신 장기 확장성을 희생하는 꼴 입니다.

현업을 하다보면, 이슈가 발생하고 이에 대해서 해결하는 사람이 나타나게 된다.

그러면, 이에 대한 경험치는 누가 얻게 되는건가? 를 생각해보면, 팀이 아닌 문제를 해결한 개인에게 집중된다.

다음에 비슷한 류의 이슈가 발생하게 되면, 이전의 동일한 문제의 경험치가 쌓여 있는 개발자가 문제를 순식간에 해결하고 해당 이슈는 closed 된다.

여기까지는 해피엔딩이다.

하지만, 해당 개발자가 퇴사를 하거나 부서 이동, 긴 휴가를 쓰는 과정에서 비슷한 이슈가 또 발생한다고 가정하면, 해당 이슈에 대해 경험치가 없는 개발자가 해당 이슈를 다시 처음부터 디버깅하며 문제를 해결하거나 퇴사/휴가 상태의 개발자에게 연락을 해야한다.

그렇기에 포스트 모멘텀 문서, 이슈 문서등 문서화를 통한 지식의 전파가 중요하다.

나도 현업에서 개발을 진행할때 AWS RDS 의 CPU 스파이크 현상을 해결하며 이를 문서로 정리하였고, 내가 휴가중에 발생한 비슷한 문제를 팀 동료가 문서를 통해 실마리를 잡아 해결했다는 이야기를 휴가 복귀하고 들었었다.

https://helicopter55.tistory.com/82

[AWS 트러블 슈팅] RDS CPU 점유율 99% 스파이크 현상 트러블 슈팅

목차 0. 들어가며 1. RDS CPU 99% 이슈 발생 및 대응 2. RDS 인스턴스 타입 변경 이후에도 동일한 이슈 재발생 3. 또 다른 RDS 인스턴스의 비정상 지표 패턴 4. 작업전 지표와 작업후 지표 비교 5. 후속 대

helicopter55.tistory.com

| 일부 내용
앵무새처럼 흉내내기
이해하지 못한 상태로 흉내만 내는것을 말합니다.
이증상에 빠진 사람은 목적을 이해하지 못하고 무의식적으로 기존 패턴이나 코드를 따라 합니다.

대학교, 학원등 다양한 활로를 통해 개발을 접하고 학습하며 노력하고, 현업에 참여하게 되면 기존의 방식과는 전혀 다른 구조의 프로젝트, 커스터 마이징된 프레임워크등을 마주하게 된다.

실제로 연차가 쌓이고 여러 트러블 슈팅을 겪으며, 새로운 프로젝트 개발을 완료하면서 실력을 쌓는 과정이 없었다면, 나는 아직 까지도 책에서 말하는 "앵무새 처럼 흉내내기" 단계에 머물러 있었을것이다.

| 일부 내용
초심자가 저지르는 가장 큰 실수는 무언가 막혔을 때 질문하지 않는것 입니다.
혼자서 극복해내고 싶다거나 ' 너무 기초적인' 질문이란 소리를 든는게 두려워서 일 수 있습니다.
혹은, '도움을 청하기 전에 최대한 노력해봐야해' 라고 생각할지 모릅니다.
이 함정에 빠지지 마세요!

프로그래밍을 업으로 삼거나 프로그래머가 되기 위해 노력하고 있는 사람들 중 대부분은 이러한 고민을 해봤지 않았을까 생각된다.

하지만, 책에서는 이러한 내용을 "함정" 으로 정의하고 빠지지 말라고 당부하고 있다는것에 한편으로는 웃음이 났다.

( 나도 한때는 그랬었는데... )

많은 사람들이 질문의 필요성을 강조하지만, 현업에 참여하게 되면 회바회, 부바부, 사바사 란말을 괜히 있는게 아니란걸 알게 된다.

내가 어디 있느냐에 따라서 이런 고민을 할 필요조차 없을 수 있고, 혹은 이런 고민만을 하게 될 수 도 있다.

그렇기에 개발 조직과 개발 문화에 대해서 다시금 생각해보게 된다.

| 일부 내용
구글에서는 '누글러 (구글에 새로 입사한 직원)' 가 합류하자마자 분위기를 만들어주려 노력합니다.
멘토 정해주기는 누글러에게 심리적 안전을 심어주는 효과적인 방법 입니다.
멘토의 공식 역할은 궁금한 점에 답해주고 누글러의 성장을 돕는 것입니다.

심리적 안정을 위한 사수의 중요성에 대해 다시금 되새긴다.

더불어, 나는 심리적 안정을 위한 사수 였는지 반추하게 된다.

바쁜 시간의 업무속..

조금 더 친절하게

조금 더 자세하게

조금 더 많은 내용을
알려주지 못했음이 아쉬움으로 남는다.

과거는 바꿀 수 없음을 알기에 앞으로의 미래에 이를 인지하고 행동해야겠다.

| 일부 내용
'무언가를 옮기거나 바꾸려면 그게 왜 그 자리에 있는지 부터 이해하자' 라고 말하는 체스터슨의 울타리 원칙을 떠올려보세요.

외주를 맡긴 프로젝트를 인수 인계 받거나 기존의 레거시 프로젝트를 마이그레이션 하는 경우, 이런 생각을 가지게 된다.

"이게 뭐지"

내가 사용하지 않는 방식이기에

내가 사용하지 않은 라이브러리이기에

내가 사용하지 않은 언어이기에

등등 다양한 이유로 처음에는 거부감을 느끼게 된다.

나도 현업에서 갑자기 외주를 맡긴 프로젝트를 인수 인계 받아 서비스를 해야하는 상황에 동일하게 반응했다.

하지만, 시간을 들여 프로젝트 구조를 파악하고 커스터마이징된 부분을 파헤치다보면 어떤 의도로 이렇게 코드를 작성했는지 파악되는 순간이 오고 오히려 이러한 방식이 더 효율적이지 않을까 하고 생각이 변했던적도 있었다.

[알고리즘 - 기초] Python 인접 리스트 구현하기 ( feat. 유향 | 무향 )

TLOWAC — Wed, 13 Nov 2024 03:45:26 +0900

들어가며

DFS / BFS 구현 과정에서 데이터를 입력 받아 정리할때 사용하는 인접 리스트와 인접 행렬 방식이 있으며,

이번 글에서는 그중에서도 인접 리스트에 대해서 정리해 보았습니다.

이번글에서는 아래의 3가지 내용을 소개하고자 합니다.

첫번째로는 인접 리스트 구현 ( 유향 )

두번째로는 인접 리스트 구현 ( 무향 )

세번째로는 실제 PS 에서 사용하는 방식

✅ 인접 리스트 구현하기

정점과 간선으로 이루어져 있는 그래프 구조의 데이터를

1) 유향 ( 방향성이 있는 간선 ) 인접 리스트 구현하기

1-1) 유향 ( 방향성이 있는 간선 ) 인접 리스트

1-2) 실행 결과

1-3) 인접 리스트 구현

class DirectedGraph:
    def init(self):
        self.adjacency_list = {}

    def add_vertex(self, vertex):
        if vertex not in self.adjacency_list:
            self.adjacency_list[vertex] = []

    def add_edge(self, source, destination):
        if source in self.adjacency_list and destination in self.adjacency_list:
            self.adjacency_list[source].append(destination)

    def print_graph(self):
        for vertex in self.adjacency_list:
            print(f"{vertex}: {self.adjacency_list[vertex]}")

# 예시 사용
graph = DirectedGraph()

graph.add_vertex(1)
graph.add_vertex(2)
graph.add_vertex(3)
graph.add_vertex(4)
graph.add_vertex(5)

graph.add_edge(1, 2)
graph.add_edge(1, 4)
graph.add_edge(2, 3)
graph.add_edge(2, 4)
graph.add_edge(3, 4)
graph.add_edge(3, 5)
graph.add_edge(4, 5)

graph.print_graph()

2) 무향 ( 방향성이 없는 간선 ) 인접 리스트 구현하기

2-1) 무향 ( 방향성이 없는 간선 ) 인접 리스트

2-2) 실행 결과

2-3) 인접 리스트 구현

class UndirectedGraph:
    def __init__(self):
        self.adjacency_list = {}

    def add_vertex(self, vertex):
        if vertex not in self.adjacency_list:
            self.adjacency_list[vertex] = []

    def add_edge(self, vertex1, vertex2):
        if vertex1 in self.adjacency_list and vertex2 in self.adjacency_list:
            self.adjacency_list[vertex1].append(vertex2)
            self.adjacency_list[vertex2].append(vertex1)

    def print_graph(self):
        for vertex in self.adjacency_list:
            print(f"{vertex}: {self.adjacency_list[vertex]}")

# 예시 사용
graph = UndirectedGraph()

graph.add_vertex(1)
graph.add_vertex(2)
graph.add_vertex(3)
graph.add_vertex(4)
graph.add_vertex(5)

graph.add_edge(1, 2)
graph.add_edge(1, 4)
graph.add_edge(2, 3)
graph.add_edge(2, 4)
graph.add_edge(3, 4)
graph.add_edge(3, 5)
graph.add_edge(4, 5)

graph.print_graph()

✅ PS 에서 풀이를 할때 사용하는 방식

데이터 예시

V (정점 갯수) | 5

E (간선 갯수) | 7

edges (시작점, 끝점) | [(1,2), (1,4), (2,3), (2,4), (3,4), (3,5), (4,5)]

# 1 ~ V 까지 리스트를 사용하기 위해 V + 1 을 하여 빈 배열 리스트를 생성
AL = [[] for _ in range(V+1)]

# 주어진 edge 의 갯수 만큼 순회하며 s(시작점) , e(끝점) 데이터를 배열에 입력
for s,e in edges:
	AL[s].append(e)
    # AL[e].append(s) // 무향 그래프인 경우 사용
    
for x in AL:
	print(x)

[책 정리] 구글 엔지니어는 이렇게 일한다. | #2장 팀워크 이끌어내기를 읽고

TLOWAC — Tue, 12 Nov 2024 00:44:56 +0900

2장 팀워크 이끌어내기를 읽고

| 구글 엔지니어는 이렇게 일한다. #2장 팀워크 이끌어내기
| 일부 내용
사람은 완벽하지 않습니다. 그래서 인간을 '간헐적 버그들의 집합 에 가깝다고 이야기하곤 하죠. 하지만 동료에 내재된 버그를 이해하려면, 무엇보다 여러분 내면에 서식하는 버그를 먼저 이해해야 합니다.

이 부분을 읽고 가장 먼저 생각난것은 내가 최근까지도 반추하고 과거의 경험과 기록을 톺아보며, 파악하려 애썼던 "너 자신을 알라" 라는 말이 었다. 에고, 자기 객관화등 다양하게 불리우는 이 말은 쉬운것 같으면서도 쉽지 않다.

나름 성공이라 정의 했던 과거의 기억과 경험이 작금의 시점에서 반추하며 돌아보았을때, 그것이 그때 당시 나의 기준에서는 성공이었지만 경험치가 쌓인 지금의 나에게는 비참한 실패였구나를 깨닳는것은 오래 걸리지 않았지만, 그것을 인지하고 인정하기까지는 많은 시간이 걸렸다.

| 일부 내용
숨기는 건 해롭다.
------
'홀로 일하기'는 '함께 일하기' 보다 본질적으로 더 위험합니다. 다른 사람이 아이디어를 훔친다거나 여러분이 똑똑하지 않다고 생각하는게 두렵더라도, 잘못된 일에 여러분의 천금 같은 시간을 낭비 할 가능성을 더 걱정해야 합니다.

코딩테스트 레포, 토이 프로젝트 레포등을 private 로 설정하고, public 으로 바꿀때면 내 코드가 남들에게 너무나 수준 낮게 보이지 않을까 걱정했었다. 개발자라면 누구나 한번쯤은 하는 고민이다. 개발자가 아니라도 "임포스터 증후군" 는 누구나 한번쯤은 하는 고민이다.

하지만, 사회에 나와 실무를 겪으면, 협력과 협업은 선택이 아닌 필수다.

결국엔 저마다의 방법으로 이를 극복해야 한다.

부족한 코드를 공유하고 막힌 부분을 질문하며 하나의 팀으로 문제를 헤쳐 나가 프로젝트를 마무리하는 경험을 몇번 해보면 일부 혼자만의 시간도 필요하지만, 이를 공유하는 시간도 필요함을 인지하게 되었다. 더욱이 이따금 스터디에서 처음 만난 사람들과 사이드 프로젝트를 진행하며, 지식의 확장과 pain point 를 같이 극복하는 경험은 너무나도 값졌다. 이러한 경험들이 하나씩 쌓일때면, 이를 실천하고자 부단히 노력하게 된다. 내가 얻은 긍정적 영향을 다른 사람도 얻을 수 있기를 바라면서.

| 일부 내용
만약 당신에게 필요한 시스템이 있다면 그 시스템이 당신의 일을 어떻게 도울 수 있을지 연구하세요. 그러면 시스템이 당신의 바람대로 움직이게 하는 방법을 터득할 것입니다.
-----

머리를 한대 얻어 맞은것과 같은 충격이었다.

시스템에 맞춰 일한것은 비교적 떠올리기 쉬웠지만, 시스템이 일하는것을 돕는것은 떠올리기 쉽지 않았기 때문이다.

| 일부 내용
관계는 언제나 프로젝트보다 오래 지속됩니다. 동료들과 끈끈해지면 여러분이 필요할 때 기꺼이 자신들의 수고를 마다하지 않을 것 입니다.

사이드 프로젝트에서 같이 백엔드를 담당했던 팀원이 생각났다. 무난한 개발 실력과 높은 사회성.

그전까지는 에러 사이를 종횡무진하며 문제를 해결하는 천재 개발자를 실무에서 봐왔었기 때문에 나도 이런 모습이 되고자 지향했던것 같다. 하지만, 너무나 당연히 생각했던 사회성에 대해 다시금 인지하게된 지금은 이것이 경쟁력을 갖춘 개발자의 모습이라고 생각하게 됬다.

물론, 훌륭한 개발지식에 대한 지향도 좋지만, 너무 치우쳐졌던것 같다. 다시금 균형을 잡을 필요가 있어 보인다.

[golang 1% 이해하기] godotenv | dotenv 환경 변수값 활용하기

TLOWAC — Mon, 11 Nov 2024 06:04:14 +0900

들어가며

지금까지는 viper 를 활용한 환경 변수 값 활용에 대해서 정리했습니다.

이번 글에서는 또 다른 도구인 godotenv 를 사용해 환경 변수 값을 활용하는 방법을 정리해 보았습니다.

viper 를 사용하는 방식이 궁금하신분들을 위해 링크를 남겨 놓겠습니다 !
https://helicopter55.tistory.com/94

https://helicopter55.tistory.com/95

✅ godotenv 설치 및 환경 변수 활용하기

1) godotenv 설치하기

go get 명령어를 통해 godotenv 라이브러리를 다운로드 받습니다.

go get github.com/joho/godotenv

go get github.com/joho/godotenv

2) 환경 변수 활용하기

godotenv 를 통해 .env 파일에서 환경 변수 값을 가져오는 방식은 viper 와 단순히 비교해보자면, 무척이나 간단합니다.

godotenv.Load() 을 통해 .env 파일에서 환경 변수값을 불러오고

os.Getenv("환경변수명") 을 통해 환경 변수값을 활용하면 됩니다.

package main

import (
    "log"
    "os"

    "github.com/joho/godotenv"
)

func main() {
  err := godotenv.Load()
  if err != nil {
    log.Fatal("Error loading .env file")
  }

  dbPort := os.Getenv("DB_PORT")
  dbHost := os.Getenv("DB_HOST")
}

✅ env 맵핑을 사용하는 방식

경우에 따라서는 .env 파일에서 환경변수값을 불러오고 EnvConfig 구조체에 값을 넣는 방식을 사용 합니다.

이럴때 사용하면 좋은게 바로 env 입니다.

라이브러리 이름이 env 이기 때문에 혼동이 올 수도 있습니다.

하지만, 기능은 단순히 환경 변수를 파싱해서 구조체에 할당하는 역할만 합니다.

1) godotenv 설치하기

go get 명령어를 통해 env 라이브러리를 다운로드 받습니다.

go get github.com/caarlos0/env/v11

go get github.com/caarlos0/env/v11

2) 환경 변수를 EnvConfig 구조체에 맵핑하기

go get 명령어를 통해 env 라이브러리를 다운로드 받습니다.

`env:DB_HOST,required` 와 같이 구조체 필드에 할당하고자 하는 환경 변수명을 작성 합니다.

이후에는 env.Parse(config) 를 통해 실제 환경변수 값을 envConfig 구조체에 맵핑 합니다.

package main

import (
	"log"

	"github.com/caarlos0/env"
	"github.com/joho/godotenv"
)

type EnvConfig struct {
	ServerPort string `env:"SERVER_PORT,required"`
	DBHost     string `env:"DB_HOST,required"`
	DBName     string `env:"DB_NAME,required"`
	DBUser     string `env:"DB_USER,required"`
	DBPassword string `env:"DB_PASSWORD,required"`
}

func NewEnvConfig() *EnvConfig {
	err := godotenv.Load()

	if err != nil {
		log.Fatalf("Unable to load .env: %e", err)
	}

	// EnvConfig 참조
	config := &EnvConfig{}

	// 환경변수 값 파싱
    // 환경변수 값 맵핑
	if err := env.Parse(config); err != nil {
		log.Fatalf("Unable to load variables from .env: %e", err)
	}

	return config
}

마무리하며

이번 글을 통해서 godotenv 를 활용해 .env 파일의 환경 변수 값을 가져오는데 도움이 되었으면 좋겠습니다 :)

실제 동작하는 코드는 여기서 확인 하실 수 있습니다.

[golang 1% 이해하기] viper | dotenv 환경 변수값을 읽는 기능 도입 하기 #2 mapstructure 를 사용해 Env 구조체 할당하기

TLOWAC — Sun, 10 Nov 2024 00:03:59 +0900

들어가며

이번글에서는 지난번 글의 연장선으로 viper 에서 mapstructure 를 활용해 환경 변수 값을 활용하는 방법을 정리하였습니다.

https://helicopter55.tistory.com/94

[golang 1% 이해하기] viper | dotenv 환경 변수값을 읽는 기능 도입 하기 #1 Config 전역 변수를 활용하기

들어가며이번 글에서는 viper 를 사용해서 dotenv 에 정의된 환경 변수를 읽어오는 방법에 대해서 정리해 보았습니다. godotenv 라이브러리를 사용하는 방식과 mapstructure 를 사용해 Env 구조체(s

helicopter55.tistory.com

✅ Viper 설치 및 mapstructure 를 사용해 Env 구조체 할당하기

1) viper 설치하기

go get 명령어를 통해 viper 라이브러리를 다운로드 받습니다.

go get github.com/spf13/viper

go get github.com/spf13/viper

2) Env struct 생성하기

LoadEnvConfiguration() 이후에 env.AppEnv, env.DBHost, env.DBPort 와 방식으로 사용하기 위해 Env struct 를 mapstructure 을 사용해 작성 합니다. .env 파일에 작성된 DB_PORT 환경 변수값은 Env 구조체의 DBPort 에 맵핑 됩니다.

mapstructure | map[string]interface{}로 표현된 설정 값을 사용자가 정의한 구조체로 손쉽게 매핑할 수 있도록 해줍니다.

type Env struct {
	AppEnv                 string `mapstructure:"APP_ENV"`
	ServerAddress          string `mapstructure:"SERVER_ADDRESS"`
	ContextTimeout         int    `mapstructure:"CONTEXT_TIMEOUT"`
	DBHost                 string `mapstructure:"DB_HOST"`
	DBPort                 string `mapstructure:"DB_PORT"`
	DBUser                 string `mapstructure:"DB_USER"`
	DBPass                 string `mapstructure:"DB_PASS"`
	DBName                 string `mapstructure:"DB_NAME"`
	AccessTokenExpiryHour  int    `mapstructure:"ACCESS_TOKEN_EXPIRY_HOUR"`
	RefreshTokenExpiryHour int    `mapstructure:"REFRESH_TOKEN_EXPIRY_HOUR"`
	AccessTokenSecret      string `mapstructure:"ACCESS_TOKEN_SECRET"`
	RefreshTokenSecret     string `mapstructure:"REFRESH_TOKEN_SECRET"`
}

3) LoadEnvConfiguration 제작하기

viper 를 통해 .env 파일에서 환경 변수 값을 가져오고 mapstructure 을 사용해 Env 구조체에 맵핑 하기 위해 LoadEnvConfiguration 함수를 제작 합니다.

이렇게 불러온 .env 파일의 환경 변수 값은 main 에서 env.DBName 과 같은 방식으로 호출 하여 사용 할 수 있습니다.

package main

import (
	"fmt"
	"log"

	"github.com/spf13/viper"
)

func main() {

	env := LoadEnvConfiguration()
	dbName := env.DBName
	fmt.Println("dbName", dbName)

	secret := env.AccessTokenSecret
	fmt.Println("secret", secret)
}

type Env struct {
	AppEnv                 string `mapstructure:"APP_ENV"`
	ServerAddress          string `mapstructure:"SERVER_ADDRESS"`
	ContextTimeout         int    `mapstructure:"CONTEXT_TIMEOUT"`
	DBHost                 string `mapstructure:"DB_HOST"`
	DBPort                 string `mapstructure:"DB_PORT"`
	DBUser                 string `mapstructure:"DB_USER"`
	DBPass                 string `mapstructure:"DB_PASS"`
	DBName                 string `mapstructure:"DB_NAME"`
	AccessTokenExpiryHour  int    `mapstructure:"ACCESS_TOKEN_EXPIRY_HOUR"`
	RefreshTokenExpiryHour int    `mapstructure:"REFRESH_TOKEN_EXPIRY_HOUR"`
	AccessTokenSecret      string `mapstructure:"ACCESS_TOKEN_SECRET"`
	RefreshTokenSecret     string `mapstructure:"REFRESH_TOKEN_SECRET"`
}

func LoadEnvConfiguration() *Env {
	env := Env{}
	viper.SetConfigFile("config.env")

	err := viper.ReadInConfig()
	if err != nil {
		log.Fatal("Can't find the file .env : ", err)
	}

	err = viper.Unmarshal(&env)
	if err != nil {
		log.Fatal("Environment can't be loaded: ", err)
	}

	if env.AppEnv == "development" {
		log.Println("The App is running in development env")
	}

	return &env
}

✴️ 아쉬운점

처음에는 Env 구조체의 필드에 ServerConfig, DBConfig 와 같은 구조체를 만들어 사용할려고 했었다.

node.js 에서는 이런 방식으로 많이 사용했었기에 이런 방법을 찾아보고 있었다.

하지만, 아직은 숙련도가 부족한 탓인지 .env 환경 변수값을 가져온 케이스를 작성하지 못했다.

추후에 방법을 알게 되면 링크를 여기에 추가해놓겠습니다 :(

아래는 제가 처음에 의도했던 코드 입니다.

type Env struct {
	ServerConfig ServerConfig
	DBConfig DBConfig
}

type ServerConfig struct {
	AppEnv			string `mapstructure:"APP_ENV"`
	Address			string `mapstructure:"SERVER_ADDRESS"`
}

type DBConfig struct {
	Host                 string `mapstructure:"DB_HOST"`
	Port                 string `mapstructure:"DB_PORT"`
	User                 string `mapstructure:"DB_USER"`
	Pass                 string `mapstructure:"DB_PASS"`
	Name                 string `mapstructure:"DB_NAME"`
}

마무리하며

이번 글을 통해서 viper 를 활용해 .env 파일의 환경 변수 값을 가져와 mapstructure 를 사용해 Env 구조체 할당하는데 도움이 되었으면 좋겠습니다 :)

실제 동작하는 코드는 여기서 확인 하실 수 있습니다.

[golang 1% 이해하기] viper | dotenv 환경 변수값을 읽는 기능 도입 하기 #1 Config 전역 변수를 활용하기

TLOWAC — Sat, 9 Nov 2024 00:44:19 +0900

들어가며

이번 글에서는 viper 를 사용해서 dotenv 에 정의된 환경 변수를 읽어오는 방법에 대해서 정리해 보았습니다.

godotenv 라이브러리를 사용하는 방식과 mapstructure 를 사용해 Env 구조체(struct) 에 할당해서 사용하는 방법도 정리해놓았으니 도움이 되길 바랍니다.

node.js 에서는 개발을 진행하다보면 다양한 환경 변수값을 .env 파일에 작성하여 사용 합니다.

예를 들어, 서버 설정을 위한 server_host, server_port, 데이터베이스 설정을 위한 dsn, db_host, db_port, db_username, db_password 등 실제 값을 하드코딩으로 박아넣는 대신 dotenv 을 사용해 .env 파일에서 값을 불러와 사용 합니다.

go 에서는 이러한 기능을 지원하는 라이브러리로 viper, godotenv 가 있습니다.

정리하자면, 최종적으로는 3가지 내용을 얻어 가실 수 있습니다.

첫번째로는 viper 를 사용한 .env 값 가져오는 방식

두번째로는 viper 를 사용한 .env 값을 가져와 mapstructure 을 통해 Env 구조체(struct) 에 맵핑하여 사용하는 방식

세번째로는 godotenv 를 사용한 .env 값을 가져오는 방식

✅ Viper 설치 및 LoadEnvConfiguration 제작하기

1) viper 설치하기

go get 명령어를 통해 viper 라이브러리를 다운로드 받습니다.

go get github.com/spf13/viper

go get github.com/spf13/viper

2) LoadEnvConfiguration 제작하기

viper 를 통해 .env 파일에서 환경 변수 값을 가져오기 위해서 LoadEnvConfiguration 함수를 제작 합니다.

이렇게 불러온 .env 파일의 환경 변수 값은 main 에서 Config.ServerPort 또는 viper.Get("SERVER_PORT") 와 같은 형식으로 불러와 사용할 수 있습니다.

Config.ServerPort

viper.Get("SERVER_PORT)

package main

import (
	"fmt"

	"github.com/spf13/viper"
)

func main() {
	LoadEnvConfiguration(".", "config", "env")
	fmt.Println("SERVER_HOST", Config.ServerPort)
	fmt.Println("SERVER_HOST", viper.Get("SERVER_PORT"))
}

type Configuration struct {
	Server_Port string
}

// 불러온 .env 환경 변수를 전역으로 사용하기 위해 전역 변수 설정
var Config *Configuration

func LoadEnvConfiguration(configPath, configName, configType string) error {
	var config *Configuration

	// config 파일 경로 설정
	viper.AddConfigPath(configPath)
	// config 파일 이름 설정
	viper.SetConfigName(configName)
	// config 파일 타입 설정 ( yaml / toml / env )
	viper.SetConfigType(configType)

	viper.AutomaticEnv()

	err := viper.ReadInConfig()
	if err != nil {
		fmt.Errorf("could not read the config file: %v", err)
	}

	err = viper.Unmarshal(&config)
	if err != nil {
		fmt.Errorf("could not unmarshal: %v", err)
	}

	// 전역변수에 값 입력
	Config = config
	return nil
}

마무리하며

이번 글을 통해서 viper 를 활용해 .env 파일의 환경 변수 값을 가져오는데 도움이 되었으면 좋겠습니다 :)

실제 동작하는 코드는 여기서 확인 하실 수 있습니다.

[책 정리] 구글 엔지니어는 이렇게 일한다. | #1장 소트프웨어 엔지니어링이란? 을 읽고

TLOWAC — Fri, 8 Nov 2024 19:22:21 +0900

1장 소트프웨어 엔지니어링이란?

"프로젝트 수명 주기"

이따금 과거의 프로젝트를 돌아보면, "완성 땅땅" 하고선 열어보지도 않는 '프로젝트의 수명주기' 가 채 1주일도 가지 않는것들이 많았다.

더욱이 알고리즘 같은 경우는 프로젝트의 수명 주기가 1시간이나 될까..

이번에 "프로젝트 수명 주기" 를 인지 함으로써, 항상 프로젝트 시작전 많은 고려사항을 고민하며 골머리를 썩히는 시간을 줄일 수 있을것 같다.

"아.. 이거 넣어야 되나? 아... 이거 필요한데"

"이거 프로젝트 수명 주기 1주일 용도다! 넘겨!"

(웃자고 한소리다... )

실제 회사에 근무를 할때 특정 라이브러리들의 의존성 업데이트로 인해 기술 부채가 발생한 경험이 있다.

스타트업의 특성상 기술 부채의 처리와 고객 유입과 지표 상승, 투자 유치를 위한 신규 기능 업데이트 사이에서의 저울은 항상 어렵게 느껴진다.

당시에는 우린 라이브러리의 버전을 2.x 에서 3.x 로 올리는 과정에서 많은 트러블 슈팅이 있었고, 완료되었다고 생각되는 시점에 에러가 발생하여 업데이트한 내역을 다시 되돌리기도 했다. 이번에 "구글 엔지니어는 이렇게 일한다" 에서 특정 컴파일러 버전에 대한 이러한 사례를 설명해주는데 더욱 공감이 갔다. 라이브러리로도 이렇게 많은 고민을 하고 수정을 거쳤음에도 문제가 발생하였는데, 컴파일러라니 작금의 나는 그 고통을 상상조차 할 수 없을것 같다. 특히, 이로인해 특정 버전의 컴파일러에 의존하게 만들었었다 라는 부분에서도 공감이 갔다.

"인프라를 변경하여 서비스가 주단되는 등의 문제가 발생하더라도 같은 문제가 지속적 통합 시스템의 자동 테스트에서 발견되지 않는다면 인프라팀의 책임이 아니다." 라는 '비욘세 규칙' 과 같은 구글만의 재밌는 규칙도 있다는걸 알게 되었다. ( 책에서는 '네가 좋아했다면 CI 테스트를 준비해뒀어야지' 라는 추가 설명도 달려 있다. ㅋㅋㅋㅋㅋㅋ )

솔직히 이런 요소조차 없었으면 704 페이지.. 의 책 두께를 보고 포기할뻔했다.

그리고, '원점 회귀' 라는 소주제에서 심금을 울리는 도표를 하나 발견했다.

모든 개발자들의 심금을 울리지 않았을까 짐작한다.

( 배포 직전 들어오는 신규 기능 추가 / 수정 요청들의 향연... 그 홍수 속 어딘가의 나.. )

[생각정리] golang 프레임워크를 fiber 에서 gin 으로 바꾸며

TLOWAC — Thu, 7 Nov 2024 19:38:03 +0900

들어가며

go 를 처음 배울때는 gin - gorm 조합을 썼었다.

일정 기간 go 를 사용하지 않다가 다시금 go 를 쓰고자 연습을 하는 과정에서 gin 대신 node.js 의 express 와 유사하다고 홍보하는 fiber 를 보게 되었고, 보일러 플레이트 제작 및 연습 프로젝트 제작에 gin 대신 fiber 를 사용하였다.

API 문서 자료도 gin 보다는 fiber 가 휘황찰란하게 되어 있어 눈길이 더 갔던것도 사실이다.

Gin Docs (왼쪽) / Fiber Docs (오른쪽)

구현 예제 코드는 2개 다 잘 되어 있다.

무엇인가 구현하고자 한다면 대부분의 예시 코드를 해당 프로젝트에서 만들어 놓아 참고 하기 좋았다.

✴️ 고민이 되었던 부분

문제는 gorilla/websocket 을 사용해서 화상채팅 프로젝트를 진행하는 과정에서 발생했다.

net/http 기반으로 제작된 Gin 의 경우 타고 들어가면 Request *http.Request / Writer ResponseWriter 가 존재하지만,

fasthttp 기반으로 제작된 Fiber 의 경우 타고 들어가도 Request *http.Request / Writer ResponseWriter 가 존재하지 않아 해당 라이브러리 사용이 어려웠다.

https://github.com/gorilla/websocket/issues/640

https://github.com/gorilla/websocket/pull/98

https://github.com/valyala/fasthttp/issues/18

이론상 net/http 보다 10x 빠르다고 설명되어 있는 Fasthttp 기반으로 제작된 Fiber 와 net/http 기반으로 제작된 Gin 중에서 나는 결정을 내려야 했다.

golang 에서 거의 표준으로 사용하는 websocket 라이브러리는 gorilla/websocket 였고, 예제와 실섭 구현에 대한 이야기도 이쪽이 훨씬 더 많았기에 프레임워크를 Fiber 에서 Gin 으로 변경하고 gorilla/websocket 를 쓰기로 결정했다. ( Fiber 는 별도의 websocket 미들웨어를 제공 하고 있다. )

추후, 많은 기능을 필요로 하는 프로젝트 진행시에는 pion/webrtc 와 gorilla/websocket 를 쓸 생각이다.

✅ Gin / Fiber 의 Router 구현체 파고들기

1) Fiber Router ( fasthttp )

Router -> Handler

Handler -> Ctx

Ctx -> *fasthttp.RequestCtx

*fasthttp.RequestCtx

2) Gin Router ( net/http )

gin 의 경우 타고 들어가면 Request *http.Request / Writer ResponseWriter 가 존재한다.

Router -> HandlerFunc

HandlerFunc -> *Context

Context -> *http.Request / ResponseWriter

[golang 1% 이해하기] air | 실시간 코드 변경을 위한 live-reload 기능 도입하기 #2 docker 컨테이너와 로컬 레포 연동하기

TLOWAC — Wed, 30 Oct 2024 17:29:21 +0900

들어가며

이번 글에서는 이전 글의 연장선으로 air 를 사용하여 docker container 와 로컬 레포를 연동하여 사용하는 방법에 대해서 알아보겠습니다.

일반적으로는

1. Dockerfile 작성 /

2. docker container stop ( 구동중인 docker container 정지 ) /

3. docker build ( 새로운 docker 이미지 빌드 ) /

4. docker container start ( 새로운 이미지 기반의 docker container 실행 )

등의 과정을 거치게 됩니다.

코드의 변경 과정이 생긴다면 2 ~ 4 과정을 반복해야하는 불편함이 있습니다.

하지만, docker 이미지 빌드 과정에서 docker container 와 로컬 레포를 연동하고, 코드의 변경 사항이 발생 할 때마다 air 가 docker container 내부에서 동작 중인 go 서버를 재시작 함으로써 이러한 불편함을 해결 할 수 있습니다.

정리하자면, 최종적으로는 2가지 효용성을 얻을 수 있습니다.

첫번째로는 air 를 사용하여 코드 변경에 따른 서버 재시작 기능 입니다.

두번째로는 추가적인 docker conatiner 빌드 과정 없이 사용 할 수 있다는점 입니다.

✅ local 환경에서의 air 설치 및 구성

1) Dockerfile 작성하기

전체적인 내용은 go 기반의 프로젝트를 이미지로 빌드하는 일반적인 방법 이지만, 2가지 부분이 변경 됩니다.

첫번째로 docker container 에 air 를 설치 합니다.

RUN go install github.com/air-verse/air@latest

두번째로 docker container 실행시의 명령어를 go run 을 대신해 air 명령어로 변경 합니다.

CMD ["air", "-c", ".air.toml"]

# 빌드 스테이지
FROM golang:1.23-alpine AS builder

WORKDIR /app

# air live-reload 설치
RUN go install github.com/air-verse/air@latest

# 의존성 파일 복사 및 다운로드
COPY go.mod ./
RUN go mod download

# 소스 코드 복사
COPY . .

# 접근 가능 포트 설정
EXPOSE 8080

# air live-reload 실행
CMD ["air", "-c", ".air.toml"]

2) Docker 명령어 수정

-p 8080:8080 | docker container 포트를 맵핑 합니다. 로컬의 8080 / docker 컨테이너의 8080

--rm | docker container 가 종료되면 자동으로 삭제 합니다.

- v $(pwd):/app | 현재의 로컬 레포를 docker container 의 /app 폴더에 연결 합니다.

go-docker-container | 실행할 docker container 이름. ( 빌드시에 별도로 작성해줘야 합니다.

docker run -p 8080:8080 --rm -v $(pwd):/app go-docker-container

마무리하며

이번 글을 통해서 반복적인 docker 와의 중지 / 삭제 / 빌드 / 실행의 무한 루프에서 벗어나시는데 도움이 되었으면 좋겠습니다 :)

[golang 1% 이해하기] air | 실시간 코드 변경을 위한 live-reload 기능 도입하기 #1 설치하기

TLOWAC — Tue, 29 Oct 2024 14:30:56 +0900

들어가며

Typescript 에서 프론트 / 백엔드 개발을 진행하다보면, 사용하는 라이브러리 또는 프레임워크 자체에 자동으로 변경 내역을 반영하여 서버를 재시작 해주는 기능을 기본으로 제공 해주거나 별도로 nodemon 과 같은 라이브러리를 사용하여 해당 기능을 구현할 수 있습니다.

예를 들면, ReactJS, NestJs, nodemon 등이 있습니다.

이번에, Go 를 학습하면서 당연하게 생각했던 기능이 없어 검색을 하는 과정에서 변경 내역을 자동으로 반영하여 서버를 재시작 해주는 기능을 제공하는 air 라는 도구를 알게 되어 실제 적용을 해보며 글을 작성하게 되었습니다.

이번에 제가 air (live-reloading) 글에서 정리하고자 하는 내용은 크게 2가지 입니다 .

#1 local 환경에서의 air 설치 및 구성
#2 dockerfile 작성 및 docker container 에서의 air 설치 및 구성

✅ local 환경에서의 air 설치 및 구성

1) air 설치하기

go install github.com/air-verse/air@latest

2) air 정상 설치 확인하기

air -v

3) 프로젝트에 air 구성하기

air init

air init 명령어가 정상적으로 실행되었다면, .air.toml 파일이 정상적으로 생성된것을 확인 할 수 있습니다.

( 아래의 더보기 버튼을 통해 실제 생성된 .air.toml 파일을 확인 해볼 수 있습니다. )

.air.toml

root = "."
testdata_dir = "testdata"
tmp_dir = "tmp"

[build]
  args_bin = []
  bin = "./tmp/main"
  cmd = "go build -o ./tmp/main ."
  delay = 1000
  exclude_dir = ["assets", "tmp", "vendor", "testdata"]
  exclude_file = []
  exclude_regex = ["_test.go"]
  exclude_unchanged = false
  follow_symlink = false
  full_bin = ""
  include_dir = []
  include_ext = ["go", "tpl", "tmpl", "html"]
  include_file = []
  kill_delay = "0s"
  log = "build-errors.log"
  poll = false
  poll_interval = 0
  post_cmd = []
  pre_cmd = []
  rerun = false
  rerun_delay = 500
  send_interrupt = false
  stop_on_error = false

[color]
  app = ""
  build = "yellow"
  main = "magenta"
  runner = "green"
  watcher = "cyan"

[log]
  main_only = false
  silent = false
  time = false

[misc]
  clean_on_exit = false

[proxy]
  app_port = 0
  enabled = false
  proxy_port = 0

[screen]
  clear_on_rebuild = false
  keep_scroll = true

4) go run 대신 air 를 사용하여 서버 실행하기

마무리하며

air 를 다루는 2번째 글에서는 Dockerfile 을 정의하고, 별도의 컨테이너 중지, 코드 변경, 빌드, 재실행의 과정을 생략 할 수 있게끔 환경을 구성하는 방법을 다루어 보겠습니다 :)

[Git 1%이해하기] git 브랜치 이름 변경하기

TLOWAC — Wed, 29 May 2024 15:31:52 +0900

들어가며

자주 사용하는 git 명령어중 하나인 "git 브랜치 이름 변경하는 방법" 에 대해서 정리 해보았습니다.

'git pull' , 'git push' 와 비교했을때 사용률을 다소 떨어지지만 꼭 알고 있어야 한다고 생각 합니다 :)

저는 주로 3가지 상황일때 해당 명령어를 사용해 git 브랜치의 이름을 변경 했습니다.

main 브랜치를 기준으로 새로운 브랜치를 생성할때 오타가 발생한 경우
로컬의 main 브랜치의 .git 이 꼬인 경우
remote 저장소에 push 하기 위해 local 저장소에 push 하는 과정에서 branch 이름을 수정하는 경우

제가 이번 글에서 정리하고자 하는 내용은 크게 2가지 입니다.

현재 사용중인 브랜치의 이름 변경하는 방법
현재 사용중인 브랜치 이외에 다른 브랜치의 이름 변경하는 방법

✅ git 브랜치 이름 변경

1차 : 현재 브랜치의 이름을 변경하기

기존 : main
변경 : main2

git branch -m <새로 변경할 브랜치 이름>

브랜치 이름 변경을 위해 아래와 같이 명령어를 입력 합니다.

명령어가 정상적으로 실행되었다면, 브랜치의 이름이 변경된것을 확인 할 수 있습니다.

더불어, 'git status' , 'git branch --list' 명령어를 통해서도 브랜치의 이름이 정상적으로 변경된것을 확인 할 수 있습니다.

왼쪽 (git status) / 오른쪽 (git branch --list)

2차 : 현재 사용중인 브랜치 이외에 다른 브랜치의 이름을 변경하기

상황에 따라서 "git checkout <브랜치>" 명령어를 통해 이름을 바꿀 브랜치로 이동하는 작업이 불필요하다고 느껴질 수 있습니다.

이럴때는 "git branch -m <변경전 브랜치 이름> <변경후 브랜치 이름>" 명령어를 사용해 별도의 checkout 을 사용한 브랜치 이동 없이 브랜치의 이름을 변경 할 수 있습니다.

git branch -m <변경전 브랜치 이름> <변경후 브랜치 이름>

브랜치 이름 변경을 위해 아래와 같이 명령어를 입력 합니다.

동일하게 'git status' , 'git branch --list' 명령어를 통해서 변경된 브랜치 이름을 확인 할 수 있습니다.

왼쪽 (git status) / 오른쪽 (git branch --list)

[IDE 99% 에러잡기] cursor ide - cursor . 명령어 "zsh: command not found: cursor"

TLOWAC — Sun, 26 May 2024 00:18:54 +0900

들어가며

최근에 IDE 를 vscode -> cursor 로 변경하기 위해 개발 환경 구성을 하는 과정에서 맞닥뜨린 가벼운 에러의 해결 방법을 정리 하였습니다. vscode 에서 자주 쓰는 `code .` 와 같은 명령어를 cursor 에서는 지원하지 않는건지 한참을 찾아봤네요. ( 이슈/포럼 )

도움이 되었으면 좋겠습니다 :)

이슈 발생

cursor ide 를 설치하고 터미널에서 프로젝트를 `cursor .` 명령어로 여는 과정에서 에러가 발생 했습니다.

1차 : 에러 로그 확인 zsh: command not found: cursor

✅ 이슈 해결

1차(성공) : 'install cursor command'

vscode 의 `code .` 명령어와 같은 기능의 명령어를 지원하지 않는건지 한참을 찾았었는데, 결국은 cursor ide 구성 과정에서 'cursor command' 가 터미널에 설치되지 않았던것 같았습니다.

방법을 찾다보니 cursor ide 에서 'cursor command' 만 별도로 설치 할 수 있었습니다.

vscode 에서 ctrl + shift + p 명령어 입력
install cursor 검색

정상동작 확인(성공)

'cursor command' 설치 이후에는 터미널에서 `cursor .` 명령어가 `vscode .` 처럼 정상적으로 동작하는것을 확인 할 수 있었습니다.

마무리하며

유튜브에서 해외 개발자들의 개발 관련 영상을 보는 과정에서 cursor 라는 ide 를 알게 되어, 최근에 vscode 대신에 cursor 를 쓰고 있습니다. vscode 의 theme 이나 extension 도 전부 그대로 사용할 수 있고 AI 관련 기능도 지원되고 있어 사용한지 얼마 안됬지만, 요긴하게 쓰고 있습니다. cursor ide 한번 써보시길 추천 드립니다 :)

참고자료

- https://forum.cursor.sh/t/trouble-install-cursor-command-in-path/156

[Github 99% 에러해결하기] Github Action 티스토리 블로그 RSS 406 Error - Not Acceptable 에러

TLOWAC — Wed, 10 Apr 2024 01:33:08 +0900

들어가며

이력서와 포트폴리오를 업데이트하며, 기존에 제작했던 Github Profile README 의 구성도 업데이트를 하게 되었습니다.

"README 를 꾸미는데 사용할 도구로 괜찮은게 없을까" 찾는 과정에서 다양한 템플릿을 지원하는 lowlighter/metrics 를 발견하게 되었고, 이를 사용해 README 업데이트 작업을 진행하였습니다.

이 과정에서 티스토리 RSS 를 활용해 lowlighter/metrics 의 "블로그 포스팅 리스트" 템플릿을 설정하는 과정에서 발생한 406 에러에 대한 해결 과정을 담고 있는 포스팅 입니다.

다양한 템플릿을 지원하는 metrics

⚒️ lowlighter/metrics 작업

lowlighter/metrics 템플릿은 하나의 svg 파일을 생성하거나 여러개의 svg 파일을 생성하여 README 에 배치할 수 있습니다.

저는 필요한 템플릿을 모두 구성하고 하나의 svg 파일을 생성하여 정상적으로 동작하는지 테스트 후 템플릿 배치 변경을 위해 여러개의 svg 파일을 생성하여 재배치하는 방향으로 진행하고자 하였습니다.

1차 : Github Action 제작

기본적인 템플릿 제작은 별도의 Generator 페이지 가 있어 손쉽게 템플릿 구성과 그에 필요한 Github Action 코드를 만들 수 있었습니다.

# Generator 페이지에서 생성된 Github Action 코드
# Visit <https://github.com/lowlighter/metrics#-documentation> for full reference
name: Metrics
on:
  # Schedule updates (each hour)
  schedule: [{cron: "0 * * * *"}]
  # Lines below let you run workflow manually and on each commit
  workflow_dispatch:
  push: {branches: ["master", "main"]}
jobs:
  github-metrics:
    runs-on: ubuntu-latest
    permissions:
      contents: write
    steps:
      - uses: lowlighter/metrics@latest
        with:
          token: ${{ secrets.METRICS_TOKEN }}

          # Options
          user: tlowac
          template: classic
          base: header, activity, community, repositories
          base_hireable: yes
          config_display: large
          config_padding: 1, 8 + 10%
          config_timezone: Asia/Seoul
          plugin_activity: yes
          plugin_activity_days: 14
          plugin_activity_filter: all
          plugin_activity_limit: 5
          plugin_activity_load: 298
          plugin_activity_visibility: all
          plugin_followup: yes
          plugin_followup_archived: yes
          plugin_followup_indepth: yes
          plugin_followup_sections: repositories
          plugin_languages: yes
          plugin_languages_analysis_timeout: 15
          plugin_languages_analysis_timeout_repositories: 7.5
          plugin_languages_categories: markup, programming
          plugin_languages_colors: github
          plugin_languages_limit: 8
          plugin_languages_recent_categories: markup, programming
          plugin_languages_recent_days: 14
          plugin_languages_recent_load: 300
          plugin_languages_sections: most-used
          plugin_languages_threshold: 0%
          plugin_rss: yes
          plugin_rss_limit: 4
          plugin_rss_source: https://helicopter55.tistory.com/rss

2차 : README.md 수정

앞서 제작한 Github Action 이 실행되고 Profile Repo 의 Root 경로에는 github-metrics.svg 가 결과물로 생성되게 됩니다.

( 별도의 파일명을 사용할 수 있으며, 템플릿을 쪼개서 각각의 파일을 만들어 사용할 수도 있습니다. )

이렇게 생성된 github-metrics.svg 를 README.md 에 불러와 사용하면 됩니다.

<p align="center">
	<img src="/github-metrics.svg" alt="Metrics" width="400">
</p>

3차 : 결과물 확인

생성된 lowlighter/metrics 템플릿이 정상적으로 Github Profile README 에 반영된것을 확인 할 수 있었습니다.

변경전(왼쪽) / 변경후(오른쪽)

이슈 발생

여기까지 확인을 했다면 사실상 Github Action 을 쪼개고 템플릿 배치만 수정하여 README 를 업데이트하면 작업이 끝날것으로 예상을 했습니다. 하지만, 항상 한번에 끝나는건 없는것 같습니다 :)

1차 : 에러 로그 확인 Unexpected error > 406 Error - Not Acceptable

README 에서 “RSS feed” 템플릿에서 “Unexpected error” 가 발생한것을 발견하였습니다.

Gihub Action 은 “Passed” 로 표시되어 있더라도 로그상에서 티스토리 블로그의 rss 데이터를 불러오는 과정에서 에러가 발생하는것을 확인 할 수 있었습니다.

✅ 이슈 해결

1차(실패) : 블로그 포스팅 리스트 표시를 위한 Github Action 변경

기존 : lowlighter/metrics
변경 : gautamkrishnar/blog-post-workflow

예전에 gautamkrishnar/blog-post-workflow 를 사용하여 Github Action 을 구성했을때 티스토리 rss 데이터가 정상적으로 불러와졌던 기억이 있어 블로그 포스팅 템플릿만 대체할 생각으로 주석 처리해놓았던 코드를 되살려 Github Action 을 실행 해보았습니다.

하지만, 기대와는 다르게 여기서도 동일하게 406 Error - Not Acceptable 에러가 발생했습니다.

2차 : 찾게된 알맞은 검색 키워드

여러가지 키워드를 사용해 검색하는 과정에서 발견한 대부분의 글들은 Java + Spring 에서 발생하는 xml 파싱 406 에러에 대한 내용이었습니다. 명확한 해결책을 찾을 수 없어 삽질을 반복하고 있을때 gautamkrishnar/blog-post-workflow 프로젝트의 이슈를 발견하게 되었습니다.

3차 : gautamkrishnar/blog-post-workflow 406 Error 이슈 히스토리

당시에 제가 맞딱뜨린 이슈의 상황과 해당 이슈가 거의 유사했고 감사하게도 해당 이슈에 대한 히스토리와 동작이 되는 코드를 확인 할 수 있었습니다.

https://github.com/gautamkrishnar/blog-post-workflow/issues/19

[Bug]: Response 406 when asking for rss stream · Issue #19 · gautamkrishnar/blog-post-workflow

Describe the bug When I use the provided configuration and the cronjob runs I get a 406 Not Acceptable response in the github action as an error. To Reproduce Steps to reproduce the behavior: Imple...

github.com

accept-header 에 대한 문제 제기

로컬 환경에서 accept-header 를 “text/xml” 로 변경하여 테스트를 했을때 정상 동작

해당 사항을 반영하여 accept_header 를 수정할 수 있게 변경하였다.

실제로 해당 issue 에 연결된 PR 과 merge 된 코드를 확인해보았습니다.

Github Action 상에서 accept_header 를 입력할 수 있게 수정된것을 확인할 수 있었습니다.

4차 : 티스토리 RSS Response Header 의 Content-Type 확인

실제 티스토리 블로그의 RSS 의 Response Headers 를 확인해보았을때 "Content-Type : text/xml;charset=UTF-8" 인것을 확인할 수 있어 방향성에 대한 어느정도 확신을 갖게 되었습니다.

5차 : accept_header : "text/xml" 옵션 추가

기존 : lowlighter/metrics
변경 : gautamkrishnar/blog-post-workflow

블로그 포스팅 리스트 표시를 위한 Github Action 을 변경하고 accept_header : “text/xml” 와 user_agent 를 추가하고 실행해 보았습니다.

그 결과 Github Action 도 정상적으로 동작하고 블로그 포스팅 리스트도 노출되는것을 확인하였습니다! XD

gautamkrishnar/blog-post-workflow 에 user_agent 와 accept_header 를 추가

gautamkrishnar/blog-post-workflow 블로그 포스팅 GIthub action 정상 동작 확인

결과물!

블로그 포스팅 리스트가 정상적으로 노출!

마무리하며

Github Action 을 lowlighter/metrics에서gautamkrishnar/blog-post-workflow 로 변경하고 accept_header 을 수정하며 문제를 해결 할 수 있었습니다.

이 과정에서 lowlighter/metrics 에서도 accept_header 를 수정할 수 있는지 확인해보았는데 아쉽게도 해당 기능은 지원하지 않는것 같았습니다. 나중에 기회가 되면 해당 issue 로 contribution 하는것도 고려해 보아야겠습니다 :)

lowlighter/metrics 의 RSS Feed 템플릿 Github Action 옵션 정보

긴글을 끝까지 읽어주셔서 감사합니다.

이만 글을 줄입니다.

[vscode 1% 이해하기] Jetbrains Mono 폰트 vscode 적용하기 (feat. Font Ligature)

TLOWAC — Tue, 26 Mar 2024 02:01:32 +0900

들어가며

vscode 에서 Ligature 기능을 활성화 하면 '===' , '!=', '>=', '=>' 등의 문구를 아래의 이미지와 같이 변경 할 수 있습니다.

하지만, 모든 폰트에서 Ligature 기능을 지원하지 않기 때문에 이를 지원하는 폰트를 찾아 vscode 에 적용해야합니다.

Ligature 기능

Jetbrains Mono 폰트 적용하기

1) 폰트 다운로드

아래의 링크를 통해 Ligature 기능을 지원하는 Jetbrains Mono 폰트를 다운로드 합니다.

https://www.jetbrains.com/lp/mono/#how-to-install

JetBrains Mono: A free and open source typeface for developers

Try JetBrains Mono in your IDE. Its simple forms and attention to every detail make coding a nice experience for developers’ eyes, no matter which IDE you choose.

www.jetbrains.com

2) 폰트 적용하기

폰트를 다운로드 했다면, 압축을 풀고 ttf 라는 이름의 폴더로 이동합니다.

ttf 폴더에 있는 모든 폰트 파일을 선택하고 더블 클릭하면 해당 폰트를 설치 할 수 있습니다.

3) vscode Font Ligature 활성화하기

앞선 과정을 통해 폰트를 다운받았다면, 이제 vscode 에서 해당 폰트를 사용하기 위해 settings.json 을 수정해야 합니다.

vscode 에서 'Crtl + Shift + p' 단축키를 입력하고 "settings json" 을 검색하여 settings.json 을 열어 editor.fontFamily, editor.fontLigatures 를 검색합니다.

아래와 같이 Jetbrains Mono 폰트와 Ligature 기능을 활성화 합니다.

- editor.fontFamily : "Jetbrains Mono"

- editor.fontLigatures : true

vscode 에 폰트 설정이 정상적으로 반영 되었다면, '===' , '!=', '>=', '=>' 등의 문구의 모양이 변경된것을 확인 할 수 있습니다.

만약, 폰트 설정이 반영 되지 않았다면 vscode 를 재시작을 권장 드립니다!

마무리하며

Font Ligature 기능을 활성화 하는 과정에서 Jetbrains Mono 폰트를 vscode 에 적용까지 하는 방법을 정리해보았습니다.

Jetbrains Mono 폰트가 별로라면 Font Ligature 기능을 지원하는 firacode 폰트도 있으니 관심 있으신 분들은 추천 드립니다!

긴글 읽어주셔서 감사합니다 :)

이만 글을 줄입니다.

[사이드프로젝트] 프로필 링크 랜딩 페이지 제작하기

TLOWAC — Tue, 19 Mar 2024 12:55:05 +0900

들어가며

1) 프로젝트 시작 계기

다양한 활동을 하다보면 사람들과 연락처를 공유하거나 내가 어떤 작업을 하고 있고 어떤 일을 하는 사람인지 소개하기 위해 링크드인이나 깃허브, 인스타등의 링크를 공유하는 경우가 있습니다. 그때마다 어플에 들어가서 프로필 링크를 복사하고 공유하는 과정이 너무 번거롭다 생각되서 나를 소개 할 수 있는 링크를 모두 모아놓은 "프로필 링크용 랜딩 페이지" 를 제작하게 되었습니다.

더불어, 깃허브에 늘어만 가는 첨부 링크들도 한몫을 했습니다.

점점 늘어만 가는 링크의 흔적들 . .

프로필 링크 랜딩 페이지 프로젝트

1) 프로젝트 기술 스택

처음에는 단일 정적(static) 페이지여서 index.html 에 inline css 로 박아 넣고 S3 에 올려 CloudFront 로 호스팅하고 끝낼려고 했습니다. ㅋㅋ

하지만, [빌드 -> S3 업로드 -> Clear Cache] 깃허브 액션을 또 언제 만들까 싶어 예전부터 눈독드렸던 vercel 을 써보기로 했습니다. 더불어, 추후 og(open graph) 적용도 할 예정이라 @vercel/og 를 지원한다는점도 매력적이었습니다.

막상 프로젝트를 배포하고나니 드는 생각은 "아니 다들 이 좋은걸 쓰고 있었단 말이야?"

물론 회사 프로젝트였다면 관리 포인트, 운영 비용등의 문제가 고려되어야겠지만, 사이드 프로젝트를 배포함에 있어 vercel 에서 지원하는 hobby 플랜으로도 충분했고 GA 까지는 아니지만 @vercel/analytics 을 통해 방문자 트랙킹 기능 (Web Analytics) 도 지원한다는게 만족스러웠습니다.

컴포넌트 디자인을 어떻게 할지도 정해야 했었는데, 지금까지는 styled-component 로 만들어서 쓰거나 MUI (material-ui) 의 props 에 css 커스터마이징의 늪에서 사경을 해맸었기에 이번에는 그런 경험을 지양하고자 설정과 디자인을 간단하게 할 수 있는 tailwindcss 로 선택하였습니다.

tailwindcss 초창기에 좋아보여서 시도했다가 터저나오는 의존성 이슈로 고생했던적이 있었는데, 이번 프로젝트를 통해 사용해본 경험으로는 "안쓸이유가 없다" 만족스러운 경험이었습니다. 물론, 단일 정적 페이지여서 더 그런것 같습니다 :)

이렇게 제가 프로젝트 제작을 위해 선정한 기술스택은 아래와 같습니다.

vercel
tailwindcss
vite-react-typescript

2) 작업 내역

✅ 2-1) Favicon 제작

Favicon 제작에는 Free Favicon Maker 를 사용했습니다.

텍스트, 모양, 색상, 이모지등을 자유롭게 설정해서 svg 형태로 export 해줘 사용하기 편리했습니다.

✅ 2-2) 도메인 구매 & 설정 ( 진행중 )

도메인은 가비아 를 통해 이전부터 눈독 드리고 있던 도메인을 구매했습니다. ( 저도 이제 도메인 오너... )

profile.tlowac.com, profile-link.tlowac.com, profile-group.tlowac.com 중에서 고민하다가 깔끔하고 명확한게 나을것 같아 최종적으로 profile.tlowac.com 으로 결정했습니다.

vercel 에 서브 도메인을 설정하는것도 비교적 간편했습니다.

도메인을 발급받은 가비아에서 DNS 관리 기능을 사용해 tlowac.com 의 서브도메인 설정시 vercel 의 DNS 값을 CNAME 으로 설정하였습니다.

실제 반영까지 n분의 시간이 소요되었지만, 서브 도메인이 정상적으로 적용되는것을 확인하였습니다!!

작업전(왼쪽) / 작업후(오른쪽)

✅ 2-3) 기능 구현

간단한 배치와 스타일링만 했기에 적을만한 내용이 없는게 아쉽습니다.

한가지 헤맨게 있다면, 배포후 링크를 클릭하는 과정에서 텍스트에만 링크가 걸려 있어 링크의 선택 영역을 박스로 확장했습니다.

3) 프로필 링크 랜딩 페이지 프리뷰

지금은 링크드인, 인스타, 블로그, 깃허브 링크만 추가되어 있습니다.

추후에 유튜브나 디스코드 링크등 추가할 수 있도록 노력해야겠습니다 :)

마무리하며

만들고나서 보니 linktree 라는 멋진 도구가 이미 있군요...

그래도 재직중일때는 바쁜 회사일에 치여 개인 프로젝트를 완성까지 해본적이 없었는데, 별다른 기능이 들어가지 않은 프로젝트이지만 어느정도 마무리를 하고 배포까지 한것에 의미를 두고 싶습니다 :)

제작한 랜딩 페이지와 프로젝트 링크를 첨부 해두겠습니다!
긴글 읽어주셔서 감사합니다 :)

링크 첨부

[Profile] profile.tlowac.com

[Github] profile-link-landing-page

[AWS 트러블 슈팅] RDS CPU 점유율 99% 스파이크 현상 트러블 슈팅

TLOWAC — Thu, 14 Mar 2024 02:54:12 +0900

0) 들어가며

2022년 당시 AWS 에 대해 무지했던 시기에 "서버 살려야한다.. AWS 배워야 한다." 라는
경각심을 일깨워준 좋은(?) 경험에 대한 내용을 정리해보았습니다.

-----

개발 인력의 퇴사와 더불어 사업 방향성이 웹에서 어플로 변경됨에 따라 어플의 출시와 신규 기능 개발 및 운영을 위해
Typescript 기반의 프론트/백엔드 개발 업무에서 어플의 백엔드 전담으로 업무가 변경 되었습니다.

신규 기능 배포 및 친구 초대 이벤트 홍보등 다양한 이슈로 인하여 신규 회원의 가입자 수가 폭발적으로 상승하는 때가 있었습니다.

그리고, 이 시기에 서버가 죽어버려 어플에 들어가면 홈 화면에서 무한로딩이 발생하게 되는 이슈가 발생하게 됩니다.

퇴근을 하고 지하철을 타기위해 지하철 게이트에 카드를 찍은 순간 걸려온 전화 한통..
"지금 APP 에 들어가면 무한 로딩이 되고 아무 기능도 쓸 수 없어요."

1) RDS CPU 99% 스파이크 발생 및 1차 대응

미쳐(?) 날뛰는 RDS CPU 점유율

당시에는 AWS 에 대한 지식이 부족했기 때문에 RDS Performance Insight 에서 문제가 되는 쿼리와 테이블을 확인하고
RDS 의 DB 락을 풀고 문제가 되는 유저를 벤하는등의 자연스러운 프로세스를 진행하지는 못했습니다.

당시에 제가 문제를 파악하고 대응했던 방법은

1. 해당 서버가 배포된 AWS EC2 접속

2. docker swarm 의 형태로 배포된 서버의 로그 확인

3. 서버의 로그 확인 결과 API 요청에 대한 DB 쿼리 결과가 null 로 리턴되는것을 확인

4. 관계자에게 해당 내용 전달 및 대응

5. EC2 종료 ( 실제 운영중인 서비스에서 운영중인 서버를 꺼버린다는게 말이 안되었지만 무한로딩의 상태에서 사용자들의 지속적인 접속으로 인해 API 요청이 계속해서 쌓이고 DB 에 락된 쿼리들을 풀어도 다시 락이 걸려버려 이를 방지하기 위해 생각난 방법이 이것 밖에 없었다.. )

6. DB 트랜잭션 모니터링 ( select * from information_schema.innodb_trx; )

7. RDS 인스턴스 임시 업그레이드 ( large > xlarge )

8. AWS RDS CPU 점유율 모니터링

9. 락된 트랜잭션 해제 작업 진행

10. DB 테이블별 쿼리 통계 모니터링 ( select * from sys.schema_table_statistics )

11. 문제가 발생한 DB 테이블 및 쿼리 확인

12. 해당 쿼리의 userId 확인

13. 해당 유저의 API 요청 빈도수 확인 ( 룰렛 API 의 경우 평균 n 초를 정상 유저로 판단 )

14. 메크로 유저 판단 및 벤 처리

15. EC2 부팅

16. EC2 CPU 및 RDS CPU 점유율 모니터링

17. 경과 보고 및 문제 원인 공유

서버 재부팅 이후 한동안은 서버의 동작과 모니터링 지표가 정상범위내 머물렀기에 이슈가 어느정도 해결단계에 있다고 생각했었습니다. 하지만, 지표는 다시금 상승하기 시작했습니다.

2) RDS 인스턴스 타입 변경 이후에도 동일한 이슈 발생

처음 해당 이슈에 대한 노티를 전달받았을때 짐작되는 문제 원인 에는 크게 3가지가 있었습니다.

첫번째로 당시 어플에는 무제한으로 돌릴 수 있는 포인트 룰렛이 존재했고, 이로 인해 늘어난 어뷰징 유저로 인해 문제가 발생했다고 추측했습니다.

두번째로 어뷰징 유저로 인해 유저들의 포인트를 적립하는 테이블의 조회/생성 쿼리 성능에 문제가 있다고 추측했습니다.

세번째로 신규 유저들의 폭발적인 유입 대비 RDS 인스턴스의 처리 용량이 받춰주지 못하는것은 아닐까 추측했습니다.

RDS 인스턴스 타입을 large > x.large 로 변경하였음에도 동일한 이슈가 재발생했기에 3번은 제외하고 나머지 원인들에 대한 확인 작업을 진행하였습니다.

이 과정에서 요청이 몰리는 엔드포인트의 쿼리 실행계획을 확인해본 결과 일부 조회 쿼리의 실행계획에 문제가 있는것을 확인 할 수 있었습니다.

실제 의도와는 다르게 조회 쿼리가 인덱스를 타고 있지 않았고, 불필요한 정렬과 필터링 그리고 급격하게 늘어난 row 로 인해 조회 성능이 떨어졌음을 확인 할 수 있었습니다. 로컬 환경에서 도커를 통해 mysql container 를 구동하고 prisma orm 을 사용해 schema migration 과 데이터 seed 작업 진행 후 로컬에서 다중 컬럼 인덱스를 추가하였을때의 실행계획이 기대와 동일하게 나오는지 1차적으로 확인하고 개발 서버에서 2차 확인후 실제 운영 서버의 DB 에 추가하는 작업을 진행하였습니다

다중 컬럼 인덱스 추가 후 지표가 정상 범위로 돌아오는것을 확인 할 수 있었습니다.

해당 작업으로 어플을 정상화 시킬 수 있었습니다.

3) 또 다른 RDS 인스턴스의 비정상 지표 패턴

이슈를 해결하고 다음날 출근해서 경과 확인을 위해 모니터링 지표를 체크하는 과정에서 문득 이상한점을 발견했습니다.

"분명 이슈는 해결했고 어플의 정상 동작도 확인했는데 패턴을 가진 초록색/파란색 RDS CPU 점유율은 뭘까"

앞선 경험이 있었기에 비교적 간단하게 원인을 찾아 개선 작업을 진행 할 수 있었습니다.
지표상 나타나는 패턴이 반복된다는점에서 스케줄러로 추측 할 수 있었고, RDS Performance Insight 를 통해 특정 쿼리가 사용되는 스케줄러를 파악하여
개선 작업을 진행하여 최종적으로 스케줄러의 쿼리성능을 기존 11.11s 에서 1.79s 까지 단축할 수 있었습니다.

4) 작업전 지표와 작업후 지표 비교

개선작업을 통해 날뛰던 RDS CPU 점유율 지표를 개선할 수 있었고
작업전과 작업 후 CPU 점유율 지표가 눈에 띄게 줄어든것을 확인 할 수 있었습니다.

작업전(왼쪽) / 작업후(오른쪽)

최종적으로 개선된 지표 경과는 아래와 같습니다.
표를 보실 때 대략적인 퍼센트만 표시한것을 감안해서 보시면 좋을 것 같습니다.

RDS	작업전	작업후
Instance A	40% ~ 99%	5% ~ 약 25%
Instance B	5% ~ 약 70%	5% ~ 약 15%
Instance C	5% ~ 약 70%	5% ~ 약 15%

5. 후속 대응 작업

서비스를 운영하며 이런 크리티컬한 이슈들을 CS 인입을 통해 알게되는것은 개발자의 간담을 서늘하게 하는 상황중 하나라고 생각 합니다. 추후에 이런 상황이 재발하는것을 막기 위해 아래 3가지 작업을 진행하였습니다.

첫번째로 Prometheus, Granfana 를 사용한 RDS CPU 모니터링 대시보드를 만들었습니다.

두번째로 Slow Query 가 발생하는 경우 Microsoft Teams 의 Slow Query Monitoring 채널로 메시지가 발송되게 만들었습니다.

세번째로 AWS CloudWatch RDS CPU Utilization 경보기능을 통해 RDS 의 CPU 점유율이 일정 퍼센트를 넘게되면, 메일이 전송되게 만들었습니다.

CloudWatch RDS CPU Utilization 경보 메일은 이후 서비스 운영과정에서 실제 발생 할 수 있는 이슈를 개발자에게 사전에 고지하는 역할을 톡톡히 했습니다.

6. 글을 마무리하며

저에게는 간담이 서늘했던 경험이었고 다시는 마주하고 싶지 않은 상황이지만
이를 통해 APM 구축의 중요성과 서버 운영에 대한 전반적인 경험, AWS 와 같은 인프라 구축, 쿼리 성능 개선 작업의 중요성을 배울 수 있는 기회였다고 지금은 생각 합니다.

제가 과거의 기억을 끄집어내 이 글을 작성하는 이유는
별다른 생각없이 썼던 n년전의 회고글을 지금 시점(2024)에서 다시 읽어보았을때 얻은 임팩트로 인해

과거의 경험을 퇴고하며 개발자로써 자신을 돌아보게 되는 계기가 되었기 때문 입니다.

더불어, 어딘가에서 과거의 저와 비슷한 문제를 맞닦뜨린 개발자들에게 조금이나마 도움이 되었으면 좋겠습니다.

긴글을 끝까지 읽어주셔서 감사합니다 :)

이만 글을 줄입니다.

[회고] DND 10기를 마무리 하며 ( feat. 최종 발표 )

TLOWAC — Thu, 29 Feb 2024 20:54:58 +0900

1. 들어가며

약 2달의 기간동안 진행된 DND 10기가 마무리 되었습니다.

의욕 넘치고 열정적인 동료들과 프로젝트를 진행하며 협업하는 방식과 코드 컨벤션, 퀄리티에 있어 배운점도 많았고, 불철주야.. 야근하던 동료들의 모습에 자극을 많이 받았습니다.

더불어, 최종발표때는 “와 이게 우리가 기획하고 만든서비스야?” 소리가 나올정도로 멋진 PPT 에 감탄밖에 안나왔습니다.

2달에 걸쳐 만든 서비스가 하나의 결과물로써 최종발표에 보여진다는것도 감회가 새로웠고,

“와 이게 우리가 기획하고 만든서비스야?” 소리가 나올정도로 멋진 PPT 에 감탄이 절로 나왔습니다 :)

2. 프로젝트 소개

처음 아이디어 회의를 진행했을때 선정된 아이디어는 “재난상황에서 사용할 수 있는 대피소 어플” 이었습니다.

하지만, 기간내 구현 가능 여부와 기술적인 이슈들을 어떻게 풀어나갈것인지에 대해서 논의한 끝에 아이디어를 변경하게 되었습니다.

첫만남의 5분을 책임지는 아이스브레이킹 서비스 “얼음땡 ”

그렇게 선정된 아이디어는 “모임의 첫 5분을 책임진다” 라는 슬로건을 가진 아이스 브레이킹 서비스 였습니다.

DND 첫 아이디어 회의를 했을때 서먹했던 분위기에 다들 공감해주셨고, 아이디어가 제시 되었을때 많이 호응 해주셨습니다.

공통된 문제점 정의 및 설문조사

아이스 브레이킹이 필요한 여러 상황들에 대해 정의하고, 각자 어떤 주제로 대화를 시작하고 이끌어 나갔는지와

이 과정에서 필요한 기능들, 어려웠던 경험을 공유하며 설문조사 질문을 작성하였습니다.

이후 진행된 설문조사를 통해 다양한 분들이 새로운 모임에 참여하는 자리에서 대화를 이끌어 나가는것에

어느정도 부담감을 느끼고 있다는것과 던지는 화두에 있어 MBTI 와 관심분야를 자주 사용한다는것을 확인 할 수 있었습니다.

구현 방향 설정

설문조사를 통해 문제점, 개선점, 필요기능등을 정리하고, 실제 서비스 구현 과정의 방향성을 정하였습니다.

“모임의 첫만남에 어플을 깔고 회원가입, 로그인까지 하는건 불필요하다.” 라는 의견도 있었기에

저희 아이스 브레이킹 서비스는 회원가입과 로그인 기능을 제외한 ‘비회원 전용’ 서비스로 방향을 잡게 되었습니다.

주요 기능 선정

2달이라는 기간내 완성을 목표로 하고 있기 때문에, 앞선 설문조사를 통해 사용자들이 필요한 기능들의 전부는 구현하지 못하는 상황이었습니다. 토의 과정 끝에 “아이스 브레이킹” 을 주제로 제시된 여러가지 기능들 중 “MBTI” , “빈칸주제” , “주제 가챠” 총 3 가지를 선정하여 작업하게 되었습니다.

기능 구현 - 스플래쉬 화면

스플래쉬 화면에서는 “얼음땡” 서비스 사용 가이드가 안내되어 있어 사용자가 보다 손쉽게 아이스 브레이킹 서비스를 이용할 수 있도록 하였습니다.

기능 구현 - 홈 화면 / 주제 가챠

홈 화면에는 방 생성, 방 참가, 토픽 룰렛 총 3가지 기능을 사용할 수 있습니다.

방을 생성한 참여자는 ‘방장’ 의 권한을 갖게 되고 다른 사용자들을 초대 할 수 있으며, 방장의 초대 코드를 받은 사용자는 ‘참여자’ 의 권한으로 방에 참여 할 수 있습니다.

MVP 를 위해 기간내 구현 가능한 수준으로 기능을 추리다보니 사전에 기획한 내용에 비해 컨텐츠가 너무 적어졌다는 의견이 있었습니다. 토픽 룰렛은 비교적 간단한 구현과 더불어 즐길 수 있는 컨텐츠를 하나 더 늘릴 수 있다는점에서 추가하게 되었습니다.

“어떤 음식을 제일 좋아하나요?” , “평생 여름 vs 겨울” 와 같이 여러가지 카테고리로 화두를 던질 수 있는 질문을 준비 해두었습니다.

기능 구현 - 대기실 화면

대기실 화면에서는 방장/참여자들의 상태 정보를 확인 할 수 있습니다.

대기실에는 방을 생성한 “방장” 과 참여 코드를 통해 방에 참여한 “참여자” 로 구성되어 있으며, 게임 시작을 위한 준비중/준비 완료 를 설정 할 수 있습니다. “방장” 은 “참여자” 들의 준비가 완료되면 게임을 시작 합니다.

“참여자” 들은 게임 선택이 완료될때까지 '게임 준비중 화면' 에서 이동하여 대기하게 되며, “방장” 은 대기실에 입장한 “참여자” 들과 함께 진행할 게임을 선택하는 화면으로 이동 합니다.

기능 구현 - 빈칸주제

“방장” 이 게임 선택 화면에서 ‘빈칸 주제 게임’ 을 선택하면, “참여자” 들과 함께 게임이 시작 됩니다.

‘빈칸 주제 게임’ 은 “지하철에서 만난 빌런은 ___ 이다.” 와 같은 질문에 자신만의 경험을 적어 제출합니다.

소켓을 통해 사용자들의 모든 답변이 완료되거나 1분 타이머가 종료되는것을 실시간으로 체크하고 결과 페이지로 이동 하게 되며, 결과 페이지에서는 “방장” 이 답변을 랜덤으로 선정하게 됩니다.
랜덤으로 선정된 답변을 작성한 사용자는 자신의 경험을 공유하며 아이스 브레이킹을 진행 할 수 있습니다.

기능 구현 - MBTI

“MBTI 가 뭐예요?” 라는 질문은 첫 모임에서 자주 하게되는 단골 질문이 되었습니다.

‘팀원 성향 파악 게임’ 은 실시간으로 사용자의 MBTI 정보를 입력 받아 “나의 MBTI 별명” , “우리팀의 MBTI 조합/별명” , “MBTI 설명” 등을 확인 할 수 있습니다.

3) 프로젝트를 마무리하며

저에게 DND 가 한단계 성장할 수 있는 기회가 되었듯이

다음 기수에 지원하시는 분들에게도 DND 가 좋은 경험이 되었으면 좋겠습니다 :)

링크 : DND 10기 합격 후기 & 지원서

열정적인 기획 회의의 흔적들…

많은 시간을 프로젝트를 위해 투자해준 팀원들에게 다시 한번 감사하다는 말씀 전하고 싶습니다.

최종 발표 한컷

2달간 온라인에서만 만났던 팀원들을 오프라인에서 만나게되니 감회가 새로웠습니다

기념품 인증사진

DND 로고가 들어가 있는 손목 보호대를 기념품으로 받았습니다 :)

( 너무 귀엽지 않나요…. )

4) 프로젝트를 끝마치고 나자신을 돌아보며

내가 다른이에게 해주는 이야기는 결국 돌고 돌아 나 자신에게 하는 이야기가 되는것 같습니다.

최선의 하나를 본받을것인가, 최악의 하나를 본받지 않을것 인가

이번 프로젝트를 진행하며 과거에 본받지 않기를 희망했던 모습의 일부가 나에게서 보여졌다는것을 인지하게 되었다.

나에 대한 실망감이 크면서도 어떻게 해야할까 라는 의문만이 머리속에 남으며, 한편으론 깨닳을 수 있던 기회조차 없었다면 나에게 보여졌던건 일부의 모습이 아니라 전체의 모습이 아니였을까.

어떤 사람을 만나느냐에 따라, 어떤 경험을 하느냐에 따라 찰나의 내가 가지게 되는 가치관은 변해간다.

나는 오는 사람을 분별해서 받지 않고 떠나가는 사람을 붙잡지 않았다. 나는 이것이 사람간의 관계에 있어 상처 받지 않기 위해 내가 할 수 있는것이라고 생각했다. 오해로 인해 틀어진 관계라고 하더라도 내가 가진 도구중에 “오해를 해명하고 관계를 복구” 하는 능력을 가진 도구는 없었다.

프로젝트를 진행하다보면 사람간의, 파트간의 다툼은 흔하게 발생한다.

누군가는 말을 하기도, 누군가는 속으로 참기도 한다. 과거 (회사) 의 나는 후자의 경우로 참다가 병이난 케이스였다.

이번 프로젝트를 진행하며 내가 알지 못했던 방법으로 지혜롭게 문제를 풀어가는 사람들의 모습을 보게 되었다.
그 모습을 지켜보면 신기하면서도 한편으로는 슬럼프로 인해 쌓여있던 마음속 응어리가 사라지는게 느껴졌다.

나는 “사람은 변한다” 라는 말을 믿기에 이번의 잘못을 인정하고 나아가기 위해 '바뀌겠다' 다짐하게 되는 계기가 되었다.
이제 털어내야지.

[지원하기] DND 10기 백엔드 합격 후기 ( feat. 지원서 )

TLOWAC — Wed, 28 Feb 2024 20:09:47 +0900

https://www.dnd.ac/

1. 들어가며

원래는 DND 합격 발표일인 23년 12월 28일에 합격 후기를 작성해야 헀는데,

개인적인 사정으로 인해 DND 최종 발표까지 마무리한 지금에서야 합격 후기를 작성하게 되었습니다.

부디 넓은 마음으로 양해 부탁드립니다

1.1) DND 에 지원하게된 계기

저는 스타트업에서 2년 1개월의 경력을 마무리하고 나온시점에 그동안 바쁘다는 핑계로, 프로젝트를 진행해야 한다는 책임감으로 외면하고 회피했던 번아웃을 겪게 되었습니다. 퇴사를 하고 난뒤 시간이 많아져서 그런가, 흔히들 말하는 “놀면 병난다” 라는 말이 너무 공감 되던 시기 였습니다.

“1일 1커밋” , “수영 배우기” , “카페에서 업무하기” , “바빠서 만나지 못했던 사람들 만나기” , “블로그 글쓰기” , “요리 배우기” 등 이 상황을 벗어나고자 발버둥 쳤고 다방면으로 노력 했습니다. 하지만, 저에겐 예전과 같은 의욕도, 열정도 무언가에 대한 흥미도 느낄 수 없었습니다.

개발자라는 직업에 있어 커리어를 지속하는것을 고민하던중 인스타그램을 통해 DND 모집 공고를 보게 되었습니다.

대학생활과 회사 생활을 할때도 다양한 개발 프로그램을 지원했지만 한번도 합격한적이 없었습니다.하지만, 지원조차 하지 않으면 바늘구멍을 통과할 기회조차 주어지지 않는다는것을 알고 있었기에 붙을것이라는 기대는 내려놓고 DND 에 지원하게 되었습니다.

1.2) DND 합격

10기 합격 발표일 : 2023.12.28
10기 프로젝트 시작일 : 2024.01.01
10기 최종 발표일 : 2024.02.24
10기 지원 파트 : 백엔드

23년 12월 28일에 DND 10기 합격 메일을 받고 한편으로는 기쁘면서도 걱정이 많았습니다.

하지만, 최종 발표까지 마무리한 지금 지난 2달을 돌아보면 너무나 감사할따름 입니다.

2. 지원서 작성하기

다음 기수 지원시에는 질문의 내용이 이번 기수와는 다를 수 있기에 참고만 하시길 권장 합니다 :)

제가 DND 10기를 지원하며 작성한 지원서를 공개하는 이유는 크게 2가지 입니다.

첫번째는 저처럼 지원하는 개발 프로그램마다 떨어지시는 분들께 조금이나마 도움이 되었으면 좋겠습니다.

두번째는 자소서를 여러번 작성해봤지만 300자, 500자 와 같이 질문당 제한된 글자수로 인해 제가 어떤 경험을 했는지, 문제들을 어떻게 극복했는지에 대해 작성하기 어려웠습니다. 쓰다보면 금방 글자수 제한에 걸려버려서 제가 이야기하고자 하는 내용의 20% 도 작성하지 못하는 경우가 많았습니다. 하지만, DND 지원서를 작성할때는 글자수 제한이 없었기 때문에 제가 이야기하고자 하는 내용의 70%는 담아낼 수 있었다고 생각합니다. ( 나머지 30% 는 저의 미숙한 글쓰기로 인해… )

DND에 지원하게 된 동기와 활동을 통해 이루고 싶은 목표에 대해 최대한 구체적으로 작성해주세요.

지난 2년, 개발자로 근무하면서 진행한 업무들은 개발을 처음 공부할때와는 다른 경험과 성장을 할 수 있었습니다.

하지만, 한가지 아쉬웠던 점은 스타트업 특성상 빈번히 교체되는 동료/선임 개발자들과 백엔드는 혼자서 감당했어야 했다는점입니다.

회사 전체 인력의 60%가 한순간에 날아가는 그 시기는 아직도 기억에 남습니다.

"이제 어떻게 하지, 내가 혼자서 잘 할 수 있을까 라는 불안", "매크로 유저들로 인해 RDS CPU 점유율이 99% 에 맴돌아 멈춰버린 서버를 수습할때의 초조함", "맘놓고 질문하고 함께 문제를 해결해나갈 동료, 선임 개발자들이 없는 막막함". 여러가지 벽을 넘어가며 성장했지만, 혼자였기에 넘지 못했던 벽들이 존재했고 이번 기회에 그 벽을 넘어서는 경험을 해보고 싶습니다.

개발 활동(학교 수업, 프로젝트, 경진대회 등)을 진행하며 모르는 문제를 마주했을 때 해결한 경험에 대해 설명해주세요. 얼마나 기술적으로 어려운 문제였는지는 중요하지 않습니다. 사소하더라도 본인의 접근 방법과 해결 과정, 해결하지 못했더라도 그것을 통해 어떻게 성장했는지를 중점적으로 최대한 자세히 작성해주세요.

다수의 인력이 퇴사한 이후, 회사는 주요 비즈니스를 WEB 에서 APP 으로 변경하고자 하였고,

이 과정에서 1달이라는 시간안에 외주 개발사로부터 프로젝트를 인수인계 받아 서비스 출시 및 배포, 운영해야하는 상황이었습니다.

외주사와의 의견차이, 기존 설계와는 다른 결과물, 빈약한 인수인계 문서등의 부차적인 문제를 제외하고 우여곡절 끝에 출시한 서비스는 많은 부분에서 문제가 있었습니다.

오후 7시 40분 퇴근을 하고 지하철을 타기위해 지하철 게이트에 카드를 찍은 순간 걸려온 이사님의 전화 한통. '창훈님 지금 APP 에 들어가면 무한 로딩이 되고 아무 기능을 쓸 수 없어요. 빨리 와주셔야 할것 같아요."

당시에는 AWS 에 대한 지식이 부족했기 때문에 RDS Performance Insight 를 확인하고 문제가 되는 쿼리를 확인하고 DB 락을 풀고 문제가 되는 유저를 벤하는등의 자연스러운 프로세스를 진행하지 못했습니다.

당시에 제가 문제를 파악했던 방법은

해당 서버가 배포된 AWS EC2 접속
docker swarm 의 형태로 배포된 서버의 로그 확인
서버의 로그 확인 결과 API 요청에 대한 조회 결과가 null 로 리턴되는것을 확인
옆에 같이 계시던 이사님에게 해당 내용 전달 및 대응
EC2 재부팅 ( 실제 운영중인 서비스에서 운영중인 서버를 꺼버린다는게 말이 안되었지만 무한로딩의 상태에서 사용자들의 지속적인 접속으로 인해 API 요청이 계속해서 쌓이고 DB 에 락된 쿼리들이 늘어나는것을 방지하기 위해 생각난 방법이 이것 밖에 없었다.. )
DB 트랜잭션 모니터링 ( select * from information_schema.innodb_trx; )
RDS 인스턴스 임시 업그레이드 ( large > xlarge )
AWS RDS CPU 점유율 모니터링
락된 트랜잭션 해제 작업 진행
DB 쿼리별 통계 모니터링 ( select * from sys.schema_table_statistics LIMIT 1; )
문제가 발생한 DB 테이블 및 쿼리 확인
해당 쿼리의 userId 확인
해당 유저의 API 요청 빈도수 확인 ( 룰렛 API 의 경우 평균 3 ~ 5 초를 정상 유저로 판단 )
메크로 유저 판단 및 벤 처리
EC2 부팅
EC2 CPU 및 RDS CPU 점유율 모니터링
경과 보고 및 문제 원인 공유

해당 작업을 마치고 나서 여러가지 생각이 들었다.

내가 조금 더 많은 지식을 알고 있고 다양한 경험이 있었으면, 좀 더 빠르게 대응할 수 있지 않았을까.

이후에 AWS 에 대한 공부를 진행하며, 출시한 서비스의 인프라 및 빠른 대응을 위한 방법들을 찾을 수 있었고 하나씩 적용해나갔다.

첫번째는 Grafana 를 사용한 회사내 인원들이 RDS 모니터링을 할 수 있게끔 구성하는것이었다.

실 서비스에서 문제가 발생하여 대응하는것이 아닌 누구나 지표상 문제가 있다고 생각되면 개발자나 대표님에게 알릴 수 있도록 하기 위함이었다. 여기에 더해서 CloudWatch 를 통해서 RDS 의 CPU 점유율이 일정 비율을 넘어가면 특정 인원에게 알림과 메일이 발송되도록 구성하였다. 기준이 되는 CPU 점유율은 30% ~ 50% 였고 80%가 넘어가면 무조건 모니터링 해야한다는 텍스트가 담긴 메일이 전송되게 구성하였다.

두번째는 DB 쿼리의 용도에 따른 RO/WO ( ReadOnly/WriteOnly ) 쿼리 분리 작업이었다.

기존에 회사에서 개발하던 서비스의 백엔드는 해당 작업이 적용되어 있지만, 외주 작업으로 진행된 백엔드에는 해당 작업이 진행되어 있지 않았다. 그렇기 때문에 모든 쿼리가 W/O 로만 요청되어 과도한 트래픽이 발생되었고 이로 인해서 RDS CPU 가 튀는 현상이 발생했던것이었다. 외주 프로젝트의 백엔드 코드중 db client 코드를 수정하여 dbROClient, dbWOClient 를 추가하여 쿼리 작업을 세분화하는 작업을 진행했다.

마지막으로 해당 이슈가 발생한 원인과 대응작업에 대한 내용을 공유하기 위해서 포스트모멘텀을 작성하여 공유하였다.

본인이 열정을 가지고 깊게 몰입하여 목표했던 것을 성취한 경험에 대해서 최대한 자세히 작성해주세요. 개발 관련 경험이 아니어도 괜찮습니다.

내가 겪은 스타트업이란 투자금을 기반으로한 회사 유지에 있어서 서비스의 출시와 운영, 매출 발생까지 필사의 사투를 이어 나가는것이었다. 그렇기에 회사의 런웨이 자금의 소모에 있어서 지출을 줄이는것은 개발자에게 주어진 하나의 숙제였다.

'서버 운영비' 지레 짐작하건데 인건비와 광고비를 제외하고 제일 많은 비용이 발생하는 부분이다. 당시 매월 약 500 만원 가량의 비용을 AWS 에 지불하고 있는 상황에서 받은 컨설팅 결과 회원수와 DAU/MAU 대비 과도한 비용이라는 지적이 나왔다. 약 1주일의 기간동안 서버 비용을 절감 하기 위한 작업에 착수 하였다.

우선적으로 작업한 부분은 AWS cost explorer 를 통해서 사용하고 있는 AWS 서비스별 발생 금액에 대한 지표 정보를 확인하는것이었다. 서비스별, 월별, 그룹별 지표를 다운로드하여 정리한 다음 가장 비용이 많이 발생하는 EC2 와 RDS 비용에 대해서 절감 방법을 모색하였다.

지난번 이슈로 인하여 임시로 변경한 RDS 인스턴스는 다음 앱 버전 업데이트에 맞춰 변경하기로 하였다.

EC2 의 경우 회사가 PR 을 위해 테스트용으로 운영했던 서버, 해외 진출 과정에서 해외 리전에 구성한 서버, 지금은 개발하고 있지 않는 프로젝트 서버등 별에 별 용도의 불필요한 서버가 동작하고 있었다. 해당 서버를 리스트업한다음에 대표님께 컨펌을 받고 서버를 종료하는 작업을 진행하였다. 이 과정에서 기존에 운영되고 있는 서비스들에 영향이 없는지 확인하기위해 모든 서비스를 8개 정도의 크롬창에 띄워놓고, 기획팀에도 요청드려 같이 체크해가면서 진행하였다. 그 결과 서버 비용은 약 500만원에서 200만원 중후반대까지 비용을 줄 일 수 있었다.

공동의 목표를 달성하기 위해 타인과 협업했던 경험과 본인이 수행한 역할에 대해 작성해주세요. 또한 갈등, 의견 차이 등 문제 발생 시 해결 경험과 해당 경험을 통해 얻은 것은 무엇인지도 최대한 구체적으로 기술해 주세요.

개발 관련 경험이 아니어도 되며, 만약 협업 경험이 없다면 본인의 협업 가치관과 문제 발생시 어떻게 해결할 수 있을지에 대해 작성해주세요.

스타트업은 실력 좋은 동료들과 새로운 기술스택을 기반으로 빠르게 서비스 출시를 위해 달린다.

내가 합류한 시점의 회사에서도 기존 서비스 리뉴얼하고 신규 프로젝트의 시작을 준비하던 시점이었다.

합류하자마자 기존 프로젝트를 팔로우업하고 새로운 프로젝트 요구사항을 분석하는 과정에서 들었던 한가지 의문은 기존 프로젝트들의 문서가 거의 존재하지 않는다는점이었다. 그렇기에 신규 입사자가 들어올때마다 주어진 가이드 문서를 기반으로 기존 프로젝트를 학습하는것이 아닌 팀장님이 직접 가르치고 계셨다. 당시에 내가 가장 잘하는것이 정리하는 글쓰기 라고 생각했었기에 프로젝트를 팔로우를 위해 주어진 기간동안에 내가 파악한 기존 프로젝트의 구조와 API 제작 방식등을 정리해서 공유하였고 이후에 들어온 신규 입사자는 해당 자료를 통해서 기존 프로젝트를 팔로우하여 신규 입사자의 교육을 담당하던 팀장님과 동료들의 공수를 줄일 수 있었다.

프로젝트가 커지면 커질 수록 개발 문서의 중요성은 수직 상승하는것 같다.

하지만, 문서를 정리하는것을 '일 이 늘어나는것' 이라고 생각하여 지양하는 개발자도 존재한다.

설득하기 위해 시도했던 방법은 솔선수범하는것과 문제를 정의하고 이를 해결하기 위한 방법을 적용했을때의 결과를 공유하는것이다.

앞서 문서화를 예로 들어보자면,

첫번째 문제로 기능별로 API 를 분담해서 작업하는 개발자 특성상 내가 룰렛 API 를 제작하고 동료 개발자가 뽑기 API 를 제작한다고 하면 자기가 개발할 API 에 대한 부분은 인지하고 있을지라도 다른 사람의 담당 API 는 알지 못하는 문제가 있다. "이게 뭐가 문제야" 라고 할 수도 있지만, 해당 API 를 담당한 개발자가 휴가를 해외로 가거나 전화를 받을 수 없는 상황인 경우 문서가 없기 때문에 코드로만 원인을 파악해야나가야한다. 우리도 알다시피 남이짠 코드는 선뜻 수정하기에 어려움이 있다.

두번째 문제로 기존에 개발을 진행한 개발자가 다 빠진 상황에서 새로운 개발자로 투입되어 프로젝트를 파악하고 신규 기능을 업데이트 할때이다. 기존에 개발에 참여한 개발자가 존재한다면 해당 개발자에게 프로젝트의 전반적인 내용, 배포 방법, 프로젝트 이슈 히스토리 등을 물어볼 수 있지만 개발팀 교체인 경우 물어볼 사람도 없을뿐더러 퇴사한 사람에게 연락하여 "혹시 00님이 개발한 00 부분 기억나세요?" 라고 물어보는것도 전화를 받는다는 가정하에 가능하다.

세번째 문제는 첫번째 문제와 비슷하다. 만약 신규 기능을 업데이트 한뒤 룰렛 API 에서 문제가 발생하여 해당 API 개발을 담당한 A 라는 개발자가 이슈를 수정한뒤, 원인과 코드를 수정한 부분/해결 과정등을 정리하여 공유하지 않았다고 가정한다. 그러면 해당 개발자가 자리를 비운 사이에 동일한 CS 가 발생할 경우 해당 이슈의 처리를 할당 받은 B 라는 개발자는 어느정도의 삽질을 감수해야한다.

경험에서 얻은 문제점을 정의하고나서 이를 기반으로 기능 제작 작업 과정 및 이슈 처리 과정에 대한 문서를 정리하여 개발팀 세미나 시간에 공유하였다. 대표적으로 가장 큰 호응을 얻었던 문서는 이사님 전화를 받고 부랴부랴 회사에 와서 처리한 이슈에 대해 정리된 문서였다. 해당 문서에는 문제의 원인, 해결 과정, 후속 대응에 대해 적어놓은 포스트모멘텀 문서였다. 이후에, 내가 휴가를 갔거나 한 상황에서 RDS CPU 점유율 이슈가 발생한적이 있었는데 이때도 사전에 공유한 문서를 기반으로 문제가 될 수 있는 부분을 확인하고 해결 과정에 정리되어 있는 DB 쿼리 통계 SQL 등을 참고하여 이슈를 해결하는데 참고 할 수 있었다고 전해들었다.

3. 글을 마무리하며

다음 기수에 지원하시는 분들도 DND 가 좋은 경험이 되었으면 좋겠습니다.

기존 기수는 DND 참여가 1회정도 더 가능하기에 연이 닿는다면 프로젝트를 같이 하게 될 수도 있겠네요 :)

마지막으로 제가 DND 에서 진행한 프로젝트가 궁금한 분들을 위해 링크를 남깁니다 XD

링크 : DND 를 마무리하며 ( feat. 최종 발표 )

[AWS 트러블슈팅] AWS 운영 비용 절감하기

TLOWAC — Tue, 7 Feb 2023 00:44:49 +0900

1. 들어가며

1.1 히스토리 ( 썰풀기 )

이전까지는 "인프라는 팀장님!" 이라는 수식어가 붙어 있었던만큼 해볼 기회가 많이 없었다.

하지만, 기존 인력들이 대거 퇴사하고 내가 서버쪽에 모든 업무를 담당하게 되고 직무가 벡엔드 개발자로 변경됨에 따라 자연스럽게 AWS 서비스들의 운영과 관리등의 업무도 내 담당이 되었다.

이제는

서버에 문제가 생기면,

CS 가 들어오면,

신규 기능 추가 요청이 들어오면,

새로운 이슈가 생기면

내 이름이 노티되기 시작했다.

1.2 다시 현재로

전 담당자분이 퇴사하시기전까지는 한달에 약 5**만원 정도의 AWS 비용이 청구되고 있었다.

예전에 아무것도 모를때는 이 비용이 당연한것인줄 알았는데, AWS 서비스들을 공부하고 현재 우리 회사 서비스들의 유저수/트래픽 대비 너무 과다한 비용이 발생하고 있다는것을 알게 되었다.

2. 비용 절감 작업

2.1 목적 정의

이번에 투자 시장이 얼어붙으면서 회사에서도 기존에 예상한 런웨이 기간보다 버터야하는 기간이 길어진것 같았다.

현재 가장 많은 비용이 발생하고 있는것은 EC2/RDS 였고 이에 대한 비용 절감이 이번 작업의 목표였다.

2.2 작업 정의

작업을 진행기 앞서서 체크리스트를 작성하여 체크해야되는 부분들을 정리한뒤 작업을 진행했다.

메인 절감을 AWS 비용에 있어서 큰 비율을 차지하는 EC2/RDS 위주로 작성되었지만, S3, Config 등도 비용 절감 작업에 포함되었다.

작업전 EC2 일별 발생 비용
작업전 RDS 일별 발생 비용
동작하고 있는 EC2 인스턴스 정보
동작하고 있는 RDS 클러스터 ( 하위 인스턴스 ) 정보
기타

3. 작업 내역

3.1 EC2

청구 비용의 비율이 제일 큰 서비스만큼 현재 구성되어 있는 인스턴스상에서도 문제점들이 많았다.

첫번째는 과거 MVP 프로젝트 또는 IR 발표를 위해 임시로 생성한 EC2 인스턴스들이 아직도 구동되고 있었다. 인스턴스 타입 ( 예시 : xlarge, large, medium 등 ) 은 낮은편에 속해 있어 비교적 비용 부담이 적을 수 있다고 생각 할 수 있지만, 그 갯수가 약 10개 가량되었다.

두번째는 앞서 설명한 EC2 들에 EIP, EBS 등이 추가되어 비용이 발생하고 있었다는점이었다.

세번째는 베타 서비스 과정에서 외국 region 에 새롭게 설정해놓은 EC2 인스턴스들이 현재는 사용되지 않는 않고 있었다.

네번째는 굵직굵직한 비용을 발생시키고 있는 인스턴스 타입 ( 예 : large, xlarge ) 의 인스턴스들의 경우에는 쉽게 건들 수 없었는데

그 이유는 몇몇 인스턴스에서는 어떤 서비스/서버가 구동되고 있는지 그 누구도 모르기 때문이다. 이 때문에 해당 인스턴스 타입 변경 이후 재부팅시 발생할 수 있는 사이드 이펙트를 누구도 알 수 없었다.

일부는 내가 작업한 프로젝트이기 때문에 알고 있지만, 내가 입사하기도전에 작업이 마무리된 프로젝트들도 있기 때문에 Github 에 업로드 되어 있는 프로젝트들의 Github Action CI/CD 의 workflow 파일을 일일이 확인해가며 확인한뒤 작업을 진행했다.

3.2 RDS

시작한지 얼마되지 않은 서비스들의 경우 상황에 따라서 '돈' 으로 해결하는 경우가 있다.

특히 슬로우 쿼리 같은 부분은 서비스 초기에는 발생하지 않고 어느정도 규모가 커지고 데이터 레코드가 쌓이기 시작하며 문제가 발생하는 경우가 많기 때문에 RDS 의 CPU 점유율을 모니터링하고 있다가 CPU 피크가 발생할때 작업을 진행한다. 이를 위해서 slack/teams/discord 등에 채널 훅을 사용하여 슬로우 쿼리 모니터링 알림을 보내고 있다. ( 이를 위해서는 슬로우 쿼리 필털이 기준을 설정해야 하는데 보통 3 ~ 5초 정도를 설정하는것 같다. )

우리 회사도 서비스 출시 이후 급격히 몰리는 트래픽과 성능상 이슈 처리에 대한 임시방편으로 현재 운영 환경에서 사용하고 있는 RDS 인스턴스의 타입을 ( 예시 : xlarge, large 등 ) 수정하여 대응한적이 있다.

변명아닌 변명을 하자면 이렇게 하지 않으면, DB 는 CPU 점유율 99% 찍어놓은 상태에서 추가적으로 계속해서 서버에서 요청을 받는다.

DB 는 해당 요청을 처리하여 데이터를 추출하지 못하기 때문에 서버의 요청에 대해서 데이터를 반환하지 못하게 되는 악순환이 지속된다.

따라서

1. 서버 장애 공지

2. 사용자의 API 요청 제한

3. DB 인스턴스 타입 변경

4. 서버 재부팅

5. 개발자 테스트

6. 서비스 운영 재개

7. 기타

등등의 방법으로 진행한다.

이야기가 잠시 다른데로 샜는데... ( 이거에 대해서 트러블 슈팅했을떄가 떠올라 울컥했다... )

다시 본래의 이야기로 돌아와 이야기를 해보자면, 앞서 설명한 이슈들로 인해 일시적으로 한사이즈 업그레이드 했던 RDS 인스턴스 타입을 이슈가 해결된 이후에 원복을 하지 않은 상태였다. ( 물론 이와 관련해서도 여러가지 히스토리가 있다. )

그래서 이번 작업은 RDS 의 인스턴스 타입을 다시 원복하고 운영 서비스를 재개했을때의 RDS 의 CPU 점유율을 모니터링하면서

혹시나 발생할 수 있는 사이드 이펙트들을 대응하였다.

3.3 Config

Config 와 관련하여 불 필요해 보이는 규칙들이 많이 설정되어 있었다..

이게 1초당 약 10개 정도가 처리되는것을 확인 할 수 있었는데.....

자세한 설명은 생략하겠다...

3.4 Nat Gateway

외주 개발자분과 함께 기존에 운영되고 있는 서비스 마이그레이션 작업을 진행하였다.

이 과정에서 AWS 인프라도 전면 리팩토링 되었는데 VPC 내 설정한 Nat Gateway 과도한 비용이 발생하게 되었다.

Terraform 으로 AWS 인프라를 작업한 개발자분도 이렇게까지 비용이 많이 발생할것이라고 미쳐 생각하지 못하신것 같았다.

이거 하나만으로도 1월 청구 비용이 3/1 줄어든다. ( 1월에 이것 떄문에 비용이 많이 나와 현재 AWS Support 에 문의글 넣어놓은 상태이다... )

4. 작업 결과

AWS cost explorer 에서 일별 비용을 뽑아 결과를 비교해보았을때 3/1 정도로 비용이 절감된것을 확인 할 수 있었다.

아직은 Saving Plan 을 사용하지 않은 상황인데 Saving Plan 을 적용하였을때 추가적인 비용 절감 효과를 볼 수 있을것 같다.

cost explorer

4. 마무리글

지금까지 AWS 서비스 비용을 지출한게 내 돈이라는 생각을 해보면 머리가 아찔해진다...

회사에서 비용 절감 작업을 맡아 진행하게된 업무였지만, 이번 업무를 통해서 각 서비스별 비용 산출 방법 및 서비스의 인스턴스 타입별 특징 및 Saving Plan/RI 등 비용절감에 대한 다양한 개념을 학습할 수 있었다.

나도 내 서비스를 만들떄 이런 경험들에 유의하며 작업해야겠다는 생각이든다...

그때는 회사돈이 아닌 내돈이니까..

더불어 개발분야는 공부할께 끝도 없음을 새삼 다시 느낀다. ( 개발, DB, 업무 도메인, 인프라, 네트워크등... 이제는 비용까지... )

5. 참고자료

https://aws.amazon.com/ko/blogs/korea/10-things-you-can-do-today-to-reduce-aws-costs/

https://calculator.aws/#/

https://aws.amazon.com/ko/ec2/instance-types/

[ 생각정리 ] 인수인계 / 문서가 전무한 상황에서 원인 파악후 해결하기

TLOWAC — Thu, 2 Feb 2023 03:01:43 +0900

1. 들어가며

개발자들에게 있어서 가장 막막한 상황중 하나는 이슈가 발생헀는데, 해당 이슈와 관련해서 문서가 존재하지 않고 기존 인력의 퇴사로 개발 히스토리를 알 수 없는 상황이 아닐까.

그 건드리면 안될것 같은 지뢰밭을 내가 밟게 되었다.

2. 이슈

2. 1 이슈 발생 계기

잔잔하던 나의 회사생활에 긴장감을 주는 순간이었다..

이번에 개발자분께서 AWS 관련하여 작업한 부분으로 인해 이슈가 발생하였다.

해당 이슈 발생 이후 사태 해결을 위해 작업한 내용에 대해서 원복하였지만 그럼에도 계속해서 이슈가 발생하고 있었다.

2. 1 이슈 설명

현재 다니고 있는 회사는 공유기 기반의 에드테크를 사업을 진행하고 있어 각종 서비스가 공유기와 의존성이 있다.

MQTT , Mosquitto broker 서버 , pub/sub 서버 , 스케줄러등... 진짜 다양한데, 이번에 여기서 이슈가 발생하였다.

3. 트러블 슈팅

3.1 담당자와의 커뮤니케이션

공유기와 관련된 API 및 기능, 서버 / 인프라들은 내가 입사하기 훠어어어얼씬 전에 구성되어 있었고 실제 개발에 참여하여 개발 히스토리를 꿰고 있는 개발자 ( 서버 ) 분은 퇴사를 하셨기 때문에 첫 시작은 되게 막막했다.

우선은 해당 내용을 알만한 개발자 ( 펌웨어 ) 분과 커뮤니케이션 하면서 정보의 구멍을 하나씩 메꿔갔다.

그나마 다행이었던점은 펌웨어 개발자분이 공유기 개발을 진행하시면서 개발자 ( 서버 ) 분과 커뮤니케이션 하는 과정에서 대략적인 흐름은 알고 계셨다는점이었다. ( 하지만, 어느 EC2 인스턴스에 서버/스케줄러/redis/mongoDB 가 배포되어 있는지에 대한 정보와 Github Repo 중 관련되어 있는 Repo 에 대한 내용은 알 수 없었다. )

담당자와 커뮤니케이션한 내용을 기반으로 대략적으로 플로우 차트를 그렸다.

3.2 개봉 들어갑니다. 딴 ~ 따라란

"예림이 그 REPO / EC2 봐봐 사쿠라여?"

"이게 뭐여 꽝이네?"

이슈를 해결한 지금에 와서는 "제비뽑기하는줄 알았다" 라고 말하고 웃어 넘기겠지만, 당시의 착잡한 심정을 이루 말할 수 없다.

정리된 내용이 없다보니 Github Repo / EC2 중에서 이번 이슈와 연관되어 보이는것으로 추측되는것들을

1차적으로 리스트업하고 하나씩 확인해보는 작업을 진행했다.

3.3 삽질, 삽질 그리고 삽질

Notion 정리한 내용이 거의 한바가지기 때문에 다 작성하는것은 무리일것 같다.

일부분만 작성하자면, 아래의 방법들을 시도했었다.

1. Github Action CI/CD workflow 파일 확인

2. redis/mongoDB 도커 컨테이너 배포 인스턴스 확인

3. redis/mongoDB 도커 컨테이너 로그 확인

4. redis/mongoDB 데이터 베이스 및 데이터 확인

5. 어드민에서 호출하는 API 엔드포인트 트랙킹 ( 가비아에서 CName 확인 -> AWS 의 EC2 리스트업 )

6. MQTT Topic Pub/Sub 로그 확인

7. MQTT Topic 을 구독하는 서버 확인

8. EC2 의 Linux Daemon 에서 구동중인 service 상태 및 로그 확인

9. 기타 등등등등

진짜 피가 마른다는거를 실시간으로 체감하였다.

실제 운영중인 서비스에 장애가 발생한것과 마찬가지였기 때문에 더 초조했었다.

3.4 전체적인 서비스 구성은 도대체 어떻게 되어 있는거야?

"3.3 삽질, 삽질 그리고 삽질" 의 과정을 통해 어느정도 파악이된 부분들을 하나씩 정리해나갔다.

우선은 AWS 인프라 아이콘등을 활용하여 대략적인 서비스의 인프라 구성도를 제작하였다.

트러블 슈팅 과정에서 "공유기 -> Mosquitto broker 서버 -> Redis -> 스케줄러 -> RDS" 과정중에 "Redis -> 스케줄러 -> RDS" 에서 문제가 발생한것을 확인하였고, 대응 작업을 진행했다.

다행히도 서비스는 다시 정상적으로 돌아왔다..

4. 마무리글

밤샘의 흔적들..

간혹가다가 맞닦뜨리는 상황이지만 관련 문서가 아무것도 없는것을 알게되면 눈앞이 아찔해진다.

그래도 이제는 짬이 좀 찼는지 이런 상황에서 어떤식으로 문제에 접근하고 시도하고 해결하는지에 대해서
경험치가 쌓인게 확실히 느껴진다.

조금이지만 노하우? 를 공유하자면,

이런 "인수인계 / 문서가 없는 이슈" 들을 맞닦뜨리면 이제는 아래와 같이 대응 할 수 있다.

1. 관련 부서 담당자 커뮤니케이션 ( 이슈중 개발 히스토리를 알고 있는것이 있으신지 질문 드리고 정리 )

2. 커뮤니케이션 내용을 바탕으로 플로우 차트 초안 제작 ( 부족한 부분은 트러블 슈팅 과정에서 파악해가며 수정 )

3. 삽질 ( 이슈 원인으로 추측되는 모든것들을 리스트업하고 하나씩 수행 )

4. 3번의 삽질을 통해 하나씩 파악하게 되는 내용을 정리

5. 3, 4번의 과정을 반복

6. 해결

해당 이슈가 이번 한번만 일어날것이라는 보장은 없기 때문에 다음에 똑같은 이슈를 맞닦뜨리는 사람을 위해

이번에 삽질한 내용과 트러블 슈팅 과정, 해결 방법등을 정리해서 회사 채널의 Notion 에 공유해놓았다.

미래의 내가 될수도 있지만, 개발자들이 이슈 원인 파악을 위한 접근성이 수월해지기를 기대한다.

[ 회고 ] 2022년을 돌아보며

TLOWAC — Wed, 4 Jan 2023 09:13:25 +0900

들어가며

안녕하세요 개발자 이창훈 입니다. 오랜만에 찾아뵙게 되었습니다 :)
이번년도 첫글은 지난 2022년도를 회상하며 회고하는 글을 작성해보고자 합니다.

아! 2023년도를 다짐하는 글도 포함되어 있습니다.

Good Bye 2022!

인턴 교육 & 면접 진행

회사와 연계된 교육기관으로부터 4분정도를 인계 받아 한달이라는 짧은 기간동안 교육을 진행하였습니다.

인턴분들의 열정 넘치는 모습에 자극을 받아 저도 더 열심히 그리고 하나라도 더 알려드리려고 노력했습니다.

인턴분들이 과제로 주어진 프로젝트를 하시면서 다양한 질문을 주셨는데, 답변하는 과정에서 몇몇 질문은 얼버무렸던 기억이 있습니다..

후일담으로 얼버무렸던 질문들은 얼른 찾아보고 정리하여 답변드렸었습니다 ㅋㅋㅋㅋ

인턴분들의 면접을 진행하게 되면서 면접 질문 초안 작성과 면접 참여를 하게 되었습니다.

"낮은 연차에 이걸 해도 되나?" 라는 생각이 들었지만, 다양한 업무를 진행할 수 있는 스타트업의 매력인것 같습니다.

덕분에 "다른 개발자들은 이런 질문에 어떻게 대답할까?", "다른 개발자들은 어느것에 우선순위를 두고 있는지", "어떻게 학습하는지", 어떻게 대처하고자 하는지" 등에 대해서 인사이트를 얻을 수 있는 귀중한 경험이었습니다.

강릉시 프로젝트

2022년도에 처음 맡아 진행하게된 프로젝트였습니다.

아무래도 공공기관 프로젝트이다보니 여러가지 제약사항이 많았습니다.

AWS 와 같은 서비스는 일체 사용할 수 없었고 회사에 서버를 가져와서 직접 환경 구성 및 작업을 해야했습니다.
( 이때 팀장님께서 전산실에 있을법한 서버를 가져와서 초기 작업을 진행하셨습니다. )

어드민과 캡티브포털 페이지는 next.js, mui, react, typescript 로 제작을 진행하였으며

서버는 graphql, apollo, express, mongodb 로 구성하였습니다.

현재는 정상적으로 운영중이며, 강릉시 공공와이파이 접속시 캡티프 포털 페이지에서 확인 할 수 있습니다.

매장주 어드민 프로젝트

동시다발적인 동료들의 퇴사

스타트업의 특성상 인력의 순환(?) 은 비교적 자주 있어지만, 이렇게 한꺼번에 인력이 빠진건 처음이었습니다.

더불어 개발 팀장님과 이 회사에서 6년정도 근무하신 파트장님도 퇴사하시게 되었는데 진짜 앞이 컴컴했습니다. ( 두분다 저희팀.. )

시기상 산업체 전역일 5개월 하고 n일 남은 시점이라 이직이 안되서 오도가도 못하는 상황이어서 더 멘붕이었습니다.

지금에 와서 이때를 회상해보면 "와... 이때 무슨 정신으로 버텼을까" 라는 생각이 제일 먼저 듭니다.

그리고 이때부터였습니다...

모든 이슈와 기획과 운영글에 제가 노티되던 시점이...

갑작스러운 직무 변경

기존에는 프론트에 중점을 두고 백엔드는 서브로 진행하는 형식으로 Typescript 기반의 풀스택 프로젝트를 진행했었습니다.

하지만, 인력이 빠지면서 회사가 메인으로 진행하는 서비스를 웹 -> 앱으로 변경하면서 프론트는 Flutter 개발자 분이 담당하시게 되었습니다. 그래서 남은 선택지는 퇴사 or 직무 변경 이었고 결국에는 백엔드 전담으로 직무를 변경하게 되었습니다.

그렇게 하루 아침에 처음 보는 프로젝트의 신규 기능 개발을 2주안에 끝마쳐야하는 상황에 놓여지게 되었습니다.

"그정도는 개발자면 당연하게 해야하는거 아니냐!?" 라고 하실 수도 있습니다.

하지만, 당시를 회상해보며 변명 아닌 변명을 하자면

"1년 반을 근무하면서 난생 처음 보는 프로젝트"

, "미쳐날뛰는 RDS CPU 점유율"

, "전무한 테스트 코드"

, "처음 보는 패턴의 API 작성법"

, "존재하지 않는 가이드 문서"

, "의미를 알 수 없는 DB 테이블"

, "테스트 환경조차 구성이 안되 로컬 구동시 죽어버리는 서버... ( yarn dev 가 안된다.. )"

그리고 정점은 추가해야할 신규 기능은 "코인 입/출금" , "기프티콘 구매(코인)" 이었습니다.

미쳐날뛰는 RDS CPU 점유율

물론 이런 가시밭길을 걸어오며 쌓인 경험치를 통해 급격한 실력 향상이 이루어졌고 이를 체감하고 있습니다.

하지만, 다시는 하고 싶지 않은 경험입니다.

( AWS RDS CPU 점유율 관련된 내용은 Notion 에 따로 정리되어 있습니다. 추후에 기회가 되면 블로그에 정리하도록 하겠습니다. )

앞선 이슈들이 있고난뒤 올린 인스타에는 참담한 심정만이 남아있습니다.

Real MySQL 스터디 참여

RDS CPU 점유율이 피크치는 이슈들을 잡으면서 DB 쪽 지식이 부족한걸 절실히 깨닳게 되었고 Real MySQL 오프라인 스터디에 참여하게 되었습니다.

스터디에 참여하신 현직 DBA 분들에게 정말 많은 인사이트를 얻어 갈 수 있었고 DB 쪽 트러블 슈팅에 있어서도 한결 수월해졌습니다.

'임시' 파트장

10월달 부터는 '임시' 파트장으로서 업무를 진행하게 되었습니다.

담당하는 업무는 기존과 동일하지만, 파트장 회의, 기획 회의 등에 추가로 참여하게 되어 부담감이 크게 다가왔었습니다.

어플의 신규 버전 출시 ( node.js 백엔드 담당 )

앱버전이 v1.0.0 에서 v1.5.1 로 올라가는 과정동안

( 그때 당시에는 힘들어서 쓸 엄두조차 못냈던 내용... 지금에서는 추억이다..... )

신규 인프라 변경 & 적용

다룰 내용이 많아 별도로 포스팅 하도록 하겠습니다.

( 스포를 조금 하자면, EC2 기반의 Docker swarm 으로 구성되어 있는 서버를 ECS,

그래도 국방부의 시계는 흘러간다.

드디어 산업기능요원이 끝나 자유의 몸이 되었습니다.

( 아무도 날 막을수 없다 !! )

Welcome 2023!

자격증

올해의 목표는 notion 에 정리해놓은 자격증 목록에서 2개 이상의 자격증을 취득하는것을 목표로 두고 있습니다.

기술 스택

* 2021

회사 업무를 진행하기 위해 기술스택들을 학습하였습니다.

react, typescript, node.js, express, docker, mysql, graphql, graphql-codegen, apollo-client, apollo-server

* 2022

담당 업무가 백엔드로 변경되며 인프라에 대해서 학습하였습니다.

...위의 내용 포함 , aws ( s3, lambda, ec2, cloudfront, rds, alb ), terraform

* 2023

...위의 내용 포함 , aws ( ecs, eks, eventbridge, ecr ), terraform, nest.js

사내 세미나

2021 ~ 2022 중순 까지는 사내 세미나를 통해서 발표를 진행했었습니다.

하지만, 인원이 빠지고 나서는 세미나가 진행되지 않아 아쉬움이 남습니다. 그래서 기회가 되면 하루에 30분씩이라도 세미나를 진행하고 싶습니다. ( 우선은 팀원한테 한번 물어봐야겠습니다. )

이직

상황이 상황인지라 팀에 제 위로 아무도 없기 때문에 모든것을 해볼 수 있다는 장점은 있지만, 그만큼 짊어져야하는 책임에 있어서 조금은 힘이 들기 시작합니다. 팀장, 파트장님들이 있는 좀 더 큰 규모의 팀에 가고 싶습니다.

마무리글

2023년, 이제는 3년차 개발자로 불리게 됩니다.

이따금 "내가 3년차 라고 할수나 있을까?" 라는 회의가 들고는 합니다.
하지만, 이럴때마다 notion 에 기록된 제 삽질을 보며 "아 이정도 굴렀으면, 3년차라고 할 수 있지 않을까?" 라고 스스로를 다독여 봅니다.

[ tip ] 사용중인 포트 찾는 방법

TLOWAC — Thu, 2 Dec 2021 01:00:09 +0900

들어가기

'crtl' + 'c' 는 개발자들 뿐만 아니라 일반인들도 자주 애용하는 키보드 단축키입니다.

하지만, 개발자들의 경우 터미널에서 코드를 실행한 다음 중지 ( 또는 종료 ) 시키기 위한 용도로 'crtl' + 'c' 단축키를 사용하곤 하는데요.단축키를 사용하는 과정에서 현재 실행되고 있는 프로세스가 정상적으로 종료 되는 경우도 있습니다.

하지만, 경우에 따라서 종료 메시지는 출력되더라도 프로세스가 종료되지 않은 상황을 맞닥뜨리고는 하는데요.

이때 유용하게 사용할 수 있는 Linux Command 입니다.

( MAC, Linux 는 별다른 프로그램 없이 실행 가능하지만, window 의 경우에는 bash shell 이 요구 됩니다.)

현재 사용중인 PORT 의 PID 찾기

PORT 가 이미 사용중입니다 !

서버를 실행하는 과정에서 위와 같은 에러가 발생하였습니다.

해당 서버의 실행을 위해 사용하는 PORT 는 9000 번이기 때문에 명령어를 통해서 한번 확인해보도록 하겠습니다.

#$ lsof -i <port>
$ lsof -i 9000

 PID 확인하기

명령어를 통해서 PID 는 36248 임을 확인 할 수 있었습니다.

다음으로는 PID 를 사용해서 프로세스를 종료하는 과정을 진행하도록 하겠습니다.

PID 를 기반으로 프로세스 종료 시키기

#$ kill -9 <pid>   
$ kill -9 36248

명령어를 통해서 프로세스를 종료시킴으로써 해당 프로세스가 사용하고 있던 PORT 를 사용할 수 있게 된것을 확인 할 수 있습니다.

( 서버를 다시 동작시켰을때 정상적으로 실행되는것을 확인 할 수 있었습니다. )

전체 과정

[ 한걸음씩/지원하기 ] 우아한 스터디 ( Rust 스터디 그룹 ) 지원하기

TLOWAC — Mon, 8 Nov 2021 03:00:48 +0900

2021년 11월 01일에 '우아한형제들' 로부터 홍보성 메일이 하나 왔습니다.

응? 우아한 스터디 !?

우아한 형제들에서 진행하는 우아한 테크코스, 우아한 테크캠프와 비슷한 형태의 교육 프로그램인가..?

한번 내용을 쭉 훑어봤는데 기존에 진행하던 교육들과는 다른 방식이었습니다 :)

진행기간은 21년 12월 ~ 22년 1월 로 약 2개월 동안 진행되는데
몇몇 스터디는 "우아한 스터디" 가 종료된 후 일정기간동안 추가적으로 진행한다고 하네요.

추가로 직장인들도 참여할 수 있게끔 스터디의 진행시간이 7시 ~ 9시로 설정되어 있는 것이 아주 마음에 들었습니다.

( 막상 회사를 다니고보니 퇴근 후의 시간에 참여 할 수 있는 활동들이 많이 제한되었던 기억이.. )

총 5개의 스터디 그룹이 존재 했는데 저는 그중에서 2가지가 매력적으로 다가왔습니다.

문제 풀이로 익히는 알고리즘과 프로그래밍

: 회사에 지원하거나 이직하는 과정에서 요즘에는 코딩테스트를 보편적으로 진행하고는 합니다.

현재 근무중인 회사의 산업기능요원 근무기간이 끝나고 이직을 하는 과정에서 많은 도움이 될 것 같았습니다.

Deno와 함께하는 Rust 프로그래밍 (장기간)

: 비록 산업기능요원이지만 신입으로서 경력을 시작한지 얼마 안된 지금.

low-level 언어에 대한 이해와 Open Source 프로젝트에 참여하고 싶은 욕심이 생겼습니다.

회사에서 Typescript FullStack 개발자로 근무하면서 다양한 분야의 업무를 진행하고 있지만,

'재미' 와 '흥미' 의 요소가 다소 결여되어 있어 이번 스터디에 참여하여 다소 러닝커브가 있는 Rust 를 함께 학습하고

나아가 Github 에 존재하는 다양한 Rust 프로젝트에도 기여해보고 싶었습니다.

최종적으로는 "Deno와 함께하는 Rust 프로그래밍 (장기간)" 스터디 그룹에 지원하게 되었습니다.

스터디원으로써 선정될지도 미지수지만, 선정이 된다면 Rust 의 매력에도 한번 빠져보고 싶네요 :)

"우아한 스터디" 에 관심이 있으신 분들은 링크를 통해서 참여해보세요 !

2021년 9월 공지

TLOWAC — Sun, 19 Sep 2021 00:44:32 +0900

다시 만나게 되어서 반갑습니다.

11월의 블로그 포스팅 이후에 약 10개월만에 글을 쓰게 되는 것 같습니다.

여러분은 잘 지내셨는지 모르겠습니다.

제가 자리를 비운 약 10개월 동안 많은 분들이 블로그에 방문해 주셔서 내심 놀랐습니다.

이렇게 제 블로그에 찾아주시는게 감사할따름 입니다.

제가 업로드한 마지막 포스팅은 2020년 11월을 기점으로 하고 있습니다.

바쁘고 힘겨운 나날들을 보내느라 블로그 확인이 뜸했음에도 블로그에 찾아와 주시고 댓글을 달아주신 모든분들에게 감사드립니다 :)

항상 읽어주셔서 감사합니다.

앞으로는 이런 글들을 작성하게 될 것 같습니다.

이번에 다시 블로그 포스팅에 시간을 할애하게 되면서

처음 시작하게될 이야기는 최근 근황에 대한 내용이 될 것 같습니다.

저는 현재 개발자로서 "산업기능요원" 으로 군복무 중에 있습니다.

일반인이 보기에는 조금은 특수한 환경인지라 어떻게 해서 개발자로 "산업기능요원" 을 하게 됬는지 계기로 시작하여

2021년 1월 부터 2021년 9월인 현재까지 약 8개월 동안 회사 생활을 하면서 겪은 다양한 경험들을

포스팅으로 작성하여 전해드리도록 하겠습니다.

더불어 제 블로그에 앞서 포스팅 되어 여러분들의 발걸음을 이끌었던

"알고리즘", "1% 이해하기 시리즈" , "1% 에러잡기 시리즈" 등의 포스트도 주기적으로 업데이트될 예정입니다.

마지막으로 앞으로 업로드 될 포스팅에 대한 자그마한 스포를 드리자면

"제목", "내용" 등의 세부사항들은 변경 될 수 있지만, 전하고자 하는 내용의 주제는 아래와 같이 유지될 예정입니다.

- [ 산업기능요원 ] 포트폴리오를 준비했던 시간에 관한 이야기

- [ 산업기능요원 ] 나한테 맞는 회사를 찾고자 했던 이야기

- [ 산업기능요원 ] 월급 받는개발자로서의 상반기 회고

- . . .

앞으로도 제가 고민하며 해결해나간 여러 상황들에 대한 이야기들을 전해드리도록 노력하겠습니다.

항상 읽어주셔서 감사합니다. TLOWAC

[CodeWars] javascript - 6kyu : Returning Strings

TLOWAC — Mon, 10 Aug 2020 17:31:19 +0900

기본적인 문제는 문제풀이 없이 Solution만 작성되어 있습니다.

Title

Returning Strings

Description

Make a function that will return a greeting statement that uses an input; your program should return,
"Hello, <name> how are you doing today?".

[ Example Output ]

'Naver'		// => "Hello, Naver how are you doing today?".
'Google'	// => "Hello, Google how are you doing today?".
'Daum'		// => "Hello, Daum how are you doing today?".

Test Code

Solution

글 읽어주셔서 감사합니다.

보다 유익한 컨텐츠를 제작할 수 있도록 노력하겠습니다.

- 작성자 이창훈 -

[CodeWars] javascript - 6kyu : Will the present fit?

TLOWAC — Tue, 28 Jul 2020 00:52:22 +0900

기본적인 문제는 문제풀이 없이 Solution만 작성되어 있습니다.

Title

Will the present fit?

Description

Santa's elves are boxing presents, and they need your help! Write a function that takes two sequences of dimensions of the present and the box, respectively, and returns a Boolean based on whether or not the present will fit in the box provided. The box's walls are one unit thick, so be sure to take that in to account.

[ Example Output ]

Examples : Present and box respectively

[10, 7, 16]		, [13, 32, 10] --> true, box is bigger than present
[5, 7, 9]		, [9, 5, 7]    --> false, present and box are same size
[17, 22, 10]		, [5, 5, 10])  --> false, box is too small

How Can I Solved

문제 요구사항 정의

선물상자에 선물이 담길 수 있는지 구하여라.

문제 접근

// => 결과값 : 선물상자에 선물을 넣을 수 있는지를 판단하여 True 또는 False 로 반환

// => 조건 1 . 상자는 두께가 1이다.

// => 상자 크기 : [13, 32, 10]

// => 담을수 있는 선물 크기 : [12, 31, 9]

문제 풀이

1. function 의 인자를 확인했다.
function 의 첫번째 인자는 present 로 선물 크기 , function 의 두번째 인자는 box 로 상자 크기

function WillFit ( present , box ){
	. . .
}

2. function 의 인자로 받은 값을 오름차순 ( ASC ) 으로 정렬해주었다.

예제로 주어진 Data 를 통해서 Data 가 정렬된 값이 아닌 뒤죽박죽 섞인 값으로 넘어온다는 것을 확인했기 때문이며,
정렬을 해줌으로써 보다 쉬운 방법으로 문제를 풀어나갔다.

배열에 담긴 문자를 정렬할때 : sort( )
배열에 담긴 숫자를 정렬할때 ( ASC ) : sort( ( a, b ) => a - b )
배열에 담긴 숫자를 정렬할때 ( DESC ) : sort( ( a, b ) => b - a )

function WillFit ( present , box ){
	let presentSize = present.sort((a,b)=> a-b)
	let boxSize= box.sort((a,b)=> a-b)
    . . .
}

2 - 2. 하지만, 한가지 주의해야 할것이 있다.

문제에는 아래와 같은 문구가 적혀있는데, 이 문구에서는 상자가 1 의 두께를 가지고 있다고 적혀있다.

The box's walls are one unit thick, so be sure to take that in to account.
( 상자의 벽은 두께가 1 단위이므로 반드시 고려해야합니다. )

만약 box 배열에 담긴 숫자들의 값에 각각 -1 을 해주지 않는다면,
TestCase 는 통과해도 Attempt 에서 막히는 상황이 발생한다.

TestCase 통과 , Attempt 실패

이 상황은 기존에 작성한 코드에 map() 메서드를 사용함으로써 간단하게 해결 할 수 있다.

function WillFit ( present , box ){
	let presentSize = present.sort( ( a , b ) => a - b )
	//let boxSize= box.sort( ( a , b ) => a - b )			// => 수정 전
	let boxSize= box.map( v => v - 1  ).sort( ( a , b ) => a - b )		// => 수정 후
    . . .
}

3. 이제 선물이 상자에 들어갈 수 있는지 확인하는 과정이 필요하다.

presentSize 배열의 요소들과 boxSize 배열의 요소들을 비교한다.

boxSize 값이 presentSize 보다 큰 경우 true 를 반환한다. ( boxSize > presentSize )
boxSize 값이 presentSize 보다 작은 경우 false 를 반환한다. ( presentSize > boxSize )

  let result = presentSize.map((v,idx)=>{
    return boxSize[idx] > v ? true : false
  })

4. 최종적으로 이 선물이 상자에 들어갈 수 있는지 판단한다.

일련의 과정들을 통해 result 배열에는 Boolean 값의 요소들이 담겨져 있다.

result 배열에 false 가 하나라도 있는 경우 false 를 반환한다.
result 배열애 false 가 없는 경우 true 를 반환한다.

if(result.includes(false)){return false}
return true

Solution

function willFit(present, box){
  console.log('nonSortPresent : ',present)
  console.log('nonSortBox     : ',box)
  
  let presentSize = present.sort((a,b)=>a-b)
  let boxSize = box.map(v=>v-1).sort((a,b)=>a-b)
  // HaHa... You Must Be Consider that the box's walls are one unit thick 
  
  let result = presentSize.map((v,idx)=>{
    return boxSize[idx] > v ? true : false
  })
  
  console.log('sortPresentSize : ',presentSize)
  console.log('sortBoxSize     : ',boxSize)
  console.log(result)
  if(result.includes(false)){ return false }
  return true
}

글 읽어주셔서 감사합니다.

보다 유익한 컨텐츠를 제작할 수 있도록 노력하겠습니다.

- 작성자 이창훈 -

[백준] javascript - 2742번 : 기찍 N

TLOWAC — Mon, 27 Jul 2020 01:59:03 +0900

기본적인 문제는 문제풀이 없이 Solution만 작성되어 있습니다.

Title

기찍 N

Description

자연수 N이 주어졌을 때, N부터 1까지 한 줄에 하나씩 출력하는 프로그램을 작성하시오.

[ Example Input ]

첫째 줄에 100,000보다 작거나 같은 자연수 N이 주어진다.

[ Example Output ]

첫째 줄부터 N번째 줄 까지 차례대로 출력한다.

Solution

const fs = require('fs');
const input = fs.readFileSync('/dev/stdin').toString().split(' ')

const RANGE_VALUE = Number(input)

for(let i=RANGE_VALUE; i>=1; i--){
    console.log(i)
}

글 읽어주셔서 감사합니다.

보다 유익한 컨텐츠를 제작할 수 있도록 노력하겠습니다.

- TLOWAC 이창훈 -

[백준] javascript - 2741번 : N 찍기

TLOWAC — Sun, 26 Jul 2020 01:32:39 +0900

기본적인 문제는 문제풀이 없이 Solution만 작성되어 있습니다.

Title

N 찍기

Description

자연수 N이 주어졌을 때, 1부터 N까지 한 줄에 하나씩 출력하는 프로그램을 작성하시오.

[ Example Input ]

첫째 줄에 100,000보다 작거나 같은 자연수 N이 주어진다.

[ Example Output ]

첫째 줄부터 N번째 줄 까지 차례대로 출력한다.

Point

readline 모듈을 사용하는 경우 시간 초과...?

이 경우에는 readline 모듈을 사용할때 toString() 메서드를 사용하지 않았는지 확인해보자.

실험해본 결과 ( fs 모듈은 해당하지 않음 )

input = line.toString().split(' ') // => 시간 초과 실패

input = line.split(' ') // => 통과

임을 확인할 수 있었다.

fs 모듈

const fs = require('fs');
const input = fs.readFileSync('/dev/stdin').toString().split(' ')

const RANGE_VALUE = Number(input)

...

readline 모듈

const readline = require('readline');
const rl = readline.createInterface({
  input: process.stdin,
  output: process.stdout
});

let input = [];
rl.on('line', function (line) {
  input = line.split(' ')
}).on('close', function () {
  const RANGE_VALUE = Number(input[0])
	
    ...
    
    process.exit();
});

Solution

const fs = require('fs');
const input = fs.readFileSync('/dev/stdin').toString().split(' ')

const RANGE_VALUE = Number(input)

for(let i=1; i<=RANGE_VALUE; i++){
    console.log(i)
}

글 읽어주셔서 감사합니다.

보다 유익한 컨텐츠를 제작할 수 있도록 노력하겠습니다.

- TLOWAC 이창훈 -

[백준] javascript - 2739번 : 구구단

TLOWAC — Sat, 25 Jul 2020 00:13:56 +0900

기본적인 문제는 문제풀이 없이 Solution만 작성되어 있습니다.

Title

구구단

Description

N을 입력받은 뒤, 구구단 N단을 출력하는 프로그램을 작성하시오. 출력 형식에 맞춰서 출력하면 된다.

[ Example Input ]

첫째 줄에 N이 주어진다. N은 1보다 크거나 같고, 9보다 작거나 같다.

[ Example Output ]

출력형식과 같게 N*1부터 N*9까지 출력한다.

Solution

// => 결과값 : 입력값에 따라서 구구단을 출력

const readline = require('readline');
const rl = readline.createInterface({
    input: process.stdin,
    output: process.stdout
});

let input = [];
let fixedPoint = 0;

rl.on("line", function (line) {
  input = line.split(' ').map((_) => Number(_));
}).on("close", function () {
  fixedPoint = input[0]

  for (let i = 1; i <= 9; i++) {
    console.log(`${fixedPoint} * ${i} = ${fixedPoint * i}`);
  }
  process.exit();
});

글 읽어주셔서 감사합니다.

보다 유익한 컨텐츠를 제작할 수 있도록 노력하겠습니다.

- TLOWAC 이창훈 -

[백준] javascript - 14681번 : 사분면 고르기

TLOWAC — Fri, 24 Jul 2020 21:23:08 +0900

기본적인 문제는 문제풀이 없이 Solution만 작성되어 있습니다.

Title

사분면 고르기

Description

흔한 수학 문제 중 하나는 주어진 점이 어느 사분면에 속하는지 알아내는 것이다. 사분면은 아래 그림처럼 1부터 4까지 번호를 갖는다. "Quadrant n"은 "제n사분면"이라는 뜻이다.

예를 들어, 좌표가 (12, 5)인 점 A는 x좌표와 y좌표가 모두 양수이므로 제1사분면에 속한다. 점 B는 x좌표가 음수이고 y좌표가 양수이므로 제2사분면에 속한다.

점의 좌표를 입력받아 그 점이 어느 사분면에 속하는지 알아내는 프로그램을 작성하시오. 단, x좌표와 y좌표는 모두 양수나 음수라고 가정한다.

[ Example Input ]

첫 줄에는 정수 x가 주어진다. (−1000 ≤ x ≤ 1000; x ≠ 0)
다음 줄에는 정수 y가 주어진다. (−1000 ≤ y ≤ 1000; y ≠ 0)

12
5

[ Example Output ]

점 (x, y)의 사분면 번호(1, 2, 3, 4 중 하나)를 출력한다.

How Can I Solved

문제 요구사항 정의

좌표값에 따라 1,2,3,4 사분면으로 구분하여 출력하라.

문제 접근

// => 결과값 : 좌표값에 따라 1,2,3,4 사분면으로 구분됨

// => 조건 1 . x 값이 양수일때

// => y값이 양수이면 1 사분면

// => y값이 음수이면 4 사분면

// => 조건 2 . x 값이 음수일때

// => y값이 양수이면 2 사분면

// => y값이 음수이면 3 사분면

Error

fs 모듈을 사용하는 경우 런타임 에러 발생 ...?

말 그대로다.
어디서 어떻게 잘못됬는지 찾을려는 시도는 많이 했지만 찾지 못했다.

단지 fs 모듈 대신에 readline 모듈을 사용하니 '런타임 에러'는 눈녹듯이 사라졌다 . .

아래는 내가 작성한 fs 와 readline으로 값을 입력받는 코드이다.

fs 모듈

const fs = require('fs')
const input = fs.readFileSync('/dev/stdin').toString().split('\n').map(_=>+_)
const [X,Y] = input

//logic생략

readline 모듈

const readline = require('readline')
const rl = readline.createInterface({
  input: process.stdin,
  output: process.stdout
})

let input = []
rl.on('line', function (line) {
  input.push(parseInt(line));
}).on('close', function () {
  const X = input[0];
  const Y = input[1];
  
  //logic 생략
  })

p.s 에러 발생 원인이나 코드의 문제점을 알고계시는 분들은 댓글 달아주시면 감사하겠습니다 :)

Solution

const readline = require('readline');
const rl = readline.createInterface({
  input: process.stdin,
  output: process.stdout
});

let input = [];
rl.on('line', function (line) {
  input.push(parseInt(line));
}).on('close', function () {
  const X = input[0];
  const Y = input[1];

  if(X >0){
        Y > 0 ? console.log(1) : console.log(4)
    }
  if(X <0){
        Y > 0 ? console.log(2) : console.log(3)
    }
    process.exit();
});

원인을 찾고자 했던 흔적들 . . .

글 읽어주셔서 감사합니다.

보다 유익한 컨텐츠를 제작할 수 있도록 노력하겠습니다.

- TLOWAC 이창훈 -

[백준] javascript - 2753번 : 윤년

TLOWAC — Thu, 23 Jul 2020 18:16:52 +0900

기본적인 문제는 문제풀이 없이 Solution만 작성되어 있습니다.

Title

윤년

Description

연도가 주어졌을 때, 윤년이면 1, 아니면 0을 출력하는 프로그램을 작성하시오.

윤년은 연도가 4의 배수이면서, 100의 배수가 아닐 때 또는 400의 배수일 때이다.

예를 들어, 2012년은 4의 배수이면서 100의 배수가 아니라서 윤년이다. 1900년은 100의 배수이고 400의 배수는 아니기 때문에 윤년이 아니다. 하지만, 2000년은 400의 배수이기 때문에 윤년이다.

[ Example Input ]

첫째 줄에 연도가 주어진다. 연도는 1보다 크거나 같고, 4000보다 작거나 같은 자연수이다.

[ Example Input ]

첫째 줄에 윤년이면 1, 아니면 0을 출력한다.

Solution

const fs = require('fs')
const inputData = fs.readFileSync('/dev/stdin')
const originalData = inputData

if(originalData % 4 == 0 && originalData % 100 != 0){
    console.log(1)
}
else if(originalData % 4 == 0 && originalData % 400 == 0){
    console.log(1)
}
else
    console.log(0)

글 읽어주셔서 감사합니다.

보다 유익한 컨텐츠를 제작할 수 있도록 노력하겠습니다.

- TLOWAC 이창훈 -

[백준] javascript - 9498번 : 시험 성적

TLOWAC — Wed, 22 Jul 2020 23:31:54 +0900

기본적인 문제는 문제풀이 없이 Solution만 작성되어 있습니다.

Title

시험 성적

Description

시험 점수를 입력받아 90 ~ 100점은 A, 80 ~ 89점은 B, 70 ~ 79점은 C, 60 ~ 69점은 D,
나머지 점수는 F를 출력하는 프로그램을 작성하시오.

[ Example Input ]

첫째 줄에 시험 점수가 주어진다. 시험 점수는 0보다 크거나 같고, 100보다 작거나 같은 정수이다.

[ Example Output ]

시험 성적을 출력한다.

Solution

const fs = require('fs')
const inputData = fs.readFileSync('/dev/stdin')
const a = inputData


if(100>= a && a>=90){
    console.log('A')
}
else if(89>= a && a>=80){
    console.log('B')
}
else if(79>= a && a>=70){
    console.log('C')
}
else if(69>= a && a>=60){
    console.log('D')
}
else
    console.log('F')

글 읽어주셔서 감사합니다.

보다 유익한 컨텐츠를 제작할 수 있도록 노력하겠습니다.

- TLOWAC 이창훈 -

[백준] javascript - 1330번 : 두 수 비교하기

TLOWAC — Tue, 21 Jul 2020 23:04:44 +0900

기본적인 문제는 문제풀이 없이 Solution만 작성되어 있습니다.

Title

두 수 비교하기

Description

두 정수 A와 B가 주어졌을 때, A와 B를 비교하는 프로그램을 작성하시오.

[ Example Input ]

첫째 줄에 A와 B가 주어진다. A와 B는 공백 한 칸으로 구분되어져 있다.

1 2

[ Example Output ]

첫째 줄에 다음 세 가지 중 하나를 출력한다.

A가 B보다 큰 경우에는 '>'를 출력한다.
A가 B보다 작은 경우에는 '<'를 출력한다.
A와 B가 같은 경우에는 '=='를 출력한다.

Solution

const fs = require('fs')
const inputData = fs.readFileSync('/dev/stdin').toString().split(' ').map(val=>+val)
const [a,b] = inputData

if(a>b){
    console.log('>')
}
else if(a<b){
    console.log('<')
}
else{
    console.log('==')
}

글 읽어주셔서 감사합니다.

보다 유익한 컨텐츠를 제작할 수 있도록 노력하겠습니다.

- TLOWAC 이창훈 -

[백준] javascript - 2588번 : 곱셈

TLOWAC — Mon, 20 Jul 2020 21:30:25 +0900

기본적인 문제는 문제풀이 없이 Solution만 작성되어 있습니다.

Title

곱셈

Description

(세 자리 수) × (세 자리 수)는 다음과 같은 과정을 통하여 이루어진다.

(1)과 (2)위치에 들어갈 세 자리 자연수가 주어질 때 (3), (4), (5), (6)위치에 들어갈 값을 구하는 프로그램을 작성하시오.

[ Example Input ]

첫째 줄에 (1)의 위치에 들어갈 세 자리 자연수가, 둘째 줄에 (2)의 위치에 들어갈 세자리 자연수가 주어진다.
472
385

[ Example Output ]

첫째 줄부터 넷째 줄까지 차례대로 (3), (4), (5), (6)에 들어갈 값을 출력한다.
2360
3776
1416
181720

Solution

const fs = require('fs')
const input = fs.readFileSync('/dev/stdin').toString().split('\n')
const num1 = Number(input[0]);
const num2 = Number(input[1]);

const oneNum = num2 % 10;
const tenNum = Math.floor((num2 % 100)/10)
const hundredNum = Math.floor(num2 / 100);


console.log(num1 * oneNum);
console.log(num1 * tenNum);
console.log(num1 * hundredNum);
console.log(num1 * num2);

글 읽어주셔서 감사합니다.

보다 유익한 컨텐츠를 제작할 수 있도록 노력하겠습니다.

- TLOWAC 이창훈 -

[백준] javascript - 10869번 : 사칙연산

TLOWAC — Sun, 19 Jul 2020 20:02:48 +0900

기본적인 문제는 문제풀이 없이 Solution만 작성되어 있습니다.

Title

사칙연산

Description

두 자연수 A와 B가 주어진다. 이때, A+B, A-B, A*B, A/B(몫), A%B(나머지)를 출력하는 프로그램을 작성하시오.

[ Example Input ]

두 자연수 A와 B가 주어진다. (1 ≤ A, B ≤ 10,000)
7 3

[ Example Output ]

첫째 줄에 A+B, 둘째 줄에 A-B, 셋째 줄에 A*B, 넷째 줄에 A/B, 다섯째 줄에 A%B를 출력한다.
10
4
21
2
1

Solution

const fs = require('fs')
const inputData = fs.readFileSync().toString().split(' ').map(value => +value)
const [a,b] = inputData

console.log(a+b)
console.log(a-b)
console.log(a*b)
console.log(Math.floor(a/b))
console.log(a%b)

글 읽어주셔서 감사합니다.

보다 유익한 컨텐츠를 제작할 수 있도록 노력하겠습니다.

- TLOWAC 이창훈 -

[백준] javascript - 10430번 : 나머지

TLOWAC — Sat, 18 Jul 2020 20:09:56 +0900

기본적인 문제는 문제풀이 없이 Solution만 작성되어 있습니다.

Title

나머지

Description

(A+B)%C는 ((A%C) + (B%C))%C 와 같을까?

(A×B)%C는 ((A%C) × (B%C))%C 와 같을까?

세 수 A, B, C가 주어졌을 때, 위의 네 가지 값을 구하는 프로그램을 작성하시오.

[ Example Input ]

첫째 줄에 A, B, C가 순서대로 주어진다. (2 ≤ A, B, C ≤ 10000)
5, 8, 4

[ Example Output ]

첫째 줄에 (A+B)%C, 둘째 줄에 ((A%C) + (B%C))%C, 셋째 줄에 (A×B)%C, 넷째 줄에 ((A%C) × (B%C))%C를 출력한다.
1
1
0
0

Solution

const fs = require('fs')
const inputData = fs.readFileSync('/dev/stdin').toString().split(' ').map(val=>+val)
const [A,B,C] = inputData

console.log((A+B)%C)
console.log(((A%C) + (B%C))%C)
console.log((A*B)%C)
console.log(((A%C) * (B%C))%C)

글 읽어주셔서 감사합니다.

보다 유익한 컨텐츠를 제작할 수 있도록 노력하겠습니다.

- TLOWAC 이창훈 -