안녕하세요! 그로스로그 입니다!😊 🌱
받는 자리에 있던 사람이 주는 자리로 옮겨가는 이야기. 연말 회고 두 편과 그 구조를 설명하는 글 한 편입니다.
성장일지는 멤버들이 2주에 한 번씩 자신의 성장을 기록하는 활동이에요. 매 회차 운영진이 모든 글을 읽고, 그중 특히 마음에 남은 글을 함께 골라 큐레이션합니다.
7회차는 연말 회고 시즌입니다. 2025년 12월 말에 올라온 회고 두 편이 나란히 들어왔어요. 5년 차와 2년 차의 기록입니다.
01
🗓️ 2025년 회고
김석현 님
만 5년 차 개발자의 한 해 정리입니다. 업무 방식의 변화 · 대학교 · 커뮤니티 세 갈래로 나눠 적었어요.
가장 긴 부분이 커리어 궤적입니다. SI → SM → 세 번째 회사 → 현재. 각 단계에서 제품 개발 프로세스의 어느 지점부터 참여했는지로 자기 성장을 설명해요.
그리고 커뮤니티. 한국 스프링 사용자 모임에서 참여자였다가 오거나이저가 됐고, 올해는 큰일꾼을 맡았습니다.
첫 문단에 이런 고백이 있습니다. "글은 제가 다 쓰고.. Gemini로 평서체로 한번 다듬었네요." 요즘 회고 글에서 보기 시작한 종류의 각주예요.
조금 더 들어가 보면
이 글의 뼈대는 한 줄짜리 프로세스입니다.
그리고 자기가 어느 지점부터 참여했는지로 커리어를 설명해요. 이 방식이 아주 명료합니다.
| 회사 | 참여 시작 지점 |
|---|---|
| 첫 번째 (SI) | 설계 및 구현부터 — 나머지는 이미 정해진 상태 |
| 두 번째 (SM) | 워크플로우 정의부터 — 기획자와 소통 |
| 세 번째 | 가설 정의 이후부터 — 타 직군과 논의, 일정 직접 결정 |
| 현재 | 고객 정의부터 — 문제 식별과 가설 수립 |
화살표를 왼쪽으로 계속 옮겨온 것이 커리어였다는 겁니다.
연차나 직급이 아니라 "어디서부터 관여하는가"로 성장을 잰 관점이 좋았어요. 같은 3년 차라도 이 지점이 다르면 하는 일이 완전히 다르니까요.
😰 왼쪽으로 갈수록 무거워진다
솔직한 대목이 이어집니다.
그리고 무엇이 힘들었는지를 구체적으로 적어요.
"그 사람이 이미 알 것이다 라는 전제를 하지 않는 것" — 이게 정말 어려운 일입니다.
한 분야에 오래 있으면 뭘 설명해야 하는지 감각을 잃습니다. 나에게 당연한 게 남에게도 당연할 것 같거든요. 그런데 "이 API 응답이 늦어져서요"라는 말이 상대에게는 아무 정보가 아닐 수 있어요.
그리고 어디까지가 당연한지 매번 다시 계산해야 합니다. 상대가 누구냐에 따라, 어떤 회의냐에 따라 다르니까요. 끊임없이 신경을 써야 하는 종류의 노동입니다.
두 번째로 든 것도 실질적이에요.
일정을 받는 것과 정하는 것의 차이입니다. 받으면 그 안에서 최선을 다하면 되는데, 정하면 틀렸을 때 그게 내 판단 실수가 돼요.
🤝 해결 방법이 사람이었다는 것
그리고 어떻게 넘겼는지가 나옵니다.
책이나 강의가 아니라 옆 사람이었습니다. 그리고 먼저 요청했어요. 1 on 1을 정기적으로 잡고 피드백을 달라고 한 겁니다.
이런 종류의 능력은 자료로 배우기가 어렵습니다. "이 상황에서 이렇게 말하더라"를 보는 게 빠르거든요.
자기 평가도 재미있어요.
같은 게 강점이자 단점이라는 자기 인식입니다.
🔄 잘하고 있다고 생각했을 때 옮긴 것
이 글에서 가장 인상적이었던 판단이 여기입니다.
잘 되고 있었습니다. 자기 인정도 명확해요.
그런데 옮깁니다.
"여기가 떨어진다면, 몇년간 이직하지 않겠단 생각도 했었다" — 각오의 크기가 이 한 줄에 있습니다. 안 되면 다른 데를 알아보는 게 아니라 아예 접겠다는 거예요. 그만큼 그 자리가 특정한 선택이었다는 뜻입니다.
🧩 프로덕트 엔지니어
옮긴 뒤의 이야기가 이어집니다.
그리고 그 결과가 이렇습니다.
"어떻게 구현할 것인가는 후순위"라는 문장이 5년 차 백엔드 개발자에게서 나왔다는 게 이 회고의 요점입니다.
그런데 부담 이야기로 끝나지 않아요.
"아직 갈 길이 멀다"를 동력으로 쓰고 있습니다. 앞에서 "충분히 기여하고 있다고 생각했었다"는 자리에서 스스로 걸어나온 사람의 문장이에요.
📚 무리해본 학기
학업 부분은 짧지만 강렬합니다.
빨리 졸업하겠다는 계획으로 시작했다가, 일과 공부를 같이 끌고 가는 게 만만치 않아 한 해를 통째로 쉬었다고 적혀 있어요. 그리고 돌아온 학기에 감당하기 어려운 양을 한 번에 신청합니다.
6회차 신헌주 님 글에서 "매일 퇴근하고 2시간"이 기준선이라고 했던 걸 떠올리면, 이건 그 몇 배입니다. 쉬어본 것과 무리해본 것을 다 적어둔 기록이라 오히려 참고가 돼요. 잘된 이야기만 있는 회고는 따라 하기가 어렵거든요.
🎪 참여자에서 기여자로
커뮤니티 부분이 이 회고의 백미입니다.
한 번 만들어본 사람만 갖는 시선입니다. 참가자일 땐 안 보이던 게 보이죠. 장소를 어떻게 잡았는지, 저 간식은 누가 사왔는지, 시간표가 왜 저렇게 됐는지요.
그리고 그 시선이 행동으로 이어집니다.
후원 3회, 그리고 참석 목록이 열한 개. Devchat Night, UbuCon Korea, FEConf, K-DEVCON, 데이터야 놀자, DEVFEST INCHEON, GopherCon Korea, PYWEB SYMPOSIUM, GDG I/O Extended, Tech Friends Mixer, 표준프레임워크 오픈커뮤니티 세미나.
공부하러 간 게 아니라 운영을 보러 간 참석들이에요.
그리고 깨달음이 하나 나옵니다.
기여자를 위한 행사라는 개념이 흥미롭습니다. 만드는 사람들도 어딘가에서 채워져야 계속할 수 있다는 뜻이에요. 4회차에서 본 FOSS for All의 문제의식 — "열정만으로 운영되다가 사라진다" — 과 같은 자리입니다.
올해는 큰일꾼을 맡았다고 해요.
예상하지 못한 상황에서 처음으로 이끄는 자리를 맡게 됐고, 시행착오가 많았지만 한 해를 무사히 보낸 것에 안도한다고 적었습니다. 그리고 괄호를 하나 열어 이렇게 덧붙여요.
슬쩍 괄호에 넣어둔 이 한 줄이 커뮤니티 운영의 현실을 말해줍니다. 즐거워서 하는 일에도 비용이 든다는 것이요.
그리고 함께한 사람들의 이름을 하나하나 적어뒀습니다. 회고에 같이 한 사람들의 이름이 들어가는 게 좋았어요.
큐레이터 노트
성장을 '위치'로 설명한 글이라 뽑았습니다.
경력 회고는 대개 무엇을 했는지 나열합니다. 이 글은 어디서부터 참여했는지로 씁니다. 프로세스 한 줄을 그려두고 화살표를 왼쪽으로 옮겨온 궤적을 보여줘요. 읽는 사람도 자기 위치를 찍어볼 수 있는 틀입니다.
잘 되던 자리에서 스스로 나온 것이 이 회고의 핵심이라고 봤습니다. "충분히 기여하고 있다고 생각했었다"는 상태에서 옮기는 건 쉽지 않아요. 그리고 그 판단에 "떨어지면 몇 년간 이직하지 않겠다"는 각오까지 붙어 있습니다.
커뮤니티 이야기를 커리어와 같은 무게로 쓴 것도 눈에 띄었습니다. 보통 회고에서 커뮤니티는 부록처럼 붙는데, 여기서는 세 갈래 중 하나예요. 그리고 참여자 → 기여자 → 리더의 이동이 회사에서의 이동과 같은 모양입니다. 양쪽에서 같은 방향으로 걸어간 한 해였어요.
AI로 다듬었다고 밝힌 것도 언급해두고 싶습니다. "글은 제가 다 쓰고.. Gemini로 평서체로 한번 다듬었네요." 내용은 자기 것이고 문체만 손봤다는 걸 정확히 구분해 적었어요. 앞으로 더 자주 보게 될 종류의 각주일 텐데, 이 정도 밝히는 게 기준선이 되면 좋겠습니다.
02
🐧 오픈소스 프로젝트로서 리눅스와 파이썬
박석희 님
오픈소스의 역사와 구조를 정리한 글입니다. 1960년대 해커 문화 → AT&T의 유닉스 폐쇄 → 스톨먼의 GNU와 GPL → 토르발스의 리눅스 커널 → '성당과 바자' → 오픈소스 이니셔티브(OSI)로 이어져요.
그리고 왜 그게 가능해졌는가를 짚습니다. Git과 GitHub, 그리고 포크 → 푸시 → Pull Request라는 절차요.
마지막은 파이썬입니다. PSF 라이선스와 PEP 제안 시스템이 어떻게 언어를 성장시켰는지로 마무리해요.
6회차에 이어 두 번째로 소개하는 저자입니다. 이번에도 역사로 지금을 설명하는 방식이에요.
조금 더 들어가 보면
'오픈'이라는 말의 뿌리부터 시작합니다.
그리고 구체적인 사건을 계기로 짚습니다.
이 배경이 중요합니다. 원래는 열려 있었어요. 대학과 연구소가 유닉스 소스를 받아 고쳐 쓰던 시절이 있었습니다. 그게 닫히면서 잃어버린 자유를 되찾으려는 운동이 시작된 거예요.
그래서 '자유 소프트웨어'의 자유가 무슨 뜻인지도 명확히 짚습니다.
영어의 free가 둘 다를 뜻해서 지금도 오해가 잦은 지점이죠.
⛪ 성당과 바자 — 이 글의 중심 개념
가장 중요한 대목이 에릭 레이먼드의 에세이 소개입니다.
성당은 조용하고, 바자는 시끄럽습니다.
당시 통념은 성당 쪽이었어요. 소프트웨어처럼 복잡한 걸 아무나 손대게 두면 엉망이 될 거라고요. 그런데 리눅스가 반례가 됐습니다. 수천 명이 동시에 건드리는데도 품질이 올라갔거든요.
그리고 이 글이 실제 영향까지 짚습니다.
에세이 한 편이 회사의 결정을 바꾼 사례입니다. 그리고 그 결정에서 나온 코드가 훗날 파이어폭스가 되죠.
🔧 바자를 가능하게 한 도구
이 글에서 가장 실용적인 연결이 여기라고 봤습니다.
리눅스를 만든 사람이 Git도 만들었다는 사실이 여기서 의미를 갖습니다. 우연이 아니에요. 수천 명이 참여하는 프로젝트를 굴리다 보니 그런 도구가 필요해진 것입니다.
그리고 절차를 짚습니다.
여기서 짚고 싶은 게 하나 있습니다. Pull Request는 허락을 구하지 않아도 되게 만든 장치예요.
예전 방식이라면 프로젝트를 고치려면 먼저 커밋 권한을 받아야 했습니다. 신뢰를 쌓아야 참여할 수 있었죠. 그런데 포크는 아무한테도 안 물어보고 할 수 있습니다. 내 계정에 복사본을 만들고, 마음대로 고치고, 그다음에 "이거 어때요?"라고 제안하면 돼요.
먼저 만들고 나중에 물어보는 순서로 바뀐 겁니다. 진입 문턱이 이 지점에서 결정적으로 낮아졌어요.
4회차 FOSS 리포트에서 본 FOSDEM의 자원봉사 문화 — "허락을 기다리지 않게(not wait for permission)" — 와 정확히 같은 원리입니다.
🐍 파이썬 — PEP라는 장치
마지막 장이 파이썬입니다.
언어를 바꾸는 절차 자체가 공개돼 있다는 게 요점입니다.
PEP는 번호가 붙은 문서예요. 누가 무엇을 제안했고, 어떤 반론이 나왔고, 왜 받아들여졌거나 거절됐는지가 전부 남습니다. 그래서 "파이썬은 왜 이렇게 됐나"를 궁금해하면 찾아볼 문서가 있어요.
이게 바자 모델의 구체적인 모습입니다. 글의 표현이 정확해요.
라이선스 성격을 짚은 것도 정확합니다.
GPL과 대비되는 지점입니다. GPL은 "고쳐서 배포하면 너도 공개하라"고 요구하는데, 퍼미시브 라이선스는 그런 조건이 거의 없어요. 그래서 기업이 마음 놓고 쓸 수 있고, 파이썬이 산업 전반으로 퍼진 배경이 됩니다.
교육 이야기로 마무리한 것도 이 저자다웠습니다.
교육 쪽을 아는 사람이 아니면 안 넣었을 문단이에요. 라이선스 이야기를 하다가 교과서까지 내려가는 시선이요.
큐레이터 노트
우리가 매일 쓰는 것의 내력을 정리한 글이라 뽑았습니다.
포크하고 PR 보내는 건 이제 너무 익숙해서 원래 그랬던 것처럼 느껴집니다. 그런데 이 글을 읽으면 각 단계가 다 누군가의 선택이었다는 게 보여요. AT&T가 닫았고, 스톨먼이 GPL을 만들었고, 레이먼드가 이름을 붙였고, 토르발스가 Git을 만들었습니다.
철학과 도구를 이어붙인 구성이 특히 좋았습니다. "정보는 자유로워야 한다"는 신념이 → GPL이라는 법적 장치가 되고 → Git이라는 기술 도구를 만나 → PR이라는 일상 절차가 됩니다. 이념이 어떻게 실무가 되는지의 경로가 그려져요.
한 언어를 사례로 끝까지 따라간 것도 좋았습니다. 파이썬 하나를 놓고 라이선스, 거버넌스(PEP), 생태계(NumPy·Pandas·PyTorch), 교육까지 봅니다. 추상적인 이야기가 구체적인 예로 착지해요.
4회차 김노석 님의 FOSS 컨퍼런스 리포트와 나란히 읽으면 특히 좋습니다. 이 글이 오픈소스가 어떻게 여기까지 왔는지를 다루고, 그 리포트가 지금 어떤 문제에 부딪혔는지를 다루거든요. 지속가능성, 재정, 그리고 각국의 규제요.
03
🌱 주니어 개발자의 2025년 회고
이종경 님
2년 차 개발자의 한 해 정리입니다. 앞의 회고가 5년 차였으니, 나란히 놓으면 대비가 재미있어요.
큰 주제가 하나예요. "문제를 해결하는 사람에서 문제를 정의하는 사람으로."
그 아래 구체적인 사건들이 붙습니다. FSD 아키텍처 도입(아직 해결 못 한 문제 포함), WASM 도전(오버 엔지니어링으로 끝남), 멘토링, 커뮤니티 운영. 그리고 2026년 목표 둘.
앞의 회고와 달리 아직 안 풀린 것들이 그대로 적혀 있습니다. 그게 이 글의 성격이에요.
조금 더 들어가 보면
첫 문단이 솔직합니다.
"자연스럽게 되어 있을 줄 알았다"는 감각을 대부분 겪습니다. 그런데 막상 그 연차가 되면 밖에서 보던 그 사람과 지금의 내가 안 겹쳐요.
🎯 문제를 정의하는 사람
가장 큰 주제가 이겁니다.
그리고 정직하게 덧붙여요.
"아직은 어색하지만"이 좋습니다. 조언을 들었다고 바로 되는 게 아니라는 걸 아는 문장이에요.
그런데 여기서 앞의 김석현 님 회고와 겹칩니다. 5년 차는 이렇게 썼거든요.
같은 방향입니다. 한쪽은 이제 막 시작했고, 한쪽은 그 자리에 서 있어요. 연차가 다른 두 사람이 같은 축 위 다른 지점에 있는 게 나란히 보입니다.
🗂️ FSD — 안 끝난 이야기를 쓴 것
가장 배울 게 많았던 절입니다.
배경이 명확해요.
"필요한 컴포넌트를 찾는 일조차 힘들어졌다" — 구조 개편이 필요해지는 순간을 정확히 짚은 증상입니다.
그리고 자기들만의 변형을 만들었어요.
여기서부터가 이 글의 값입니다. 결과를 미화하지 않아요.
"둘째, 일부 레이어의 구분이 명확하지 않아 '계륵' 같다는 생각이 들었다."
표준 아키텍처를 자기 상황에 맞춰 변형했더니 새로운 비용이 생긴 이야기입니다. 아주 흔한 일인데 글로는 잘 안 나와요.
그리고 Three.js 사례가 구체적입니다.
아키텍처 규칙과 도메인 특성이 충돌하는 지점입니다. FSD의 레이어 구분은 대개 데이터 중심 서비스를 상정하는데, 3D 씬처럼 상태가 얽혀 있는 도메인에서는 경계가 잘 안 그어져요.
그런데 결말이 이렇습니다.
"어떻게든 굴러가고 있는"이라고 적었습니다. 회고 글에서 좀처럼 보기 힘든 문장이에요. 대부분 해결된 것만 씁니다. 그런데 실무의 대부분은 이 상태거든요.
🧪 오버 엔지니어링이라고 이름 붙인 것
두 번째 사례도 실패담입니다.
문제 정의가 명확합니다. 그리고 해법도 합리적이에요. 서버에서 하던 경로 계산을 프론트엔드로 옮기자는 것. 2회차에서 본 세 편과 같은 발상입니다. 계산을 다른 자리로 옮기기.
그런데 안 됐습니다.
"둘째, 경로 생성을 위해 프로젝트에 추가적인 C++ 세팅이 필요했고, 이로 인해 CI/CD 파이프라인 시간이 오히려 증가할 것으로 예상되었다."
두 가지 다른 종류의 비용입니다. 하나는 실행 시점의 문제(브라우저가 멈춤), 하나는 개발 과정의 문제(빌드가 느려짐).
두 번째가 특히 놓치기 쉬운 비용이에요. 성능은 좋아졌는데 팀 전체의 배포가 느려지는 상황이거든요. 개인이 감당하는 비용이 아니라 팀이 매일 나눠 내는 비용입니다.
그래서 결론이 이렇습니다.
멈출 줄 아는 것도 판단입니다. 2회차 오세명 님이 tinycc를 포기하고 라이브러리로 넘어간 것과 같은 결이에요. "할 수 있다"와 "해야 한다"는 다르다는 것.
🤲 받았던 자리로 돌아가기
멘토링 부분이 이 글에서 가장 따뜻한 대목입니다.
자기가 수료한 곳에 멘토로 돌아갔습니다.
그리고 자기 취준 시절을 먼저 적어요.
그래서 후배들에게 무엇을 줬느냐면요.
"대단한 조언을 해줄 순 없었지만" — 그런데 사실 2년 차라서 줄 수 있는 게 있습니다. 방금 그 자리를 지나왔거든요. 10년 차의 조언보다 1년 전의 나와 가까운 사람의 이야기가 더 닿을 때가 있어요.
커뮤니티 이야기도 같은 결입니다.
"가족보다 더 자주 만나"가 실감납니다. 그리고 지향점이 명확해요.
"놀이터"라는 단어 선택이 좋았습니다. 학원도 학교도 아니고요.
🎯 2026년 목표 둘
마무리가 이 회고의 방향을 다시 확인해줍니다.
첫째, 오픈 소스 컨트리뷰터.
"시작이 어려워"가 정확합니다. 기술이 부족해서가 아니라 어디서 시작할지를 모르는 것이 진짜 장벽이에요. 그래서 "커뮤니티의 힘을 빌려"라는 방법을 골랐습니다.
박석희 님 글이 설명한 그 구조 — 포크하고 PR 보내는 절차 — 를 실제로 처음 써보려는 사람이 바로 옆에 있는 셈입니다.
둘째, 같이 일하고 싶은 동료.
김석현 님이 "강점도 커뮤니케이션, 단점도 커뮤니케이션"이라고 쓴 그 지점을 2년 차가 목표로 적었습니다.
큐레이터 노트
안 풀린 것을 안 풀렸다고 쓴 회고라서 뽑았습니다.
연말 회고는 정리하는 글이라 자연스럽게 결론이 붙습니다. 어려웠지만 배웠다, 실패했지만 의미가 있었다 하는 식으로요. 이 글에도 그런 문장이 있어요. 그런데 그 앞에 안 풀린 상태를 그대로 남겼습니다.
FSD는 "어떻게든 굴러가고 있는" 상태이고, WASM은 R&D에서 멈췄고, 문제 정의는 "아직 어색"합니다. 이걸 다 적어놓고 2026년 목표로 넘어가요.
실패의 이유를 구체적으로 적은 것도 값집니다. WASM이 왜 안 됐는지가 "브라우저가 멈췄다"와 "CI/CD 시간이 늘어날 예정이었다" 두 가지로 나와요. 같은 걸 시도하려는 사람에게 미리 확인할 목록이 됩니다.
그리고 받았던 자리로 돌아간 것이 이 회고를 관통합니다. SeSAC 수료생 → SeSAC 멘토. 커뮤니티 회원 → 운영진. 오픈소스 사용자 → (내년엔) 기여자. 자기가 도움받은 곳마다 다시 가고 있어요.
프로필의 한 줄도 이 글과 어울립니다. "잘 하고 싶어요."
💡 세 편을 겹쳐 읽으며
회고 두 편과 오픈소스 역사 한 편. 언뜻 한 편이 겉도는 것 같은데, 놓고 보니 그 한 편이 나머지 둘의 설명서였습니다.
세 글 다 받는 자리에서 주는 자리로 옮겨가는 이야기예요.
김석현 님은 컨퍼런스 참여자에서 기여자로 갔습니다. 그리고 옮기고 나서 시선이 바뀌었어요. "이제는 다른 커뮤니티 행사에 갈 때마다 준비한 분들의 노고를 먼저 떠올리게 된다." 회사에서도 같은 방향이었습니다. 주어진 걸 구현하던 자리에서 문제를 정의하는 자리로요.
이종경 님은 수료생에서 멘토로, 회원에서 운영진으로 갔습니다. 그리고 내년엔 사용자에서 기여자로 가려 합니다. 업무에서도 같아요. 문제를 푸는 사람에서 정의하는 사람으로.
박석희 님의 글은 그 이동이 왜 가능한지를 설명합니다. 원래 소프트웨어는 성당이었어요. 만드는 사람과 쓰는 사람이 나뉘어 있었죠. 그런데 바자 모델이 나왔고, Git과 GitHub가 그걸 실제로 굴러가게 만들었습니다.
특히 포크와 Pull Request가 결정적입니다. 허락을 먼저 받을 필요가 없어졌거든요. 복사해서 고치고 나서 제안하면 됩니다. "먼저 만들고 나중에 물어보는" 순서로 바뀐 게 문턱을 무너뜨렸어요.
그리고 세 글 모두 옮기고 나면 안 보이던 게 보인다고 말합니다.
행사를 준비해봐야 다른 행사의 준비 과정이 보이고, 문제를 정의해봐야 왜 그 문제가 나왔는지가 보이고, PR을 보내봐야 오픈소스가 어떻게 굴러가는지가 보입니다.
그러니까 이 이동은 베푸는 일이 아니라 배우는 일에 가까워요. 두 회고 다 그렇게 적고 있습니다. 김석현 님은 "어떤 고민을 했을지 직접 보고 싶었기 때문"에 행사를 다녔고, 이종경 님은 멘토링에서 자기가 꺾였던 때를 다시 꺼내 이야기했어요.
마지막으로 하나. 두 회고 다 자기 부족함을 적고 있는데, 그게 멈춰 있는 문장이 아닙니다.
김석현 님은 "아직 갈 길이 멀다"를 "오히려 공부할 맛이 난다"로 잇고, 이종경 님은 "여전히 성장에 목마른 주니어"를 "그래도 올 한 해 치열한 노력을 해왔다"로 잇습니다.
같은 자리에서 다른 방향을 보고 있어요.
이번 회차에서 가져갈 것
1. 성장은 "무엇을 했나"보다 "어디서부터 참여하나"로 잴 수 있다.
고객 정의 → 가설 → 워크플로우 → 모델링 → 구현. 화살표가 왼쪽으로 갈수록 하는 일이 달라집니다. 자기 위치를 한번 찍어보세요.
2. "상대가 이미 알 것이다"라는 전제를 거두는 게 진짜 어렵다.
한 분야에 오래 있으면 뭘 설명해야 하는지 감각을 잃습니다. 매번 다시 계산해야 하는 종류의 노동이에요.
3. 일정을 받는 것과 정하는 것은 다르다.
정하면 틀렸을 때 내 판단 실수가 됩니다. 이 압박은 능력 부족이 아니라 역할이 바뀐 신호예요.
4. 잘 되고 있을 때 옮기는 게 가장 어렵다.
"충분히 기여하고 있다"는 상태는 편안합니다. 거기서 걸어나오려면 각오가 필요해요.
5. 포크와 PR은 "허락을 먼저 받지 않아도 되게" 만든 장치다.
예전엔 커밋 권한부터 받아야 했습니다. 지금은 복사해서 고치고 나서 제안하면 돼요. 시작 문턱이 여기서 무너졌습니다.
6. free의 뜻은 무료가 아니라 자유다.
사용·수정·공유할 자유요. 그리고 GPL(공개 강제)과 퍼미시브 라이선스(조건 거의 없음)의 차이를 알아두면, 왜 어떤 프로젝트는 기업이 마음 놓고 쓰는지가 보입니다.
7. 표준 아키텍처를 변형하면 새 비용이 생긴다.
FSD에 Platform 층을 하나 끼웠더니 폴더 깊이가 깊어지고 레이어 구분이 흐려졌습니다. 변형 자체가 나쁜 게 아니라, 그 대가를 미리 셈해두는 게 요점이에요.
8. 최적화 비용은 두 종류로 나눠 보라.
실행 시점의 비용(브라우저가 멈춤)과 개발 과정의 비용(빌드·배포가 느려짐)이요. 후자는 팀 전체가 매일 나눠 내는 비용이라 놓치기 쉽습니다.
9. 멈추는 것도 판단이다.
"할 수 있다"와 "해야 한다"는 다릅니다. R&D에서 멈추고 교훈만 챙기는 것도 완결된 결과예요.
10. 저연차라서 줄 수 있는 것이 있다.
방금 그 자리를 지나왔으니까요. 1년 전의 나와 가까운 사람의 이야기가 더 닿을 때가 있습니다.
11. 안 풀린 건 안 풀렸다고 쓰기.
"어떻게든 굴러가고 있는" 상태를 그대로 적은 회고가 오히려 참고가 됩니다. 실무의 대부분이 그 상태니까요.
12. 만드는 사람도 채워져야 한다.
"기여자를 위한 행사와 참가자를 위한 행사 모두가 조화롭게 필요하다." 커뮤니티가 오래 가려면 이 균형이 필요합니다.
좋은 글 남겨주신 김석현 님, 박석희 님, 이종경 님께 감사드립니다! 😊
다음 큐레이션으로 다시 찾아오겠습니다! 🌱
- 에디터 · 성장일지 큐레이터 -
※ 본 큐레이션은 각 저자가 공개한 글을 소개하는 것이며, 모든 원문의 저작권은 저자에게 있습니다. 저자 본인의 요청이 있을 경우 즉시 수정 또는 삭제합니다.