티스토리 뷰
주니어 때는 성장하는 법을 배우고 성장 곡선의 기울기를 가파르게 만들어야 할 때!
하드 스킬은 성장의 더하기라면 소프트 스킬은 곱하기이다. 소프트 스킬은 한 번 익혀두면 평생 써먹을 수 있다. chatGPT가 하드 스킬은 대체할 수 있더라도 과연 소프트 스킬을 대체할 수 있을지는 의문이다.
1. 그림으로 소통하기
개발자는 커뮤니케이션을 못하는 것이 아니다.
커뮤니케이션이란? "전달자와 수신자 사이의 정보 전환, 개인을 포함한 집단 간의 의미의 전달" 이라고 정의되기도 하고, "일반적인 상징을 통한 정보나 의사의 전달" 이라고 정의하기도 한다. 즉, 의사나 정보를 갖고 있는 자가 그것을 받아들이려는 타인에게 전달하는 언어적인 것과 비언어적인 것이 해석되는 모든 과정을 의미한다.
커뮤니케이션은 말하기가 아니다. 커뮤니케이션의 본질은 상대방과 나의 생각을 싱크하는 것이다. 말을 잘 못하더라도 생각의 싱크를 잘하면 커뮤니케이션이션을 잘하는 것이다. 말보다는 그림으로 소통하기를 추천한다.
생각 / 이미지 -> 구어 -> 생각/이미지 (정보 유실 매우 큼)
생각 / 이미지 -> 문장 -> 생각 / 이미지 (정보 유실 큼)
생각 / 이미지 -> 도표, 그림 -> 생각 이미지 (정보 유실 상대적으로 적음)
그림으로 소통하는 습관을 들여야 한다. 또한, 다이어그램 툴 하나 정도는 익숙해질 필요가 있다.
2. 나만의 TODO List 만들기
우리는 우리가 평생 해내온 TODO의 결과물이다. 모두에게 공평하게 주어진 간을 더 잘 쓰기 위해서는 TODO List를 활용해야 한다.
회사 업무 관리 툴(JIRA 등)로 관리하는 사람도 있겠지만, 업무 외에도 내가 중심인 TODO List를 만들어야 한다. 그 안에는 물론 일도 있고 공부, 매일 되새겨야할 명언, 사적으로 챙겨야 할 일(약속, 미용실, 피부과)도 있다. 즉, 내 뇌의 백업처럼 동작해야 한다.
내 뇌의 백업인 TODO List는 어디서든 손쉽게 접근할 수 있어야 하고, 항상 동기화 되어 있어야 한다. (언제 어디서나, 어떤 디바이스를 쓰든, 집이든 출근길이든 휴가중이든~~) 계속 손이 가는 TODO List를 만들어야 한다.
복잡한 기능이 많은 TODO List는 오히려 손이 안가게 된다. 일, 프로젝트, 공부, 취미, 여행, 목적별로 만들면 관심 있는 TODO List만 열심히 보게된다. 또한 TODO가 계속 쌓이게 되면 잘 안보게 된다.
아래와 같은 방법을 추천한다.
- Google Task를 활용하여 Today, Weekly, Monthly, Yearly로 주기별로 TODO List를 나눈다.
- 평소엔 Today 위주로 보고, 각 주기에서 오래 머문 TODO는 다음 주기로 이동한다.
3. 코드를 보는 안목 기르기
기존에 있던 잘 돌아가는 코드, 선배들의 코드가 답이 아니다. 기존 코드를 마냥 우수하다고 생각하면 안된다. 기존 코드에는 다양한 요구사항, 수많은 히스토리, 빡빡한 일정, 비즈니스 예외사항 등이 숨겨져 있다. 안목이 없으면 현실적인 코드(매우 많은 if-else 등)에 익숙해지게 된다. 불편함(Code Smell)을 느낄 수 있는 안목을 길러야 한다.
아래와 같은 방법을 추천한다.
- 평소에 쓰는 오픈소스 코드 열어 보기 (Spring, Kafka 등등)
- 유명한 오픈소스 프로젝트 코드 통째로 받아서 공부하기
- 소스코드 가독성, 리팩토링, 디자인 패턴을 다루는 책 다양하게 읽어보기
- 평소에 코딩 70%, 리팩토링 30% 시간 쓰기
- (취미로) 시간 날 때마다 예전에 본인이 짠, 다른 사람이 짠 소스코드 리팩토링 하기
4. 왜? 라고 묻기
개발자는 개발을 넘어 문제를 해결하는 사람이어야 한다.
최악의 개발: 개발은 실컷하고 문제는 해결 못 함
최고의 개발: 개발도 안 했는데 문제 해결
단순히 시키는 대로 하는 수동적인 개발자가 아닌, 왜? 라고 항상 물음을 던지고 더 좋은 방향으로 같이 고민해야한다.
또한, 내가 요청할 때에도 상대방이 왜? 를 쉽게 알 수 있도록 해야한다.
- 해결하고 싶은 문제의 배경을 먼저 설명한다.
- 내가 생각하는 해결책을 몇가지 제시한다.
- 더 좋은 방법이 있는지 물음표를 던짐으로써 상대방이 생각을 하게 만든다 -> 더 좋은 솔루션
- 항상 해결책을 유도할 수 있는 질문을 해야한다.
5. 나만의 개발 공부법 찾기
사람마다 본인에게 맞는 개발 공부법이 있다. 크게는 책과 이론을 바탕으로 공부하는 사람, 실전을 바탕으로 공부하는 사람으로 나눌 수 있지만 여기서는 책과 이론을 바탕으로 공부하는 방법을 소개한다. (그렇다고 실전을 바탕으로 공부하는 것이 잘못된 것은 아니다.)
- 무엇을 모르는지 알기 위해 얇은 책이나 오버뷰 읽기
- 이 기술이 왜 필요한지, 기존 기술보다 왜 좋은지 학습하기
- 튜토리얼 코드를 짜보면서 경험의 크기를 늘리기
- 경험이 쌓이면 책보고 이론 쌓으며 경험 다듬기
- 책 바꿔가며 2-3단계 반복
- 저자마다 다르게 이야기를 하기 때문에, 머릿속으로 종합해서 나만의 지식으로 만드는 데 도움이 도미
- 관련된 오픈소스 파보기
- 회사에서 일하면서 써보기
주니어는 성장이 본업이다.
주니어 첫 3년에 성장 곡선의 기울기를 바꾸면 10년 후 엄청난 실력 차이가 발생한다.
3년차가 3년차 만큼 한다고 잘 한다고 생각하고 안주하면 안된다. 3년차가 5-7년차의 일을, 5년차가 10년차의 일을 하는 개발자가 진정 실력있는 개발자이다.
Q&A
문제를 해결하기 위한 A안과 B안이 있는데, 둘 중 하나를 선택을 해야할 때 어떻게 해야하나?
- 말로 하기 전에 그림을 그린다.
- 상대방과 같이 그림을 덧대면서 한 가지 방안으로 수렴시킨다.
- 처음 칠판에 그린 사람이 이길 확률이 높다. (정리된 자기 생각의 그림 위에서 논의하기 때문에)
이론파 VS 실전파
- 본인의 성향을 바꾸는 건 추천하지 않는다.
- 각각 본인에게 맞는 방법을 추천한다.
- 실전파 -> 코드를 깊게 판다. 튜닝, 검색 래퍼런스
- 이론파 -> 래퍼런스를 먼저 정독한다.
- 어떤 방식을 취하든 추구하는 방향이 같지만 본인의 본질적인 성향을 바꾸지는 않았으면 한다.
이론과 실전 사이의 괴리
- 본인이 공부한 것을 어디에 쓸지 항상 고민한다.
- 단순히 공부만 하면 안되고 튜토리얼 코드도 많이 짜고 블로그 등에 많이 출판한다. 남들이 보니 엄청 신경 써서 작성하고 예시 코드를 작성하게된다.
빌런과 의사소통을 현명하게 하는 방법
- 개발자 시절에는 일을 모두 끌어와 직접했지만, 매니지하는 단계로 넘어가면 불가능하다.
- 그 분들과 밥먹고 같이 시간을 보내며 왜 이렇게 생각하는지, 바쁘지는 않은지 슬슬 파본다.
- 공감과 위로를 해주며 내 편으로 만든다. 관계가 개선되면 나와 관련된 일들도 잘 처리해준다.
- 조금 더 다가가고, 지나가다 말걸고 하면서 관계는 노력으로 개선할 수 있다.
- 개발의 퀄리티가 문제인 경우 -> cowork하기 힘들다고 조직장에게 Escalation을 한다.