[GL 3기 10회차 ②] 한 번에 끝나게 만들기 — push 한 번의 배포, 인턴에서 파트장까지 🌱

GL 3기 성장일지 10회차 큐레이션

안녕하세요! 그로스로그 입니다!😊 🌱

코드를 push하는 것만으로 앞뒤가 모두 배포되는 구조를 그린 기록, 그리고 첫 직장을 떠나며 2년을 정리한 회고. 3기의 마지막 큐레이션입니다.

성장일지는 멤버들이 2주에 한 번씩 자신의 성장을 기록하는 활동이에요. 매 회차 운영진이 모든 글을 읽고, 그중 특히 마음에 남은 글을 함께 골라 큐레이션합니다.

 

01

🚀 CI/CD가 필요한 이유

김남주 님

이런 내용이에요
왜 CI/CD가 필요한가에서 시작해, GitHub Actions·Docker·AWS ECR/ECS·Nginx·SSL·S3+CloudFront까지 배포 전체 지도를 한 편에 그렸습니다.
백엔드는 Actions → Docker → ECR → ECS로, 프론트엔드는 Actions → S3 → CloudFront로 나뉘어요.
어려운 개념을 비유로 풀어낸 것이 특징입니다. 컨테이너를 "집 안의 여러 방"으로, Docker 이미지를 "가구까지 포함된 모델하우스 설계도"로요.

7회차의 홍범영 님, 9회차의 김종진 님에 이어 3기에서 세 번째로 나온 배포 이야기입니다. 그런데 결이 또 달라요.

조금 더 들어가 보면

시작이 좋습니다. CI/CD 이전에는 어떻게 했는지부터 적어요.

"예전에는 서버에 코드를 수정하면 변경된 파일을 직접 서버에 복사하거나, jar 파일만 교체하고 톰캣을 재시작하는 식으로 배포했습니다."

그리고 문제를 짚습니다. "반복 작업 + 휴먼에러가 필연적으로 발생합니다."

휴먼에러라는 단어가 정확해요. 손으로 배포하면 언젠가 반드시 실수합니다. 파일 하나를 빠뜨리거나, 다른 서버에 올리거나, 재시작을 잊거나요. 사람이 조심해서 될 문제가 아닙니다. 그래서 자동화가 필요한 거죠.

🏠 비유가 좋은 글

이 글의 특징은 어려운 개념을 일상어로 옮긴 부분입니다.

"컨테이너는 하나의 집 안에 여러 개의 방을 만든 것과 같다. 같은 집에서는 TV(포트 80) 한 대만 켤 수 있지만, 각 방에는 자기만의 TV를 두고 마음대로 켤 수 있는 것처럼, 컨테이너 안에서는 각자 독립된 Nginx를 실행할 수 있다."

포트 충돌을 설명하는 데 이만한 비유가 드뭅니다. 일반 서버에서는 80번 포트를 하나만 쓸 수 있는데, 컨테이너는 각자 자기 네트워크 공간을 가지니 여러 개가 동시에 80번을 씁니다. 왜 컨테이너를 쓰는가에 대한 실감 나는 답이에요.

Docker 이미지도 마찬가지입니다.

"모델하우스 설계도에 가구와 장식까지 포함된 것과 같음"

설계도만이 아니라 안에 들어갈 것까지 포함한다는 뜻이죠. 그래서 어디서 실행하든 같은 환경이 나옵니다.

🔐 Certbot이 도메인 소유를 확인하는 방법

이 글에서 기술적으로 가장 재미있는 부분입니다.

1. Let's Encrypt 서버에 인증서 발급 요청
2. 무작위 토큰 발급 → Nginx가 해당 경로에 서빙하도록 구성
3. Let's Encrypt가 해당 URL로 접근해 토큰 확인
4. 검증 성공 시 인증서 발급

"이 도메인이 정말 당신 것인가"를 어떻게 증명할까요? 답은 "그 도메인으로 접속했을 때 내가 준 값을 보여줄 수 있는가"입니다.

도메인을 통제하는 사람만 그 주소의 특정 경로에 파일을 놓을 수 있으니까요. 소유권을 통제력으로 증명하는 아주 영리한 방식입니다.

8회차에서 김영진 님이 다룬 CSR(인증서 서명 요청)의 실제 사용 장면이 여기 나오는 셈이에요. 두 회차의 글이 이어집니다.

🧭 앞뒤가 다른 길로 가는 이유

글이 정리한 구조가 명확합니다.

