안녕하세요! 그로스로그 입니다!😊 🌱
여섯 과목 별점 후기, "자바는 워크북이 사실상 족보", 그리고 학교 밖 강의 필기 7,700자. 학기가 끝난 자리에서 쓴 세 편입니다.
성장일지는 멤버들이 2주에 한 번씩 자신의 성장을 기록하는 활동이에요. 이번 글은 1회차에 이어 1기를 다시 읽는 두 번째 큐레이션입니다. 그때 담지 못한 글을 회차별로 하나씩 꺼내고 있어요.
1기 2회차, 2024년 6월입니다. 방통대 1학기 기말시험이 막 끝난 시점이라 "한 학기를 정리하는 글"이 몰려 있는 회차예요.
01
📊 24-1학기 후기
권준형 님
마지막 시험으로 학기가 끝난 뒤, 그 학기에 들은 여섯 과목을 별점과 함께 정리한 글입니다. 파이썬 프로그래밍, 운영체제, 데이터베이스시스템, 인공지능, 알고리즘, 그리고 복수전공으로 들은 통계학개론이에요.
시작이 솔직합니다. "이번 학기 역시 게으름으로 인해 시험 3주전까지 진도율 50% 정도밖에 되지 않았고, 결국 시험을 최대한 뒤로 미루고" 연휴 나흘을 집에 틀어박혀 공부했다고요.
그런데 후기 자체는 대단히 실용적입니다. 어떤 교수님이 어떻게 가르치는지, 교재만으로 되는 과목은 무엇인지, 어떤 과목을 먼저 들어야 하는지까지 적혀 있어요.
방통대에서 다음 학기 수강신청을 앞둔 분들이 가장 알고 싶어 하는 게 이런 정보입니다. 강의계획서에는 없거든요.
일과 공부를 함께 이어가는 사정이 글 전체에 깔려 있습니다. 게으름을 고백하는 문장도 그래서 엄살로 읽히지 않아요.
조금 더 들어가 보면
🧭 공식에 없는 선수과목
이 글에서 가장 값진 부분은 별점이 아니라 과목 사이의 관계를 짚은 대목입니다.
공식 선수과목이 아닌데 실질적으로는 선수과목인 관계입니다.
왜 이런 일이 생길까요. 두 과목의 목차를 비교하면 겹치는 항목이 거의 없습니다. 알고리즘은 정렬·탐색·동적 계획법을 다루고, 인공지능은 탐색 전략·지식 표현·기계학습을 다루니까요. 학사 안내에 선수과목으로 지정할 근거가 없습니다.
그런데 실제로 수업을 들으면 다릅니다. 인공지능의 상태공간 탐색은 알고리즘의 그래프 탐색과 같은 사고방식이고, 기계학습의 최적화는 알고리즘에서 다룬 반복·수렴 개념 위에 서 있어요. 내용이 겹치는 게 아니라 사고의 훈련량이 필요한 겁니다.
이런 관계는 목차 비교로는 절대 안 보입니다. 두 과목을 같은 학기에 듣고 고생해본 사람만 알 수 있어요. 권준형 님은 실제로 그 순서를 어겨서 고생했고, 인공지능 후반부의 신경회로망과 심층학습은 "반포기 상태로 과거 기출문제 답안을 그대로 외워서 시험을 보는 수준"이었다고 적었습니다.
그리고 그 경험을 다음 사람을 위한 조언으로 바꿔뒀습니다.
📖 교재로 되는 과목과 안 되는 과목
별점 자체보다 별점의 근거가 갈리는 지점이 흥미롭습니다.
운영체제(★★★★☆)에 대해서는 이렇게 적었어요.
교재 + 기출로 닫히는 과목입니다. 반면 알고리즘(★★★☆)은 사정이 달랐습니다.
그런데 결론이 반전입니다.
교재로 닫히는 과목과 강의로 닫히는 과목이 다르다는 겁니다. 이걸 모르고 알고리즘을 교재 중심으로 준비하면 순서가 안 맞아 헤매고, 운영체제를 강의만 듣고 기출을 안 풀면 시험에서 막힙니다.
과목마다 무엇에 시간을 써야 하는지가 다르다 — 학기가 끝나야만 정리되는 정보예요.
⭐ 별점은 누구를 위한 것인가
별점은 본인에게 아무 쓸모가 없습니다. 이미 그 과목을 들었으니까요. 오직 아직 안 들은 사람을 위한 표시입니다.
그런데 이 글의 별점에는 기준이 일정합니다. 파이썬(★★★★★)과 통계학개론(★★★★★)이 만점인데, 둘 다 이유가 같아요. 강의 밖의 무언가를 얹어줬다는 것.
파이썬은 "실제 현업에서 일을 하고 있는 개발자를 초청하여 산업의 현황이나 생태, 앞으로 개발자들이 어떤 자세와 지식을 갖추어야 생존할 수 있는지"를 다뤘고, 통계학개론은 이론이 아니라 R 실습이 만족스러웠다고 적었습니다.
반대로 별이 깎인 과목은 전부 구조적 불편 때문입니다. 파이썬은 만점이지만 "따로 교재가 없어 프린트물로 한 학기를 공부"한 점을 아쉬워했고, 알고리즘은 교재와 강의 순서 불일치였어요.
내용의 난이도로 별점을 매기지 않았습니다. 어렵다고 별을 깎지 않고, 재밌다고 무조건 올리지도 않았어요. 기준이 일정하면 읽는 사람이 자기 기준으로 환산할 수 있습니다.
📊 통계 수업에서 R을 처음 만나다
여섯 과목 중 하나가 통계학개론인데, 컴퓨터과학과 과목이 아닙니다. 그런데 이 글에서 만점을 받았어요. 이유가 이론이 아니라 실습 쪽이었습니다.
R은 통계 분석과 데이터 시각화를 위해 만들어진 언어입니다. 파이썬이 여러 일을 두루 하는 언어라면, R은 처음부터 데이터를 다루려고 설계됐어요. 그래서 평균·분산·회귀분석 같은 걸 함수 한 줄로 부를 수 있고, 그래프도 명령 하나로 나옵니다.
글에서 짚은 대목이 정확합니다.
이론과 구현을 같이 배운다는 게 핵심입니다. 카이제곱검정이 무엇인지 글로만 읽으면 시험이 끝나는 순간 잊습니다. 그런데 데이터를 넣고 함수를 돌려서 결과를 보면, 그 검정이 무엇을 판정하는 도구인지가 남아요.
그리고 마지막에 컴퓨터과학과 학생에게 이렇게 권합니다.
"코딩과 흡사한 UI"라는 표현이 재밌습니다. 프로그래밍을 배우는 사람 눈에는 R 콘솔이 익숙한 물건으로 보였다는 거예요. 실제로 R 스튜디오는 코드를 쓰고 실행하고 결과를 보는 구조라, IDE를 써본 사람이면 진입이 훨씬 쉽습니다.
전공 밖 과목에서 언어를 하나 더 얻어온 셈입니다. 그리고 이건 직접 들어본 사람만 알려줄 수 있는 정보예요. 과목명만 봐서는 통계학개론에서 프로그래밍을 배운다는 걸 알 수가 없으니까요.
📝 원문에서는 이렇게 마무리합니다
여섯 과목을 다 훑고 나서 총평이 이어집니다.
"조금만 어려워지면 넘겨버렸다"는 자기 진단이 정확합니다. 그리고 그게 별점이 낮았던 두 과목과 정확히 겹칩니다.
그다음 문단에서 학기 중 있었던 두 가지 변화를 적습니다. 통계데이터과학과 복수전공 신청, 그리고 그로스로그 가입이에요. 가입 이유를 적은 대목이 이 글에서 가장 오래 남습니다.
혼자 이론만 공부하는 상태가 1년쯤 이어졌을 때 무엇이 남는지를 정직하게 적었습니다. 열정이 식은 게 아니라, 배운 것을 쓸 데가 없었던 겁니다.
그리고 이렇게 이어집니다.
"활용하여 생각하고" "나눌 수 있게" — 두 개가 붙어 있습니다. 배운 것을 쓸 자리와 말할 상대, 둘 다 없었다는 뜻이에요.
큐레이터 노트
과목 후기는 성장일지에 자주 올라오는 형식입니다. 그런데 대부분 "어려웠다", "재밌었다"로 끝나요.
이 글이 다른 점은 판단 근거를 같이 남겼다는 겁니다. 왜 별 다섯인지, 왜 별 셋 반인지, 어떻게 하면 좋은 성적을 받는지, 그리고 무엇을 먼저 들어야 하는지까지요. 다음 학기 수강신청 화면 앞에서 실제로 쓸 수 있는 정보입니다.
그리고 게으름을 숨기지 않은 점. 진도율 50%에서 나흘 만에 따라잡은 이야기를 적어두면, 비슷한 상황에 놓인 사람이 자기만 그런 게 아니라는 걸 알게 됩니다. 일하면서 공부하는 분들이 많은 학교에서, 이건 생각보다 중요한 정보예요.
02
📚 컴퓨터과학과 2학년 1학기 마무리
임준혁 님
"컴과 학과 공부나 개발 공부 블로그 글 작성은 이번이 처음"이라는 문장으로 시작하는, 임준혁 님의 첫 기술 블로그 글입니다.
전공 세 과목(Java 프로그래밍, HTML5 웹 프로그래밍, 이산수학)과 교양 세 과목을 다루는데, 형식이 특이합니다. 과목마다 「수강후기」와 「과목 공부 팁」을 따로 나눠서 씁니다.
그리고 학교 수업과 현업의 거리에 대해, 듣기 편하지 않은 관찰까지 그대로 적었습니다.
첫 글인데 구조가 잡혀 있습니다. 여섯 과목이 전부 같은 틀로 정리돼 있어요.
조금 더 들어가 보면
🗂️ 후기와 팁을 나누면 무엇이 달라지나
같은 내용을 한 덩어리로 쓸 수도 있었을 텐데, 왜 나누는 게 나을까요.
두 정보의 독자가 다르기 때문입니다.
「수강후기」는 아직 신청하지 않은 사람이 봅니다. 이 과목이 어떤 과목인지, 재미있는지, 내 진로에 맞는지를 알고 싶어 해요. 「과목 공부 팁」은 이미 신청해놓고 시험을 앞둔 사람이 봅니다. 무엇을 봐야 하고 무엇은 건너뛰어도 되는지가 궁금하죠.
두 정보를 섞어 쓰면 양쪽 다 손해입니다. 수강 여부를 고민하는 사람은 공부법 얘기를 스크롤로 넘겨야 하고, 시험을 앞둔 사람은 과목 소개를 지나쳐야 해요. 읽는 사람이 자기에게 필요한 부분만 골라 읽지 못합니다.
나눠두면 목차만 훑고도 필요한 칸으로 바로 갈 수 있습니다. 첫 블로그 글에서 이 구조를 잡은 게 인상적이에요.
그리고 이 틀은 과목 후기 말고도 씁니다. 프로젝트 회고를 "이런 프로젝트였다"와 "다시 한다면 이렇게 하겠다"로 나누면 똑같이 동작해요.
📕 "워크북이 사실상 족보다"
「팁」쪽에 실제로 쓸 만한 정보가 몰려 있습니다. Java 프로그래밍에서는 스터디에서 만난 선배의 말을 그대로 옮겼어요.
그런데 여기에 조건을 붙입니다.
목표에 따라 다른 답을 줬습니다. "워크북만 보면 된다"가 아니라 "최소 투자로 최대 점수를 원한다면"이라는 전제를 달았어요.
이게 왜 중요하냐면, 조건 없는 공부법 조언은 누군가에게는 반드시 틀리기 때문입니다. 전공을 깊이 파려는 사람에게 "워크북만 보면 된다"고 하면 손해를 끼치고, 학점만 필요한 사람에게 "전부 풀어라"라고 하면 시간을 낭비하게 합니다. 전제가 붙는 순간 읽는 사람이 자기가 어느 쪽인지 판단해서 골라 쓸 수 있게 됩니다.
🔄 자기가 배운 공부법에 반대되는 결론
이산수학 항목이 더 흥미롭습니다.
배운 대로 하지 않은 쪽이 더 나았다고 적은 겁니다. 보통 이런 건 안 씁니다. 정석대로 하지 않았다고 말하는 셈이니까요.
그런데 이분은 적고, 그 방식이 이산수학에도 그대로 통했다고 이어갑니다. 그리고 여기에도 조건을 답니다.
"~할 생각이 있는 게 아니라면"이 붙는 순간, 이건 변명이 아니라 판단이 됩니다. 깊이 갈 사람에게는 권하지 않는다는 뜻을 분명히 했으니까요.
🎒 안 들어도 된다고 말하는 후기
이 글에는 과목을 권하지 않는 문장도 있습니다.
이산수학에 대해서는 "현업 개발과는 연관성이 떨어지는 만큼 편입으로 학교에 들어와서 빠르게 졸업할 생각이라면 안 듣는 것을 추천"한다고 적었고, 교양 과목 하나에 대해서는 이렇게 썼어요.
또 다른 교양 과목은 "호불호가 갈리는 만큼 본인이 자신 있다면 (…) 적극적인 선택을 권장하지만 그게 아니라면 다른 교양과목으로 변경하면 된다"로 정리했습니다.
후기를 쓰면서 "이건 굳이 안 들어도 된다"고 적는 건 드뭅니다. 자기가 들인 시간을 스스로 깎는 셈이니까요. 대개는 "그래도 배운 게 있었다"로 마무리합니다.
그런데 이렇게 적어야 후기가 선택에 쓰입니다. 모든 과목이 다 좋았다고 적힌 후기는 읽고 나서도 무엇을 고를지 알 수 없어요. 권하는 것과 권하지 않는 것이 갈려 있어야 비로소 목록이 지도가 됩니다.
그리고 각 조언에 누구에게 해당하는지가 붙어 있습니다. "빠르게 졸업할 생각이라면", "본인이 자신 있다면". 무조건 듣지 말라고 하지 않아요. 같은 과목이 어떤 사람에게는 효자 과목이고 어떤 사람에게는 부담이라는 걸 알고 쓴 문장입니다.
교양 과목 후기를 굳이 넣은 이유도 그래서 납득이 됩니다. 편입으로 들어오면 전공보다 교양 학점을 채우는 게 더 막막하거든요. 자기가 막막했던 자리를 기억하고 쓴 겁니다.
📝 원문에서는 이렇게 말합니다
이 글에서 가장 눈에 남는 대목은 HTML5 과목 후기입니다.
증언이 세 개 나란히 놓입니다. 선배, 튜터, 동기. 그리고 그중 둘이 같은 방향이고 하나가 반대예요. 자기 판단만 적지 않고 근거를 나열한 겁니다.
수업에 대해 이렇게 쓰는 건 쉽지 않습니다. 그런데 이분은 냉소로 끝내지 않아요. 마지막 문단에서 이렇게 정리합니다.
차이가 있다는 것과 쓸모가 없다는 것은 다르다. 이 구분을 2학년 1학기에 내려두고, 그 위에서 다음 계획을 세웁니다.
그리고 교양과목 후기를 왜 썼는지도 밝힙니다.
첫 글부터 읽을 사람을 정해놓고 썼다는 뜻입니다.
큐레이터 노트
첫 블로그 글에 여섯 과목을 같은 틀로 정리한 것부터가 놀랍습니다. 보통 첫 글은 "블로그를 시작합니다"로 끝나거든요.
고른 이유는 불편한 관찰을 적었기 때문입니다. 학교 수업과 현업의 거리는 자주 나오는 이야기인데, 대개 말로 끝나고 기록으로는 잘 안 남습니다. 남더라도 불평으로 남지 판단으로 남지는 않고요.
이 글은 관찰을 적고, 여러 사람의 증언을 나란히 놓고, 결론을 냈습니다. 그리고 그 결론이 균형 잡혀 있어요. 학교의 몫을 축소하지도, 과장하지도 않습니다.
03
🍃 Spring Boot 강의 필기
형기상 님
7,729자짜리 강의 필기입니다. 학교 과목이 아니라 스프링 부트와 JPA로 웹 애플리케이션을 만드는 외부 강의를 들으며 정리한 기록이에요.
start.spring.io에서 프로젝트를 만드는 것부터 시작해 VS Code 확장 설치, 의존성 선택, H2 데이터베이스 설정, application.yml 옵션, 엔티티 어노테이션, 그리고 엔티티 설계 시 주의사항까지 순서대로 이어집니다.제목은 "필기"인데, 읽어보면 재현 가능한 설정 문서에 가깝습니다.
이 글이 2회차에 있다는 게 의미심장합니다. 학교 학기가 끝난 그 주에, 학교 밖 강의 필기를 올렸거든요.
조금 더 들어가 보면
📓 남이 읽을 수 있는 필기와 아닌 필기
강의 필기는 보통 자기만 알아볼 수 있게 씁니다. 화살표와 약어와 "이거 중요"로 채워지죠. 그런 필기는 시간이 지나면 본인도 못 읽습니다.
이 글이 다른 점은 설정값이 그대로 들어 있다는 겁니다. 예를 들어 개발 중 파일을 고치면 서버가 자동으로 다시 뜨게 하는 설정이 이렇게 적혀 있어요.
build.gradle > dependencies에 추가 implementation 'org.springframework.boot:spring-boot-devtools' application.properties에 옵션 추가 spring.devtools.livereload.enabled=true spring.freemarker.cache=false spring.thymeleaf.cache=false
이 세 줄이 왜 같이 있어야 하는지가 중요합니다. devtools는 자바 코드가 바뀌면 서버를 다시 띄워줍니다. 그런데 HTML 템플릿은 서버를 다시 안 띄워도 되니까 대상이 아니에요. 대신 스프링이 성능을 위해 템플릿을 한 번 읽고 메모리에 캐시해둡니다.
그래서 캐시를 꺼두지 않으면 이런 일이 생깁니다. HTML을 고치고 새로고침해도 예전 화면이 그대로 뜹니다. 코드는 분명 바꿨는데요. 처음 스프링을 하면 여기서 한참 헤맵니다. 오타를 찾고, 경로를 의심하고, 브라우저 캐시를 지워보다가, 결국 서버를 껐다 켜면 되는 걸 발견하죠.
세 줄을 같이 적어둔 필기가 그 한나절을 없애줍니다.
⚡ N+1 문제와 지연 로딩
필기 후반부에 실무 주의사항이 나옵니다.
즉시 로딩: 테이블을 조회할 때 연관된 내용을 한번에 조회
- 예측이 어렵다
- 어떤 SQL이 실행될지 추적이 어렵다
- 특히 JPQL을 실행할 때 N + 1문제가 자주 발생
N+1 문제는 JPA를 쓰면 거의 반드시 한 번은 만나는 함정입니다. 이름 그대로 쿼리가 1개 + N개 나가는 상황이에요.
주문 목록을 가져온다고 해봅시다. select from orders로 주문 10건을 읽습니다. 이게 1입니다. 그런데 화면에 주문자 이름도 띄워야 해서 각 주문의 회원 정보가 필요해요. 즉시 로딩이 걸려 있으면 JPA가 주문 하나마다 select from member where id = ?를 날립니다. 그게 N, 여기서는 10개예요.
쿼리 하나를 부른 줄 알았는데 열한 개가 나갑니다. 주문이 100건이면 101개고요.
무서운 건 개발할 때는 안 보인다는 점입니다. 테스트 데이터가 열 건뿐이면 쿼리 열한 개가 나가도 눈 깜짝할 사이에 끝나요. 데이터가 쌓이고 나서야 갑자기 느려집니다. 그리고 그때는 원인을 찾기 어렵습니다. 코드 어디에도 반복문으로 조회하는 부분이 없거든요.
즉시 로딩(EAGER)이 위험한 이유가 이겁니다. 편해 보이는데 언제 어떤 쿼리가 나갈지 코드만 봐서는 예측이 안 됩니다. 그래서 실무에서는 전부 지연 로딩으로 두고, 필요한 곳에서만 명시적으로 함께 가져오는 방식을 씁니다.
강의를 들으며 이 대목에 "(중요)"를 붙여 적어둔 것 — 나중에 본인이 이 필기를 다시 열었을 때 가장 먼저 눈에 들어올 부분입니다.
🔒 Setter를 열지 않는 이유
엔티티 설계 주의사항 첫 항목이 Setter 이야기입니다.
변경 포인트가 많으면 유지보수에 어려움 발생. 리팩토링을 통해서라도 꼭 제거가 필요
그리고 엔티티 클래스 항목에는 이렇게 적혀 있어요.
읽기는 열고 쓰기는 좁힌다 — 이게 원칙입니다. 값을 읽는 건 어디서 하든 사고가 안 나지만, 값을 바꾸는 통로가 여러 개면 "누가 언제 왜 바꿨는지"를 추적할 수 없게 됩니다.
JPA에서는 이게 더 심각합니다. 4회차 큐레이션에서 다룰 변경 감지 때문인데요. 영속성 컨텍스트가 관리하는 엔티티는 필드값만 바꿔도 트랜잭션이 끝날 때 UPDATE 쿼리가 나갑니다. save()를 부르지 않아도요.
즉, 아무 데서나 order.setStatus(...)를 호출할 수 있으면 의도치 않은 곳에서 데이터가 바뀝니다. 그것도 조용히요. 그래서 cancel()이나 complete() 같은 의미 있는 메서드만 열어두고 그 안에서 값을 바꾸게 합니다. 그러면 상태 변경이 반드시 그 메서드를 거치니 추적이 됩니다.
스프링과 JPA를 넘어 객체를 다루는 원칙에 가까운 이야기예요.
📝 원문에서는 이렇게 적습니다
H2 데이터베이스 설정 부분에 주석이 촘촘합니다.
spring:
datasource:
url: jdbc:h2:tcp://localhost/.../jpashop;MVCC=TRUE
driver-class-name: org.h2.Driver
jpa:
hibernate:
ddl-auto: create # 자동으로 테이블을 생성하는 모드
properties:
hibernate:
format_sql: true
logging:
level:
org.hibernate.SQL: debug
org.hibernate.type: trace # SQL문의 파라미터 값을 알 수 있음
마지막 두 줄이 개발 중에 가장 자주 쓰게 되는 설정입니다.
org.hibernate.SQL: debug를 켜면 JPA가 실제로 날리는 SQL이 콘솔에 찍힙니다. JPA는 쿼리를 대신 만들어주니까, 내가 짠 코드가 어떤 SQL이 되는지 보이지 않으면 성능 문제를 찾을 수 없어요. 앞서 말한 N+1도 이 로그를 켜야 보입니다. 같은 select가 열 번 찍히는 게 눈에 들어오거든요.
org.hibernate.type: trace는 한 걸음 더 갑니다. SQL만 찍으면 조건 부분이 where id = ?처럼 물음표로 나오는데, 이걸 켜면 그 물음표에 실제로 들어간 값까지 보입니다. 필기에 "SQL문의 파라미터 값을 알 수 있음"이라고 적어둔 게 이겁니다.
그리고 ddl-auto: create에 붙은 주석도 눈여겨볼 만합니다.
앱을 켤 때마다 테이블을 지우고 새로 만든다는 뜻입니다. 개발 초기에는 편해요. 엔티티를 고칠 때마다 테이블 구조가 알아서 따라오니까요. 대신 넣어둔 데이터가 전부 사라집니다. 이 옵션을 운영 서버에 그대로 올리면 배포할 때마다 데이터가 날아갑니다.
주석 한 줄이 그 사고를 막습니다.
큐레이터 노트
필기를 큐레이션에 넣는 게 맞나 싶을 수 있습니다. 새로 알아낸 것이 아니라 강의를 옮겨 적은 것이니까요.
그런데 이 글은 옮겨 적는 방식이 다릅니다. 설정 파일 내용이 그대로 있고, 어노테이션마다 무슨 역할인지가 붙어 있고, 주의사항에는 이유가 적혀 있어요. 강의를 듣지 않은 사람이 읽어도 따라갈 수 있는 형태입니다. 자기 노트에서 문서로 한 발 넘어온 셈이에요.
그리고 이 글은 시작점이라서 의미가 있습니다. 형기상 님은 이 필기 이후 프로젝트 필기, Spring Data JPA, Querydsl로 이어가고, 마지막 회차에서는 결국 자기 개인 프로젝트의 서버 구성도를 그립니다.
4회차와 6회차 큐레이션에서 다시 만나실 겁니다. 필기가 설계로 바뀌는 과정을 보시면 좋겠습니다.
💡 세 편을 겹쳐 읽으며
세 글의 형식이 전부 다릅니다. 별점 후기, 과목별 팁 정리, 강의 필기.
그런데 세 분이 서 있는 자리가 같습니다. 학교에서 배운 것만으로는 부족하다는 자리예요.
권준형 님은 이걸 감정으로 먼저 겪었습니다. 1년 동안 이론만 공부하니 회의감과 지루함이 쌓였다고 적었어요. 임준혁 님은 관찰로 확인했습니다. 선배도, 동기도, 학교 수업과 현업의 거리를 말하더라는 거죠. 형기상 님은 아예 말을 하지 않습니다. 그냥 학교 밖 강의 필기를 올립니다.
같은 자리에 서서 셋 다 다른 쪽으로 움직였습니다.
권준형 님은 사람을 찾았습니다. 배운 걸 쓸 자리와 말할 상대가 없다는 게 문제였으니 모임에 들어갔어요. 임준혁 님은 몫을 나눴습니다. 학교는 기초를 주는 곳이고 심화는 따로 해야 한다고 정리하고, 그 위에서 다음 공부 방향을 정했습니다. 형기상 님은 바로 실무 스택으로 갔습니다. 스프링 부트와 JPA를 학기 끝나자마자 시작했어요.
셋 중에 정답은 없습니다. 다만 셋 다 학기가 끝난 그 자리에서 판단을 내렸다는 게 눈에 띕니다. 학기 중에는 진도를 따라가느라 이런 결정을 할 여유가 없고, 방학이 지나면 흐지부지되기 쉽거든요. 성장일지 2주 주기가 마침 그 시점에 걸린 셈입니다.
그리고 세 글에 공통으로 조건이 붙어 있습니다. "인공지능을 들으려면 알고리즘을 먼저", "고득점만 필요하다면 공식 암기로", "실무에서는 가급적 Setter를 열지 않고". 전부 누구에게 언제 해당하는지를 함께 적었어요. 첫 기수 두 번째 회차 글치고 태도가 일관됩니다.
이번 회차에서 가져갈 것
1. 후기와 팁을 나눠 쓰기.
임준혁 님이 과목마다 「수강후기」와 「과목 공부 팁」을 분리한 방식입니다. 읽는 사람의 상황이 다르니까요. 프로젝트 회고도 "이런 프로젝트였다"와 "다시 한다면"으로 나누면 똑같이 동작합니다.
2. 공식에 없는 선수관계를 남기기.
"인공지능은 알고리즘을 먼저 듣고 오세요"는 학사 안내 어디에도 없습니다. 순서를 어겨서 고생해본 사람만 알아요. 지금 배우는 것 중에 "이걸 먼저 알았으면 훨씬 쉬웠을 텐데" 싶은 게 있다면, 그게 남길 값어치가 있는 정보입니다.
3. 조건을 붙여서 조언하기.
"워크북만 보면 된다"가 아니라 "최소 투자로 최대 점수를 원한다면". 조건이 없는 조언은 누군가에게 반드시 틀립니다. 조건이 붙는 순간 읽는 사람이 자기가 어느 쪽인지 판단해서 골라 쓸 수 있게 됩니다.
4. 자기 경험에 반하는 결론도 적기.
임준혁 님은 "유형을 많이 풀라"고 배웠지만 공식 암기가 더 나았다고 적었습니다. 정석과 다른 결론은 쓰기 껄끄러운데, 조건을 달면 변명이 아니라 판단이 됩니다.
5. 필기에 설정값과 이유를 같이 남기기.
형기상 님의 필기에는 application.yml이 그대로 있고, 각 옵션에 무엇을 하는지가 붙어 있습니다. 같은 시간을 들여 적는데, 이렇게 적으면 6개월 뒤의 나와 처음 보는 사람이 함께 읽을 수 있는 문서가 됩니다.
1기는 그로스로그의 첫 기수였습니다. 학기가 끝나고 방학이 시작되는 구간에 활동이 걸쳐 있었어요.
방학은 보통 기록이 비는 시기입니다. 학교 일정이 없으니 정리할 것도 없거든요. 그런데 2주에 한 번 무언가를 써야 하니, 오히려 그 시기에 "학기를 어떻게 보냈고 다음에 뭘 할까"를 적게 됐습니다. 세 편 다 그 자리에서 나온 글입니다.
좋은 글 남겨주신 권준형 님, 임준혁 님, 형기상 님께 감사드립니다. 그리고 아무 전례도 없던 첫 기수에서 묵묵히 기록을 이어가주신 모든 1기 멤버분들께도요! 😊
다음 큐레이션으로 다시 찾아오겠습니다! 🌱
- 에디터 · 성장일지 큐레이터 -
※ 본 큐레이션은 각 저자가 공개한 글을 소개하는 것이며, 모든 원문의 저작권은 저자에게 있습니다. 저자 본인의 요청이 있을 경우 즉시 수정 또는 삭제합니다.
'성장일지' 카테고리의 다른 글
| [GL 1기 4회차] 맡긴 만큼 안 보인다 — 영속성 컨텍스트, Spring Data JPA, 상태관리 도구 🌱 (0) | 2026.08.09 |
|---|---|
| [GL 1기 3회차] 경계를 먼저 긋지 않으면 — 언리얼의 메시와 충돌, Redux 상태 동기화, 쇼핑몰 첫걸음 🌱 (0) | 2026.08.09 |
| [GL 1기 1회차] 접었던 블로그를 다시 연 세 사람 — 사진 3요소, 깃허브 학생 인증, 완주 다짐 🌱 (0) | 2026.08.09 |
| [GL 3기 8회차 ①] 같은 약자 다른 뜻 — CSR 렌더링과 인증서, 그리고 타입스크립트 🌱 (0) | 2026.08.07 |
| [GL 3기 7회차 ②] 만들기 전에 고르는 것 — 앱 개발 방식 선택, ArrayList와 LinkedList 🌱 (0) | 2026.08.07 |