기록이 왜 중요한가?
1. 이해의 차이
기록의 중요성에 대해 고민해 보니, 결국 이해도의 차이에서 비롯된다는 생각이 들었다.
무언가를 기록한다는 건 단순히 글을 적는 행위가 아니라, 타인에게 설명할 수 있을 정도로 충분히 이해한 상태여야 가능하다고 믿는다.
특히, “기록하는 사람은 같은 문제를 두 번 반복하지 않는다”는 말이 크게 와닿았다.
개발은 단순히 코드를 타이핑하는 일이 아니라, 문제를 정의하고 해결하는 과정이다. 그렇기 때문에 기록은 그 과정을 완전히 내 것으로 만드는 중요한 도구라고 생각한다.
나의 경험을 조금 이야기해 보자면, 시간이 부족하다는 이유로 친구들이 하는 걸 어설프게 따라 하거나 눈앞에 보이는 문제만 급히 해결할 때가 있었다. 그 순간에는 괜찮아 보일지 몰라도, 시간이 지나면 그 지식이 완전히 내 것이 아니라는 걸 뼈저리게 느꼈다.
나는 배우고 성장하기 위해 이 학교에 왔기 때문에, 진정한 개발자가 되기 위해서는 기록하는 습관을 통해 이해를 완벽히 다지는 과정이 꼭 필요하다고 생각한다.
2. 협업 능력 강화
기록 없이 혼자만 이해한 상태로 협업을 진행하다 보면, 반드시 소통의 문제와 이해의 차이에서 비롯된 문제가 발생한다.
예를 들어, 내가 생각한 기능과 팀원이 생각한 기능이 다르면 그 차이는 협업 전체에 큰 혼란을 불러온다.
그래서 주기적으로 내가 어떤 일을 하고 있는지, 어떤 기능을 만들었는지를 꾸준히 기록하고 공유하는 과정이 필요하다.
이렇게 하면 팀원들은 내가 진행한 작업을 명확히 이해할 수 있고, 전반적인 프로젝트의 흐름이 어긋나는 것을 사전에 방지할 수 있다.
결국 기록은 팀 전체의 생산성을 높이고 협업 능력을 강화하는 핵심 습관이라고 생각한다.
개발자가 단순히 자기 코드만 아는 사람이 아니라, 함께 성장할 수 있는 동료가 되기 위해서 기록은 필수적이다.
3. 커리어의 증거
우리의 가장 가까운 목표는 취업이다!!!!
내가 최근 어떤 고위 개발자분의 강연을 들은 적이 있는데 면접에서 꼭 말하는 부분은 정말로 자신이 이 프로젝트를 진행했는지에 대해 의문점을 가지고 얼마나 잘 이해했는지에 대해 묻는다고 언급했던 부분이 떠올랐다.
우리가 면접관들에게
제가 이런거 햇어요~라며 어영부영 이야기 하고 시간이 지나면 어떤 걸 했는지 까먹고.....
프로젝트를 많이 진행했어도 인간은 망각의 동물이여서 이게 계속해서 반복이 될 것이다!😅😅
But, 내가 어떤 프로젝트를 진행하던 중에 어떤 오류를 발견해서 어떻게 해결했는지에 대해 구체적으로 작성한 기록들이 많다면 이게 가장 면접관들에게 신뢰성있는 증거가 아니겠는가!!! 그렇기 때문에 우리는 기록을 해야한다.
그래서..기록 그거 어케 하는데?
자 이제 기록의 중요성을 다 알게 되엇다면 기록 도대체 뭘? 어떻게? 기록하는건데!! 라는 의문이 생길것이다. 기록, 어렵지 않다!!!!
가장 중요한 keyPoint!
시간이 지나도 다시 찾아봤을 떄 도움이 되는 것을 우리는 기록 해야한다! 내가 개발을 하던 중에 만나는 어마무시하게 많은 오류들! 인간이 똑같은 실수하지 않도록 오류를 내가 해결한 방법에 대해 기록을 해야하는 것이다..!
1. 에러/버그 노트
계속 이여기 하지만 어영부영 지피티라도 돌려서 오류? 찾을 수 있다!
근데 그게 왜 어떻게 해결되었는지, 내가 어떤 문제가 있었기 때문에 오류가 발생했는지 모르고 넘어가면 또 문제가 찾아오면 99.99% 또 해결 못한다!(인간은망각의동물)
내가 똑같은 실수를 하면 내가 또 찾아볼 수 잇도록 우리는 에러/버그 노트를 작성해여한다!
에러/버그 노트는 크게 6가지만 작성하면 된다
1. 무슨 문제였는지
2. 어떤 상황(환경)과 행동에서 발생했는지
3. 원인은 무엇이였는지
4. 어떻게 해결했는지
5. 같은 문제를 반복하지 않을 방법은 무엇인지
6. 배운점은 무엇인지
만 작성하면 당신은 에러/버그 노트의 고수가 될 수 있다.
2. 기술 선택 기록(ADP)
프로젝트를 하다가 보면 어떤 기술을 사용할지 고민하게 된다.
왜 이걸 선택했는지 이게 다른 것들이랑 도대체 뭐가 다르길래 내가 이걸 선택했는지 우리는 면접관들에게 알려줄 수 잇는 개발자가 되어야한다... (걍 지피티가 추천해줘서요 안된다 이말이야.)
뭘 적어야하냐!?!!
1. 상황 - 내가 어떤 상황에 처했는지, 내가 왜 이걸 선택하게 되었는지 원인을 알려줘여한다!
2. 후보 - 내가 할 수 있는 후보가 몇개가 있는지, 어떤 종류가 있는지, 각자 차이점은 뭔지를 알아봐야한다!
3. 선택 - 내가 최종적으로 선택한 기술과 왜 선택했는지에 대해 설명하면 된다
위 3개만 작성하면 당신은 ADP 작성도 SO EASY~
3. 실험 로그
실험 로그가 뭔데요.....? >> 실험 로그는 어떻게 하면 더 나은 결과를 도출해낼 수 있을까라고 고민 한 뒤에 여러가지 방법으로 적용해보는 것을 의미한다
실험 로그에서 가장 중요한것은 실패한 것에도 의의를 둬라~이다.
실험 로그는
1. 내가 기대하는 효과(가설)
2. 실험 절차(방법)
3. 실제로 나온 모습(결과)
4. 이걸 계속 해야할지? 다른길을 찾을지(다음 액션)
만 작성하면 된다
4. 런북
4번쨰로 작성해야하는 것은 런북이다.
런북은 말 그대로 따라 할 수 있는 매뉴얼로 내 벨로그 중 오디오 문제 글 처럼 순서대로 어떻게 해결하면 되는지 작성하는 방법이다.
특히, 런북을 사용하면 팀플인 경우 팀원에게 방법을 공유해서 팀원이 고통받지 않게 해줄 수 잇다 ㅎㅎ
5. 리팩터링
마지막 방법 리팩터링이다 리팩터링은 말 그대로 내가 예전에 작성했던 코드들을 다시 더 가독성 있거나 수정하기 편하게 재구조 하는 것이다!
리팩터링에서 주의해야할 점은 내가 왜 이걸 바꿨는지에 대해 기록하는 것이 매우 중요하다! 그렇기 때문에
1. BEFORE
2. 문제점
3. 해결 방법
4. ATFER
5. 효과
순서대로만 작성하면 된다!!!
최종적으로 정리헤보자면 그저 개발하다가 문제 생긴거 왜 생겼는지, 어케 해결했는지 등등 나의 활동에 대한 기록을 그저 작성하는 것이다.
완벽하게 이해하고 기록하는 습관을 가지기 위해 이 글을 난 작성한다!!
모든 여러분 기록하는 개발자가 되세요....💗 즐코!