· 백엔드 — Actions → Docker → ECR → ECS

· 프론트엔드 — Actions → S3 → CloudFront

왜 다를까요. 성격이 다르기 때문입니다.

백엔드는 계속 돌고 있어야 합니다. 요청을 받아 처리하고 DB에 접근하죠. 그래서 컨테이너가 떠 있어야 하고, ECS가 그걸 관리합니다.

프론트엔드는 빌드하고 나면 그냥 파일입니다. HTML, CSS, JS 뿐이에요. 돌고 있을 필요가 없으니 저장소에 두고 나눠주기만 하면 됩니다. S3가 저장하고 CloudFront가 전 세계에 뿌리죠.

그리고 여기서 9회차 김종진 님의 판단과 비교하면 흥미롭습니다. 그분은 스테이징 목적이라 CDN 캐시 때문에 오히려 EC2를 골랐어요. 이 글은 운영 배포를 다루니 S3+CloudFront가 맞고요.

같은 도구도 목적에 따라 답이 달라진다 — 세 편의 배포 글을 나란히 읽으면 그게 보입니다.

큐레이터 노트

전체 지도를 그린 글이라 뽑았습니다.

배포는 등장하는 도구가 너무 많습니다. GitHub Actions, Docker, ECR, ECS, Nginx, Certbot, S3, CloudFront. 하나씩 배우다 보면 이것들이 어떻게 이어지는지를 놓치기 쉬워요.

이 글은 각각이 어느 자리에 있는지를 보여줍니다. 저장소는 어디고, 실행은 어디서 하고, 인증서는 누가 발급하고, 정적 파일은 어디로 가는지요. 지도가 있으면 다음에 어느 부분을 파고들지 정할 수 있습니다.

비유를 잘 쓴 것도 좋았어요. "집 안의 여러 방", "가구까지 포함된 설계도". 이런 비유는 자기가 확실히 이해한 사람만 만들 수 있습니다. 어설프게 알면 원문 표현을 그대로 옮기게 되거든요.

블로그를 보니 컴퓨터 시스템, 컴퓨터 네트워킹, 혼자 공부하는 컴퓨터구조 운영체제 같은 기초 과목 기록이 차곡차곡 쌓여 있더라고요. 기초와 실무를 같이 가고 계신 분입니다.

원문 읽으러 가기  ↗knj123.tistory.com/62

 

02

🎓 정든 첫 직장을 마무리하며

임세현 님

이런 내용이에요
고등학생 산학 인턴으로 입사해 파트장이 되기까지 2년을 정리한 회고입니다.
2023년 7월 인턴 → 10월 정직원 → 2024년 2월 산업기능요원 → 2025년 1월 안드로이드팀 파트장 → 2025년 7월 퇴사.
배운 것, 아쉬웠던 것, 이직을 결심한 계기, 그리고 자기만의 방식으로 준비한 면접까지 담았습니다.

기술 글이 아닙니다. 그런데 3기 마지막 큐레이션으로 이보다 잘 맞는 글이 없었어요.

조금 더 들어가 보면

먼저 시간표가 인상적입니다. 고등학교를 회사에서 졸업했고, 학점은행제를 하며 방송대에 입학했다고요. 그 2년 안에 인턴에서 파트장까지 갔습니다.

그리고 그게 가능했던 이유를 이렇게 적습니다.

"특히 나이가 어리다는 이유로 배제하지 않고, 오히려 파트장이라는 권한을 부여해준 것은 나를 단단하게 성장시킨 계기였습니다."

권한이 사람을 키운다는 이야기입니다. 이어지는 문장이 그걸 설명해요. "파트를 책임지는 위치가 되자 자연스럽게 더 많이 고민했고."

📊 지표로 말하는 문화

배운 것 중 눈에 띄는 대목이 있습니다.

"request, impression, CTR, ARPDAU 같은 세부 광고 지표를 일 단위로 추적하며 데이터 기반으로 소통하는 문화는 실무에서의 정량적 의사결정이란 무엇인지 명확하게 체득하게 했습니다."

정량적 의사결정을 몸으로 익혔다는 겁니다. "이게 더 나은 것 같아요"가 아니라 "CTR이 0.3%p 올랐습니다"로 말하는 훈련이요.

그리고 관리자 스터디에서 얻은 관점도 좋았습니다. "부분 최적과 전체 최적은 다를 수 있다."

