안녕하세요! 그로스로그 입니다!😊 🌱
기능은 없고 설정만 있는 서버, 코드 한 줄 쓰지 않은 프로젝트 참여기, 화면 없이 정한 색과 글꼴. 본론 앞에 있는 것들입니다.
성장일지는 멤버들이 2주에 한 번씩 자신의 성장을 기록하는 활동이에요. 이번 글은 1기를 다시 읽는 여섯 번째 큐레이션입니다.
6회차는 2024년 8월 10일이었습니다. 1기 마지막 회차를 2주 앞둔 시점이에요.
01
🏗️ 개인프로젝트_서버 구상
형기상 님
강의 필기만 네 편을 이어오던 분이, 처음으로 자기 프로젝트의 설계도를 그린 글입니다.
구성은 이렇습니다. 프론트는 React + TypeScript, 백엔드는 Spring Boot 3, 그리고 그 앞에 Nginx 프록시를 둬서 URL에 따라 둘 중 하나로 보냅니다. 셋 다 각각 도커 컨테이너로 띄우고 docker-compose로 묶어요.
Dockerfile 세 개, nginx.conf, application.yml, docker-compose.yml이 전부 그대로 들어 있습니다.2회차 큐레이션에서 이분의 「Spring Boot 강의 필기」를, 4회차에서 「Spring Boot Data JPA」를 소개해드렸습니다. 둘 다 강의를 들으며 정리한 글이었어요.
이번 글에는 강의가 없습니다. 처음부터 끝까지 자기가 정한 구성입니다.
조금 더 들어가 보면
이 구성에서 가장 눈여겨볼 부분은 Nginx를 앞에 세운 이유입니다.
React로 만든 화면은 3000번 포트에서 돌고, Spring Boot는 8080번 포트에서 돕니다. 사용자가 브라우저로 접속할 때 이 둘을 어떻게 하나처럼 보이게 할까요? 포트 번호를 알려줄 수는 없으니까요.
Nginx가 그 앞에 서서 주소를 보고 갈라줍니다.
location / → 프론트엔드(3000)
/api로 시작하면 서버로, 나머지는 전부 화면으로 보냅니다. 사용자는 포트 하나만 보고, 뒤에 몇 개가 돌고 있는지 몰라도 됩니다.
그리고 도커 이미지를 만드는 방식에 대한 판단이 하나 적혀 있는데, 이게 경험에서 나온 대목입니다.
가장 기본이 되는 초기화 상태를 구성. 이후에 비슷한 환경에서 개발 할 경우에는 초기화 상태를 가져다가 사용
프레임워크가 이미 깔린 이미지를 쓰지 않고, 그게 돌아갈 수 있는 환경만 만들어둔다는 겁니다. 그러면 다음 프로젝트에서 프레임워크 버전이 달라도 같은 바탕을 재사용할 수 있어요. 한 번 쓰고 버릴 설정이 아니라 다음번을 생각한 설계입니다.
application.yml에 달아둔 주석 하나도 그렇습니다.
# Docker Container에서 연결하려는 DB를 모르기 때문에 미리 dialect 설정
보통은 Hibernate가 데이터베이스에 접속해서 종류를 알아서 판단합니다. 그런데 도커 안에서는 접속이 늦거나 실패할 수 있어서, 미리 못 박아두는 것이 안전해요. 이런 건 한 번 겪어봐야 아는 설정입니다.
📝 원문에서는 이렇게 구성합니다
docker-compose.yml에서 백엔드 서비스 부분이 이렇습니다.
backend_local:
build: ./backend
container_name: backend_local
ports:
- 8080:8080
volumes:
- ./backend/프로젝트이름:/app
restart: always
environment:
SPRING_DATASOURCE_URL: jdbc:mysql://host.docker.internal:3306/DB이름
TZ: Asia/Seoul
# command: java -jar app.jar
command: ./gradlew bootRun
주석 처리된 줄이 눈에 띕니다. java -jar app.jar는 배포할 때 쓰는 명령이고, ./gradlew bootRun은 개발할 때 쓰는 명령이에요. 지금은 개발 중이니 후자를 켜두고 전자는 남겨뒀습니다.
host.docker.internal도 중요한 부분입니다. 컨테이너 안에서 localhost라고 쓰면 그건 컨테이너 자기 자신을 가리킵니다. 내 컴퓨터에 깔린 MySQL에 붙으려면 이 특별한 주소를 써야 해요. 도커를 처음 쓰면 반드시 한 번 막히는 지점입니다.
🔌 컨테이너끼리는 이름으로 부른다
그런데 nginx.conf를 보면 주소를 쓰는 방식이 또 다릅니다.
upstream backend_local {
server backend_local:8080;
}
upstream frontend_local {
server frontend_local:3000;
}
IP가 아니라 backend_local이라는 이름입니다. 그리고 이 이름은 docker-compose.yml에 적힌 서비스 이름과 같아요.
도커 컴포즈로 여러 컨테이너를 함께 띄우면 같은 네트워크에 묶이고, 서비스 이름이 곧 주소가 됩니다. 그래서 nginx 컨테이너에서 backend_local:8080이라고 쓰면 백엔드 컨테이너로 갑니다.
이게 왜 편하냐면, 컨테이너 IP는 다시 띄울 때마다 바뀌기 때문입니다. IP를 하드코딩하면 재시작할 때마다 설정을 고쳐야 해요. 이름으로 부르면 그럴 일이 없습니다.
정리하면 이 프로젝트 안에 세 가지 주소 방식이 공존합니다.
| 쓰는 곳 | 주소 | 가리키는 것 |
|---|---|---|
| nginx → 백엔드·프론트 | backend_local:8080 |
같은 네트워크의 다른 컨테이너 |
| 백엔드 → DB | host.docker.internal:3306 |
컨테이너 밖, 내 컴퓨터 |
| 브라우저 → nginx | localhost:80 |
내 컴퓨터에 열린 포트 |
어디서 부르느냐에 따라 같은 대상의 주소가 다릅니다. 도커를 처음 다룰 때 가장 헷갈리는 부분이고, 이 세 줄이 설정 파일에 흩어져 있어서 한눈에 보이지도 않아요. 그래서 이 구성도를 글로 남겨둔 게 값집니다.
큐레이터 노트
이 글은 혼자서는 의미가 절반인 글입니다. 앞의 네 편과 같이 봐야 해요.
형기상 님의 1기 다섯 편은 이렇게 이어집니다.
| 회차 | 글 | 성격 |
|---|---|---|
| 2회차 | Spring Boot 강의 필기 | 강의를 따라감 |
| 3회차 | Spring Boot 프로젝트 필기 | 강의를 따라감 |
| 4회차 | Spring Boot Data JPA | 강의를 따라감 (11,361자) |
| 5회차 | Spring Boot Querydsl | 강의를 따라감 |
| 6회차 | 개인프로젝트_서버 구상 | 자기가 정함 |
네 편의 필기 뒤에 설계가 나옵니다. 그리고 그 설계에 앞서 배운 것들이 그대로 들어가 있어요. Data JPA도, Querydsl도, DevTools 설정도 전부 앞 편에서 정리한 것들입니다. 4회차 필기에 남겨뒀던 "동적 쿼리는 어떻게?"라는 물음표의 답이 5회차 Querydsl이었고, 그게 이 구성의 의존성 목록에 올라와 있습니다.
배운 것이 언제 자기 것이 되는지를 묻는다면, 이 다섯 편이 하나의 답입니다. 자기 프로젝트의 설정 파일에 그 항목이 들어갈 때요.
그리고 이 글에는 앞 네 편에 없던 것이 있습니다. 선택입니다.
강의 필기에는 선택이 없어요. 강사가 정한 대로 따라가면 됩니다. 그런데 이 글에는 정할 것이 계속 나옵니다. 프론트를 무엇으로 할지, 프록시를 둘지 말지, 도커 이미지를 어떤 단위로 만들지, 개발 모드와 배포 모드를 어떻게 나눌지.
그 선택마다 이유가 붙어 있는 것도 아닙니다. 대부분 그냥 정해져 있어요. 하지만 정했다는 것 자체가 앞 네 편과의 차이입니다.
배운 것을 쓰는 단계와 배운 것으로 정하는 단계는 다릅니다. 후자에서는 틀릴 수 있거든요. 강의를 따라갈 때는 틀릴 일이 없습니다.
02
📋 [Growth Log] 1기 6차
권준형 님
커뮤니티 안에서 한 달간 진행한 웹 크롤러 개발 프로젝트 참여기입니다. 방송통신대 소프트웨어 경진대회 출품이 목표였고, 마감까지 한 달이 채 안 되는 일정이었어요.
그런데 이 글은 개발기가 아닙니다. 글쓴이는 코드를 한 줄도 쓰지 않았거든요. "개발에 대해서는 거의 관여하지 못했다"고 스스로 적었습니다.
대신 학교에 제출할 설명 자료를 만들었고, 그 과정에서 프로젝트 전체를 이해하게 된 이야기를 남겼습니다.
성장일지에 이렇게 쓰기가 쉽지 않습니다.
개발자 커뮤니티의 기록에, 개발을 못 했다고 적는 겁니다.
조금 더 들어가 보면
기술 해설 대신, 이 글이 프로젝트에 대해 남긴 것을 정리해보겠습니다.
웹 크롤러는 웹사이트에 등록된 업체나 필요한 정보를 자동으로 수집해 분석 자료로 만들어주는 프로그램입니다. 예를 들어 특정 산업군을 고르면 웹에서 관련 데이터를 모아 보여주는 식이에요.
일정이 빠듯했고, 참여자들의 개인 사정이 겹쳤습니다. 그래서 실제로는 이렇게 됐습니다.
이 두 문장을 저희가 오래 들여다봤습니다.
1기 성장일지를 다시 읽으면서 확인한 것이 있습니다. 한대천 님이 남기신 원문은 지금 열리지 않습니다. 개인 서버에 블로그를 두셨는데 그 주소가 응답하지 않아요. 소개해드리고 싶어도 읽을 글이 없습니다.
그런데 그분이 그 한 달 동안 무엇을 했는지는 다른 사람의 글에 남아 있습니다. 자기 기록은 사라졌는데 남의 기록에는 남은 거예요.
📝 원문에서는 이렇게 마무리합니다
설명 자료를 만든 것이 어떤 의미였는지를 이렇게 적었습니다.
설명 자료를 만드는 일이 곧 이해하는 일이었습니다.
남에게 설명할 수 있게 정리하려면 기획 배경도, 목적도, 처리 흐름도, 기대 효과도 알아야 합니다. 모르는 채로는 한 장도 못 만들어요. 개발을 못 해서 맡은 일이었는데, 결과적으로는 프로젝트 전체를 훑는 자리였던 겁니다.
📐 설명 자료가 요구하는 것
이게 왜 이해로 이어지는지는 설명 자료가 무엇을 요구하는지를 보면 알 수 있습니다.
코드를 읽는 것은 부분을 아는 일입니다. 이 함수가 무엇을 하는지, 저 클래스가 어떤 값을 들고 있는지요. 그런데 설명 자료는 부분으로는 한 장도 못 채웁니다. "이 프로그램은 무엇을 위한 것인가"에 답해야 하고, 그러려면 부분들이 어떻게 연결되는지를 알아야 해요.
글에서 만든 자료의 항목이 그걸 보여줍니다.
프로세스 · 사용법 · 화면 · 기대효과. 네 가지 다 "이 코드가 무엇을 하는가"가 아니라 "이 프로그램이 누구에게 무엇을 해주는가"를 묻습니다.
그리고 이 질문들은 개발자에게도 어렵습니다. 만드는 데 몰두하면 오히려 안 보이거든요. 못 채우는 칸이 곧 아직 정해지지 않은 것이고, 그래서 설명 자료를 만들다 보면 팀이 놓친 부분이 드러납니다.
개발을 못 하는 사람이 맡았기 때문에 오히려 잘된 면도 있습니다. 아는 게 없으니 전부 물어봐야 했고, 물어보는 과정에서 설명하는 쪽도 정리가 되니까요.
그리고 마지막 문장이 담담합니다.
"단 한 줄의 코드라도" — 목표를 이렇게 잡는 사람은 그만두지 않습니다.
🧾 커뮤니티 프로젝트의 실제 모습
이 글에는 프로젝트 후기에서 잘 안 보이는 문장들이 있습니다.
한 달 미만의 일정, 참여자 이탈, 한 사람에게 몰린 개발. 세 가지가 다 적혀 있습니다.
이게 커뮤니티 프로젝트에서 드문 일이 아닙니다. 모인 사람 모두가 본업이 있고, 학기 중이고, 각자 사정이 생기니까요. 출품 마감 같은 외부 일정이 걸리면 조정할 여지도 없고요.
그런데 이런 내용은 후기에 잘 안 남습니다. 완성된 결과만 적는 게 자연스러우니까요. "무엇을 만들었고 어떤 기술을 썼다"로 마무리하면 깔끔하고, 굳이 사람이 빠졌다는 말을 쓸 이유도 없습니다.
문제는 그렇게 남은 기록만 보면 다음에 프로젝트를 여는 사람이 잘못된 계획을 세운다는 겁니다. 다들 잘 굴러간 것처럼 보이니 인원과 일정을 낙관적으로 잡게 되죠.
이 글은 그 반대의 정보를 남겼습니다. 한 달은 짧고, 사람은 빠지고, 결국 누군가 몰아서 하게 된다는 것. 다음 프로젝트를 여는 사람에게는 성공담보다 이쪽이 더 쓸모 있습니다.
그리고 그 상황에서 자기가 할 수 있는 일을 찾아 맡았다는 것도요. 빠지지 않고, 코드를 못 쓴다고 손 놓지도 않고, 설명 자료를 만들었습니다.
큐레이터 노트
이 글을 고른 이유는 커뮤니티에서 실제로 일어나는 일을 기록했기 때문입니다.
프로젝트 후기는 대개 성공담으로 남습니다. 무엇을 만들었고 어떤 기술을 썼고 얼마나 배웠는지요. 이 글은 다릅니다. 일정이 촉박했고, 사람들이 빠졌고, 한 사람이 거의 다 했고, 자기는 코드를 못 썼다고 적혀 있어요.
그런데 그게 커뮤니티 프로젝트의 실제 모습입니다. 다들 본업이 있고 학기 중이니까요. 이렇게 적힌 기록이 있어야 다음에 프로젝트를 여는 사람이 현실적인 계획을 세울 수 있습니다.
그리고 하나 더. 이 글에는 감사 인사가 세 번 나옵니다. 한대천 님께 두 번, 팀원 전체에게 한 번이요. 자기가 못 한 일을 한 사람의 이름을 정확히 적어둔 글입니다.
기록이 왜 중요한지에 대해, 저희가 이 회차에서 가장 많이 생각한 부분이었습니다.
03
🎨 피그마_페이지의 기본 스타일 설정
이지은 님
스터디 프로젝트의 디자인 기본값을 정하는 작업 기록입니다. 화면을 그리기 전에 색과 글꼴부터 정하는 단계예요.
색상 팔레트를 만들기 위해 피그마 플러그인 두 개를 써보고 하나를 고릅니다. Tailwind 플러그인은 "팔레트 생성이 없네. 안 멋지니깐 아웃~"으로 탈락시키고, Foundation Color Generator를 씁니다.
그리고 이 프로젝트에 왜 헤더 글꼴을 많이 설정했는지, 그 판단 근거도 적었습니다.
3·4·5회차 큐레이션에 이어 네 번째로 만나는 분입니다. Redux 두 편과 Visitor 패턴을 지나 이번엔 피그마예요.
시작 문장이 솔직합니다.
배운 것과 필요한 것이 어긋난 상태. 인터랙션은 연습했는데 정작 색과 글꼴을 정하는 법은 안 배웠다는 겁니다.
조금 더 들어가 보면
디자인 시스템에서 기본 스타일 설정은 개발의 상수 선언과 같은 자리입니다.
색을 그때그때 골라 쓰면 화면마다 조금씩 달라집니다. 비슷한 회색이 대여섯 개 생기고, 나중에 브랜드 색을 바꾸려면 전부 찾아다녀야 해요. 그래서 처음에 팔레트를 만들어두고 이름으로 부릅니다. 코드에서 #B51F38 대신 primary라고 쓰는 것과 같습니다.
글이 고른 플러그인의 차이가 정확히 이 지점입니다.
2) Foundation Color Generator라는 Plug in을 사용했다.
기본톤의 색상을 중심으로 색분위를 나눠 기본설정을 해주고 팔레트도 생성해주며, 코드로 적용할수도 있다.
"팔레트 생성이 없네"가 탈락 사유입니다. 색을 쓸 수는 있는데 체계로 남지 않는다는 거예요. 그리고 고른 쪽은 기준색 하나로 명도 단계를 자동으로 만들어주고, CSS 코드로 내보낼 수도 있습니다.
이게 왜 중요하냐면, 디자인과 코드가 갈라지는 가장 흔한 지점이 여기라서입니다. 디자이너가 피그마에서 정한 색과 개발자가 CSS에 적은 색이 미묘하게 다른 일이 자주 생겨요. 내보내기가 되면 그 어긋남이 사라집니다.
글꼴 설정에도 판단이 붙어 있습니다.
만들려는 서비스의 성격에서 역산한 결정입니다. 읽을 글이 많은 서비스라면 본문 글꼴을 촘촘히 정해야 하지만, 버튼과 동작 위주라면 제목 쪽이 중요하니까요. 기본값을 정할 때도 무엇을 만드는지가 먼저입니다.
🎚️ 색 다섯 개에서 팔레트를 만든다는 것
글에 적힌 프로젝트 기본색은 다섯 개입니다.
그런데 실제 화면을 만들다 보면 이 다섯 개로는 부족합니다. 버튼에 마우스를 올렸을 때 조금 어두워져야 하고, 비활성 상태는 흐려야 하고, 배경에 옅게 깔리는 색도 필요하거든요.
그때 눈대중으로 색을 조금씩 바꿔 쓰기 시작하면 비슷비슷한 회색이 여덟 개쯤 생깁니다. 화면마다 미묘하게 다르고, 나중에 브랜드 색을 바꾸려면 전부 찾아다녀야 해요.
팔레트 생성이 푸는 문제가 이겁니다. 기준색 하나를 넣으면 밝기 단계를 규칙적으로 만들어줍니다. 그러면 "이 초록의 조금 어두운 버전"이 이름으로 존재하게 되고, 눈대중이 사라져요.
글이 Tailwind 플러그인을 탈락시킨 이유가 정확히 여기였습니다.
그리고 고른 쪽에는 하나가 더 있었습니다.
코드로 내보낼 수 있다는 게 마지막 조건이었어요. 디자인 도구에서 정한 색과 개발자가 CSS에 적는 색이 어긋나는 일이 흔한데, 내보내기가 되면 그 어긋남이 사라집니다.
색 다섯 개를 고르는 일과, 그 다섯 개를 팀이 함께 쓸 수 있는 체계로 만드는 일은 다릅니다. 이 글은 후자를 했어요.
🔧 배운 것과 필요한 것이 어긋날 때
이 글의 첫 문단에는 흔한 상황이 하나 적혀 있습니다.
인터랙션은 배웠는데 색과 글꼴 정하는 법은 안 배웠다는 겁니다.
배우는 순서와 쓰는 순서가 어긋나는 일은 자주 있습니다. 강의는 대개 눈에 띄는 것부터 가르치거든요. 버튼을 누르면 화면이 넘어가는 프로토타입은 결과가 바로 보이니 배우기에 좋습니다. 반면 색 팔레트를 정하는 건 지루하고, 배워도 뭘 했는지 잘 안 보여요.
그런데 실제로 프로젝트를 시작하면 순서가 정반대입니다. 색과 글꼴부터 정해야 화면을 그리고, 화면이 있어야 인터랙션을 붙입니다.
여기서 이분이 한 일이 눈여겨볼 만합니다.
"어떻게 하는지"가 아니라 "다른 분들은 어떤 방법을 사용하는지"를 봤다는 게 다릅니다. 정답 하나를 찾은 게 아니라 여러 방식을 비교해보고 자기 상황에 맞는 걸 고른 거예요. 플러그인 두 개를 써보고 하나를 버린 것도 그 결과고요.
배운 것과 필요한 것이 어긋났을 때, 강의를 탓하는 대신 다른 사람들이 어떻게 하는지부터 본 것입니다.
📝 원문에서는 이렇게 끝납니다
작업을 마치고 붙인 마지막 문단이 좋습니다.
이 글이 왜 쓰였는지가 여기 나옵니다. 머신러닝 이론에 지쳐서 손을 쓰는 일을 하고 싶었던 것이에요.
그리고 그 앞에 이런 대목도 있습니다.
따라 할 수 있는 것과 이해해야 하는 것을 구분하고 있습니다. 라이브러리 사용법은 검색하면 되지만 그 밑의 수학은 시간을 들여야 한다는 것 — 4회차의 상태관리 도구 비교에서도, 5회차의 Visitor 패턴에서도 같은 태도가 보였던 분입니다.
큐레이터 노트
이 글을 고른 이유는 도구를 고르는 과정이 남아 있기 때문입니다.
플러그인 두 개를 써보고 하나를 버렸어요. 그리고 버린 이유가 적혀 있습니다. "팔레트 생성이 없다"는 것. 결과만 적었다면 "Foundation Color Generator를 썼다"로 끝났을 텐데, 탈락한 쪽까지 적어두니 읽는 사람이 자기 상황에서 판단할 수 있게 됩니다. 팔레트가 필요 없는 작은 작업이라면 Tailwind 플러그인이 더 간편할 테니까요.
그리고 "안 멋지니깐 아웃~"이라는 표현. 기술 글에 이런 문장이 있는 게 좋습니다. 판단은 정확한데 말투는 편해요. 읽는 사람이 부담 없이 따라 들어올 수 있게 만드는 문장입니다.
7회차에서 이분의 마지막 글을 만나실 수 있습니다. 오늘 정한 색과 글꼴 위에 화면을 올리고 움직임을 붙입니다.
💡 세 편을 겹쳐 읽으며
이번 회차 세 글에는 공통점이 하나 있습니다. 아직 아무것도 안 만들었습니다.
형기상 님의 서버 구상에는 기능이 없습니다. Dockerfile과 nginx.conf와 docker-compose.yml뿐이에요. 화면도 API도 아직 없습니다.
권준형 님은 코드를 한 줄도 쓰지 않았습니다. 만든 것은 설명 자료 한 벌입니다.
이지은 님이 정한 것은 색 다섯 개와 글꼴입니다. 화면은 아직 한 장도 없어요.
그런데 셋 다 프로젝트가 이미 시작되어 있습니다.
이게 만드는 일의 이상한 점이라고 생각합니다. 결과물로 보여줄 게 없는 구간이 반드시 있고, 그 구간을 건너뛰면 나중에 두 배로 돌아옵니다. 서버 구성 없이 기능부터 만들면 배포할 때 막히고, 무엇을 만드는지 정리하지 않고 시작하면 다 만들고 나서 설명을 못 하고, 색을 정하지 않고 화면을 그리면 열 장쯤에서 손대야 합니다.
그리고 이 구간에는 본인만 아는 진척이 있습니다. 남에게 보여주면 "그래서 뭐가 됐어?"라는 말을 듣기 쉬워요. 그래서 기록으로 잘 안 남습니다.
여기에 한 가지가 더 겹칩니다. 이 구간의 작업은 나중에 고치기가 가장 비쌉니다.
서버 구성을 바꾸려면 이미 만든 기능들이 전부 영향을 받습니다. 프론트와 백을 나누는 방식을 바꾸면 주소 체계가 바뀌고, 데이터베이스를 바꾸면 쿼리를 다시 봐야 해요. 색 체계를 바꾸면 만들어둔 화면을 전부 손봐야 하고요.
그래서 뒤로 미룰수록 비싸집니다. 기능이 열 개일 때 구조를 바꾸는 것과 백 개일 때 바꾸는 것은 다른 일이에요.
세 분이 이 구간에 시간을 쓴 게 그래서 타당합니다. 형기상 님은 기능을 하나도 안 만든 상태에서 배포 구조를 먼저 그렸고, 이지은 님은 화면을 한 장도 안 그린 상태에서 색과 글꼴을 정했어요. 가장 싸게 바꿀 수 있을 때 정한 겁니다.
세 분은 남겼습니다. 그래서 2년이 지난 지금, 형기상 님이 배운 것을 언제 자기 설계에 넣었는지, 권준형 님이 개발을 못 하면서도 어떻게 프로젝트를 이해했는지, 이지은 님이 화면을 그리기 전에 무엇을 정했는지를 볼 수 있습니다.
이번 회차에서 가져갈 것
1. 설정 파일도 기록으로 남기기.
형기상 님의 nginx.conf와 docker-compose.yml은 6개월 뒤 본인이 가장 많이 찾아볼 파일입니다. 개발 명령과 배포 명령을 주석으로 나란히 남겨둔 것처럼요. 한 번 맞춰놓은 설정은 다음 프로젝트의 출발점이 됩니다.
2. 설명 자료를 직접 만들어보기.
권준형 님은 코드를 못 썼지만 설명 자료를 만들면서 프로젝트 전체를 이해했습니다. 지금 참여 중인 프로젝트가 있다면, 한 장으로 설명해보세요. 못 쓰는 칸이 곧 모르는 부분입니다.
3. 도구를 버린 이유도 적기.
이지은 님은 Tailwind 플러그인을 왜 안 썼는지 적었습니다. 고른 것만 적으면 추천이 되고, 버린 것까지 적으면 판단 근거가 됩니다.
4. 남의 기여를 이름으로 적기.
권준형 님이 한대천 님의 이름을 적어둔 덕분에, 기록이 하나도 남지 않은 분의 한 달이 지금 확인됩니다. 내가 남기는 기록에 남의 이름이 들어가면, 그건 그 사람의 기록이기도 합니다.
5. 가장 싸게 바꿀 수 있을 때 정하기.
서버 구성이든 색 체계든, 나중에 바꾸려면 이미 만든 것을 전부 손봐야 합니다. 기능이 열 개일 때와 백 개일 때는 같은 변경도 비용이 다릅니다. 결과물이 없어 보이는 구간에 시간을 쓰는 게 아깝게 느껴진다면, 나중에 치를 값을 먼저 생각해보면 좋겠습니다.
1기는 그로스로그의 첫 기수였습니다. 그때 남긴 글 중에는 지금 열리지 않는 것도 있어요. 블로그를 닫으신 분도, 서버를 내리신 분도 있습니다.
그래서 저희가 지금 이 작업을 하고 있습니다. 읽을 수 있을 때 읽고, 소개하고, 남겨두려고요.
좋은 글 남겨주신 형기상 님, 권준형 님, 이지은 님께 감사드립니다. 그리고 기록은 남지 않았지만 그 여름에 함께 만드셨던 한대천 님과, 아무 전례도 없던 첫 기수를 채워주신 모든 1기 멤버분들께도요! 😊
다음 큐레이션이 1기 마지막 회차입니다. 🌱
- 에디터 · 성장일지 큐레이터 -
※ 본 큐레이션은 각 저자가 공개한 글을 소개하는 것이며, 모든 원문의 저작권은 저자에게 있습니다. 저자 본인의 요청이 있을 경우 즉시 수정 또는 삭제합니다.
'성장일지' 카테고리의 다른 글
| [GL 1기 7회차] 마지막 회차에 0편을 씁니다 — 엔진 분석, 낙관적 락 실습, 타임리프 화면 만들기 🌱 (0) | 2026.08.09 |
|---|---|
| [GL 1기 5회차] 본체를 열지 않고 기능을 더하는 법 — Spring AOP, Visitor 패턴, 레벨 시퀀스 🌱 (0) | 2026.08.09 |
| [GL 1기 4회차] 맡긴 만큼 안 보인다 — 영속성 컨텍스트, Spring Data JPA, 상태관리 도구 🌱 (0) | 2026.08.09 |
| [GL 1기 3회차] 경계를 먼저 긋지 않으면 — 언리얼의 메시와 충돌, Redux 상태 동기화, 쇼핑몰 첫걸음 🌱 (0) | 2026.08.09 |
| [GL 1기 2회차] 학교에서 배운 것과 현업 사이 — 과목 별점 후기, 워크북 족보론, 강의 밖의 스프링 🌱 (0) | 2026.08.09 |