이건 PhD 연구의 가장 큰 어려움을 잘 보여준다고 봄
흥미로운 주제를 잡고 관련 선행연구를 가능한 한 다 읽다 보면, 이미 내가 하려는 걸 해둔 것이 얼마나 많은지 깨닫게 되면서 scope creep가 심해지기 쉬움
초반의 에너지와 설렘을 다 써버린 뒤에는, 남은 20~30%를 억지로 밀어붙여서 출판 가능한 상태까지 끌고 가야 함
1일 차엔 기존 산업용 촉매를 새로운 용도에 적용해 필수 의약품 전구체 생산 비용을 낮춰보자고 시작함
400일 차엔 만물 이론을 거의 다 설명한 뒤, 알려진 우주의 모든 힘을 매개하는 보편 입자를 검출하려고 라그랑주점 궤도 실험 장치를 만들려 듦
그 느낌이 너무 생생하게 와닿음
이걸 완화하려면 어떻게 해야 하는지 궁금함
대부분의 박사과정이 이걸 겪는 이유는, PhD의 목적이 결국 normal science를 할 수 있음을 증명하는 데 있기 때문이라 봄
실상은 시스템의 관측 가능성을 1%에서 1.001%로 올리는 식의 작업이고, 학계 커리어에 들어가기 위한 관문에 가까움
그래서 정말 흥미롭거나, 대단히 새롭거나, 과학에 직접 적용 가능한 내용이 담긴 학위논문은 거의 못 봄
게다가 애초에 PhD를 시작한 것에 대한 후회까지 점점 무거워지는 상태에서 이걸 버텨야 함
선행연구를 가능한 한 전부 읽고 시작하는 건 확실히 잘못된 접근이라 봄
실제로 그렇게 연구하는 사람은 거의 못 봤고, 보통은 논문 두세 편 정도를 읽고 거기서부터 쌓아 올리는 편이 맞음
연구 문헌을 깊게 훑는 건 결과가 좀 나온 뒤, 글로 정리하기 시작할 때 하는 게 더 낫다고 봄
더 나은 것이면 충분하다는 말이 계속 떠오름
작은 개선도 시간이 지나면 누적되고, 처음부터 완벽한 새것은 없으니 완벽한 설계를 앉아서 짜내려는 태도는 오히려 역효과가 큼
장애물이 곧 길이 된다는 말도 여기 잘 맞음
완벽함이 충분히 좋은 것의 적이 되게 두지 말라는 말이 딱 맞음
같이 일하던 동료는 코드 변경을 비판할 때도, 자기가 너무 사소한 걸 잡는다고 느끼면 "예전보단 낫다"라고 말했음
덕분에 개선점은 짚으면서도, 사소한 흠이 남아 있어도 일단 진행해도 된다는 허락을 함께 줬고 이런 태도를 강하게 지지함
이건 결국 완벽주의임
예전엔 완벽주의를 지나치게 높은 성취를 무리해서 추구하는 걸로만 생각했는데, 완벽하지 않으면 못 받아들여서 진전 없이 포기하는 것도 완벽주의일 수 있음
큰 일을 미루는 procrastination도 같은 뿌리일 때가 많음
Rec Room의 CEO가 한 말이 좋았음
팀들은 늘 프로젝트를 더 짧게 했으면 좋겠다고 하지, 출시를 더 미루고 더 복잡하게 만들고 더 다듬었으면 좋겠다고 말하는 경우는 거의 없다고 함
모든 상황에 100% 맞진 않겠지만, 실수할 거라면 너무 크게 벌여 시간을 낭비하느니 작게 만들어 일찍 출시하는 쪽이 낫다고 봄
인간은 본성상 비슷한 아이디어를 떠올리기 쉬워서, 모르고 프로젝트를 완성하면 결국 어느 정도는 재발명이 되기 쉽다고 봄
반대로 먼저 조사하면 부분적으로는 이미 있던 것의 반복임을 깨닫고 김이 빠질 수 있음
그래도 자기 학습을 위해 끝까지 만들어보는 일 자체가 가장 중요할 수 있음
물론 새로운 학술 성과를 내야 하거나 고유한 프로젝트로 수익을 내야 할 때는 더 어렵지만, 그런 영역도 기존 것을 조금만 비틀어도 의외로 꽤 관대함
지금 딱 사이드 프로젝트에서 이런 상황을 겪고 있음
분야가 Information Retrieval이라 경험이 적고, 배울 수 있거나 통합할 수 있는 prior art가 당연히 많음
그래서 이 글을 읽고 나니 우선 내 걸 만들면서, 막히거나 아이디어가 필요할 때만 선행 사례를 들여다보는 쪽으로 더 마음이 감
한편 최근 나온 Clojure 다큐를 보면 Rich Hickey는 오히려 오랫동안 선행연구, 논문, 다른 언어를 깊게 파고든 뒤 작업한 것처럼 보였음
하지만 그 사람도 그 전에 이미 다른 언어들을 만들어봤으니, 더 큰 그림은 결국 직접 만들어보며 배우는 데서 시작된 셈임
너무 오래 고민만 하지 말고 일단 만들어보고, 실전에서 교훈을 쌓고 벽에 부딪힌 다음에 더 깊은 조사가 필요해지는 게 아닐까 싶음
마감기한을 잡으면 scope creep 문제 대부분이 풀렸음
체감상 game jam이나 프로그래밍 대회처럼 하드 데드라인이 있는 프로젝트는 끝내기 쉬운데, 끝이 열려 있는 프로젝트는 완주가 훨씬 어려움
C++ 표준도 원하는 기능이 다 준비될 때까지 기다리지 않고 왜 3년마다 내보내는지와 비슷한 맥락으로 보임 https://news.ycombinator.com/item?id=20428703
글이 흥미롭긴 했지만, 저자의 생각이 좀 산만하게 흩어져 보였음
여기서 핵심은 결국 scope creep라고 봄
이건 특정한 주제를 날카롭게 파는 블로그 글이 아니라, 이 사람을 팔로우하는 독자에게 보내는 뉴스레터 업데이트에 가까움
scope creep에 압도된다고 말하는 사람치고는, 글 끝에 온갖 주제의 링크가 잔뜩 달려 있을 정도로 엄청 많은 일을 해내는 편으로 보임
결국 배우고 이것저것 해보는 걸 진짜 좋아하는 타입 같고, rabbit hole로 빠지는 과정 자체가 머리를 즐겁게 자극하는 듯함
혼자 만드는 입장에서 크게 도움 됐던 깨달음이 하나 있음 필수 추상화처럼 보이는 것 대부분은 이름만 바꾼 scope creep였음
새 기능마다 flag를 붙이다가 내 코드에서 패턴이 보여서 규칙을 하나 세움
기능은 flag-off 동작에 대한 테스트가 없으면 배포하지 않기로 한 것임
그러자 flag를 탈출구가 아니라 제품의 일부로 보게 됐고, 백로그에 있던 기능 셋은 그렇게 생각하기 시작하자 자연스럽게 사라졌음
과도한 계획과 scope creep가 문제인 건 맞지만, 반대로 너무 즉흥 개발 쪽으로 흔들리는 것도 경계해야 함
가장 성공적이었던 프로젝트 중 일부는, 실제로 돌아가는 소프트웨어를 만들기 전에 데이터를 모델링하면서 기능 대부분을 미리 계획하고 검토했던 경우였음
그 단계에서는 무엇이 과한지 잘 모를 때가 많고, 나나 사용자가 원할 법한 기능을 빼면 나중에 코드 핵심을 크게 다시 설계하느라 시간을 많이 씀
반대로 틀리면 프로젝트가 너무 커져서 scope creep라고 부르게 됨
결국 이 판단은 도메인을 얼마나 잘 아느냐에 달려 있음
도메인을 생각보다 덜 알면 재작업이 많아지고, 생각보다 더 잘 알면 사실 크게 나갈 수 있었는데 baby step으로 시간을 낭비하게 됨
어느 쪽으로 가도 후회는 남아서, 결국 큰 판단의 문제라고 느껴짐
이상적인 방법은 분석 단계에서 충분히 시간을 써서 머릿속에 올바른 맥락을 채워 넣되, 막상 만들 때는 과설계한 해법을 버리고 손이 가는 쪽으로 바로 구현할 준비를 하는 것이라 봄 매몰비용 오류에 빠지면 안 되고, 박사과정 수준 주제를 몇 시간 조사했다고 해서 그걸 프로젝트에 꼭 써야 하는 건 아님
지금 문제에 딱 맞지 않으면 과감히 버리는 편이 맞음
Hacker News 의견들
이건 PhD 연구의 가장 큰 어려움을 잘 보여준다고 봄
흥미로운 주제를 잡고 관련 선행연구를 가능한 한 다 읽다 보면, 이미 내가 하려는 걸 해둔 것이 얼마나 많은지 깨닫게 되면서 scope creep가 심해지기 쉬움
초반의 에너지와 설렘을 다 써버린 뒤에는, 남은 20~30%를 억지로 밀어붙여서 출판 가능한 상태까지 끌고 가야 함
400일 차엔 만물 이론을 거의 다 설명한 뒤, 알려진 우주의 모든 힘을 매개하는 보편 입자를 검출하려고 라그랑주점 궤도 실험 장치를 만들려 듦
이걸 완화하려면 어떻게 해야 하는지 궁금함
실상은 시스템의 관측 가능성을 1%에서 1.001%로 올리는 식의 작업이고, 학계 커리어에 들어가기 위한 관문에 가까움
그래서 정말 흥미롭거나, 대단히 새롭거나, 과학에 직접 적용 가능한 내용이 담긴 학위논문은 거의 못 봄
실제로 그렇게 연구하는 사람은 거의 못 봤고, 보통은 논문 두세 편 정도를 읽고 거기서부터 쌓아 올리는 편이 맞음
연구 문헌을 깊게 훑는 건 결과가 좀 나온 뒤, 글로 정리하기 시작할 때 하는 게 더 낫다고 봄
더 나은 것이면 충분하다는 말이 계속 떠오름
작은 개선도 시간이 지나면 누적되고, 처음부터 완벽한 새것은 없으니 완벽한 설계를 앉아서 짜내려는 태도는 오히려 역효과가 큼
장애물이 곧 길이 된다는 말도 여기 잘 맞음
같이 일하던 동료는 코드 변경을 비판할 때도, 자기가 너무 사소한 걸 잡는다고 느끼면 "예전보단 낫다"라고 말했음
덕분에 개선점은 짚으면서도, 사소한 흠이 남아 있어도 일단 진행해도 된다는 허락을 함께 줬고 이런 태도를 강하게 지지함
예전엔 완벽주의를 지나치게 높은 성취를 무리해서 추구하는 걸로만 생각했는데, 완벽하지 않으면 못 받아들여서 진전 없이 포기하는 것도 완벽주의일 수 있음
큰 일을 미루는 procrastination도 같은 뿌리일 때가 많음
Rec Room의 CEO가 한 말이 좋았음
팀들은 늘 프로젝트를 더 짧게 했으면 좋겠다고 하지, 출시를 더 미루고 더 복잡하게 만들고 더 다듬었으면 좋겠다고 말하는 경우는 거의 없다고 함
모든 상황에 100% 맞진 않겠지만, 실수할 거라면 너무 크게 벌여 시간을 낭비하느니 작게 만들어 일찍 출시하는 쪽이 낫다고 봄
인간은 본성상 비슷한 아이디어를 떠올리기 쉬워서, 모르고 프로젝트를 완성하면 결국 어느 정도는 재발명이 되기 쉽다고 봄
반대로 먼저 조사하면 부분적으로는 이미 있던 것의 반복임을 깨닫고 김이 빠질 수 있음
그래도 자기 학습을 위해 끝까지 만들어보는 일 자체가 가장 중요할 수 있음
물론 새로운 학술 성과를 내야 하거나 고유한 프로젝트로 수익을 내야 할 때는 더 어렵지만, 그런 영역도 기존 것을 조금만 비틀어도 의외로 꽤 관대함
지금 딱 사이드 프로젝트에서 이런 상황을 겪고 있음
분야가 Information Retrieval이라 경험이 적고, 배울 수 있거나 통합할 수 있는 prior art가 당연히 많음
그래서 이 글을 읽고 나니 우선 내 걸 만들면서, 막히거나 아이디어가 필요할 때만 선행 사례를 들여다보는 쪽으로 더 마음이 감
한편 최근 나온 Clojure 다큐를 보면 Rich Hickey는 오히려 오랫동안 선행연구, 논문, 다른 언어를 깊게 파고든 뒤 작업한 것처럼 보였음
하지만 그 사람도 그 전에 이미 다른 언어들을 만들어봤으니, 더 큰 그림은 결국 직접 만들어보며 배우는 데서 시작된 셈임
너무 오래 고민만 하지 말고 일단 만들어보고, 실전에서 교훈을 쌓고 벽에 부딪힌 다음에 더 깊은 조사가 필요해지는 게 아닐까 싶음
이어서 "Easy made Simple", "Hammock Driven Development"까지 보고 나니 Clojure를 배우고 싶어짐
Clojure documentary on CultRepo channel: https://www.youtube.com/watch?v=Y24vK_QDLFg
Simple Made Easy: https://www.youtube.com/watch?v=SxdOUGdseq4
Hammock Driven Development: https://www.youtube.com/watch?v=f84n5oFoZBc
마감기한을 잡으면 scope creep 문제 대부분이 풀렸음
체감상 game jam이나 프로그래밍 대회처럼 하드 데드라인이 있는 프로젝트는 끝내기 쉬운데, 끝이 열려 있는 프로젝트는 완주가 훨씬 어려움
C++ 표준도 원하는 기능이 다 준비될 때까지 기다리지 않고 왜 3년마다 내보내는지와 비슷한 맥락으로 보임
https://news.ycombinator.com/item?id=20428703
글이 흥미롭긴 했지만, 저자의 생각이 좀 산만하게 흩어져 보였음
scope creep에 압도된다고 말하는 사람치고는, 글 끝에 온갖 주제의 링크가 잔뜩 달려 있을 정도로 엄청 많은 일을 해내는 편으로 보임
결국 배우고 이것저것 해보는 걸 진짜 좋아하는 타입 같고, rabbit hole로 빠지는 과정 자체가 머리를 즐겁게 자극하는 듯함
혼자 만드는 입장에서 크게 도움 됐던 깨달음이 하나 있음
필수 추상화처럼 보이는 것 대부분은 이름만 바꾼 scope creep였음
새 기능마다 flag를 붙이다가 내 코드에서 패턴이 보여서 규칙을 하나 세움
기능은 flag-off 동작에 대한 테스트가 없으면 배포하지 않기로 한 것임
그러자 flag를 탈출구가 아니라 제품의 일부로 보게 됐고, 백로그에 있던 기능 셋은 그렇게 생각하기 시작하자 자연스럽게 사라졌음
과도한 계획과 scope creep가 문제인 건 맞지만, 반대로 너무 즉흥 개발 쪽으로 흔들리는 것도 경계해야 함
가장 성공적이었던 프로젝트 중 일부는, 실제로 돌아가는 소프트웨어를 만들기 전에 데이터를 모델링하면서 기능 대부분을 미리 계획하고 검토했던 경우였음
그 단계에서는 무엇이 과한지 잘 모를 때가 많고, 나나 사용자가 원할 법한 기능을 빼면 나중에 코드 핵심을 크게 다시 설계하느라 시간을 많이 씀
반대로 틀리면 프로젝트가 너무 커져서 scope creep라고 부르게 됨
결국 이 판단은 도메인을 얼마나 잘 아느냐에 달려 있음
도메인을 생각보다 덜 알면 재작업이 많아지고, 생각보다 더 잘 알면 사실 크게 나갈 수 있었는데 baby step으로 시간을 낭비하게 됨
어느 쪽으로 가도 후회는 남아서, 결국 큰 판단의 문제라고 느껴짐
매몰비용 오류에 빠지면 안 되고, 박사과정 수준 주제를 몇 시간 조사했다고 해서 그걸 프로젝트에 꼭 써야 하는 건 아님
지금 문제에 딱 맞지 않으면 과감히 버리는 편이 맞음