소프트웨어 학습 태도

소프트웨어 학습 태도를 읽고 느낀점을 기록한 포스트이다. 글의 평가는 나의 실력이 너무 부족해 하지 못하고 나의 상황에 대입해 보면서 나는 어떤 위치인가 고민하는 글이다.

1. 내가 걷는 속력과 방향을 인지하자.

나에게 가장 부족한 부분이 아닐까 싶다. 회사에서는 보통 기능 단위로 일을 받아서 진행한다. 목표는 정해져 있다. 그 목표를 향해서 올바른 방향으로 제한 시간 안에 걸어가야 하는데 갈피를 못 잡고 이리저리 헤매거나, 너무 느린 속도로 가버린다거나 아니면 중요한 부분에서 속도를 너무 내서 주변을 살피지 못하고, 중요하지 않은 부분에서 너무 늦게 걷는 것 같다. 올바른 방향과 알맞은 속도로 일을 진행해야 하는데 헤매면서 날리는 시간이 너무 많은 것 같다. 이 카드(업무)가 끝이 나야 카드 오너도 다음 업무를 진행하는데 나떄문에 늦어지거나 카드 방향을 바꿔야 하는 경우가 생기는 것이다. 올바른 방향과 알맞은 속도, 이 두 가지 개념을 어떻게 잡아야 할지 많은 고민이 필요해 보인다.

2. 익숙한 것을 내려놓고, 낯선 방식으로 해결하자.

나는 스스로 배운 것을 한 번이라도 써먹으려고 노력하는 편인 것 같다. 하지만 문제는 항상 1번에서 터진다. 목표를 달성하기 위해서는 방향/속도가 중요한데 한번 어긋난 방향/속도로 인해서 나에게 주어진 시간이 얼마 남지 않았다는 것을 깨달았을 때는 ctrl + c/v의 연속이 돼버린다. 또한 새로운 시도를 해보았을 때 또는 이게 아닌걸 깨달았을 때 시간이 너무 없다는 것을 깨닫고 이건 아닌데.. 싶은 코드를 그냥 올리기도 하는 것 같다. 지속적으로 써야 피가 되고 살이 되는데.. 피가 되려다 말고, 살이 되려다 마는 느낌이다. 다만 의도적으로 써먹으려고 하는 것에 다행이라고 느끼며 지금 태도를 유지해보도록 노력해봐야겠다.

3. 개구리를 해부하지 말고, 직접 만들어봐라.

요즘 udemy에서 강의를 하나 듣고 있는데 바닐라 스크립트로 20개의 작은 프로젝트를 만드는 것이다. 20 Web Projects With Vanilla JavaScript 라는 강의인데 사실 이것도 개구리를 해부하는 형태의 학습이라 느껴진다. 하지만 클론 코딩을 하면서 많은 것을 배우고 깨달았다. 개구리를 만드는 것도 개구리 안에 무엇이 있는지 알아야 개구리를 만들 수 있다. 무작정 개구리를 만들다가는 두꺼비가 나올지도 모르고, 올챙이가 나올지 모른다. 일단은 개구리에 대해서 학습하고 이해해야 개구리에 대해서 조금 더 이해할 수 있다. 내가 사용하는 기능/기술이 정확한 이 해없이 그냥 사용만 하고 있다는 것을 깨달았다. 사실 이 글에서 내가 더 중요하게 생각한 것은 개구리를 직접 만들어봐라 보다는 개구리를 깊이 있게 이해해야 한다는 것이다. 나는 여태까지 개구리가 무엇인지 깊은 이해 없이 이게 개구리인지 아닌지 구분도 없이 그냥 개구리 일 거라 생각하며 일은 한 것이다. 내가 알고 있는 것이 무엇인지, 내가 알고 있는 게 맞는지 우선 판단해봐야겠다.

4. 자존심을 버리고, 자존감을 키우자.

