[일일 회고] 2023-03-15 (수)

실패-피드백-실행의 사이클을 의식적으로 수행하기.

​

일반적으로 학습을 하다가 모르는 부분이 생기거나 개발을 하다가 에러가 발생하면 우리는 문제를 해결하기 위해 에러 메시지를 읽거나 구글링을 해보거나 케이스를 바꿔보는 등 여러 가지 시도를 하게 된다. 어쩌면 당연하다는 듯이 실패-피드백-실행을 수행하고 있다는 생각이 들 수도 있지만, 이 과정을 조금 더 의식적으로 행하는 것이 중요하다고 생각한다.

​

#실패

사람은 일반적으로 실패를 싫어하는 것 같다. 어쩌면 쪽팔리기도 하고 스스로 실패했다는 것에 기분이 좋지 않아서 그렇지 않을까. 그래서 당장의 실패를 빠르게 무마하기 위해 그 상황을 피해버리거나 혹은 근본적인 문제를 해결하는 것이 아닌 당장 눈앞의 문제만 해결하고 덮어버리려고 한다. 나는 실패라는 상황을 게임의 퀘스트처럼 재밌게 여길 수 있다고 생각이 들었다. 실패는 우리를 성장시켜 줄 수 있는 아래와 같은 소중한 기회를 제공한다고 생각한다.

​

1. 내가 무엇을 모르고 있는지 확인할 수 있다.

2. 성장할 수 있는 작은 미션이 생긴다.

3. 더욱 기억에 잘 남는다.

​

실패는 경험치다. 그리고 사람들은 레벨 업에 혈안이 되어있지만 제대로 된 사냥터를 찾아가는 사람들은 많지 않다. 다들 경험치를 적게 주는 몬스터가 약한 사냥터를 많이 찾는다. 그러나 실패라는 것을 경험할 수 있는 사냥터에 가면 사냥은 힘들겠지만 많은 보상과 경험치를 얻는다.

​

실패를 겪을 때 많이들 실수한다고 생각되는 부분은 왜 실패를 했는지에 대한 분석 없이 '이렇게 하면 해결된다더라.' 하고 넘어가는 것 같다. 나도 그랬지만 이렇게 실패를 겪고 나면 결국 남는 게 없다. 실패를 통해서 배우는 게 없으니 나중에도 똑같은 실패를 하게 된다. 그래서 나는 실패를 분석하려고 했다. 잠깐 다른 이야기지만, 지인 중에 주니어 개발자인 분이 계시는데 '타입스크립트에 대한 피드백이 들어오면 이해를 하나도 못하고, 검색해도 이해가 잘 안 된다. 타입스크립트에 대한 기반이 없었다. 그래서 타입스크립트 서적을 읽기로 했다.'라고 스스로 피드백을 한 내용을 들려주셨다. 그런데 나는 실패에 대한 분석과 피드백이 너무나도 추상적이라는 느낌이 들었다. 이상적이긴 하지만 실제로 실천하기엔 어렵지 않을까? 정말 효율적일까? 그래서 나는 아래와 같이 실패와 피드백을 쪼개보는 것을 추천을 드렸다.

​

실패

타입스크립트에 대한 기초가 하나도 없어서, 타입스크립트를 고도화 해서 사용하는 방식을 제안을 받았을 때 이해를 못 했다.

- 타입스크립트의 자료형에 대해 잘 모른다.

- 타입스크립트 문법 자체가 아직 조금 헷갈린다.

- 타입스크립트에서 어떨 때 타입을 정해줘야 하는지 조금 헷갈린다.

- 타입스크립트에서 고도화란 어떤 의미일까?

- 고도화는 뭐가 좋을까?

- 타입스크립트에서 왜 타입을 중복해서 잡으면 안 된다고 하는 걸까? 그냥 중복해서 잡아도 상관없는 거 아닌가? 정확히 체크하면 되는 거 아닌가?

​

위와 같이 실패를 쪼개보니 당장 무엇을 실천해야 할지 조금 뚜렷해지는 느낌이 들었고 지인분 께서도 너무 좋은 것 같다고 얘기를 해주셨다. 나도 위와 같이 실제로 개발을 하면서, 혹은 학습을 하면서 겪는 실패에 대해서 자세히 살펴보았다.

​

1. 현재 실패한 것에 대해 어떤 것을 모르고 있어서 실패했을까? 정확히 무엇을 모르고 있을까?

2. 만약 알고 있었다면 왜 실패했을까?

3. 정확히 무엇이 원인일까?

​

일반적으로 실패를 했을 때 '너무 어려워~, 잘 모르겠어.'처럼 큰 범위의 문장으로 퉁 쳐버리곤 하는데 이런 방식이 아니라 스스로와의 대화를 통해 정확한 실패의 원인을 분석하니 무엇을 피드백해야 할지는 자연스럽게 따라오는 느낌이었다. 그리고 곧바로 실행에 옮겼다. 그렇게 하나의 사이클을 완료했고, 그 내용은 아직도 머릿속에 잘 남아있다.

​

당장의 변화가 느껴지니 더욱 의식적으로 수행할 수 있을 것 같다.