안녕하세요, SCG 31기 박준성입니다.
이번 인프라 스터디에서 첫 주제인 Introduction + Docker를 맡았습니다. Nix로 개발 환경을 맞추고, 같은 정의를 바탕으로 이미지를 만들어 Docker로 실행하는 흐름을 다루는 주제였습니다.
다만 이 글에서는 Nix나 Docker의 사용법을 다시 설명하기보다, 제가 스터디를 준비하면서 어떤 부분을 고민했는지 이야기해보려고 합니다. 개념과 실습 명령은 SCG 워크스페이스의 Introduction 자료에 정리해두었습니다.
자료가 있어도 바로 이해되는 것은 아니었다
이번 스터디를 준비하며 신경 쓴 부분은 듣는 사람이 처음 보는 개념을 한 번에 따라올 수 있을까였습니다.
개발 셸, 이미지, 컨테이너, 런타임 같은 단어는 각각의 정의만 읽으면 어느 정도 알 것 같습니다. 그런데 실제로 하나의 프로그램이 실행되는 흐름에 놓고 보면, 어디서 무엇이 만들어지고 어떤 환경에서 실행되는지 다시 헷갈리기 쉽습니다.
저도 준비하면서 비슷한 부분에서 막혔습니다. 그래서 자료를 먼저 완성한 뒤 발표 내용을 외우는 방식보다, 자료의 순서에 맞춰 제가 먼저 공부하고 이해가 안 되는 부분을 질문하는 방식으로 준비했습니다.
AI로 만든 초안을, 질문하면서 다시 읽기
먼저 AI를 활용해 발표 자료의 초안과 흐름을 구성했습니다. 하지만 초안이 생겼다고 제가 그 내용을 바로 설명할 수 있는 것은 아니었습니다.
자료를 읽다가 이해되지 않는 부분을 AI에게 질문하고, 답변을 읽고도 모호한 부분이 남으면 다시 질문했습니다. 특히 용어가 무엇을 가리키는지, 한 명령이 어디까지 영향을 주는지처럼 설명 속에 당연하게 들어가 있는 전제를 자주 확인했습니다.
개발 셸을 나가면 무엇이 남는지, 이미지와 컨테이너는 어떻게 다른지처럼 도구의 적용 범위와 객체의 차이를 짚는 질문이 특히 중요했습니다.
이 과정에서는 설명을 읽고 “그런가 보다” 하고 넘어가는 것과, 제가 이해한 내용을 다시 말할 수 있는 것이 다르다는 점을 계속 확인하게 되었습니다. “이미지를 실행한다”처럼 익숙하게 쓰는 표현도 이미지, 컨테이너, 실제 프로세스를 구분하지 않으면 오해하기 쉬웠습니다.
AI는 자료를 빠르게 구성하고 질문을 이어가는 데 활용했지만, 그 답변을 그대로 발표 내용으로 삼기보다는 공식 문서와 실제 실습 코드의 정의를 함께 확인하려고 했습니다. 제가 설명할 수 없는 문장을 자료에 남겨두지 않는 것이 중요하다고 생각했습니다.
AI 초안에서 질문과 Q&A 보완으로 이어진 준비 과정 (AI로 제작한 도식)
제가 했던 질문을 자료에도 남겼습니다
준비하면서 생긴 질문은 개인적으로 답을 듣고 끝내지 않고, 공유 페이지의 해당 설명 아래에 질문과 답변 형태로 추가했습니다.
제가 처음 읽으면서 막혔던 부분이라면, 이 내용을 처음 접하는 다른 사람도 비슷한 부분에서 막힐 수 있겠다고 생각했기 때문입니다. 발표에서는 흐름을 따라가더라도, 나중에 혼자 자료를 다시 볼 때 한 문장의 뜻이 모호해질 수도 있습니다.
그래서 별도의 질문 목록만 만드는 대신, 질문이 생기는 위치에서 바로 답을 찾아볼 수 있도록 구성했습니다. 예를 들어 개발 셸을 설명하는 부분에는 적용 범위와 운영체제에 관한 질문을, 이미지와 컨테이너를 설명하는 부분에는 두 객체의 차이에 관한 질문을 붙였습니다.
질문을 전부 펼쳐놓기보다는 토글로 묶어두어, 발표의 큰 흐름을 읽는 사람과 조금 더 자세한 설명이 필요한 사람이 같은 자료를 사용할 수 있도록 했습니다.
명령어보다 실행 흐름을 따라갈 수 있도록
실습도 복잡한 애플리케이션을 만드는 것보다, 환경의 차이를 눈으로 확인할 수 있는 작은 예제를 사용하는 쪽으로 구성했습니다. juntegral 브랜치의 lab에 있는 Java HTTP 서비스가 그 예제입니다.
/health는 응답 여부를, /message는 환경변수에 따른 문구를, /info는 Java·OS·CPU 등의 정보를 확인할 수 있게 했습니다. 애플리케이션 기능이 단순해야, 지금 달라진 것이 코드인지 실행 설정인지에 집중할 수 있다고 생각했습니다.
전체 흐름에서는 Nix 개발 셸에 들어가는 단계, 이미지를 만드는 단계, Docker에 등록하고 컨테이너를 실행하는 단계를 분리했습니다. 명령을 그대로 따라 치는 것에서 끝나지 않고, 지금 어느 환경에서 무엇을 하고 있는지 연결해서 이해하도록 돕고 싶었습니다.
개발 셸과 이미지, 컨테이너의 역할을 나눈 개념도 (AI로 제작)
Linux, Mac, Windows 참가자가 함께 볼 수 있다는 점도 준비할 때 고려했습니다. 같은 명령을 적어두는 것만으로 각 운영체제의 차이가 없어지는 것은 아니므로, 개발 셸과 Linux 이미지 빌드의 경계를 나누고 OS별 안내를 마련했습니다. 이는 환경별로 같은 설명을 반복하기보다, 공통으로 이해할 흐름과 환경에 따라 달라지는 부분을 구분하려는 고민이었습니다.
준비하면서 배운 것
이번 준비에서는 발표 자료를 보기 좋게 만드는 것만큼, 설명을 듣는 사람이 어디서 멈출지 생각하는 일이 중요하다고 느꼈습니다.
특히 제가 처음 이해하지 못했던 질문을 없애야 할 흔적으로 보기보다, 자료를 보완할 단서로 사용할 수 있었습니다. AI로 만든 초안에 제 질문과 확인 과정을 더하면서, 자료를 만드는 작업과 제가 학습하는 과정이 서로 이어졌습니다.
나중에 다시 읽는 사람이 필요한 설명을 찾을 수 있도록, 결과뿐 아니라 제가 준비하며 밟았던 중간 단계도 함께 남기려고 했습니다.
앞으로 다른 주제를 준비할 때도 완성된 설명만 정리하기보다, 그 설명을 이해하기 위해 어떤 질문이 필요했는지 함께 기록해보려고 합니다.