우아한테크코스 - '성장'을 위한 선배 개발자님들의 조언

 

감사하게도, 우아한테크코스 과정에는 멋진 개발자 선배님들을 만나뵐 수 있는 기회가 정말 많다! 메모장을 탈탈 털어 수업시간, 선배와의 대화, 세미나 등을 통해서 온﹒오프라인으로 만나뵈었던 선배 개발자님들의 귀중한 조언들을 한 데 모아보자.

(2021년 2월부터 시간순, 오름차순으로 작성)

 

 

FE 역량 💪

'프론트엔드니까 DB, REST API, Infra는 몰라도 돼'라고 할 수 없다. 아는 것이 적을수록 선택지가 좁아지고, 나비효과로 장애까지 이어질 수 있다. 
- 김민태 개발자님

 

과정 속에서 배우는 것에 의미를 두고, 취업만을 좇기보다는 프론트 엔지니어로써 본인만의 색깔, 본인만의 개성을 만들자.
- 장현석 개발자님

 

써드파티 라이브러리, 프레임워크는 선택한 다음에 이유를 찾는게 아니라, 무조건 선택하기 전에 이유를 찾아야 한다. 주변에서 사용하는 단 하나를 고르기 보다, 여러 후보들을 비교해보고 장단점을 파악한 다음에 이유를 생각하고 사용하자.
- 박신영 개발자님

 

프론트엔드에서 1순위로 여겨야 할 것은 JS나 TS일 것이다. '갖춰서 좋은 것'과 '꼭 해야 할 것'을 구분해서 하자. 다 알고 있는 사람이랑 구분하면 당연히 부족해 보일 것이다. 조금씩 'good to have'를 붙여나가면서 경쟁력을 키워가는 것이 좋겠다. CS에서 네트워크, 운영체제 다 공부해야 한다고 생각할 텐데 우선순위가 제일 높은 것이 아니다. 
- 남현우 개발자님

 

문제가 발생해 원하는 대로 안 되는 상황에서, 다양하게 생각해서 해결하기 위해 노력하고, 검색을 통해 원하는 것을 가장 잘 찾아내는 능력이 가장 중요하다. 질문을 잘하는 것과 검색을 잘하는 것은 서로 연관된다. 어떤 언어를 어떤 상황에서 쓰고 있고, 어떤 문제를 해결하고 싶은지 잘 정리하면 해결 방법도 쉽게 찾을 수 있다. 상황을 잘 정리하는 것이 필요하다.
- 전은정 개발자님

 

프론트엔드 분야에서 '말로 하는 것'과 '눈으로 보는 것' 사이에는 엄청난 차이가 있다. 말로 '이렇게 만들자. 이렇게 동작할 것이다.' 하는 것보다 실제로 만들어서 이야기하는 것이 이해도를 훨씬 높일 수 있다. 말과 실제 동작물의 차이가 굉장히 크기도 하다. 함께 개발하는 개발자들, 디자이너, 기획자 모두가 동작되는 모습을 보고, '우리가 만들려고 한 게 이게 맞았다.'라는 시점까지 빨리 도달하는 것이 급선무이다. 먼저 협업하는 사람들 모두가 동의할 수 있는 정도로 동작하게 하고 그 다음에 소프트웨어를 다듬는 것이 좋다. 그 때 엄밀한 리팩토링과 소프트웨어 관점에서 유지 보수하는 것이 좋다. 
- 김민태 개발자님

 

아키텍처를 만들 때는 '사용이 충분히 편리할 만큼 가능한 복잡도를 갖고있는가?' 를 유념하면서 의사결정을 해야 한다. 기술은 조금만 어려워도 도태되기 쉽기 때문에 좋은 기술이라고 해서 반드시 살아남지는 못한다. 
- 김민태 개발자님

 

이 코드가 부수효과 코드인가 아닌가는 판단하는 것은 중요하다. 판단하기 위해서는 계속해서 경험을 누적해보아야 한다. 조급해하지 말고 코드 마일리지를 쌓아가면서 곱씹어 보는 시간이 필요하다. 
- 김민태 개발자님

 

