brunch

라이킷 7 댓글 4

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 귤씨 Dec 31. 2022

2년 차 개발자가 깨달은 성장을 위해 꼭 필요한 마인드

최근 회사에서 많은 기능이 업데이트되면서 많은 에러들을 만나고 깨닫게 된 바가 있다.

바로 성장하기 위해 꼭 필요한 마인드 두 가지이다.

지금부터 깨닫게 된 과정과 그 마인드를 가져야 하는 이유에 대해 얘기해보고자 한다.

1. 6-70% 아는 건 모르는 거다.

그 정도만 알고 있었다면 차라리 모른다고 하는 게 낫다. 대충 알아서 코드는 짰겠지만 모르는 3-40%에서 비효율과 문제가 발생할 가능성이 높고, 또 그 3-40%에 대해 당장 물어봤을 때 대답할 수 없으니 문제가 나도 즉각적으로 대응할 수가 없기 때문이다.

내가 그 유경험자다. 돌아가는 코드는 짰지만 라이프사이클에 대해 확실히 알지 못해 에러를 낸 경험이 있었다. 그때 당시 선배와 대화할 때 나의 민낯이 아주 여실히 드러났었는데 애써 아는 척하기 바빴던 내 모습이 생각나 굉장히 부끄러운 기억 중 하나가 되었다.

처음 문제를 만났을 때 모르는 건 죄가 아니다. 하지만 그 후에 같은 문제를 만났을 때도 모른다면 그건 부끄러워해야 한다. 그러니 부끄러운 상황을 만들지 않도록

한 번 배울 땐 완벽하게 알고자 노력하고
그래도 모르는 게 나왔다면, 그때 빠르게 인정하고 배우려는 마인드를 탑재해야 한다.

아는 척 안됨 XXX

좀 더 구체적으로 말하자면 내가 사용하고 있는 언어나 프레임워크가 어떻게 돌아가고 있는지 확실히 이해하고, 내가 짜는 코드에 대해선 완벽히 설명할 수 있어야 한다는 것이다. (그래야 에러 발생 가능성을 낮추고 에러 대응이 빨라진다.)

사실 연차가 쌓일수록 '모른다'는 사실을 입 밖으로 내는 것이 쉽지 않을 것 같다. 사람들이 나에게 기대하는 지식수준이 높아지고, 그 기대에 못 미쳤을 때 사람들로부터 실망 섞인 모습을 봐야 하기 때문이다.

하지만 이걸 숨긴다고 해서 숨겨질 리 없다. 내가 겪어 온 과정을 이미 겪어 본 선배들이 내가 정확히 알고 있는 지의 여부 정도를 눈치 못 챌 리가 없다. 따라서 모르는 부분은 빠르게 인정하고 배워야 한다. 선배 입장에서도 그래야 더 알려줄 수 있고 나도 더 발전할 수 있는 것이다. 이때 알고 있는 지식의 범위를 말씀드리며 '여기까지는 알지만 이것까지는 확인을 못했다'라고 설명하는 것이 좋다.

모른다는 사실을 인정하지 않으면, 성장할 수 없다!

2. 문제가 나면 '누구의 책임인가' 상관없이 해결할 자세를 취해야 한다.

한 마디로 방어기제를 없애야 한다는 말이다.

내가 작업했던 파일에서 에러가 난 적이 있었다. 그걸 본 나는 분명히 그런 코드를 넣은 적이 없으니 '그럴 리가 없다'고만 생각하고 문제를 해결할 자세를 제대로 취하지 않았다. 그때 다른 분이 '여기서 났네요.'를 말해주셨고 갑자기 머리가 띵 했다.

내가 짜지 않았다고 해서 그 문제가 우리 프로젝트 문제가 아닌 건 아닌데.

나는 지금껏 나와 관련된 코드만 뒤적였다. 나도 책임을 지기 싫어서 반사적으로 취한 행동이었지만 어쨌든 니코드 내 코드 상관없이 풀어야 할 문제임은 변함이 없다. 그러니 일단 문제가 나면 원인해결하는 데 집중을 해야 한다. 내 탓이 아니더라도 내가 아는 원인이어서 도움을 준다면 그것 또한 팀에 좋은 일이니까 말이다.

이렇게 2년 차 개발자가 깨달은 성장하기 위해 꼭 필요한 마인드 두 가지를 얘기해 보았다.

나에겐 둘 다 너무 부끄러운 경험이라 다른 개발자들이 같은 경험을 하지 않길 바라는 마음과 같은 경험이 있다면 나도 그랬다는 말을 하며 적잖은 위로가 되었음 하는 마음이다. :)

keyword