안녕하세요! 그로스로그 입니다!😊 🌱
코드 한 덩어리를 떼어 이름 붙이는 일, 오래 걸리는 작업을 다른 프로세스에 넘기는 일, 무거운 연산을 여러 대에 나누는 일. 4기 2회차 세 편입니다.
4기 2회차는 2025년 10월입니다. 세 편이 서로 다른 층위에 있는데, 놓고 보면 같은 동작을 규모만 바꿔 하고 있습니다. 일을 떼어내 다른 데로 보내는 것이요.
01
🧩 프로그래밍 언어에 대한 이해
강휘윤 님
서브프로그램과 모듈을 정리한 글입니다. 전공 과목의 개념을 자기 예시로 다시 쓴 기록이에요.
커피 가격과 수량을 받아 총액을 돌려주는 함수를 만들어 "메인이 시키고 서브가 대신 계산해 돌려준다"로 설명합니다.
모듈은 "같은 이름을 가진 변수나 함수가 서로 충돌하지 않도록, 구분된 방에 저장하는 구조"라고 풀었습니다.
교재의 정의를 그대로 옮기지 않고 한 번 자기 문장으로 바꿔 쓴 게 이 글의 핵심입니다.
조금 더 들어가 보면
서브프로그램을 "전체 프로그램을 이루는 작은 코드 블록에 이름을 붙인것"이라고 정의합니다. 그리고 왜 필요한지를 두 갈래로 적었어요 — 복잡한 프로그램에서 일부분을 별개 단위로 묶으면 다루기 편하고, 한 번 정의해두면 여러 번 쓸 수 있다는 것이죠.
예시가 구체적입니다.
def 계산하기(가격, 수량):
합계 = 가격 * 수량
return 합계
커피가격 = 4500
수량 = 2
총금액 = 계산하기(커피가격, 수량)
그리고 이 코드를 이렇게 읽습니다 — "메인 프로그램이 커피가격과 수량을 계산해줘라고 명령하면, 서브 프로그램이 계산을 대신 수행하고 결과를 반환한다."
시키는 쪽과 하는 쪽으로 나눠 읽은 것이 정확합니다. 호출이라는 말보다 이 문장이 먼저 와야 이해가 됩니다.
유형은 둘로 나눕니다.
· 함수 — 연산 수행 결과 값을 반환하는 서브프로그램
· 프로시저 — 결과 값을 반환하지 않는 서브프로그램
쓰는 이유도 네 가지로 정리했어요. 중복 코드가 줄고, 유지보수가 쉬워지고, 구조가 명확해지고, 다른 프로그램에서 재활용할 수 있다는 것입니다.
📝 원문에서는 모듈로 넘어갑니다
모듈을 "독립적인 프로그램의 구성단위"로 놓고, 서브프로그램도 모듈의 일종이라고 정리합니다. 여러 개의 함수나 클래스를 하나의 파일로 묶은 것이라고요.
특징으로 독자적인 이름 공간을 듭니다. 그리고 이름 공간을 이렇게 풀었어요.
"구분된 방"이라는 비유가 이 글에서 가장 좋은 대목입니다. 이름 공간은 설명하기 까다로운 개념인데, 방이라고 하면 왜 필요한지가 한 번에 옵니다.
언어별로 모듈이 무엇에 해당하는지도 짚습니다. 객체지향 언어에서는 클래스를 모듈로 활용할 수 있고, C처럼 함수 단위로 구성된 언어에서는 소스 코드 하나를 모듈로 취급하기도 한다고요.
마지막 대목이 은근히 실용적입니다. 컴파일러와 인터프리터가 모듈 인터페이스를 찾으려면 경로를 알아야 해서 운영체제의 환경변수로 등록하는 경우가 많다는 이야기예요. C 컴파일러가 헤더 파일을 찾을 때 환경변수 include를 검색한다는 예시까지 붙였습니다.
그리고 파이썬 예시로 마무리합니다 — calculator.py에 add를 두고, main.py에서 import calculator 후 calculator.add(3, 5)로 부르는 것이요. 방 이름을 붙여 부르는 모양이 코드로 보입니다.
큐레이터 노트
교재 개념을 자기 문장으로 바꿔 쓴 기록이라 뽑았습니다.
전공 공부를 정리한 글은 대개 교재 정의를 옮겨 적는 데서 끝납니다. 이 글은 서브프로그램에 커피 계산을, 이름 공간에 구분된 방을 붙였어요. 비유를 만들려면 개념을 한 번 자기 쪽으로 가져와야 합니다. 그 과정이 글에 남아 있습니다.
"메인이 시키고 서브가 대신 한다"는 읽기도 그렇습니다. 함수 호출을 이렇게 정리해두면 나중에 콜백이나 비동기를 만나도 같은 틀로 볼 수 있어요. 이번 회차의 다른 두 편이 정확히 그 이야기입니다.
비전공으로 시작한 회원들에게는 같은 과목을 지나간 사람의 정리로 읽힙니다.
02
🧵 Django에 Celery 사용하기(1)
박나은 님
Celery를 정리한 글입니다. 대용량 파일 업로드·다운로드·일괄 변경 같은 작업에 쓰면서 익힌 것을 남겼어요.
Celery의 구성 요소 네 가지(클라이언트 · 메시지 브로커 · 워커 · 백엔드)와 작동 순서를 정리하고, 머메이드 다이어그램으로 그렸습니다.
장점 네 가지를 적고, 단점은 하나만 적습니다 — "어플리케이션 구조가 정말 복잡해진다."
쓰게 된 이유가 첫 문단에 있습니다 — "안 써놓으면 까먹을 것 같아서 정리해보았다."
조금 더 들어가 보면
Celery를 "Python으로 작성된 분산 작업 큐(Distributed Task Queue) 시스템"으로 놓고, 먼저 작업 큐가 뭔지부터 설명합니다.
공식 문서 문장을 가져온 뒤 자기 말로 다시 씁니다 — 시간이 오래 걸리거나 리소스를 많이 쓰는 작업을 바로 처리하지 않고 비동기적으로 미뤄두는 것이라고요. 그리고 생산자-소비자 모델을 기반으로 작동한다고 연결합니다.
⚙️ 네 조각으로 나눠 보기
구성을 넷으로 나눕니다. 클라이언트 · 메시지 브로커 · 워커 · 백엔드. 이 중 백엔드는 선택 사항에 가깝다고 표시한 게 친절합니다. 처음 보는 사람이 뭐부터 갖춰야 할지 알 수 있으니까요.
작동 순서도 네 줄로 정리했습니다.
· 클라이언트가 Task를 발행하고 비동기 실행을 요청한다
· 메시지 브로커가 메시지를 받아 큐에 저장한다
· 워커가 큐에서 가져와(Consume) 실제 함수를 실행한다
· 워커가 결과나 상태를 백엔드에 저장한다
그리고 이걸 머메이드 다이어그램으로 그렸어요. 큐 셋과 워커 셋을 그려서 여러 워커가 나눠 가져가는 모양이 보이게 했습니다.
📝 원문에서는 선택의 근거를 밝힙니다
왜 Celery였는지를 솔직하게 적은 대목이 이 글에서 가장 값어치 있습니다.
"할 수 있는지 모르겠다"를 그대로 적었습니다. 확신이 아니라 판단 당시의 정보 상태를 남긴 거예요.
그리고 기준을 숫자로 정했습니다 — "100개 이상/총 용량 500mb 이상의 데이터를 다뤄야 할 경우 Celery를 사용하도록". 흐름도 한 줄로 적었고요.
사용자 요청 → Django 뷰 → Celery Task 발행 → 사용자에게 즉시 응답 (백그라운드) → Celery 워커가 Task 처리 → 결과 저장/알림
즉시 응답이 이 구조의 목적입니다. 사용자는 기다리지 않고, 무거운 일은 뒤에서 도는 것이죠.
장점은 넷을 듭니다. 비동기 처리로 응답 시간을 줄이는 것, 워커나 서버를 늘려 확장하는 것, Task 정보가 브로커에 남아 서버가 죽어도 유실되지 않는 것, 그리고 Celery Beat로 주기적 작업을 거는 것이요.
단점은 하나만 적었는데, 그 하나가 무겁습니다.
이유도 구체적입니다. 시스템에 계층이 하나 더 붙고, RabbitMQ나 Redis를 따로 설치해야 하고, 워커 관리가 처음엔 복잡하고, chain·chord·group 같은 워크플로우 기능까지 쓰면 신경 쓸 게 많아진다고요.
뒷부분은 도커 기준 설치와 최소 예제입니다. pip install "celery[redis]" → Celery 인스턴스 생성 → @app.task 데코레이터로 함수를 Task로 만들기 → 워커 실행 → add.delay(4, 6)로 호출. .get()에 타임아웃과 예외 처리를 권장한다는 주석까지 달아뒀습니다.
큐레이터 노트
도입 기준을 숫자로 적어둔 기록이라 뽑았습니다.
"100개 이상 / 500mb 이상" — 이 한 줄이 이 글을 다른 Celery 소개글과 갈라놓습니다. 도구 설명은 많지만 언제부터 쓸지를 정해준 글은 드물어요. 이 기준이 있으면 작은 작업에 무거운 구조를 얹는 일을 피할 수 있습니다.
단점을 하나로 좁힌 것도 그렇습니다. 장점 넷과 단점 하나인데, 그 하나가 "정말 복잡해진다"예요. 계층이 늘고 브로커를 따로 설치해야 한다는 대가를 정확히 적었습니다. 쓸지 말지 판단하려면 이쪽이 더 필요한 정보입니다.
"안 써놓으면 까먹을 것 같아서"라는 동기도 성장일지와 잘 맞습니다. 남에게 가르치려고 쓴 게 아니라 자기가 다시 볼 것을 쓴 글인데, 그래서 오히려 실제 판단이 남았어요.
03
⚡ Pyspark: Python에서 SQL 사용하기
장욱일 님
PySpark를 소개한 글입니다. 파이썬 안에서 SQL 문법으로 SQL의 기능을 쓸 수 있게 해주는 패키지죠.
그런데 도구 설명보다 앞머리의 관점이 먼저 옵니다 — 데이터 분석의 질과 속도는 알고리즘과 데이터베이스 관리 두 축에서 결정되고, "대개 둘은 경쟁관계에 있습니다."
spark.sql()로 SQL을 쓰고, toPandas()로 익숙한 판다스 데이터프레임으로 바꾸는 흐름까지 이어집니다.도구 이야기 앞에 왜 이 도구가 필요한 자리가 생기는지를 놓았습니다.
조금 더 들어가 보면
첫머리의 대비가 이 글의 뼈대입니다.
양쪽 끝을 다 적었습니다. 메모리를 안 보고 짜면 낭비가 되고, 메모리가 부족하면 코드가 복잡해진다는 것이죠. 그래서 "알고리즘과 데이터베이스 관리 모두를 고려하는 행위는 필수적"이라는 결론으로 갑니다.
그리고 현장의 갈라짐을 짚습니다. 분석 작업은 파이썬을 쓰고, 데이터베이스 관리는 SQL을 쓴다는 것. PySpark가 놓이는 자리가 정확히 그 사이입니다.
📝 원문에서는 실행 순서를 보여줍니다
문서 링크를 먼저 걸고, 라이브러리 import → Spark 설정 및 구동 → 수행 순으로 갑니다.
설정 대목에 실무 감각이 있습니다. 가용 메모리나 core 개수로 최적화할 수 있지만 "대개는 관리자가 내려준 설정을 따르게 됩니다"라고 적었어요. 손댈 수 있는 것과 그렇지 않은 것을 구분해 둔 것입니다.
수행 부분에서는 Spark 구동을 간단한 함수로 만들어 변수를 받아 돌리는 방식을 씁니다. 그리고 핵심 두 줄이 나옵니다.
· spark.sql() 안에 SQL 문법 그대로 쓰면 결과가 데이터프레임으로 나온다
· 그 결과에 toPandas()를 쓰면 익숙한 판다스 데이터프레임으로 바뀐다
아는 문법으로 들어가서 아는 형태로 나오는 구조입니다. 새 API를 처음부터 익히지 않아도 되는 지점을 짚은 것이죠.
큐레이터 노트
도구를 소개하기 전에 좌표를 먼저 그린 글이라 뽑았습니다.
PySpark 사용법만 적었다면 공식 문서와 다를 게 없습니다. 이 글은 알고리즘과 데이터베이스 관리가 경쟁 관계라는 관점을 먼저 놓고, 그 사이에서 PySpark가 하는 일을 놓았어요. 그러면 이 도구를 언제 꺼낼지도 같이 정해집니다.
toPandas()로 끝맺은 것도 좋습니다. 분산 처리 도구를 소개하면서 결국 익숙한 판다스로 돌아오는 경로를 알려준 거예요. 새 도구의 진입 장벽은 대개 "여기서 나온 결과를 어떻게 이어 쓰지"에서 생기는데, 그 답을 미리 준 셈입니다.
"관리자가 내려준 설정을 따르게 됩니다" 같은 문장은 실제로 써본 사람만 씁니다.
💡 세 편을 겹쳐 읽으며
세 편이 일을 떼어내 다른 데로 보내는 이야기를 규모만 바꿔 하고 있습니다.
강휘윤 님은 한 프로그램 안에서 떼어냅니다. 코드 블록에 이름을 붙여 "메인이 시키고 서브가 대신 계산해" 돌려주게 하는 것이요.
박나은 님은 프로세스 밖으로 보냅니다. 오래 걸리는 파일 작업을 큐에 넣고 워커가 가져가게 해서, 사용자에게는 즉시 응답이 나가게 합니다.
장욱일 님은 여러 대로 나눕니다. 단일 머신에서 감당 안 되는 연산을 Spark로 보내고, 결과는 toPandas()로 받아옵니다.
떼어낸 다음에 무엇이 생기는지도 셋 다 같습니다. 부르는 쪽은 안을 몰라도 되고, 대신 연결하는 자리가 새로 생깁니다. 강휘윤 님의 이름 공간, 박나은 님의 메시지 브로커, 장욱일 님의 Spark 설정이 각각 그 자리예요.
그래서 박나은 님의 "어플리케이션 구조가 정말 복잡해진다"가 세 편 모두에 걸립니다. 떼어내면 편해지는 대신 관리할 것이 늘어납니다. 그 대가를 알고 고르는 게 설계고요.
이번 회차에서 가져갈 것
1. 개념은 자기 예시로 한 번 바꿔 써보기.
커피 계산, 구분된 방. 비유를 만들려면 개념을 자기 쪽으로 가져와야 하고, 그 과정에서 이해가 남습니다.
2. 함수 호출을 "시키는 쪽과 하는 쪽"으로 읽기.
이 틀을 잡아두면 나중에 작업 큐나 분산 처리를 만나도 같은 모양으로 보입니다.
3. 도구 도입 기준을 숫자로 정하기.
"100개 이상 / 500mb 이상"처럼요. 기준이 없으면 작은 작업에도 무거운 구조를 얹게 됩니다.
4. 단점을 정확히 하나 적어두기.
장점은 문서에도 있습니다. 쓸지 말지 판단할 때 필요한 건 대가 쪽이에요. 계층이 하나 늘어난다는 것 같은.
5. 판단 당시의 확신 없음도 기록하기.
"처리할 수 있는지 모르겠다는 이유로" — 나중에 그 결정을 다시 볼 때, 뭘 몰랐는지가 남아 있어야 이해가 됩니다.
6. 새 도구는 나가는 길까지 확인하기.
toPandas()처럼 익숙한 형태로 돌아오는 경로를 알면 진입이 쉬워집니다. 들어가는 법만 아는 도구는 잘 안 쓰게 됩니다.
좋은 글 남겨주신 강휘윤 님, 박나은 님, 장욱일 님께 감사드립니다! 😊
다음 큐레이션으로 다시 찾아오겠습니다! 🌱
- 에디터 · 성장일지 큐레이터 -
성장일지는 멤버들이 2주에 한 번씩 자신의 성장을 기록하는 활동이에요. 매 회차 운영진이 모든 글을 읽고, 그중 특히 마음에 남은 글을 함께 골라 큐레이션합니다.
※ 본 큐레이션은 각 저자가 공개한 글을 소개하는 것이며, 모든 원문의 저작권은 저자에게 있습니다. 저자 본인의 요청이 있을 경우 즉시 수정 또는 삭제합니다.