안녕하세요! 그로스로그 입니다!😊 🌱
같은 일을 여러 번 해야 할 때, 무엇을 먼저 해야 할까요. 2기 8회차 세 편입니다.
성장일지는 멤버들이 2주에 한 번씩 자신의 성장을 기록하는 활동이에요. 지난 기수의 성장일지를 다시 읽으면서, 그때 소개해드리지 못한 글을 하나씩 꺼내고 있습니다.
2기 8회차, 2024년의 마지막 무렵입니다. 이번 회차에는 반복을 다룬 세 편이 모였어요. 반복문으로, 함수로, 그리고 화면을 다시 그리는 일로요.
01
🔁 파이썬 독학 — for문/while문
권준형 님
파이썬
for문과 while문을 공부한 기록입니다.손으로 다섯 줄을 쓰는 코드에서 출발해서, "1,000까지 가면 어떻게 하지?"라는 질문을 던지고
for문으로 넘어가요.예제가 전부 가게 상황입니다. 대기번호, 버거킹 손님 목록, 커피 호출이요.
마지막이 솔직합니다. "실제로 이렇게 다시 배워도 살짝 난이도가 있게 느껴지는 것은 같다."
1회차와 5회차에서도 이분의 기록을 소개해드렸습니다. 이전 편이 if문이었고 이번이 반복문이에요. 순서대로 밟고 있습니다.
조금 더 들어가 보면
✋ 다섯 줄에서 시작한다
글이 반복문 문법부터 꺼내지 않습니다. 먼저 반복문 없이 써봐요.
print("대기번호 : 1")
print("대기번호 : 2")
print("대기번호 : 3")
print("대기번호 : 4")
print("대기번호 : 5")
그리고 질문을 던집니다.
"숫자가 적을 때는 쉬울 수 있지만"이라고 인정하고 들어간 게 좋습니다.
다섯 줄이면 사실 그냥 써도 됩니다. 반복문을 배우는 사람이 처음에 갖는 의문이 그거예요. "이렇게 쓰면 되는데 왜?"요. 그래서 다섯을 천으로 바꿔봅니다. 그 순간 답이 나오죠.
이게 문법을 익히는 좋은 순서입니다. 문법을 먼저 배우고 쓸 데를 찾는 게 아니라, 막히는 상황을 먼저 만들고 문법으로 푸는 것요.
그리고 첫 for문이 나옵니다.
for waiting_number in [1,2,3,4,5]:
print("대기번호: {0}".format(waiting_number))
리스트를 그대로 쓴 버전이 먼저입니다. 위의 다섯 줄과 눈으로 대조하기 쉬워요. [1,2,3,4,5]가 그대로 보이니까요.
그다음에 range(1, 6)으로 바꿉니다. 같은 일을 두 가지 방법으로 한 번씩 해본 셈입니다.
🍔 변하는 것만 남기기
세 번째 예제가 재미있습니다.
버거킹 = ["A손님", "B손님", "C손님", "D손님"]
for customer in 버거킹:
print("{0}, 메뉴가 준비되었습니다.".format(customer))
숫자가 아니라 이름 목록을 돌립니다.
파이썬 for문의 성격이 여기서 드러납니다. C나 자바의 for는 보통 "몇 번 돌아라"인데, 파이썬은 "이 목록의 것들을 하나씩 꺼내라"에 가깝거든요. 숫자를 돌리는 것도 range라는 목록을 만들어 꺼내는 것이고요.
그래서 목록이 손님 이름이든 파일 경로든 그대로 넣을 수 있습니다. 번호를 세다가 그 번호로 다시 꺼내오는 단계가 없어요.
세 예제를 나란히 놓으면 공통점이 보입니다. 문장은 항상 같고, 바뀌는 건 한 자리뿐이에요. 대기번호 자리, 손님 이름 자리요.
반복문이 하는 일이 그겁니다. 변하지 않는 부분은 한 번만 쓰고, 변하는 자리에 이름을 붙여두는 것. waiting_number와 customer가 그 이름입니다.
⏳ 몇 번인지 모를 때
while문으로 넘어가면서 성격이 달라집니다.
customer = "C손님"
person = "Unknown"
while person != customer:
print("{0}, 커피가 준비되었습니다. 데스크로 와주세요.".format(customer))
person = input("이름을 알려주세요: ")
몇 번 돌지 정해져 있지 않습니다. 맞는 이름이 들어올 때까지요.
for문으로는 이걸 못 씁니다. 돌 목록을 미리 만들 수 없으니까요. 반대로 앞의 대기번호 예제는 while로도 쓸 수 있지만 굳이 그럴 필요가 없죠.
"목록이 있는가"가 둘을 가르는 기준입니다. 돌 것이 정해져 있으면 for, 끝날 조건만 있으면 while이요.
앞의 예제도 같이 보면 대비가 분명합니다.
index = 5
while index >= 1:
print("... 호출이 {1}번 남았습니다.".format(customer, index))
index -= 1
if index == 0:
print("{0}, 커피가 폐기되었습니다.".format(customer))
index -= 1을 손으로 적어야 합니다. for문에서는 다음 값을 알아서 꺼내줬는데, while에서는 내가 줄여야 해요.
초보자가 무한루프를 만드는 자리가 정확히 여기입니다. 이 한 줄을 빼먹으면 조건이 영원히 참이거든요. while이 자유로운 대신 챙길 게 하나 늘어난 셈입니다.
📝 원문에서는 이렇게 닫습니다
마지막 문단이 이 글에서 가장 눈에 남습니다.
"다시 배워도 난이도가 있게 느껴진다"를 그대로 적었습니다.
공부 기록에서 이런 문장은 잘 안 나옵니다. 이해했다는 쪽으로 쓰게 되니까요. 그런데 한 번 배웠던 걸 다시 봐도 여전히 헷갈린다는 건 흔한 일이고, 그걸 적어두면 다음에 볼 때 도움이 됩니다.
for와 while이 헷갈리는 이유도 분명합니다. 둘 다 반복을 하는데 기준이 다르거든요. 하나는 목록을 보고, 하나는 조건을 봅니다. 문법을 외운다고 구분이 되는 게 아니라, "내가 지금 목록을 갖고 있나"를 물어봐야 갈립니다.
큐레이터 노트
문제를 먼저 만든 게 이 글을 고른 이유입니다.
for문을 설명하는 글은 대개 문법부터 시작합니다. for 변수 in 반복가능한객체: 하고 구조를 보여준 뒤 예제를 붙이죠. 그러면 문법은 남는데 왜 쓰는지가 안 남습니다.
이 글은 반대로 갔습니다. print를 다섯 번 쓰고, "천 번이면?" 하고 물은 다음, 그제야 for문을 꺼냈어요. 불편을 먼저 겪게 만든 순서입니다.
그리고 예제가 전부 가게 이야기라는 것. 대기번호, 버거킹 손님, 커피 호출요. i와 j로 된 예제보다 머리에 남습니다.
1회차 큐레이션에서 이분의 글을 소개하며 "일과 공부를 함께 이어가는 사정이 글 전체에 깔려 있다"고 적었습니다. 예제 소재도 그 자리에서 나온 것 같아요.
02
🧰 C언어 기초 함수의 개념과 표준함수
전일수 님
C의 함수를 정리한 글입니다. 구조를 먼저 보이고, 함수를 표준 함수와 사용자 정의 함수 둘로 나눠요.
그다음이 이 글의 몸통입니다. 표준 함수를 헤더 파일별로 다섯 묶음 정리했어요.
math.h, stdio.h, string.h, stdlib.h, time.h요.마지막에 주의사항 세 줄을 붙였습니다.
2·4·5·7회차에서도 이분의 C 연재를 소개해드렸습니다. 선행처리기, 연산자, 선택 제어문, 기타 제어문에 이어 함수 차례예요.
조금 더 들어가 보면
📦 왜 함수를 쓰는가
첫 문장에 이유가 다 들어 있습니다.
"재사용성"과 "구조적" 두 가지를 들었습니다.
앞 글의 반복문과 비교해보면 차이가 보입니다. 반복문은 같은 코드를 연달아 여러 번 실행하는 것이고, 함수는 같은 코드를 여기저기서 불러 쓰는 것이에요. 반복이 시간 축에 있다면 함수는 위치 축에 있습니다.
그리고 "입력값(매개변수)을 받아서"라는 대목. 함수가 유용한 건 코드를 묶어서가 아니라 바뀌는 부분을 밖에서 넣을 수 있어서입니다. add(a, b)가 쓸모 있는 이유는 두 수를 어떤 값으로든 넣을 수 있기 때문이죠.
앞 글의 waiting_number와 같은 자리입니다. 변하는 것에 이름을 붙여두고, 나머지는 한 번만 적는 것요.
🗂️ 헤더별로 묶어둔 이유
이 글의 대부분이 표준 함수 목록입니다. 그런데 알파벳순이나 자주 쓰는 순이 아니라 헤더 파일별로 묶었어요.
sqrt(), pow(), abs()2. 입출력 함수 (stdio.h) —
printf(), scanf(), getchar(), puts()3. 문자열 처리 함수 (string.h) —
strlen(), strcpy(), strcmp()4. 메모리 관리 함수 (stdlib.h) —
malloc(), free(), exit()5. 시간 함수 (time.h) —
time(), clock()이 묶음이 실무에서 그대로 쓰입니다.
C에서 함수를 하나 쓰려면 그 함수가 어느 헤더에 있는지 알아야 하거든요. strlen을 쓰려는데 #include <string.h>를 안 하면 컴파일 단계에서 막힙니다. 함수 이름만 외우면 반쪽인 셈이에요.
그래서 이름과 헤더를 묶어서 외우는 게 맞습니다. 이 정리가 그 형태로 되어 있어요.
목록을 보면 C 표준 라이브러리의 성격도 드러납니다. 다섯 묶음이 각각 계산, 입출력, 문자열, 메모리, 시간이에요. 언어 자체가 제공하지 않는 일들입니다.
특히 malloc과 free가 라이브러리 함수라는 게 눈에 띕니다. 어떤 언어에서는 메모리 관리가 문법에 붙어 있거나 아예 자동인데, C는 함수 호출로 처리해요. 5회차에서 goto를 정리하며 짚었던 "실패했을 때 할당한 메모리를 직접 풀어줘야 한다"는 이야기가 여기서 이어집니다.
⚠️ 주의사항 세 줄
마지막 세 줄이 목록보다 오래 쓰입니다.
#include 해야 사용 가능합니다.일부 함수는 특정 라이브러리에서 제공되므로 사용하기 전에 해당 라이브러리가 포함되었는지 확인해야 합니다.
표준 함수는 대부분 안정적이고 효율적이지만 주어진 문제에 맞는 함수 사용법을 정확히 숙지하는 것이 중요합니다.
첫 줄과 둘째 줄이 비슷해 보이는데 다른 이야기입니다. #include는 컴파일 단계, 라이브러리 포함은 링크 단계거든요.
math.h가 대표적입니다. 헤더만 #include하면 컴파일은 통과하는데, 링크할 때 -lm 옵션이 없으면 실패하는 환경이 있어요. 헤더는 "이런 함수가 있다"는 선언일 뿐이고, 실제 코드는 다른 파일에 있기 때문입니다.
2회차 큐레이션에서 이분의 컴파일 과정 정리를 소개해드렸는데, 그때 나눠둔 단계가 여기서 그대로 쓰입니다. 전처리·컴파일·링크를 구분해두면 에러 메시지를 보고 어느 단계에서 막혔는지 알 수 있어요.
셋째 줄의 "사용법을 정확히 숙지"도 실용적인 경고입니다. strcpy가 딱 그런 함수거든요. 잘 동작하는 것처럼 보이지만 복사할 공간이 충분한지 검사하지 않습니다. 표준에 있다고 안전한 게 아니라는 것.
📝 원문에서는 이렇게 나눕니다
함수를 둘로 가른 대목이 짧지만 중요합니다.
사용자 정의 함수 — 프로그래머가 필요에 맞게 직접 작성한 함수들
이 구분이 왜 필요할까요. 코드에 printf(...)와 add(...)가 나란히 있으면 생김새가 똑같습니다. 둘 다 이름 뒤에 괄호를 붙여 부르니까요.
그런데 하나는 어딘가에 이미 있고, 하나는 내가 만들어야 합니다. 어느 쪽인지 모르면 "정의되지 않았다"는 에러 앞에서 무엇을 해야 할지 알 수 없어요. 헤더를 추가할지, 함수를 짤지 갈리니까요.
그리고 실무에서 더 중요한 판단이 여기서 나옵니다. 만들기 전에 이미 있는지 찾아보는 것. 문자열 길이를 구하는 코드를 직접 짜기 전에 strlen을 떠올릴 수 있느냐요.
이 글이 표준 함수를 헤더별로 정리해둔 게 그 판단에 쓰입니다. 목록을 한 번 훑어둔 사람만 "아, 그건 있었지"가 되니까요.
큐레이터 노트
목록을 만들어둔 게 이 글의 값어치입니다.
표준 함수는 필요할 때 검색하면 나옵니다. 그런데 검색은 찾을 게 있다는 걸 알아야 할 수 있어요. pow()가 있는 줄 모르면 곱셈을 반복문으로 돌리게 되죠.
그래서 이런 목록은 외우려고 만드는 게 아니라 한 번 훑어두려고 만듭니다. 다섯 묶음 스무 개쯤을 한 번 지나가 두면, 나중에 필요한 순간에 "그런 게 있었던 것 같은데"가 떠오르거든요.
7회차 큐레이션에서 소개해드린 김영진 님의 트리 총정리와 성격이 닮았습니다. 설명은 짧고 항목은 많은 노트요. 두 분이 만드는 노트의 결이 비슷합니다.
그리고 이 글로 이분의 C 연재가 문법 한 바퀴를 돕니다. 자료형, 선행처리기, 연산자, 선택 제어문, 반복 제어문, 기타 제어문, 함수까지요. 교재 목차를 끝까지 따라간 기록입니다.
03
🔄 State와 생명주기
이주희 님
리액트에서 state가 왜 필요한지를 코드 두 벌로 보여준 기록입니다.
첫 줄이 결론이에요. "데이터를 업데이트 후 렌더링 하려면 state가 필요", "state를 사용하지 않으면 변화 x"요.
같은 갤러리 컴포넌트를 일반 변수로 한 번,
useState로 한 번 만들어 비교합니다.3·4·7회차에서도 이분의 리액트 기록을 소개해드렸습니다. 이번에도 전후 두 벌이에요.
조금 더 들어가 보면
📉 변수는 왜 안 되는가
바꾸기 전 코드가 이겁니다.
export default function Gallery() {
let index = 0;
function handleClick() {
index = index + 1;
}
let sculpture = sculptureList[index];
// ... index를 화면에 그린다
}
논리적으로는 맞아 보입니다. 버튼을 누르면 index가 1 늘어나니까요.
그런데 화면은 그대로입니다. 글이 적어둔 대로 "state를 사용하지 않으면 변화 x"요.
이유가 둘입니다. 하나씩 보면요.
첫째, 리액트는 변수가 바뀐 걸 모릅니다. 화면을 다시 그리려면 무언가 달라졌다는 신호가 필요한데, 일반 변수 대입에는 그런 신호가 없어요. index는 조용히 1이 됩니다.
둘째, 다시 그린다 해도 값이 사라집니다. 컴포넌트 함수가 다시 호출되면 let index = 0이 또 실행되거든요. 방금 1로 만든 값이 0으로 돌아갑니다.
두 문제는 방향이 반대인데 원인이 하나입니다. 값이 함수 안에 있다는 것요. 함수 안에 있으니 밖에서는 바뀐 줄 모르고, 함수가 다시 불리면 초기화됩니다.
🪝 useState가 푸는 두 가지
바꾼 코드가 이겁니다.
const [index, setIndex] = useState(0);
const [showMore, setShowMore] = useState(false);
function handleNextClick() {
setIndex(index + 1);
}
function handleMoreClick() {
setShowMore(!showMore);
}
useState가 앞의 두 문제를 한꺼번에 해결합니다.
값을 컴포넌트 밖에 보관하니까 다시 그려도 남아 있고, setIndex를 부르면 "바뀌었다"는 신호가 되니까 리액트가 다시 그립니다.
useState(0)의 0이 초기값인데, 이건 처음 한 번만 쓰입니다. 두 번째 렌더링부터는 보관해둔 값을 돌려줘요. let index = 0과 생김새는 비슷한데 동작이 완전히 다른 지점입니다.
showMore 쪽도 짚어둘 만합니다.
setShowMore(!showMore);
현재 값을 뒤집습니다. true면 false로, false면 true로요. 토글을 만드는 가장 짧은 방법입니다.
5회차에서 소개해드린 정원석 님의 비밀번호 토글이 떠오르는 대목이에요. 그쪽은 classList.add와 remove를 직접 불렀는데, 여기서는 값 하나를 뒤집으면 화면이 알아서 따라옵니다. 같은 일을 하는데 손대는 대상이 다릅니다.
👁️ 값과 화면을 잇기
state가 있으면 화면 쪽도 달라집니다.
{showMore ? 'Hide' : 'Show'} details
{showMore && <p>{sculpture.description}</p>}
버튼 글자와 본문 표시가 같은 값 하나에 매달려 있습니다.
showMore가 true면 버튼에 'Hide'가 뜨고 설명이 보입니다. false면 'Show'가 뜨고 설명이 사라지고요. 둘을 따로 맞출 필요가 없어요.
이게 앞의 방식과 가장 크게 다른 지점입니다. 값을 바꾼 뒤 화면을 고치는 게 아니라, 값만 바꾸면 화면이 따라오는 구조니까요.
&&를 쓴 부분도 눈여겨볼 만합니다. 자바스크립트에서 false && 무엇은 false가 되고, 리액트는 false를 화면에 아무것도 안 그립니다. if문 없이 조건부 표시가 됩니다.
?:와 &&를 자리에 맞게 나눠 쓴 것도 정확합니다. 둘 중 하나를 보여줄 때는 ?:, 보여줄지 말지일 때는 &&요.
📝 원문에서는 이렇게 씁니다
이 글에는 설명 문장이 딱 두 줄입니다.
state를 사용하지 않으면 변화 x
나머지는 코드예요. App.js와 Gallery.js를 파일 단위로 나눠 올렸고, 각 코드 위에 "state를 사용하면 변화 o" 같은 표시만 달았습니다.
"변화 x"와 "변화 o". 두 글자로 결과를 갈라뒀어요.
이런 형태의 기록이 나중에 잘 쓰입니다. 문장이 길면 다시 읽어야 하는데, 코드 두 벌과 o·x 표시는 스크롤 한 번에 들어오거든요.
7회차 큐레이션에서도 이분의 글을 두고 같은 이야기를 했습니다. 설명 대신 코드 두 벌과 짧은 주석이라고요. 형식이 일정합니다.
큐레이터 노트
안 되는 코드를 먼저 올린 게 이 글을 고른 이유입니다.
useState 사용법은 공식 문서에 잘 나와 있습니다. 그런데 문서를 읽고 나서도 "왜 그냥 변수를 쓰면 안 되지?"가 남을 때가 있어요. 되는 코드만 보면 안 되는 이유를 알 수 없으니까요.
이 글은 안 되는 버전을 통째로 올렸습니다. let index = 0으로 시작하는 코드요. 그걸 보고 나면 useState(0)이 무엇을 대신하는지가 분명해집니다.
앞의 권준형 님 글이 print 다섯 줄을 먼저 보여준 것과 같은 구조입니다. 불편을 먼저 보이고 도구를 꺼내는 순서요.
그리고 예제를 직접 만들지 않고 공식 문서의 갤러리 예제를 그대로 따라간 것도 학습 기록으로서는 정직한 선택입니다. 문서를 따라 치면서 어디서 갈리는지를 확인한 셈이니까요.
💡 세 편을 겹쳐 읽으며
세 글의 언어가 다 다릅니다. 파이썬, C, 자바스크립트요.
그런데 셋 다 같은 일을 여러 번 하는 문제를 다룹니다. 대기번호를 천 개 찍는 일, 같은 코드를 여기저기서 부르는 일, 화면을 계속 다시 그리는 일이요.
변하는 자리에 이름을 붙인다
세 글의 해법이 놀랍도록 같습니다. 무엇이 변하는지를 골라내고, 그 자리에 이름을 붙이는 것.
권준형 님의 for문에서는 waiting_number와 customer입니다. 문장은 한 번만 쓰고, 바뀌는 자리에만 이름을 뒀어요.
전일수 님의 함수에서는 매개변수입니다. add(a, b)의 a와 b요. 함수 안의 코드는 고정이고, 밖에서 값을 넣습니다.
이주희 님의 리액트에서는 state입니다. index와 showMore요. 화면 구조는 한 번만 쓰고, 바뀌는 값에 이름을 붙여둡니다.
셋 다 "고정된 틀 + 이름 붙은 구멍"이라는 같은 모양입니다. 층위가 문법, 함수, UI로 다를 뿐이에요.
이름을 붙이면 누가 채우는가
그다음이 갈립니다. 그 구멍을 누가 채우느냐요.
for문은 목록이 채웁니다. 내가 목록을 주면 반복문이 하나씩 꺼내 넣어요.
함수는 부르는 쪽이 채웁니다. 호출할 때마다 다른 값을 넣죠.
state는 이벤트가 채웁니다. 사용자가 버튼을 누르면 값이 바뀌고, 리액트가 그 값으로 화면을 다시 그려요.
while문만 조금 다릅니다. 채우는 쪽이 없어서 내가 직접 줄여야 해요. index -= 1을 손으로 적어야 하고, 빠뜨리면 무한루프가 됩니다.
자동으로 채워주는 구조일수록 실수할 자리가 줄어든다는 게 넷을 나란히 놓으면 보입니다.
불편을 먼저 보이는 글
두 편이 같은 방식으로 쓰였다는 점도 눈에 띕니다.
권준형 님은 print 다섯 줄을 먼저 보여주고 "천 번이면?"이라고 물었습니다. 이주희 님은 let index = 0으로 된 안 되는 코드를 통째로 올렸고요.
둘 다 도구보다 문제를 먼저 꺼냈습니다.
기술 글에서 흔한 순서는 반대입니다. 문법을 설명하고 예제를 붙이죠. 그러면 "이게 뭔지"는 남는데 "언제 쓰는지"는 안 남습니다.
불편을 먼저 겪게 하면 그 자리가 기억에 붙습니다. 다음에 비슷한 상황을 만났을 때 "아, 그때 그 불편"으로 떠오르니까요.
이번 회차에서 가져갈 것
1. 반복문을 쓰기 전에 손으로 몇 줄 써보기.
다섯 줄을 직접 써봐야 천 줄의 문제가 실감납니다. 문법을 먼저 외우면 쓸 자리를 못 찾습니다.
2. for와 while은 "목록이 있는가"로 가르기.
돌 것이 정해져 있으면 for, 끝날 조건만 있으면 while. while을 쓸 때는 조건을 바꾸는 줄을 빠뜨리지 않았는지 확인하세요.
3. 표준 함수 목록을 헤더별로 한 번 훑어두기.
외우려는 게 아니라 "그런 게 있었다"를 남기려는 것입니다. pow()가 있는 줄 모르면 곱셈을 반복문으로 돌리게 됩니다.
4. 컴파일 에러와 링크 에러를 구분하기.
헤더를 #include했는데도 실패하면 라이브러리 링크를 의심해보세요. math.h처럼 별도 옵션이 필요한 경우가 있습니다.
5. 리액트에서 화면이 안 바뀌면 일반 변수를 쓰고 있는지 보기.
값을 바꿔도 리액트는 모르고, 다시 그리면 초기화됩니다. useState는 값 보존과 갱신 신호를 한꺼번에 해결합니다.
2기 8회차는 2024년의 마지막 무렵이었습니다. 한 해를 정리하며 각자 진도를 이어가던 때예요.
파이썬 입문서와 C 교재와 리액트 공식 문서라는 서로 다른 자리에서, 세 분이 나란히 반복을 다루는 법을 기록했습니다. 도구는 다른데 변하는 자리에 이름을 붙인다는 발상은 똑같았고요.
좋은 글 남겨주신 권준형 님, 전일수 님, 이주희 님께 감사드립니다. 그리고 2기를 함께 채워주신 모든 멤버분들께도요! 😊
다음 큐레이션으로 다시 찾아오겠습니다! 🌱
- 에디터 · 성장일지 큐레이터 -
※ 본 큐레이션은 각 저자가 공개한 글을 소개하는 것이며, 모든 원문의 저작권은 저자에게 있습니다. 저자 본인의 요청이 있을 경우 즉시 수정 또는 삭제합니다.