Skip to main content

단점을 인정하고 ‘성장하는 개발자’ 되는 법

Less than 1 minuteCareerArticle(s)blogyozm.wishket.comcareertips

단점을 인정하고 ‘성장하는 개발자’ 되는 법 관련

Career > Article(s)

Article(s)

단점을 인정하고 ‘성장하는 개발자’ 되는 법 | 요즘IT
2024년의 상반기가 끝나고 어느덧 평가 시즌이 다가왔다. 소심한 성격의 소유자인 나는 평가 시즌이 다가올 때마다 불안감에 휩싸이곤 한다. 내가 불안한 이유는 ‘최악의 평가를 받으면 어떡하지?’라는 생각과 나의 단점을 지적받는 것이 두렵기 때문이다. 어느 유명한 경영학자는 사람들에게 자신이 가진 단점을 고치려고 하기보다, 장점을 극대화하는 데 집중하라고 조언했다. 그러나 단점을 극복하려 노력하지 않고, 그대로 둔다면 결국 언젠가 내 발목을 잡을지도 모른다. 그렇다면 어떻게 도움이 되는 방향으로 피드백을 수용할 수 있을까? 이번 글에서는 내가 단점을 극복하고 성장할 수 있었던 방법과 생각을 공유해 보고자 한다.

피드백에 대한 공포, 나만 가진 걸까?

2024년의 상반기가 끝나고 어느덧 평가 시즌이 다가왔다. 소심한 성격의 소유자인 나는 평가 시즌이 다가올 때마다 불안감에 휩싸이곤 한다. 내가 불안한 이유는 ‘최악의 평가를 받으면 어떡하지?’라는 생각과 나의 단점을 지적받는 것이 두렵기 때문이다. 어느 유명한 경영학자는 사람들에게 자신이 가진 단점을 고치려고 하기보다, 장점을 극대화하는 데 집중하라고 조언했다. 그러나 단점을 극복하려 노력하지 않고, 그대로 둔다면 결국 언젠가 내 발목을 잡을지도 모른다.

개인적으로 참여하는 독서 모임에서 이러한 마음을 솔직하게 털어놓았더니, 그 자리에 있던 대부분의 사람들이 공감했다. “소심하기 때문이 아니라, 인간은 원래 피드백을 두려워하는 것 같아요. 타인의 평가는 내가 예측하고 컨트롤하기가 힘들니까요.” 그렇기 때문에 피드백을 자주 주고받을수록 좋다는 의견이 많았다. 자주 의견을 주고받다 보면 예측할 수 있는 범위가 생기고, 조언을 통해 단점을 개선해 나갈 수도 있다.

그렇다면 어떻게 도움이 되는 방향으로 피드백을 수용할 수 있을까? 이번 글에서는 내가 단점을 극복하고 성장할 수 있었던 방법과 생각을 공유해 보고자 한다.

<출처: ChatGPT 생성>
<출처: ChatGPT 생성>

단점을 인정하고 성장할 수 있는 방법

피드백을 잘 수용하기 위해서는 우선 본인이 가진 단점이 무엇인지 알고, 받아들이고 인정해야 한다. 지금부터 내가 적용해 본 몇 가지 방법을 소개하고자 한다. 필자의 개인적인 경험이지만, 본인에게 맞는 방법으로 적용해 볼 수 있다면 참고해 봐도 좋을 것 같다.

1) 여러 개의 정체성 만들기

영화 해리포터에는 ‘호크룩스’라는 마법적 물건이 등장한다. 이 물건에는 볼드모트의 목숨이 여러 개로 쪼개져서 담겨있다. 그중 일부가 파괴되더라도 볼드모트는 죽지 않는다. 나는 이 호크룩스를 보면서 인간의 정체성을 떠올렸다. 무언가 한 가지에만 깊이 매몰된 사람은 그 분야에서 절망을 겪으면, 다시 일어서기 어려울 만큼 무너질 수도 있다. 조금 과한 비유일 수도 있지만, 내 정체성도 마치 호크룩스처럼 여러 개로 나누어서 보관하면 더 안전하지 않을까라고 생각했다.

<출처: ChatGPT 생성>
<출처: ChatGPT 생성>

흔히 회사에서의 자아는 따로 분리해서 생각하라고 하지만, 경험상 현실적으로는 굉장히 어려운 일이었다. 회사에서 상처받는 일이 있으면, 집에 돌아와서도 마음이 쓰리고 아팠다. 그래서 찾아낸 방법이 바로 내가 몰입할 수 있는 분야를 찾고, 그에 맞게 정체성을 여러 개로 나누는 것이다. 예를 들어, 퇴근 후에 취미활동을 하거나, 스터디그룹에 참여하는 등의 방법이 있다.

