Onboarding 회고
시작 전의 생각
꽤 흔한 CRUD 사이트를 만드는 과제였다. Angular나 FastAPI는 처음이라 걱정은 되었지만, 크게 복잡한 기능도 없어서 많이 낙관했다. 유저와 관련된 기능도 회원가입과 비밀번호 암호화가 제외된 로그인 뿐이었고 내부에 Todo와 관련된 기능들도 생성, 삭제, 조회 ,수정 뿐이라 조금 공부하면 해볼만할 것이라고 판단했다. 파이썬이라는 언어의 측면에서도 알고리즘 공부때 많이 사용했으므로 걸림돌이 되지 않을 것이라고 생각했다.
문제 정의
-
구현에 매몰되어 구현이 늦어졌다.
온보딩 과제를 진행하는데 태용님의 권유로 ChatGPT를 배제하였다. 기존에도, 공식 Document를 읽고 원하는 지식을 얻는 습관이 필요하다고 생각하였기에 충분히 납득하였다. Document마다 다르긴 하지만 FastAPI와 Angular는 개념들에 대한 설명과 사용 예시가 나와있었고 작은 프로젝트를 진행하는 과정도 나와있었다.
처음에는 계획대로 Document를 수차례 읽으며 진행하였다. DB table 모델을 작성하거나, 스키마를 구성하는 것은 경험이 있었고 어려운 작업이 아니기 때문에 수월하게 흘러갔다. 지금 돌이켜보면 이때마저도 읽고 이해했다기보단 ‘내가 알고 있는게 맞구나’라는 생각을 확인하는 과정이었다.
점차 새롭게 내가 알고 이해하여 응용해야 할 요소들이 나타나자, 익히는 것보단 답을 찾아내는데 치우쳤다. 작성된 수 많은 설명은 넘기고 예시로 나온 코드가 나에게 적용 가능한 지만 확인했다. 다른 블로그나 아티클도 마찬가지였다. 질문에 대한 해답보단 작성자의 코드를 복사하여 붙여넣을 수 있는지가 최우선이 되었고, 내 코드에는 책임감과 자주성이 결여되었다.
-
계획을 세우는데 최선을 다하지 않아 효율성이 떨어졌다.
나는 개인적으로 완벽한 계획은 존재할 수 없다고 생각한다. 모든 일에는 의외성이 존재하다는 것, 출현 가능성 있는 장애물에 대한 대비가 필요하다는 것은 동의한다. 항해를 준비하며 보이지 않는 암초와 폭풍를 완벽히 감안하여 육지에서 일정 거리를 유지하도록 계산한 항로는 안전할 것이다. 하지만 여정에 지나치게 많은 시간과 물자가 소모되기 때문에 완벽하다고 할 수 없다. 곳곳에서 튀어나오는 문제들을 임기응변으로 해결하며 작업을 진행해 나가는 것이 최선이라고 생각한다.
내가 첫번째로 간과한 사실은 최소한의 대비는 해야 한다는 것이다. 항해 전, 소한의 구명정과 조끼를 구비하고 괴혈병을 예방하기 위해 식단에 라임을 추가하고 쥐를 구제하기 위해 고양이를 데려가는 것처럼. 내가 처음 작성한 계획은 빈틈이 없었다. 단 하나의 요소만 벗어나면 모든 질서가 엉킨다. 계획이 계획대로 진행되지 않았을 때를 대비한 쿠션용 시간이 없었다는 것을 간과했다. 터지는 에러를 감당할 준비를 하지 못한다면, 최소한 마주쳤을 때 해결해야할 시간이라도 설정했어야 했다.
두번째는 지킬 수 밖에 없는 계획도 실패한 계획이라는 것이다. 나의 계획은 너무 광범위했다. 마치 밤에는 ‘잠’, 오전 9시부터 오후 10시까지는 ‘생활하기’로 적은 하루 계획표를 보는 것 같다. 무엇을 하든 성공하는 계획이다. 2일차에 백엔드를 구현할 때 어떤 코드를 작성하고 있던 내 계획은 차질이 없다. 오후 5시에 로그인을 구현하고 있던, 완성을 앞두고 있던 모두 계획 내의 일이다. 내 계획은 무의미한 존재로 변질되었다.
Insights
-
코드에 대한 책임감을 가져야 한다.
그동안 작성했던 코드들은 일시적인 사용이 목적이었다. 길어봤자 한 달짜리 프로젝트에 들어가는 코드들이기 때문이다. 이제 내 코드는 반영구적으로 사용될 것이라고 생각한다. 알파리뷰 서비스 내에 계속 남아서(주석처리 되지 않는 이상) 컴파일된다. 언제 어떻게 영향을 끼칠지 모르기 때문에 내가 완벽히 이해한 코드여야 한다. 작동되는 것은 최종목표가 아닌 최소한의 분기점이다. 어떤 메소드를 어디에 왜 썼는지, 로직은 어떻게 이루어지는지, 사용 가능했던 다른 옵션은 무엇이었으며 여러가지 측면에서 비교 가능한지 이해해야 하며 남에게 설명하고 납득시킬 수 있어야 한다.
블로그와 달리 공식 Document는 Tool 개발자들이 작성하였기 때문에 공신력은 있겠지만, 내가 이해하는 것과는 별개다. 그 문서의 목적은 아무 의심없이 사용할 수 있도록 설득하는 것이 아니라 사용자의 이해를 돕는데에 있다. “이 코드를 왜 썼나요?” 라는 질문에 대한 답변은 “Document에 나와있는데요”가 아니라, 그것을 읽고 내가 치열하게 생각하고 고민하여 내린 결론이어야 한다. 내가 판단을 내린 추론 과정을 설명할 수 있어야 하고 다른 사람이 수긍할 수 있어야 한다.
내가 개인적으로 멋있다고 느낀 개발자에게 이전에 들은 ‘주니어가 할 수 있는 좋은 질문이 갖춘 형식’에 관한 이야기도 일맥상통하다고 생각한다. 심도있고 진중하게 고민해야 가능하기 때문이다. 이번 온보딩 과정동안 나에게 명백히 부족했다.
-
좋은 질문의 형식
목표 : 이 질문을 해서 달성하고자 하는 것은 무엇인가?
문제 : 현재 질문을 하게 된 배경인 문제는 무엇인가?
원인 : 해당 문제가 발생하게 된 원인은 무엇인가?
3개의 가설과 근거 : 문제 해결에 대해 스스로 세운 가설과 그 근거
-
-
계획도 준비가 필요하다.
내 계획이 상세하지 않았고 비현실적이였으며 두리뭉실해진 원인은 계획을 세우기 위해 준비하지 않았기 때문이다. 우선 내가 무엇을 해야할 지를 명확히 파악했어야 했다.
“CRUD 사이트를 FastAPI와 Angular로 만들어야 하는구나” 보단
“로그인과 회원가입 기능이 필요하구나. 로직이 무사히 완료되면 다른 페이지로 넘기는 작업도 있어야 하고, 프론트단에 유저 정보도 저장해야 하네. 쿠키, 세션이 어떤 차이가 있고, 어떤 걸 사용할지 좀 알아봐야 겠다.” 가 이로운 준비일 것이다.
내가 모르는 게 투성이인 상황에서 그럴듯한 계획이 세워질 리 만무하다. 그럼 응당 파악해야 한다. ‘내가 무엇을 모르는가?’, ‘어디서, 어떻게, 무엇을 알아봐야 하는가?’가 선행되야 한다. 계획을 세우는 행위 자체는 좋은 준비를 한 것처럼 착각하면 안된다. 계획을 올바르게, 최선을 다해 세우고 나서야 비로소 좋은 출발을 위한 기틀이 마련된 것이다.
느낀점
그 외 온보딩 프로젝트 진행간 느낀 점 || 배운 점
- 무슨 느낌인지 아는 데 설명을 못하는 것은 모르는 거다. 기초적인 용어, 개념부터 확실히 알고 가야겠다.
- 계획을 너무 길게 잡아 생각보다 빨리 끝날 것은 지금은 우려하지 말자. 지금 내 수준에서 그럴리가 없다.
- 계획을 넉넉히 잡자. 지금 내 수준에선 그것도 안넉넉하다.
- 해결이 안되는 가장 큰 이유는 원인을 모르기 때문이다.
- 공식 Document에서 가져온 코드라서 신뢰성 있는 것은 알겠는데, 이해하고 썼는지는 별개의 문제이다.
- 안풀리는 문제가 자고 일어나서 다음날 아침에 보면 생각보다 쉽게 해결되는 경우가 왕왕 있다. 너무 하나에 매몰되지 말자.
- 0에서 90% 만드는 것 보다 90%에서 100%로 수렴시키는 것이 훨씬 힘들고 어렵다.
- 이름은 애초에 잘짓자. 컴포넌트, 함수, 변수 이름 찾아서 일일이 바꾸는 건 참 힘들다.
- 커밋메시지를 미리 쓰는 습관은 확실히 길을 잃을 확률을 줄여준다.