개발자에게 특히 중요한 감각입니다. 내 파트의 코드를 완벽하게 만드는 것과 제품 전체가 잘 되는 게 항상 같지 않거든요. 이 구분을 아는 사람이 팀에서 오래 갑니다.

🍽️ 아쉬움을 표현한 방식

떠나는 이유를 적은 부분이 정직합니다. 성과 평가가 정성적이었다는 점, 광고 도메인에서 유저와의 소통이 적어 지루했다는 점, 주도적으로 문제를 정의하기 어려운 구조였다는 점.

그리고 비유가 훌륭합니다.

"나는 프랜차이즈 매장에서 레시피대로 일하는 셰프였지만, 본사에서 브랜딩 전략을 수립하거나, 파인다이닝 레스토랑에서 창의적으로 일하길 원했습니다."

회사를 비난하지 않으면서 자기가 원하는 걸 정확히 말합니다. 프랜차이즈가 나쁜 게 아니에요. 다만 자기가 있고 싶은 자리가 아니었던 거죠.

이 균형이 어렵습니다. 퇴사 회고는 자칫 불평이 되기 쉬운데, 이 글은 배운 것을 충분히 인정하고 나서 아쉬움을 말합니다.

🎯 자기 방식으로 준비한 면접

이 글에서 가장 배울 만한 부분입니다.

"나는 기술을 깊게 파고드는 타입보다는 문제를 정의하고, 사용자를 위해 해결하는 것에 흥미를 느끼는 개발자입니다. 즉, 나의 성향은 '코어 엔지니어'보다는 '프로덕트 메이커'에 가깝습니다."

자기 성향을 먼저 정의했습니다. 그리고 그에 맞게 면접을 준비해요.

· 이직하려는 회사의 서비스 구조를 직접 분석

· 핵심 기능 하나를 클론해서 구현

· 기술 선택 이유와 CTR·로딩 속도 개선 전략을 보고서로 정리

· 면접에서 보고서 제출 + 실제 앱 시연

그리고 결과를 이렇게 정리합니다. "내가 주도권을 갖고 면접을 이끌어가면서, 면접관에게 내가 어떤 문제를 어떻게 바라보는 사람인지 정확히 보여줄 수 있었습니다."

질문에 답하는 자리를 보여주는 자리로 바꾼 겁니다. 알고리즘 문제로 겨루면 자기 강점이 안 드러나니, 강점이 드러나는 방식을 직접 만든 거죠.

모든 사람이 같은 방식으로 준비할 필요는 없다 — 취업을 준비하는 분들이 새겨둘 만한 부분입니다.

🧭 그리고 다짐

새 직장에서의 다짐 중 첫 문장이 좋았습니다.

"개발자는 내부에서 일하지만, 성과는 외부에서 나온다는 원칙을 잊지 않고"

우리는 코드 안에서 일합니다. 리팩터링하고, 구조를 잡고, 성능을 개선하죠. 그런데 그 결과는 밖에서 판단됩니다. 사용자가 빨라졌다고 느끼는가, 문제가 해결됐는가로요.

그리고 마지막 다짐도 인상적이었습니다.

"당장의 질타를 피하기 위해 말하지 않기보다는, 상황을 직면하고, 내가 보고 느낀 바를 숨기지 않고 말할 수 있는 사람이 되겠습니다."

기술 다짐이 아니라 정직에 대한 다짐으로 끝납니다.

큐레이터 노트

성장일지가 무엇을 남길 수 있는지 보여주는 글이라 뽑았습니다.

2주에 한 번 기록을 남기다 보면 대개 그 2주 안의 일을 씁니다. 그런데 가끔 이렇게 긴 시간을 한 번에 돌아보는 글이 나와요. 그런 글은 개인에게도, 읽는 사람에게도 다르게 남습니다.

고등학생 인턴에서 파트장까지라는 궤적 자체가 귀합니다. 그리고 그 과정을 자랑이 아니라 기록으로 적었어요. 회사가 준 것, 배운 것, 아쉬웠던 것을 나눠서요.

면접 준비 방식은 특히 여러 분께 도움이 될 것 같습니다. 방송대 컴퓨터과학과에서 공부하며 이직이나 취업을 준비하는 분들이 많으니까요. "내 강점이 드러나는 방식을 직접 만든다"는 발상이 그대로 참고가 됩니다.

무엇보다 "이 회사는 나에게 있어 첫 직장이자, 첫 무대였습니다"라는 문장이 좋았어요. 떠나면서도 그 시간을 정확히 값매김한 표현입니다.

