생각보다 간단하고 회사 생활에 도움 되었던 점 “궁금한 점은 코드를 직접 보며 답을 찾고, 코드를 효과적으로 빨리 잘 읽는 스킬을 쌓자“ 문서화가 잘 안되어 있는 곳이라면 쉽게 원하는 답을 스스로 찾기가 어렵다. 이 경우 몰라서 물어보는 건 당연히 좋지만 묻기 전에 스스로 한 번쯤 먼저 찾아보는 습관을 갖자. 물어보면 답을 빨리 찾을 수 있는 장점이 있어도 이건 문제 풀 때 답안지를 먼저 보는 것처럼 현재 마주한 문제나 궁금한 점의 주요 핵심을 이해하지 못하고 답만 찾는 것과 같다. 나중에 비슷한 상황을 맞닥뜨리면 해결 능력 없이 또다시 답만 찾는 사람이 될 수 있다. 1️⃣ 먼저 답을 찾는 사람이 주는 신뢰성 먼저 답을 찾을 줄 알면 신뢰할 수 있는 사람이 된다. 특히 코드에서 답을 찾을 수 있다면 관련 코드를 빨리 훑어보고 답을 찾으면 좋다. 2️⃣ 큰 그림을 보는 데 도움 된다 ’내가 맡은 게 아니라서‘ 코드를 안 읽어 보는 경우가 있는데, 내가 자주 안 보는 코드베이스도 훑어보는 습관을 들이면 한 프러덕트가 어떻게 유저에게 제공되는지 큰 그림을 보게 해준다. 주니어 시절, 이 습관을 갖고 다음과 같은 긍정적인 변화를 겪었다. 1. 다양한 코드 베이스를 접하며 퀄리티가 높은 코드를 접할 기회가 더 많아졌고, 배움의 기회도 더 많아졌다. 2. 소프트웨어 설계 패턴에 대해 여러 가지 실제 사용 예시를 읽어보고 익힐 수 있었다 (지난 글 참조) 3. 구성 요소 간 협력 관계를 파악하고 더 나아가 설계의 큰 그림을 보게 되었고, 한 구성 요소만 파악할 때는 몰랐던 중요한 정보를 많이 얻게 되었다. 3️⃣ 더 나아가 프로세스를 만들자 ‘나만 이 답을 찾고 끝내자’에서 ‘어떻게 하면 이 정보를 조직간 효율적으로 공유할까’로 생각을 바꾸자. 이 역할을 하는 선임이나 팀원이 있는 팀과 없는 팀의 문화와 설계 그리고 코드 퀄리티는 확실히 다르다. 팀 간 소통과 지식의 부재로 자기 팀에만 적합한 솔루선을 만들고 코드를 바꿨는데, 생각지도 못한 다른 조직의 팀이 맡은 서비스에 이상이 생기는 경우가 아주 많다. 이건 조직간 정보와 대화와 큰 그림을 보는 개발자가 부족하기 때문이다. 지난번 글에서 언급한 문서화해도 좋고, 일주일이나 한 달에 한 번씩 워크숍이나 한 시간짜리 강의해도 좋다. 가장 좋은 건 내가 없어도 이 정보가 잘 발견될 수 있도록 프로세스를 만드는 것이다. 👉 마지막으로, 모든 상황에서 위 같은 방법을 사용할 수는 없다. 때에 따라 효율적으로 답을 빨리 알아내야 하는 경우(예: 인시던트 대응), 전문 지식이 있는 팀과 조직에 먼저 물어봐야 한다. 이후에 시간날 때 답을 알아도 훑어보는 게 좋다. 🪴 함께 읽으면 좋은 글: 신입, 경력직 회사 생활과 자기 계발에 필요한 것 2탄 https://careerly.co.kr/comments/82395 기술 리더가 되기 위해 필요한 의사소통 스킬 https://careerly.co.kr/comments/82411 코딩 테스트, 알고리즘 공부 로드맵 https://careerly.co.kr/comments/82187