이를 통해 회사 밖에서도 인정받고 자아를 실현할 방법이 늘어난다. 정체성을 여러 개로 분산해 두면 어떤 날은 회사에서 일이 좀 안 풀리더라도, 취미활동이나 스터디에서 성취감을 느낄 수도 있다. 반대로 취미활동과 스터디에 권태감을 느낄 때, 회사에서 그만큼 더 열정을 쏟아 일할 수 있다. 실제로 이렇게 하면서 성과에 대한 집착을 줄이고, 큰 기복 없이 일정한 수준의 능률을 유지할 수 있게 되었다. 현재 회사에 소속된 ‘개발자’라는 정체성에 과몰입해 힘들다면, 이런 방법도 활용할 수 있다.

2) 피드백 받은 내용을 잘 보이는 곳에 두고 자주 보기

피드백을 통해 알게 된 본인의 단점을 인정했다면, 이제 개선해 볼 차례다. 앞서 잠깐 말한 것처럼, 타인의 평가는 내가 예측하고 컨트롤하기 어렵다. 그래서 예측 범위를 좁히려면 단점이 발견된 그 즉시, 그게 어렵다면 짧은 주기로 피드백을 받아 보면 좋다. 대신 피드백 받은 내용은 잊어버릴 수 있으니, 잘 보이는 곳에 적어두고 자주 들여다보도록 하자. 포스트잇도 좋고, 개인 블로그도 좋다. 피드백을 볼 때는 다음 사항을 염두에 두면 좋다.

  • 최근에도 이러한 행동을 했는지?
  • 이 행동을 하지 않기 위해 어떤 노력을 하고 있으며, 그 노력은 효과가 있는 것 같은지?

나의 경우, 원온원 미팅에서 받은 피드백을 사내 위키 개인 페이지에 기록하고, 데일리 로그(업무일지)를 적을 때마다 한 번씩 확인하고 있다. 피드백을 누구나 볼 수 있는 공개된 페이지에 적어둔 이유는 특별히 사적인 내용이 아니기 때문이다. 굳이 약점을 숨기려고 하면 부끄러운 비밀이 되지만, 이를 드러내고 고치려고 노력한다면 나에 관한 정보 중 하나일 뿐이라고 생각한다.

참고로 내가 받은 피드백들은 다음과 같다.

개인 위키에 정리해 둔 피드백 내용 <출처: 작가 캡처>
개인 위키에 정리해 둔 피드백 내용 <출처: 작가 캡처>

이를 정리해 보면,

  • 혼자서 일함
    • 사람들과 스몰톡하기
    • 완벽주의를 줄이고 자주 공유하기
  • 일하는 즐거움을 좀 찾아야 함
    • 본인이 좋아하고 즐거워할 만한 일이 뭔지 찾아내기
  • 손이 너무 빨라서 실수 가능성이 높다.
    • 신중히 처리해야 하는 일의 경우, 느리게 할 수밖에 없는 환경 만들기
    • 생각을 많이 한 후에 작업을 천천히 시작하기

이 중에서 첫 번째 항목은 스스로도 느끼고 있는 부분이었다. 아마 대부분의 사람이 본인도 알지만, 어쩌지 못하는 부분이 있을 것이라고 생각한다. 나는 사람들 앞에서 실수할까 봐 경직된 모습을 보이는 것, 그리고 같은 이유로 아이디어를 검증하기 전 공유하는 걸 부담스러워한다는 것을 잘 알고 있었다. 조금 실수를 한다고 크게 질책하는 팀도 아니고, 꼭 완벽하게 검증되지 않은 아이디어라도 팀에 먼저 공유하면 팀원들이 같이 고민해 줄 수도 있는 건데 말이다.

이러한 단점을 고치기 위해 구체적인 방법을 떠올려 보았다. 생각해 보니 먼저 스몰톡을 건넨 적이 없는 것 같아, 하루에 한 번 이상은 다른 사람에게 일과 상관없는 이야기를 건네보기로 했다. 그리고 아이디어는 어느 정도까지만 검증해 본 후, 팀원들에게 직접 찾아가서 의견을 물어보고 있다.

두 번째로 ‘일하는 즐거움’을 찾기가 상당히 어려웠다. 개발이 재미없는 것은 아니었다. 다만 신나게 하고 있지는 않았다. 회사 일을 재밌으려고 하는 것은 아니지 않냐는 나의 반문에, “신나서 즐겁게 해야 오래 할 수 있다”라는 답변이 돌아왔다. 자리로 돌아와 곰곰이 생각해 보았다. 내 개인 프로젝트가 아니라는 부담감 때문인지, 아니면 업무가 나와 맞지 않는 것인지는 정확히 모르겠다. 그러나 퇴근 후 개인 프로젝트를 할 땐 개발이 재밌는데, 회사 업무에서는 그만큼의 희열이 없었다.