엔지니어로서 주의해야 하는 것 중에 하나가 오버 엔지니어링’이다. 오버 엔지니어링과 적절한 엔지니어링의 기준점을 마련하기는 상당히 어렵다. 판단을 주관적으로 해야 하고 엔지니어마다 기준이 다를 수밖에 없다. 아무리 경험이 많아도 미래의 모든 상황을 예측하는 것은 불가능하다. 아직 내 눈에 보이지 않은 상황까지 감안하는 것은 지양해야 한다. 500ms 내에 출력되면 사용자가 빠르다고 느끼는 경우를 가정해보자. 내가 만든 UI가 1000ms가 걸린다면 사용자가 앱이 느리다고 느낄 것이므로 성능 튜닝이 반드시 필요하다. 그렇지만 300ms 가 나오는 상황에서 100ms, 50ms으로 만들기 위해서 계속 투자하는 것은 비효율이다. 내가 만든 앱이 300ms에 나오든, 50ms로 나오든 사용자는 똑같이 느낄 것이다.
- 김민태 개발자님

 

누군가가 작성한 글은 사실 글쓴이가 정확히 이해한 것과 오해한 것이 뒤섞인 것이다. 글쓴이가 오해한 것을 필터링하고 정확한 지식만 받아들일 수 있는 상태가 되려면, 결국 두 가지 모두를 이미 자세히 알고 있어야 한다. 그래야 글쓴이가 유도하는 프레임에 속아 넘어가지 않고 판단을 할 수 있다. 그래서 글을 읽을 때는 각 의견 하나 하나를 더 자세히 알아가면서 읽는 것이 좋겠다.
- 김수호 개발자님

 

 

효과적인 성장 💪

변화를 위해서는 '의지력'에 기대는 것보다 '환경'을 이용하는 것이 효과적이다. '학습을 위한 환경'을 조성하자. 데이트를 2주에 1회 하거나 친구들과 만나지 않는 등의 방법으로 시간을 확보하고, 프로그래밍 관련 책만 읽거나, TV, 게임 을 끊는 등의 방법으로 우선순위를 조정할 수 있다.
- 박재성 개발자님

 

‘마인드맵’으로 학습 내용을 적으면 곁가지를 치고 핵심만 정리할 수 있다. 그러면 기저 기술이 가시화되고, 어떻게 학습할지 어떻게 응용할지 전략을 세울 수 있게 된다. 결국 빠른 학습이 가능해진다.
- 김민태 개발자님

 

누군가의 피드백을 접할 때 무의식 중에 생기는 '내 거랑 좀 달라서 적용하기 어렵겠는데?'라는 프레임을 경계하자. 나한테 어떻게 적용할 수 있을지, 어떻게 배울 수 있을지부터 생각하자.
- 이찬호 개발자님

 

지금 내가 과거에 작성한 코드를 보고 '걸작이다' 싶으면, 그때부터 지금까지 성장한 것이 없다는 말과 같다.
- 이찬호 개발자님

 

처음 공식문서를 읽을 때 집중해야 하는 것은 '이 도구가 왜 등장하게 되었는지'이다. 소프트웨어를 학습할 때 'How to'에 집중하는 경향이 있다. 그러나 '소프트웨어'는 근본적으로 도구이고, 도구는 ‘문제 해결’을 목적으로 한다. 해당 소프트웨어가 어떤 문제를 해결하기 위해 나왔는지를 집중해야 한다. 
- 김민태 개발자님

 

프로그래밍 학습이 어려운 이유는, 소프트웨어가 단지 '한' 사람만의 사상이 아니라, '여러' 사람의 사상을 결합해서 하나의 결과물이기 때문이다. 소프트웨어를 만든 것은 ‘사람들’이고, 그 사람들의 '사상'이 그 소프트웨어에 투영되어 있다. 소프트웨어는 만고불변의 진리를 학습하는 자연과학과 다르다. 소프트웨어는 결국 어떤 사람들의 사상이 코드로 실체화된 것이기 때문에 그 사람들의 사상을 이해하는 것이 중요하다. 만든 사람들이 어떤 맥락으로 해당 기능을 만들었는지 이해해야, 나머지 기능도 이해가 된다. 단지 기술이 아니라 그 뒤에 사람이, 사람의 철학이 있다. 
- 김민태 개발자님

 

어떤 주제가 던져지면 반대를 생각해보면 시야를 확장하는데 도움이 된다. '이 질문을 왜 하지?', '어떤 이유로 이런 설명을 할 수밖에 없었을까?' 라고 생각해보면 다른 맥락도 파악할 수 있다. 기술을 바라볼 때는 여러 관점으로 바라볼 수 있을수록 좋다. 그런 여러 관점을 가지기 위해 다양한 공부를 하는 것이기도 하다. 
- 김민태 개발자님

 

