회고를 하는 이유
내가 회고를 하는 이유는 간단하다. 문서화를 통해서 언제든 내가 그때 당시의 내 생각을 되돌아 볼 수 있고, 동시에 습득한 지식을 체계화 할 수 있기 때문이다. 즉, 한달 동안 배운 것을 까먹지 않고 체득하는 수단으로써 회고를 해본다.
코딩은 혼자서 하는 것이 아니다
문제 해결 과정
[문제 정의의 필요성]
2주차가 되면서 처음으로 태스크를 할당 받았다. 한번 문제 해결 과정을 서술해본다. 회사에는 정말 많은 코드가 있다. 그리고 내가 살펴봐야 할 코드는 어딘가에 숨겨져 있다. 그렇기 때문에 어떤 부분을 집중적으로 살펴봐야 하는 지를 확정하여 문제 영역을 줄이는게 매우 중요한 능력 중 하나다. 즉 첫번째로 해야 할 것은 문제를 발생시키는 영역을 구체적으로 좁혀내는 것이다.
[모든 코드를 읽을 순 없다]
위와 같이 문제 영역을 줄이기 위해선 어떻게 해야할까? 내가 첫번째로 취한 방법은 모든 코드를 읽어보는 것이었다. 왜냐하면 어느 정도 코드에 대한 이해가 있어야 누구에게 질문을 해야 할 지 결정할 수 있고 딱 필요한 내용만 질문할 수 있다고 느꼈기 때문이다. 그러나 이것은 매우 큰 패착이었다. 난 모든 코드를 읽을 수 없었고 읽어서도 안됐다. 여기서부터 내 능력을 정확히 인지하지 못한 실수가 있었던 것이다.
[탑다운 방식의 중요성]
모든 코드를 읽으려는 시도를 하면서 내가 깨달은 것은 회사의 코드가 엄청나게 방대하다는 것뿐이었다. 물론 많은 코드를 읽었기 때문에 대략적으로 프로덕트에 대한 이해도를 높일 순 있었으나, 내가 속한 곳은 회사였고 연구가 아닌 문제 해결을 해야 했다. 그리고 문제 해결은 문제적인 코드의 영역이 좁아질수록 유리했다. 난 평소에 바텀업 방식으로 기술 자체를 이해하는 것을 즐겨왔는데 온보딩 과정에선 이 습관을 자제할 필요가 있었다. 그리하여 나는 탑다운 방식을 이용하여 문제 영역을 축소하여 필요한 모듈의 코드만 읽었고 문제에 대해서 완전히 이해했다고 생각했다.
[의사소통능력 == 문제해결능력]
이해한 내용을 문서화 하기 전에 나의 매니저에게 먼저 진행된 내용을 공유드리니 매우 충격적이게도 내가 분석한 코드는 이미 레거시가 된 것이었다. 난 매우 충격을 받았고 처음부터 다시 시작해야만 했다. 이때 나의 매니저가 먼저 다가와서 문제 해결의 큰 방향성을 제시해주었다. 한 3분 정도 코드를 보고 준 피드백이었는데 어이 없게도 내가 피처 알지 못했지만 문제를 해결하는데 결정적인 내용이었다. 즉 담당자라면 단번에 알 수 있던 내용을 난 일주일 동안 고민해야 했던 것이다. 딱 한번의 질문이었다면 해결 할 수 있었던 문제를 말이다.
[질문을 하는 방법]
이 사건을 계기로 난 문제 해결 방법으로 의사 소통의 비중을 높였다. 구체적으로는 내가 맡은 이슈가 어떤 부서에 속해 있는지 파악하고, 그 이슈에 해당하는 코드의 담당자를 찾아 구체적인 질문을 하는 방식으로 바꾸었다. 또한 담당자를 특정 짓기 어려운 경우에는 공개 슬랙 채널에 질문하도록 전략을 세웠다. 그리고 질문의 내용은 답변하기 쉬운 형태가 되도록 노력했다. 너무 추상적이거나 너무 구체적인 질문은 답변하기 어려울 수 있기 때문이다. 이 경계선을 찾는 것이 꽤나 어려운 일이지만 앞으로 경험을 쌓아가면 나아지리라 생각한다. 또한 스스로 알아보는 시간은 30분으로 제한하기로 했다.
위의 과정을 거쳐 난 결국 문제를 어느 정도 해결하게 되었다.
질문을 잘 하는 방법
- 혼자만의 고민 시간은 30분으로 제한한다
- 질문할 대상을 탐색한다
a. 평소 점심 시간을 활용하여 모든 사람들과 친해지자
b. 그 사람들의 업무 내용을 오고가며 듣는다면 전체 프로세스를 파악할 수 있다
c. 전체 프로세스 중에서 현재 발생한 이슈를 짚어내고 그 담당자 또는 부서로 찾아가 질문을 한다 - 질문 내용은 답변하기 쉬운 형태로 한다
a. 너무 추상적이거나 너무 구체적인 질문은 되도록 피하자
b. 답변자의 수고로움을 최대한 덜어내는 작업을 진행한 뒤에 질문해야 한다
c. 그럼에도 불구하고 정확한 내용을 짚어낼 수 없다면, 상황 자체를 질문거리로 만들자
d. 즉, "내가 a라는 문제를 만났고 b, c, d를 의심하여 조사해봤지만 진척이 없는 상황이다. 혹시 아는 것이 있나요?"처럼 상황 자체를 질문 거리로 만들도록 한다. - 질문은 최소 퇴근 시간으로부터 3시간 전에 하도록 하자
친근한 사람이 되자
왜 친근한 사람이 되어야 하는가?
난 개발자라면 코딩이 최우선이 되어야 한다고 생각했다. 그러나 개발자의 삶을 직간접적으로 체험해보니 가장 중요한 것은 소프트 스킬이라고 생각이 바뀌었다. 왜냐하면 소프트 스킬이 전제 되었을 때 코딩 기술이 극대화 될 수 있기 때문이다. 그래서 난 첫번째로 친근한 사람이 되어야 한다고 결심했다. 친근한 사람이라면 누구에게나 질문할 수 있고, 누구나 질문하고 싶은 사람이 될 수 있기 때문이다.
항상 웃자
친근한 사람이 되기 위해서 가장 쉬운 방법은 웃는 것이다. 웃는 사람한테 침을 뱉지는 않는다고 생각한다. 그래서 난 매일 아침마다 웃으려고 하고 웃는 것을 연습하고 있다.
긍정적인 말을 하자
회사에서 신경 쓰는 것 중에 하나가 긍정적인 말을 하는 것이다. 같은 내용이지만 어떤 자세로 말하냐에 따라서 그 결과가 천지차이라고 생각한다. 그래서 되도록 회사에서 긍정적인 말을 하려고 노력한다.
빠른 피드백 수용
팀원분들이 가볍게 권한 내용이더라도 가볍게 생각치 말고 그 피드백에 대한 고려는 언제나 이뤄져야 한다. 왜냐면 그렇게 가볍게 권한 내용 중에는 정말 중요한 것들도 있기 때문이다. 이렇게 기민하게 귀를 기울이면 수용해야 할 피드백을 놓치지 않을 수 있다. 그리고 해당 피드백을 빠르게 수용한다면 실수할 확률이 매우 낮아진다.
예시로 팀원분들이 따릉이를 결제해두는 것을 추천해주셨는데 그날 바로 결제를 했었다. 그런데 다음날 점심을 따릉이를 타고 가게 될 상황에 놓였다. 만약 내가 따릉이를 결제해두지 않았다면 팀원들이 날 기다리게 되는 상황이 발생했을 것이다. 덧붙여 줌 뮤트 등..
언제나 메모하자
팀원의 피드백이나 업무사항 전달은 보통 구두로 전달되고 한번만 이뤄진다.
그렇기 때문에 내가 메모해두지 않으면 같은 내용을 두 번 설명해야 하는 문제가 생긴다. 따라서 언제 어디서나 메모를 할 수 있도록 팬과 노트를 휴대하자. 이 부분은 인턴 생활 중에 그나마 잘했던 것이라 생각한다.
여기까지가 한달차 후기이다. 사실 세세한 것들도 많지만 내가 가장 중요하다고 생각하는 것들 위주로 서술하였다.
