안녕하세요! 그로스로그 입니다!😊 🌱
터미널 로그를 통째로 남긴 노트, 개념을 지도처럼 그린 노트, 그리고 진도를 벗어나 패킷까지 쫓아간 노트. 같은 스터디를 들은 세 사람의 기록입니다. 3기 3회차 세 편입니다.
3기 3회차, 2025년 4월 중순입니다. 이번 회차에는 도커·쿠버네티스 스터디 기록이 몰려 있었어요. 그중 성격이 가장 다른 세 편을 골랐습니다.
01
🐳 도커&쿠버네티스 스터디 1회차
박성훈 님
도커 스터디 첫 주차 실습을 터미널 로그 그대로 남긴 기록입니다. 이번 회차 세 편 중 가장 깁니다.
hello-world 실행부터 이미지 조회, nginx 컨테이너 띄우기, 포트 매핑, 컨테이너 내부 접속까지 갑니다.형식이 일정해요. 명령어 → 출력 전문 →
-> 화살표로 붙인 한 줄 해석입니다.실패한 명령까지 그대로 있습니다.
netstat 없다는 메시지도요.조금 더 들어가 보면
📜 hello-world가 알려주는 것
첫 실행이 docker run hello-world인데, 출력을 통째로 붙였습니다. 그 안에 도커가 방금 한 일 네 단계가 적혀 있어요.
2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
3. The Docker daemon created a new container from that image
4. The Docker daemon streamed that output to the Docker client
한 줄짜리 명령 뒤에 네 단계가 있었다는 걸 이 메시지가 알려줍니다.
핵심은 클라이언트와 데몬이 다른 프로그램이라는 점입니다. 우리가 치는 docker는 명령을 전달하는 쪽이고, 실제로 이미지를 받고 컨테이너를 띄우는 건 뒤에서 도는 데몬이에요.
이걸 알아두면 나중에 여러 에러가 설명됩니다. Cannot connect to the Docker daemon이 뜨는 건 데몬이 안 켜져 있다는 뜻이고, 권한 문제가 나는 것도 데몬과 통신할 권한이 없어서거든요. 이 노트의 첫 제목이 "Manage Docker as a non-root user"인 것도 그 맥락입니다.
🔍 ps와 ps -a
두 명령을 나란히 실행하고 화살표를 달았습니다.
$ docker ps -> 현재 도커 컨테이너에 대한 프로세스를 조회
CONTAINER ID IMAGE COMMAND ...
-> 현재 컨테이너에 프로세스가 없어서 조회되지 않음
$ docker ps -a -> 한번 실행 후 중지된 프로세스까지 조회
bd842e8a6508 hello-world "/hello" ... Exited (0) 2 minutes ago
같은 시점에 둘을 찍은 게 좋습니다. 하나는 비어 있고 하나는 한 줄이 나오죠.
hello-world는 메시지를 뿌리고 바로 끝나는 컨테이너라 docker ps에 안 잡힙니다. 그런데 사라진 게 아니라 멈춰 있을 뿐이에요. -a를 붙이면 보입니다.
처음 도커를 만지면 여기서 한 번 혼란이 옵니다. 분명히 실행했는데 목록에 없으니까요. 그리고 나중에는 반대 문제가 생깁니다. 멈춘 컨테이너가 계속 쌓여서 디스크를 먹는 것요. -a로 봐야 그게 보입니다.
docker pull에 붙인 화살표도 정확합니다.
docker.io(도커허브) 사이트에서 이미지를 가져오도록 설정되어 있음.로컬 먼저, 없으면 원격이라는 순서요. 그래서 두 번째 실행부터는 빨라집니다.
🔌 포트를 잇고 안으로 들어가기
nginx를 띄우는 명령에 화살표가 두 개 붙었습니다.
$ docker run --name nginx-docker -p 3000:80 -d nginx:latest
포트는 3000번으로 받으면 컨테이너에 80번 포트로 전송
-p 3000:80의 왼쪽과 오른쪽이 각각 무엇인지를 풀어 적었습니다. 이게 초보자가 가장 많이 헷갈리는 자리예요. 순서를 뒤집어 쓰면 연결이 안 되는데 에러 메시지도 친절하지 않거든요.
그리고 터미널 두 개를 띄워서 안팎을 비교했습니다.
nginx-docker /bin/bash로 접근(컨테이너 내부로 접근)terminal 1에서 local host ip가 찍힘
terminal 1에서 172.17.0.0/16 ip가 찍힘
같은 명령을 밖과 안에서 실행해 결과를 비교한 것입니다. 호스트에서는 호스트 IP가 나오고, 컨테이너 안에서는 172.17.x.x가 나와요.
이 대목이 컨테이너를 이해하는 문턱입니다. 컨테이너가 자기만의 네트워크를 갖고 있다는 걸 숫자로 확인하는 거니까요. 이 172.17.0.0/16이 어디서 왔는지는 뒤의 강승연 님 글에서 파고듭니다.
실습 환경 제약도 적어뒀습니다.
192.168.64.3:3000으로 실습을 진행함안 되는 이유와 우회 방법을 함께 적었어요. 나중에 같은 환경에서 따라 할 사람에게 바로 쓰입니다.
📝 원문에서는 이렇게 씁니다
이 노트의 특징은 출력을 자르지 않는다는 것입니다.
docker pull nginx 결과의 레이어 해시 일곱 줄도, apt update의 저장소 목록도 그대로 있습니다. 심지어 실패한 명령까지요.
$ netstat -ntlp Command 'netstat' not found, but can be installed with: sudo apt install net-tools
이걸 지우지 않은 게 이 노트의 성격을 보여줍니다.
정리된 문서라면 sudo apt install net-tools부터 적었을 거예요. 그런데 여기서는 막힌 순간이 그대로 남아 있습니다. 그래서 같은 환경에서 따라 하는 사람은 자기도 여기서 막힐 것을 미리 알게 되죠.
로그를 그대로 두면 길어지는 대신 얻는 게 있습니다. 내가 본 화면과 노트의 화면이 같다는 것요. 요약된 문서를 보다가 출력이 조금 다르면 "내가 뭘 잘못했나" 싶어지는데, 전문이 있으면 대조할 수 있습니다.
큐레이터 노트
날것 그대로 남긴 노트라 골랐습니다.
기술 기록에서 흔히 하는 조언이 "요약하라"입니다. 그런데 처음 배우는 단계에서는 반대일 때가 있어요. 무엇이 중요한지 아직 모르니, 요약하는 순간 필요한 걸 버릴 수 있거든요.
이 노트는 요약을 나중으로 미뤘습니다. 대신 화살표 한 줄씩으로 이해한 만큼만 붙였어요. "-> 현재 컨테이너에 프로세스가 없어서 조회되지 않음" 같은 것들요.
출력은 다 남기고 해석은 아는 만큼만. 첫 주차 노트로는 이게 맞는 방식이라고 생각합니다. 몇 주 지나서 다시 보면 그때 이해한 깊이가 화살표에 그대로 남아 있을 거고요.
02
☸️ 쿠버네티스 개념과 kind 설치
이혜원 님
같은 스터디 2주차, 쿠버네티스로 넘어간 기록입니다.
앞부분이 개념 지도예요. 오케스트레이션이 왜 필요한지에서 시작해 원하는 상태, 선언형 커맨드, 아키텍처, 컴포넌트별 역할까지 계층을 따라 내려갑니다.
뒷부분은 설치 실습이고, 여기서 에러가 납니다. "확인해보니 도커 설치가 안되어있었다 ^^;;;"
실습 환경 OS를 맨 위와 중간에 두 번 적어뒀어요.
조금 더 들어가 보면
🤹 왜 오케스트레이션인가
시작이 필요성입니다.
그래서 등장한 게 컨테이너 오케스트레이션(쿠버네티스)이다.
앞 주차에서 배운 것의 한계에서 출발했습니다.
박성훈 님의 1주차 노트에 docker run --name nginx-docker -p 3000:80 -d nginx:latest가 있었죠. 컨테이너 하나를 띄우는 명령입니다. 이게 서른 개, 삼백 개가 되면요. 그리고 그중 몇 개가 죽으면 누가 다시 띄우나요.
그 질문의 답이 쿠버네티스입니다. 그래서 이런 문장이 이어집니다.
🎯 원하는 상태를 적어둔다
핵심 개념을 두 개 짝지어 설명했습니다.
선언형 커맨드 — 서버에게 직접 동작을 명령하지 않고 내가 원하는 상태를 "선언"하는 명령어. vs 명령형 커맨드(
docker run)=> 원하는 상태와 선언형 커맨드는 같이 가는 개념이다!
마지막 화살표 한 줄이 두 개념을 묶습니다.
docker run은 "지금 하나 띄워라"입니다. 명령이 끝나면 도커의 일도 끝나요. 나중에 그게 죽어도 도커는 아무것도 안 합니다.
쿠버네티스는 "세 개가 떠 있어야 한다"를 적어두는 방식입니다. 그러면 하나가 죽었을 때 자동으로 하나를 더 띄웁니다. 명령을 다시 내리지 않아도요.
이 차이를 "같이 가는 개념"이라고 정리한 게 정확합니다. 선언형으로 쓰려면 시스템이 원하는 상태를 계속 확인해줘야 하고, 그 확인 장치가 있으니 선언형으로 쓸 수 있는 거니까요.
🏗️ 두 덩어리로 나뉜 구조
아키텍처 설명이 계층적입니다. Control Plane과 Worker Node로 나누고, 각각의 구성 요소를 하나씩 짚어요.
etcd — 쿠버네티스 내 모든 메타 정보를 저장하는 저장소. 쿠버네티스의 DB인데, 이 etcd는 오직 api server와만 통신함
kube-scheduler — 어떤 노드에 파드를 배포할지 골라주는 역할
controller-manager — desired state와 current state를 지속적으로 체크하며 이벤트에 따라 동작을 수행
설명마다 "그래서 무엇이 중요한가"가 붙어 있습니다.
api 서버 항목이 특히 그래요. 역할을 적고 나서 "병목이 가장 잘 생기는 부분"이라는 실무 이야기를 덧붙였습니다. 모든 요청이 한 군데로 모이니 당연한 결과인데, 구조를 알면 그게 예측됩니다.
etcd의 "오직 api server와만 통신함"도 중요한 제약입니다. DB에 아무나 직접 접근하지 못하게 막아둔 구조니까요. 앞의 문장과 이어서 읽으면 왜 api 서버의 보안이 중요한지가 분명해집니다.
그리고 앞서 나온 "원하는 상태"가 controller-manager에서 다시 등장합니다. 개념으로 설명했던 걸 실제로 그 일을 하는 컴포넌트와 연결한 거예요.
🚫 도커가 빠진 이유
컨테이너 런타임 항목에 별도 설명이 붙었습니다.
OCI : 컨테이너 표준. 도커가 OCI 표준을 준수하지 않음. 그래서 쿠버네티스 개발 시에 추가 공수가 필요함(Dockershim). 결국 쿠버네티스에서 지원 안 함
이유까지 적어둔 게 좋습니다.
도커로 쿠버네티스를 배우다 보면 이 이야기를 어디선가 만나게 되는데, 대개 "지원 안 한다"까지만 듣고 넘어갑니다. 그러면 도커를 배운 게 헛수고인가 싶어지죠.
그런데 표준 이야기까지 알면 다릅니다. 도커로 만든 이미지는 OCI 이미지 표준을 따르니 쿠버네티스에서 그대로 씁니다. 빠진 건 컨테이너를 실행하는 부분뿐이에요.
이어지는 참고 메모도 실용적입니다.
IP가 바뀐다는 전제에서 출발한 설명이라 이해가 빠릅니다.
📝 원문에서는 이렇게 씁니다
설치 파트에서 에러가 나는데, 그걸 그대로 적었습니다.
kind create cluster 실행 시 에러가 났다.확인해보니 도커 설치가 안 되어 있었다 ^^;;;
"^^;;;"까지 그대로 있습니다.
그리고 도커 설치 명령을 여덟 줄로 정리해 붙였어요. 저장소 추가부터 데몬 켜기, 자동 시작 설정, 권한 추가까지요. 마지막에 이런 줄도 있습니다.
usermod -aG docker $USER로 그룹에 넣어도 이미 열려 있는 세션에는 적용이 안 되거든요. 이걸 모르면 권한 오류가 계속 납니다.
그리고 실습 환경을 두 번 적었습니다.
맨 위에 한 번, 설치 파트 앞에 또 한 번이요. 리눅스 배포판마다 패키지 관리자와 명령어가 다르니, 따라 하는 사람이 중간부터 읽어도 알 수 있게 한 겁니다.
kind를 고른 이유도 밝혔습니다.
여러 선택지 중 왜 이걸 골랐는지를 적어둔 것. 앞선 회차들에서도 여러 번 본 습관입니다.
큐레이터 노트
개념을 계층으로 내려간 노트라 골랐습니다.
쿠버네티스는 용어가 많습니다. 파드, 노드, 컨트롤 플레인, etcd, kubelet, kube-proxy… 처음 들으면 그냥 단어의 나열이에요.
이 노트는 그걸 위에서부터 내려가며 정리했습니다. 왜 필요한가 → 무슨 개념으로 돌아가나 → 어떤 구조인가 → 각 부품은 뭘 하나요. 그래서 용어가 나올 때마다 어디에 붙는 것인지가 정해집니다.
그리고 개념 설명 중간중간에 실무 감각이 섞여 있습니다. api 서버가 병목이라는 것, etcd가 api 서버하고만 통신한다는 것, Control Plane은 최소 3대로 클러스터링해야 한다는 것요. 강의에서 들은 이야기를 놓치지 않고 적어둔 흔적입니다.
앞의 박성훈 님 노트가 손으로 친 것을 남긴 기록이라면, 이건 들은 것을 정리한 기록입니다. 같은 스터디인데 남는 게 다릅니다.
03
🕸️ docker network
강승연 님
도커 네트워크를 직접 뜯어본 기록입니다. 스터디 진도보다 한참 깊이 들어갔어요.
docker network ls로 기본 네트워크 셋을 확인하고, inspect로 서브넷과 붙은 컨테이너를 보고, 컨테이너끼리 핑을 날려 패킷 로그까지 읽습니다.그리고 끝이 솔직해요. "이건 이래저래 다른 길로 새다가 날이 새버려서 다음에 하겠습니다."
참고 링크가 여덟 개 넘게 달려 있고, 찾다가 실패한 것도 적혀 있습니다.
조금 더 들어가 보면
172.17.0.1은 어디서 왔나
시작이 기본 확인입니다.
$ docker network ls NETWORK ID NAME DRIVER SCOPE 1edf6f027a5a bridge bridge local 3807b42fe5f2 host host local e19d633c09eb none null local
docker0가 생성됩니다.컨테이너를 생성할 때 별다른 network 설정을 하지 않으면 이 중 bridge에 붙고, 기본적으로 생성된 bridge인
docker0의 subnet 172.17.0.0/16에서 ip를 자동 할당받습니다.앞의 박성훈 님 노트에서 본 그 숫자입니다.
1주차에 컨테이너 안에서 172.17.0.0/16이 찍히는 걸 확인했죠. 여기서는 그게 어디서 나오는지가 나옵니다. 도커 데몬이 켜질 때 만들어지는 가상 네트워크 장치의 서브넷이었던 거예요.
그리고 inspect로 실제 할당 상태를 봅니다.
"Containers": {
"160ca3dd...": { "Name": "apple", "IPv4Address": "172.17.0.2/16" },
"f51c256e...": { "Name": "banana", "IPv4Address": "172.17.0.3/16" }
}
컨테이너 두 개에 .2와 .3이 붙었습니다. .1은 게이트웨이인 docker0 자신이고요.
📡 핑을 날리고 패킷을 읽는다
여기서부터 스터디 범위를 넘어갑니다. apple에서 banana로 핑을 날리고 패킷 로그를 직접 해석해요.
Reply 172.17.0.3 is-at 뒤에 있는 주소는 banana에 할당된 ethernet 카드의 하드웨어 주소(MAC address)입니다.여섯 번째 줄에 있는 건 (…) apple의 주소입니다.
로그의 몇 번째 줄이 무엇인지를 짚었습니다.
is-at이 나오는 건 ARP 응답입니다. IP는 아는데 MAC 주소를 모를 때 "이 IP 쓰는 사람 누구야?"라고 묻고, 상대가 "나야, 내 MAC은 이거야"라고 답하는 거예요. IP 통신 전에 반드시 거치는 단계인데 평소엔 안 보이는 부분입니다.
그리고 경로를 정리했습니다.
두 컨테이너가 직접 통신하는 게 아니라 docker0을 거칩니다. 스위치 하나에 두 대가 꽂혀 있는 구조인 셈이죠.
그 연결선이 무엇인지도 짚었습니다.
docker0를 맺어주는 건 컨테이너 실행 시 자동으로 생성되는 virtual ethernet interface입니다. veth로 시작하는 이름의 interface가 컨테이너 생성 시마다 만들어지고, docker0에 바인딩 됩니다.veth는 양쪽 끝이 있는 가상 랜선입니다. 한쪽 끝은 컨테이너 안에서 eth0로 보이고, 다른 쪽 끝은 호스트에서 veth...라는 이름으로 보여요. 컨테이너를 하나 띄울 때마다 이 선이 한 가닥씩 생깁니다.
🌙 날이 새버려서 다음에
그다음이 이 글에서 가장 인상적인 대목입니다.
veth의 정보는 아래와 같이 생겨서 연결된 컨테이너를 바로 알긴 어렵습니다.그럼 각
veth가 어떤 컨테이너와 연결되어 있는지를 어떻게 찾느냐, 이건 이래저래 다른 길로 새다가 날이 새버려서 다음에 하겠습니다.못 푼 문제를 못 풀었다고 적고 멈췄습니다.
그리고 참고 링크 아래에 "veth 찾기 시작"이라는 소제목을 달고 시도한 흔적을 남겼어요.
ip netns list가 안 나옴같은 길을 걸어간 사람을 찾았다 다음에 봐야겠음
어디까지 갔고 왜 막혔는지가 다 적혀 있습니다. ip netns list가 비어 나오는 건 실제로 흔한 상황이에요. 도커가 네트워크 네임스페이스를 표준 위치에 링크해두지 않아서인데, 그것까지 알아내려면 또 한참을 파야 합니다.
멈춘 지점에 표시를 해둔 것이라 다음에 이어 갈 수 있습니다.
🌿 샛길에서 본 것
마지막에 "샛길"이라는 소제목이 하나 더 있습니다.
network 분리 목적 예시 : db랑 app을 하나의 private network로 묶고 app이 외부 통신하는 건 다른 network에 넣기 → db 보호
실제로 돌아가는 구성을 보고 이유를 역으로 추측한 것입니다.
이게 왜 좋은 설계인지 풀어보면요. DB를 외부와 통하는 네트워크에 두지 않으면, 밖에서는 DB로 가는 길 자체가 없습니다. 방화벽으로 막는 것과 다릅니다. 막는 게 아니라 애초에 연결이 없는 거예요.
app은 두 네트워크에 다 속해 있어서 양쪽과 통합니다. app을 반드시 거쳐야만 DB에 닿는 구조가 되죠.
앞에서 docker network ls로 본 기본 bridge 하나에 다 붙이면 이런 구분이 없습니다. 네트워크를 나눈다는 게 왜 필요한지가 이 한 줄로 설명됩니다.
📝 원문에서는 이렇게 씁니다
이 글에는 참고 링크가 여덟 개 넘게 달려 있습니다. 그리고 그냥 나열이 아니라 구간별로 묶여 있어요.
본문 참고 자료 셋, 그다음 "veth 찾기 시작" 아래 셋, 그리고 "샛길" 아래 하나요.
어느 링크가 어느 단계에서 필요했는지가 남습니다. 다음에 다시 볼 때 처음부터 다 열 필요가 없죠.
그리고 문체가 계속 바뀝니다. 앞부분은 "~합니다"체로 정돈되어 있는데, 뒤로 갈수록 "다음에 봐야겠음", "날이 새버려서" 같은 혼잣말이 섞여요.
정리해서 쓰다가 탐색으로 넘어간 지점이 문체에 그대로 보입니다.
큐레이터 노트
진도를 벗어난 기록이라 골랐습니다.
스터디 노트는 대개 그날 배운 범위 안에 머뭅니다. 그게 나쁜 것도 아니고요. 그런데 가끔 한 사람이 옆길로 새서 훨씬 깊이 들어가는 일이 생깁니다.
이 글이 그렇습니다. docker0이 있다는 것까지가 스터디 범위였을 텐데, 여기서는 핑을 날려 ARP 응답을 읽고 veth 짝을 찾으려 밤을 새웠어요.
그리고 못 찾았다고 적었습니다. 이게 이 기록을 특히 쓸모 있게 만듭니다. 완성된 답만 있으면 "그렇구나"인데, 막힌 지점과 시도한 명령이 있으면 다음 사람이 거기서부터 시작할 수 있으니까요.
마지막의 "샛길"도 좋습니다. 스터디에서 배운 걸 실제 운영 구성에 대보고 이유를 유추한 것. 배운 것과 본 것을 이어 붙이는 순간이거든요.
💡 세 편을 겹쳐 읽으며
세 편이 같은 스터디의 기록입니다. 도커에서 시작해 쿠버네티스로 가는 몇 주짜리 과정이요.
그런데 남은 노트가 완전히 다릅니다.
같은 시간, 다른 기록
박성훈 님의 노트에는 터미널이 남았습니다. 명령어와 출력 전문, 그리고 화살표 해석이요. 실패한 명령까지 있습니다.
이혜원 님의 노트에는 구조가 남았습니다. 왜 필요한지에서 시작해 아키텍처와 컴포넌트로 내려가는 지도요.
강승연 님의 노트에는 탐색이 남았습니다. 패킷 로그와 참고 링크와 막힌 지점이요.
어느 쪽이 낫다고 말하기 어렵습니다. 다시 볼 때 필요한 게 다르거든요. 명령어가 기억 안 나면 첫 번째, 구조가 헷갈리면 두 번째, 더 파고들고 싶으면 세 번째입니다.
같은 자리에 세 노트가 모이니 한 주제를 세 각도에서 보게 됩니다. 성장일지가 회차별로 모이는 형식이라 생기는 일이에요.
172.17.0.0/16이 이어진다
세 노트가 한 지점에서 만납니다.
박성훈 님이 컨테이너 안에서 172.17.0.0/16이 찍히는 걸 확인했고, 강승연 님이 그게 docker0의 서브넷이라는 걸 파헤쳤습니다. 그리고 이혜원 님의 노트에는 쿠버네티스의 Overlay Network 이야기가 나오죠.
"레이어가 하나 더 있다"는 같은 이야기입니다. 컨테이너의 세계에는 호스트와 별개의 주소 체계가 있고, 그 사이를 잇는 장치가 있다는 것요.
한 노트에서 본 숫자가 다른 노트에서 설명되고, 또 다른 노트에서 개념으로 정리됩니다.
모르는 채로 남긴 자리
세 노트 모두 모르거나 못 한 것을 적었습니다.
박성훈 님은 netstat 없다는 에러를 지우지 않았습니다.
이혜원 님은 "도커 설치가 안 되어 있었다 ^^;;;"라고 적었고요.
강승연 님은 "날이 새버려서 다음에 하겠습니다"로 끝냈습니다.
세 사람 다 매끄럽게 정리하지 않았어요. 그런데 그 덕에 세 노트 모두 다음에 이어 쓸 수 있는 상태로 남았습니다.
이번 회차에서 가져갈 것
1. docker ps와 docker ps -a를 같이 확인하기.
끝난 컨테이너는 ps에 안 보이지만 사라진 게 아니라 멈춰 있습니다. 쌓이면 디스크를 먹으니 가끔 -a로 보세요.
2. -p 3000:80의 왼쪽이 호스트, 오른쪽이 컨테이너.
순서를 뒤집으면 연결이 안 되는데 에러 메시지가 친절하지 않습니다.
3. usermod -aG docker 뒤에는 터미널을 다시 열기.
그룹 변경은 이미 열려 있는 세션에 적용되지 않습니다. 이걸 모르면 권한 오류가 계속 납니다.
4. 명령형과 선언형의 차이를 기억하기.
docker run은 "지금 띄워라"고, 쿠버네티스 yaml은 "세 개가 떠 있어야 한다"입니다. 후자는 죽으면 알아서 다시 띄웁니다.
5. DB와 앱의 네트워크를 나눠보기.
같은 네트워크에 다 붙이면 밖에서 DB로 가는 길이 열려 있습니다. app만 두 네트워크에 두면 반드시 app을 거쳐야 DB에 닿습니다.
3기 3회차는 2025년 4월 중순이었습니다. 도커·쿠버네티스 스터디가 한창이던 무렵이에요.
한 스터디를 함께 들은 세 분이 완전히 다른 노트를 남겼습니다. 같은 자리에 모아놓고 보니 서로가 서로의 빈칸을 채워주네요.
성장일지는 멤버들이 2주에 한 번씩 자신의 성장을 기록하는 활동이에요. 지난 기수의 성장일지를 다시 읽으면서, 그때 소개해드리지 못한 글을 하나씩 꺼내고 있습니다.
좋은 글 남겨주신 박성훈 님, 이혜원 님, 강승연 님께 감사드립니다. 그리고 3기를 함께 채워주신 모든 멤버분들께도요! 😊
다음 큐레이션으로 다시 찾아오겠습니다! 🌱
- 에디터 · 성장일지 큐레이터 -
※ 본 큐레이션은 각 저자가 공개한 글을 소개하는 것이며, 모든 원문의 저작권은 저자에게 있습니다. 저자 본인의 요청이 있을 경우 즉시 수정 또는 삭제합니다.