모든 개발에 통용된는 방법론은 없다. 답을 찾기 어렵기 때문에 여러 방법론이 등장하는 것이다. 방법론은 앱마다, 어떤 것을 만드느냐에 따라서도 다르다. 정답을 찾으려고 하기보다는 경험을 쌓는다는 느낌으로 접근하는 것이 좋겠다.
- 김민태 개발자님

 

다른 사람의 의견을 그대로 받아들이면 안된다. 페어와 고민도 하고, 누군가 말하는 것을 무작정 적용하는게 아니라 생각해보고, 다시 고민해보고... 또 다른 누군가와 이야기를 해보고 가장 설득력있다고 생각한대로 의견이 모아지고 적용해보는 과정. 무엇이 맞고 무엇이 틀린지 보다 이러한 과정이 더 중요하다. 이렇게 적용해 보고나서, 돌아보니 좋은 선택이었다고 생각되면 스스로에게 칭찬 한 번 해주고, 좋지 못한 선택이었다면 깨닫고 배우면서 그렇게 한 발 한 발 성장하면 된다.
- 김수호 개발자님

 

너무 정답을 찾으려는 자세는 학습을 방해할 수 있다. '이 상황에서는 이 방식이, 저 상황에서는 다른 방식이 맞지 않을까?' 라는 호기심을 갖자.
- 박재성 개발자님

 

 

건강한 성장 💪

오직 비교대상은 자기 자신이다. 다른 사람과 비교하지 말고 '어제의 나'보다 성장했는지 고민하자.
- 박재성 개발자님

 

번아웃이 오는 것은 체력이 부족해서이다. '잠'과 '운동'은 포기하며 안된다.
- 이찬호 개발자님

 

남이랑 비교하는 것 정신건강에 좋지 않다. 모든 취업과정이 멘탈 승리 과정이다. 자기가 어떤 사람인지 알고 자기를 알고 쉴 때를 아는 '메타인지'가 중요하다. 프론트엔드 분야는 알아야 할게 정말 많기 때문에 마치 '파묻히는 듯한' 심리 상태가 되기 쉽다. 다른 사람들이 공부하는 것에 휘둘리기 쉽기도 하다. 본인에게 제일 적은 노력으로 가장 크게 효과를 볼 수 있는 것, 필요한 것에 집중하는 것이 좋다.
- 전은정 개발자님

 

번아웃을 예방하기 위해서는 자신의 '최대치'를 파악하는 것이 중요하다. 번아웃이 걱정된다면 하루 동안 본인이 낼 수 있는 퍼포먼스가 100이라고 했을 때, 20정도는 여유로 남겨두는 편이 좋겠다.
- 강동혁 개발자님

 

 

함께 성장 💪

상대방의 장단점은 나의 장단점이 될 수 있다. 페어의 장점을 파악하고 페어의 장점을 흡수하자.
- 남윤서 개발자님

 

'심리적 안전감'이란 내 생각이나 의견, 질문, 걱정, 혹은 실수가 드러났을 때 처벌받거나 놀림받지 않을거라는 믿음이다. 심리적 안전감을 느낄 수 있는 우아한테크코스에서, 페어의 발목을 잡고, 또, 페어를 기다려주자.
- 임동준 개발자님

 

논리적 질문, 논리적 대화는 상대방으로 하여금 많은 에너지를 소모하게 한다. 내 질문이 상대방을 압박하는 것은 아닌지 점검해야 한다. 사람에 대해서는 지나치게 논리적으로 접근하는 것은 오히려 논리적이지 않은 정보를 얻게 한다.
- 임동준 개발자님

 

옆의 동료가 번아웃이 왔다면 그럼 본인의 책임도 있는 것이다. 동료의 멘탈도 관리를 해주는 것이 좋은 동료가 되는 법이다.
- 강동혁 개발자님

 

모든 커뮤니케이션 상황에서의 질문에는 항상 '전제'가 있다. 이 전제는 은연중에 내포할 수도, 대놓고 얘기할 수도 있다. 그 전제를 잘 인지해야 한다. 질문한 사람이 제시한 맥락을 고려해서 답변해야 한다. 
- 김민태 개발자님