> [!date] published: 2025-05-08 ## 📌 오늘의 주제 - 치킨집 토크 - 자바스크립트 특강 - 에러처리 ## 💡 배운 것 ### 치킨집 토크 (5/7) 원래는 7일에 오프라인 멘토링과 팀별 활동이 계획되어 있었는데 식사와 회의가 가능한 공간을 찾지 못한 문제로... 치킨집에서 계속 얘기를 하다가 왔다. 근데 멘토님하고 같은 테이블이었어서 그냥 캐주얼한 멘토링을 하고 온 것 같다 ㅎㅎ... #### 1. 개발을 잘하면서도 즐기는 사람을 어떻게 이길 수 있을까? 개인적으로 나는 개발을 즐기는 사람이라고 생각하긴 하는데, 확실히 찐 고수들을 볼 때면 이렇게 재밌다고 계속 하는게 맞나... 이런 고민을 요즘 들어 하고 있었다. 근데 한빈님이 일찍이 이런 고민을 하셨었고, 나름대로 내린 결론을 공유해주셔서 진짜로 도움이 되었다. 나만의 무기를 찾을 필요가 있다. 개발을 잘하는 사람들은 개발 실력이 무기일 것이고, 나는 개발 실력이 부족하다면 다른 부분에서 무기를 찾으면 되는 것이다. 그 무기는 도메인 지식이 될 수도 있고, 커뮤니케이션 스킬이 될 수도 있고. 이 부분은 메타인지 높이면서 알아보면 될 것 같다. 여기에 멘토님이 덧붙여주셨던 것 같은데 (하루 지났다고 기억이 가물...) 한국에서 개발자 커리어를 계속 쌓다 보면 팀을 관리하는 쪽으로 향하게 되는데, 이때는 개발 실력 외의 소프트 스킬들이 중요해진다. 개발 실력도 중요하긴 하지만 개발 실력'만' 중요한 것은 아니다! #### 2. 높은 연봉을 쫒는게 맞을까? 이건 요즘 내가 좀 고민하던 내용이고 어느정도 결론을 내린 부분이기도 한데... 나는 높은 연봉 보다는 내가 추구하는 방향과 회사의 방향이 맞는 곳으로 가는 것이 나와는 맞는 것 같다는 결론을 내렸다. 나도 높은 연봉이 좋긴 한데, 그냥 머물러 있는 것 보다는 즐거운 개발 → 나의 성장 → 높아지는 나의 가치 → 높은 연봉 플로우를 겪는 쪽이 좀 더 내 삶의 가치관과 맞는 것 같다... 추가로 덧붙여진 말로는, 스타트업에서 오신 분들 중에서 대단한 실력자분들이 많이 계신다. 대기업도 물론 좋지만너무 또 대기업만이 옳다! 라고는 생각할 필요는 없다. #### 3. 공부해도 끝이 없는데 어떤 시점에 끊는 것이 좋을까? 이것 역시... 요즘 내가 고민하던 부분... 공부하다 보면 계속 지식이 가지치기되면서 모르는 내용이 계속 보인다. 물론 다- 공부할 수 있으면 좋겠지만, 길을 잃지 않게 조심하자. Next.js를 공부하다가 어느새 React 파이버 트리를 공부하게 되는 자신을 발견하게 된다면? 킵해두고 일단 공부하려던 방향으로 되돌아가는 것이 좋다. 쌓아 두고 언젠간 공부하자 꼭. #### 4. 디자인패턴, 아키텍쳐를 공부해야 할까? 공부하면 좋다. (사이트를 추천 해주시려고 하셨는데 아마도 이거였을 듯? [Patterns.dev](https://www.patterns.dev/) | [Patterns.dev.kr](https://patterns-dev-kr.github.io/)) (내가 공부하려고 해도 필요성에 대해서 잘 와닿지 않아서 공부하는 의미를 잘 모르겠다고 추가로 여쭤봄) 필요한 개념인 것은 맞다. 하지만 당장 필요성을 느끼지 못한다면 좀 나중에 공부해도 된다. 언젠간 필요한 때가 온다. #### 5. 지저분한 해커톤 코드... 괜찮나요 (이것도 내가 고민하던 것...) 해커톤 코드는 유지보수나 가독성 이런 것을 하나도 신경쓰지 않고 오로지 기능구현에만 집중하기 때문에 따로 모여서 리팩토링하지 않는 이상 너무너무 지저분하다... 그래서 개인적으로는 "프로젝트"로 대하기 보다는 그냥 "경험"정도로 대하는 중이었다. 코드의 목적과 수명에 대해서 고민해보면 좋을 것 같다. 해커톤 코드는 해커톤 당일에만 쓰이고, 빠르게 기능을 구현하는 것이 우선이기 때문에 가독성이나 유지보수보다는 빠른 구현이 더 우선순위가 높다. 그래서 바쁜 해커톤 시간에 가독성이나 유지보수를 고민하기보다는 빠르게 구현하는 것에 좀 더 집중하는 것은 당연함... 하지만 해커톤이 아닌 프로젝트 코드 같은 경우에는 오래 봐야 하고, 여럿이 봐야 하는 코드이기 때문에 가독성이나 유지보수에 더 초점을 맞추는 것이 중요한 것. --- 장소가 장소이니만큼 멘토링보다는 네트워킹 느낌이 될 것 같았는데 일찍 도착한 덕에 (ㅎㅎ...) 멘토님과 같은 테이블에 앉았고, 같이 앉은 다른 분들도 되게 생각이 깊고 많은 고민을 해 오신 분들이시라 생각지도 못하게 많은 생각을 하고 많은 인사이트를 얻을 수 있었다... 🍀 ~~앞으로도 10분 일찍 도착해보는 것도 좋을 것 같다... (원래 시간 딱 맞추는 편...ㅎㅎ) ### 자바스크립트 특강 (5/8) 개인적으로는 바닐라 JS로 코딩해본 것이 너무 오랜만이라 (...) mdn 열심히 찾아가면서 라이브코딩을 했는데 자괴감이 들었다... 비동기 로직을 사용하는 여러가지 방법(then / catch와 async/await)을 실습해보고 추상화 관련된 얘기도 했다. 여러 단계로 실습을 했는데... 최종 코드의 일부는 아래와 같다. ```js async function fetchData(url) { const response = await fetch(url); if (!response.ok) { throw new Error("HTTP error!"); } return response.json(); } function fetchFirstTodo(userId) { return fetchData(`${secondUrl}/${userId}`).then((todo) => { // todo가 없는 경우 if (!todo || todo.length === 0) { throw new Error("Todo not found!"); } return todo[0]; }); } async function fetchUserTodo() { try { const user = await fetchUser(); // userId가 없는 경우 if (!user || !user.id) { throw new Error("User ID not found!"); } const userId = user.id; const todo = await fetchFirstTodo(userId); console.log(todo); } catch (error) { console.error("Error:", error); } } ``` --- then 체이닝을 할 수 있는 것은 어떤 함수가 Promise를 반환하기 때문이다. (근데 지금 생각해보니 당연함... then은 Promise의 메서드이다.) ```js // Promise를 생성할 때에는 executor를 전달해야 한다. const sth1 = new Promise(); // Uncaught TypeError: Promise resolver undefined is not a function const sth2 = new Promise((resolve, reject) => { // 무언가 하기... if (error) { reject(5); } resolve(10); }); sth2.then((ret) => console.log(ret)); // 10 ``` 직접 Promise 객체를 생성해서 사용하는 경우는 많지 않은 것 같은데, 우리가 then을 체이닝해서 사용하는 모든 함수들은 내부에서 모두 Promise를 생성해서 반환하고 있다. --- 라이브로 코드리뷰 하면서 나왔던 얘기: 회사에서든, 팀 프로젝트에서든 코드 리뷰를 하기 전에 코드 리뷰 가이드를 읽어보자. - [Google Engineering Practices Documentation \| eng-practices](https://google.github.io/eng-practices/) - [구글의 코드 리뷰 가이드 · Soojin Ro](https://soojin.ro/review/) ### 에러 처리 (5/8) 요거는 따로 팀 활동때 질문 받아 주셨던 것... 기억을 잃지 않기 위해서 빠르게 대강 정리만 해 둔다. ![[8069c9d1-b1c5-4a6e-8b3a-d289a8f9d18e.png]] ※ 에러 로깅은 어떤 레벨이든 추가할 수 있지만 필요한 부분에만 추가해야 한다! 에러를 처리하는 방법은 여러가지가 있을 수 있음 - 에러를 타고 타고 올려서 가장 상위 레벨에 모아서 한번에 처리하기 (약간 ErrorBoundary와 비슷한건가? 하는 생각을 했다.) - 에러를 받자마자 처리해서 다음 로직들은 모두 검증된 데이터들만 다루도록 하기 에러를 어디에서 던지고, 어디에서 받아서 처리할 것인지는 전체 프로젝트 구조를 보고 설계해야 하는 지점이다. ## 📝 생각과 메모 이 시기에 고민하는게 다들 비슷비슷하다는게 좀 신기했다... 내가 예전에 고민했던 것들을 어떤 분은 지금 고민하고 계셨고, 내가 지금 고민하고 있는 것들을 이미 고민해서 나름대로 결론을 내린 분도 계신다는게 너무 신기했다. 명언 자판기 한빈님의 어록... - 헤매는 만큼 자기 땅이다. (출처: [X의 Anna님](https://x.com/amourdew_/status/1407375953081241604)) - 커리어는 사다리가 아니라 정글짐이다. (출처: [\[번역\] 쉐릴 샌드버그, 2012년 하바드 비지니스 스쿨 졸업 축사](https://imseongkang.wordpress.com/2013/06/15/sandberg/)) 자기 소개를 할 때 마다 '제가 좀 늦어서...' 하면서 머쓱해하는 상황을 요즘 종종 마주하면서 진짜 늦었나? 하는 고민을 하곤 했었다. 근데 얼마 전에 간만에 만난 지인하고 얘기하면서 어쩌다가 하게 된 말인데, 개인적으로는 아직 엄청 늦었다고 생각하진 않는데 (철없다고 하면 할말은... X) 그냥 주변인들이 존경스럽게도 빨라서 뭔가 변명해야 할 것 같은 느낌을 받고 있다는 얘기를 했었다. 좀 다른 사람들보다 늦은 것도 맞긴 한데 커리어의 시작이 좀 늦었을 뿐 이것저것 해본 것들이 의미가 없진 않았다는 것을 요즘 느끼고 있었는데, 이 생각을 한방에 정리하는 말들을 해주셔서 기억에 남았다.