그래서 어떤 일을 하다가 재미있다는 생각이 들 때면 바로 메모하기 시작했다. 유난히 지루하다는 느낌이 드는 때도 메모했다. 회사 비즈니스 중에 좀 더 관심이 가는 분야가 있는지, 어떤 사람과 어떻게 일해서 즐거운지 등을 적었다. 내가 어떤 유형의 일을 좋아하는지 파악하는 게 우선이라는 생각이 들었기 때문이다.

마지막 피드백은 미처 생각지도 못한 내용이라 다소 충격적이었다. 우선 내 손이 빠른 편이라고 인지하지 못했고, 그게 장점인 동시에 단점이라는 사실도 놀라웠다. 그렇다면 느리게 할 수밖에 없는 환경을 만든다는 건 뭘까? 예를 들면, git 명령어를 너무 빠르게 치는 경향이 있다면, diff를 유심히 볼 수 있도록 GUI를 이용하는 환경으로 바꾸는 것이다. 그래서 이제 나의 IDE에서는 git 명령어를 치면 vim 화면이 아니라 GUI가 실행된다.

물론 빨리하던 것을 더 느리게 한다는 점이 답답했고, 적응하기까지 힘들었다. 그러나 지금은 생산성보다는 실수할 가능성을 줄이는 것이 먼저라는 점에 동의했으므로 꾹 참고 적응했다. 또한 생각을 좀 더 많이 하려고 코딩을 시작하기 전, ‘최소 2시간 고민하고 시작하기’라는 룰도 만들었다.

<출처: freepik>
<출처: freepik>

3) 피드백해 준 사람에게 확인받기

피드백 개선을 위해 구체적인 방법을 마련하고 실천했다면, 다음번 피드백 시간에는 확인을 받아보자. 나에게 조언해 준 상대에게 내가 노력했던 점을 이야기하고, 상대의 의견을 듣는 것이다. 이것은 상대에게 변명하기 위함이 아니라, 메타인지의 한계를 극복하기 위함이다. 사람은 누구나 본인에게 우호적일 확률이 높기 때문이다. 게다가 열심히 노력까지 했다면 자신을 기특하게 여길 수도 있다. 물론 노력한 건 잘한 일이지만, 문제점이 실제로 개선되었는지는 별개의 일이고, 이것을 판단하는 것은 남의 눈이 좀 더 정확하다.

만약 상대방이 내 이야기를 무리 없이 잘 들어준다면, 문제가 개선됐을 것이다. 그러나 내 얘기를 그저 핑계나 합리화로 받아들이는 것 같다면, 아직은 더 개선이 필요하다. 이럴 땐 방법이 잘못되었는지, 아니면 단순히 시간이 좀 더 필요한지 점검해 볼 필요가 있다.


더 나아갈 곳이 있음을 긍정적으로 바라보자

사실 누구나 피드백에 초연하기란 정말 어렵다. 하지만 피할 수 없다면 차라리 즐겨야 한다. 몸에 좋은 쓴 약처럼 생각하고 영양분으로 흡수하고자 노력한다면, 평가 시즌을 긍정적인 시간으로 만들 수 있다. 몇 번의 피드백을 거치면서 나는 많이 배우고 성장할 수 있었다.

특히 개선 방안을 찾아가는 과정은 나를 지속적으로 성장시키는 중요한 요소였다. 그중에는 조금이나마 개선된 것도 있고, 아직 노력이 필요한 것도 있다. 무엇보다 내가 마음을 열고 피드백을 받아들이고, 실천으로 옮기고자 노력했다는 점 자체가 큰 성취였다. 만약 현재 속해있는 팀에 피드백 문화가 없었다면, 나에게 독이 되는지도 모르고 계속 같은 방식으로만 일했을 것이고, 이토록 소중한 성취감도 얻지 못했을 것이다.

피드백을 통해 더 나아질 수 있다는 건 좋은 일이다. 미래에 대한 기대감이 있기 때문이다. 물론 앞으로도 때때로 불안이 엄습하겠지만, 이제는 어떻게 행동해야 할지 잘 알고 있다. 만약 이 글을 읽는 독자분들 중에 혹시 나와 같은 걱정을 가진 사람이 있다면, 다양한 방법으로 시도해 보기를 추천한다. 하다 보면 피드백이 덜 무서워지고, 오히려 더 나은 방향으로 성장할 수 있는 기회라고 받아들일 수 있을 것이다. 또한 누군가에게 조언해 줄 때도 구체적으로 방향을 제시해 줄 수 있는 본인을 볼 수 있게 될 것이다.


이찬희 (MarkiiimarK)
Never Stop Learning.