사실 나는 자존감이 굉장히 낮은 편이다. 항상 일정은 밀리고, QA를 넘기면 빨간 줄투성이고, 버그도 양산한다. 이러다 보니 내 자존감은 점점 굴을 파고 저 밑 지하로 들어가 버렸다. 또한, 퇴근 이후에는 애를 돌봐야 하므로 절대적인 학습 시간이 다른 사람에 비해 현저히 부족하다는 생각을 늘 하고 있다. 이런 게 반복되다 보니 자존감이 굉장히 낮은 편이다. 누군가 칭찬을 해줘도 그냥 빈말로 속상하지 않도록 한 말 같고, 조그마한 비난이나 잘못에 크게 반응한다. 이러면 안 돼야지 하면서도 이 자존감을 높이는 게 쉽지 않다. 누군가가 나에게 질문을 할까 봐 겁을 내고 질문을 사전에 차단하기도 한다. 이런 방식은 나에게도, 팀에게도 해로운 일이란 걸 알지만 입사 이후 2년이 되었기에 더욱 겁이 난다. 아직도 이걸 모른단 말이야? 라고 생각할까 봐 말이다. 그래서 CTO님이 무섭게 느껴진 것일 수 있다. 하여튼 자존감을 높이는 방법은 작은 성공을 누적해서 큰 성공을 이루는 게 가장 좋은 방법이라 여러 매체를 통해서 배웠다. 효과가 있을진 모르겠지만 해보는 방법밖에 없어 보인다. 일단 해보자.

5. 결과만 보기보다는 과정을 보자.

사실 이거는 아직 의미가 없어 보인다. 회고를 통해서 과정을 되짚어 보려고 하지만.. 일정이 어그러지는 순간 과정을 기록하는 것을 포기해버리는 경우가 종종 있었다. 그래서 막상 회고를 하려 해도 남은 게 없다. 내가 언제 무엇을 했는지 회고 시점에는 기억이 나지 않기 때문이다. 그래서 요즘은 내가 언제 무엇을 만들었고, 무엇을 해결했는지 적는 노력을 하고 있다. 입사 초기, 이전 회사에서는 꾸준히 했는데… 몇 달 전까지만 해도 이런 것에 손을 놨었다. 이미 일정이 늦어진 상태에서 이런 것을 하는 것이 괴롭고 자괴감이 많이 들었기 때문이다. 일단 결과를 분석하기에 앞서서 과정을 기록해 놓는 습관부터 들이려 한다.

6. 실수를 반복하면서 적어도 하나씩 개선하라.

내가 자주 하는 실수를 대표적으로 2가지만 이야기해보면 다음과 같다.

1. 테스트를 소홀히 한다.
2. 기획문서를 소홀히 읽고 반영한다.

둘 다 심각한 실수이다. 테스트를 소홀히 하니 배포 이후 문제가 발생해 롤백을 자주 하고, 기획문서를 소홀히 읽다 보니 나중에 놓친 부분을 작업하려다 보면 기존 구조, 코드를 몽땅 고쳐야 하는 경우도 발생하기 때문이다. 그래서 요즘은 ToDoList를 작성해서 하나씩 해결하는 형태로 진행하는데 이게 꽤 효과 있다. 이것도 실수를 개선하는 방법의 하나일 텐데 혹시나 나와 같은 실수를 하는 사람들이 있다면 ToDoList 작성을 해보는 것을 추천한다.

7. 스스로 여러 가지 답을 찾고, 남에게 공유하라.

사실 TIL도 하고 있고 개발 블로그도 하고 있다. 한 번이지만 오픈 소스에 PR 날려서 APPROVE 받은 기억도 남아 있다. (이때 날아온 메일은 아직도 보관중.. ㅋㅋ) 이 모든것들이 사실 남들에게 공유하는 목적보다는 내가 나중에 이런 일을 또 할 때 기억을 되살리기 위한 것들이긴 하지만 사람이란게 간사하게도 매일 같이 몇 명이 블로그를 보았는지, 가장 인기 있는 그이 무엇인지 확인하고 있다. 그리고 안타깝게도 내가 올린 글들의 대부분은 좋은 글이 아니다. 내가 학습하면서 배운 것들은 정리하거나 아니면 문제가 닥쳤을 때 이를 해결한 방법 위주로 작성했다. 다른 좋은 개발자들처럼 무언가를 분석하고, 실험해보고, 만든 것의 결과물이 아니다. 나도 이러한 글을 써야지 하지만 아직 실력이 많이 부족한 탓에 쉽지 않다. 하여튼, 앞으로 조금 더 공부하고 공유 할 수 있도록 해보려 한다. ( 주 2회 블로그 작성을 목표로 하였었는데.. 진짜 쉽지 않다. )