원문 읽으러 가기  ↗medium.com/@limsaehyun

💡 두 편을 겹쳐 읽으며

한 편은 배포 자동화, 한 편은 커리어 회고입니다. 이보다 다를 수 없는 조합이죠.

그런데 두 글을 나란히 놓으니 같은 문장이 떠오릅니다. "반복되는 일은 자동화하고, 판단이 필요한 일에 시간을 쓴다."

김남주 님의 글은 그걸 시스템으로 합니다. 파일을 서버에 복사하고 톰캣을 재시작하는 일 — 사람이 안 해도 되는 일을 기계에 넘겼어요. 그러면 사람은 무엇을 만들지, 어떻게 만들지에 집중할 수 있습니다.

임세현 님의 글은 그걸 커리어로 합니다. "레시피대로 일하는 셰프"에서 벗어나 문제를 정의하고 판단하는 자리로 옮겨간 이야기니까요.

둘 다 "정해진 대로 하는 일"과 "정하는 일"을 구분했습니다. 그리고 후자로 자기 시간을 옮겼어요.

그리고 두 글 모두 "왜"에서 시작합니다. 하나는 "CI/CD가 왜 필요한가", 다른 하나는 "왜 떠나는가". 방법보다 이유를 먼저 적은 글들이었습니다.

---

🌱 3기를 마치며

이렇게 그로스로그 3기 성장일지 큐레이션이 마무리됩니다. 2025년 3월부터 8월까지, 10회차 동안 33편의 글이 쌓였어요.

3기는 폭이 크게 넓어진 기수였습니다.

프론트엔드와 백엔드는 물론이고 인프라·보안·임베디드·게임·모바일·데이터베이스까지 들어왔어요. 아두이노 회로도가 있고, 인증서 표준 정리가 있고, Flutter 첫 도전기가 있고, 3년치 커리어 회고가 있었습니다.

돌아보면 각자의 궤적이 뚜렷합니다.

이종경 님은 다섯 번 큐레이션되며 프론트엔드를 층층이 훑어 내려갔습니다. 런타임 → BFF → 실행 컨텍스트 → 렌더링 → 모듈 시스템으로요.

강단 님은 네 번. "궁금해서 파봤다"로 시작해 HTML 스트림, SVG 마스크, CSS와 자료구조, 그리고 3년 회고까지 갔습니다. 매번 질문 하나를 끝까지 밀고 갔어요.

박지수B 님은 네 번. JVM → GC → 도커 → 앱 개발 방식으로, 지금 공부하는 것을 그때그때 정리하는 방식이 일관됐습니다.

김혜경 님은 전공 수업을 실무와 이어붙였고, 오연수 님은 1기부터 3기까지 이어오며 운영의 영역으로 넓혔고, 신지훈 님은 회사에서 받은 요청 하나를 두 회차에 걸쳐 풀어냈습니다.

그리고 처음 오신 분들도 많았어요. 한지수 님, 박하진 님, 윤창훈 님, 조성호 님, 사범기 님, 정민아 님, 홍범영 님, 황유정 님, 김영진 님, 박지훈 님, 황자혜 님, 김종진 님, 김남주 님, 임세현 님. 각자의 자리에서 각자의 속도로 기록을 남겨주셨습니다.

3기를 정리하며 가장 크게 남은 건 이겁니다.

좋은 기록은 "했다"가 아니라 "왜 그렇게 했는가"를 남깁니다. MQTT를 알아보고 HTTP를 고른 이유, EC2를 고른 이유, Meilisearch를 고른 이유. 그 판단의 근거가 남아 있으면 나중에 상황이 바뀌었을 때 다시 판단할 수 있어요.

그리고 막힌 자리를 적어둔 글이 가장 오래 쓰입니다. 4시간 걸린 QR 마스크, 24.04 AMI를 잘못 고른 일, 도커 권한 오류. 그 기록들이 뒤에 오는 사람의 시간을 아껴줍니다.

3기 여러분, 정말 고생 많으셨습니다. 😊

---

좋은 글 남겨주신 김남주 님, 임세현 님께 감사드립니다! 😊

다음은 4기 큐레이션으로 찾아오겠습니다! 🌱

- 에디터 · 성장일지 큐레이터 -

---

※ 본 큐레이션은 각 저자가 공개한 글을 소개하는 것이며, 모든 원문의 저작권은 저자에게 있습니다. 저자 본인의 요청이 있을 경우 즉시 수정 또는 삭제합니다.