창업가, 프리랜서들과의 두근두근 코워킹 | 퇴사하고 나서 부쩍 외로움이 많아졌다. 사람의 마음이 참 간사하다. 회사 다닐 때는 잘 몰랐는데, 퇴사하고 나서 혼자가 되니 사람이 그리워졌다. 아싸라 친구가 얼마 없는 것도 한 몫 했다. 그렇다고 사람을 만나러 다닌 것도 아니고 집이나 카페에서 혼자 일하기 일쑤였던 나. 그래도 여러 데모데이, 창업 네트워킹 행사를 다니며 사람들을 만나긴 했다.

노마드맵에서 함께 일하기 + 내 근황

얼마 전에 지인 소개로 노마드맵 코워킹을 다녀왔어요.

다양한 일(스타트업 창업자, 개발자, 프리랜서, 예비창업자 등등)을 하시는 분들과 만나서
같이 일도 하고 서로 하는 일에 대해 얘기도 나누면서 좋은 시간 가졌습니다.
코워킹 경험이 너무 좋아서 사무실 구해서 사람들과 같이 일하는 것도 생각 중이에요.

코워킹 어땠는지 후기랑 근황도 담아보았습니다. ㅎㅎ.
한낱 백수의 근황이라 바쁜 직장인이시라면 좀 부러우실 수도...

https://brunch.co.kr/@roseline/52

얼마 전에 지인 소개로 노마드맵 코워킹을 다녀왔어요. 다양한 일(스타트업 창업자, 개발자, 프리랜서, 예비창업자 등등)을 하시는 분들과 만나서같이 일도 하고 서로 하는 일에 대해 얘기도 나누면서 좋은 시간 가졌습니다.코워킹 경험이 너무 좋아서 사무실 구해서 사람들과 같이 일하는 것도 생각 중이에요. 코워킹 어땠는지 후기랑 근황도 담아보았습니다. ㅎㅎ.한낱 백수의 근황이라 바쁜 직장인이시라면 좀 부러우실 수도... https://brunch.co.kr/@roseline/52

Brunch Story

노마드맵 코워킹클럽 후기 + 퇴사 후 근황

Astro 4.0 is out!

Astro업데이트 주기가 정말 빠르네요. 

정적 페이지 배포나 프레임워크 통합이 필요할때 써보세요. 정말 빠르고 쉽고 강력하답니다

https://astro.build/blog/astro-4/

Astro 4.0 is out! Astro업데이트 주기가 정말 빠르네요.&nbsp; 정적 페이지 배포나 프레임워크 통합이 필요할때 써보세요. 정말 빠르고 쉽고 강력하답니다 https://astro.build/blog/astro-4/

Astro

Mobx가 class + decorator를 표준 문법으로 이제 만들고자 하네요!
구세대(?) 상태관리, class를 사용하는 방법등으로 외면받았던 mbox
이번에 정리된 문법을 보니 상당히 깔끔하네요.

과연 mobx는 어떻게 될것인지, class나 객체기반 상태관리의 패러다임은 찾아올것인지
한번 읽어보세요. 🙂

https://michel.codes/blogs/mobx-decorators?utm_source=substack&utm_medium=email

```ts
import { observable, computed, action, flow } from "mobx"

class Doubler {
    @observable accessor value

    constructor(value) {
        this.value = value
    }

    @computed
    get double() {
        return this.value * 2
    }

    @action
    increment() {
        this.value++
    }

    @flow
    *fetch() {
        const response = yield fetch("/api/value")
        this.value = response.json()
    }
}
```

Mobx가 class + decorator를 표준 문법으로 이제 만들고자 하네요!구세대(?) 상태관리, class를 사용하는 방법등으로 외면받았던 mbox이번에 정리된 문법을 보니 상당히 깔끔하네요. 과연 mobx는 어떻게 될것인지, class나 객체기반 상태관리의 패러다임은 찾아올것인지한번 읽어보세요. 🙂 https://michel.codes/blogs/mobx-decorators?utm_source=substack&amp;utm_medium=email ```tsimport { observable, computed, action, flow } from "mobx" class Doubler {&nbsp; &nbsp; @observable accessor value &nbsp; &nbsp; constructor(value) {&nbsp; &nbsp; &nbsp; &nbsp; this.value = value&nbsp; &nbsp; } &nbsp; &nbsp; @computed&nbsp; &nbsp; get double() {&nbsp; &nbsp; &nbsp; &nbsp; return this.value * 2&nbsp; &nbsp; } &nbsp; &nbsp; @action&nbsp; &nbsp; increment() {&nbsp; &nbsp; &nbsp; &nbsp; this.value++&nbsp; &nbsp; } &nbsp; &nbsp; @flow&nbsp; &nbsp; *fetch() {&nbsp; &nbsp; &nbsp; &nbsp; const response = yield fetch("/api/value")&nbsp; &nbsp; &nbsp; &nbsp; this.value = response.json()&nbsp; &nbsp; }}```

Michel

개인적으로 느꼈던 점과 받았던 피드백을 바탕으로 팁 몇 가지 적어 봅니다. 

-------------
알고리즘 면접
-------------
1️⃣ 면접 전
 * 면접관이 아닌 직장 동료와 페어 프로그래밍한다고 생각하기 (긴장감 푸는데 도움 됨)
 * 당연한 이야기지만 문제 풀이 연습 충분히 하기
 * 면접에 자주 출제되는 알고리즘 패턴을 프로그래밍 언어로 직접 적어 보며 익숙해지기
 * 특정 회사에 자주 출제되는 문제 풀어 보기
   

2️⃣ 면접 중
 * 문제 풀기 시작 전 질문을 통해 불확실한 점을 명확하게 하기
 * 최대한 여러 가지 문제 풀이법 생각해 내기
 * 여러 가지 풀이법의 절충점 파악하고 설명하기
 * 컴공 개념을 바탕으로 장단점 따져보기 (예: Time, Space Complexity, 자료 구조 성격 등등)
 * 코드 작성 전 엣지 케이스를 대입해 보고 알고리즘이 맞는지 미리 확인하기
 * 코드 작성하고 예시 대입해 보기
 * 생각 설명할 때 키워드 사용하기

3️⃣ 면접 후
 * 틀렸든 맞았든 상관없이 출제된 문제를 면접 후에 혼자 따로 다시 풀어보기
 * 풀어본 후 스스로 테스트 케이스 작성해 보기
 * 가능하다면 채용 담당자에게 피드백 요청하고 강점과 약점 파악하기 (단, 회사 정책상 피드백 공유가 불가능한 곳이 많음)

-------------
설계 면접
-------------
1️⃣ 면접 전
 * 다양한 설계법을 찾아 보고 공부하기
 * 면접관이 아닌 직장 동료와 화이트보딩 세션 한다고 생각하기 (긴장감 푸는데 도움 됨)
 * 면접 공부하는 게 아니라 실무에 도움 되는 설계 공부하기 (시간이 더 걸리더라도 상위 개념만 익히지 말고 하위 개념도 공부하자)

2️⃣ 면접 중
 * 문제의 요구 사항을 정확하게 파악하기
 * Functional 요구 사항 파악하기
 * Non-Functional 요구 사항 파악하기 (예: Consistency, Availability, Durability 등등 요구 사항)
 * 시간 확인하며 중요한 내용을 다 파악하고 언급했는지 확인하기. 특정 부분에서 너무 시간 끌면 설계를 시간 내에 다 못 끝내기 때문에, 마음속으로 타임라인을 만들어서 시간을 체크하며 설계하는 것이 좋다
 * 면접관이 원하는 설계 방향이 있을지도 모르므로 주기적으로 올바른 방향으로 가고 있는지 면접관에게 확인하기
 * 설명이 겉돌지 않도록 해야 한다. 그러려면 설계 개념을 충분히 내 것으로 만들어야 한다
 * 절충점을 충분히 파악하자 (여러 가지 설계 옵션의 절충점 파악이 가장 중요함)
 * 절충점을 파악하고 특정 옵션을 선택할 때 이유를 설명하자

3️⃣ 면접 후
 * 설계 방식이 꼭 한 가지만 있는 건 아니다. 내가 사용한 방법 말고 다른 방법이 있는지 찾아보자
 * 한 시간 내에 끝낸 설계는 부족한 부분이 많을 수 있다. 출제된 설계 문제를 혼자 그려 보고 조사해 보며 다시 풀어 보자. 다시 설계해 볼 때는 온라인에 찾아보며 언급하지 않았거나 몰랐던 개념이 있는지 확인한다. 그 부분을 다시 공부하고 다음에 까먹지 않도록 메모해 두자

-------------
행동 면접
-------------
 * 행동 면접 예시 작성하기 (시리즈의 지난 글 참고)
 * 작성한 예시를 바탕으로 말하기 연습 미리 해보기
 * 스토리텔링 스킬이 부족하다면 모의 면접을 통해 피드백 받기
 * STAR 방법으로 말하기 연습하기
 * 회사가 원하는 인재상과 기업 문화에 관해 리서치해 보고 연관 있는 예시 말하기

-------------

다음 포스팅에는 최종 합격 후 해야 할 몇 가지를 기록 삼아 적어 볼게요.

🔗 시리즈
 1. 1탄: 아마존 퇴사와 빅테크 이직 준비 https://careerly.co.kr/comments/95006
 2. 2탄:취업 준비 시 같이 준비해야 할 것들 https://careerly.co.kr/comments/95038
 3. 3탄: 이직 준비하면서 배운 점 https://careerly.co.kr/comments/95092
 4. 4탄: [현재글] 알고리즘, 시스템 설계, 행동 면접 팁
 5. 5탄: 최종 합격 후 꼭 해야 할 일 https://careerly.co.kr/comments/95312

개인적으로 느꼈던 점과 받았던 피드백을 바탕으로 팁 몇 가지 적어 봅니다.&nbsp; -------------알고리즘 면접-------------1️⃣ 면접 전<ul><li>면접관이 아닌 직장 동료와 페어 프로그래밍한다고 생각하기 (긴장감 푸는데 도움 됨)</li><li>당연한 이야기지만 문제 풀이 연습 충분히 하기</li><li>면접에 자주 출제되는 알고리즘 패턴을 프로그래밍 언어로 직접 적어 보며 익숙해지기</li><li>특정 회사에 자주 출제되는 문제 풀어 보기 </li></ul> 2️⃣ 면접 중<ul><li>문제 풀기 시작 전 질문을 통해 불확실한 점을 명확하게 하기</li><li>최대한 여러 가지 문제 풀이법 생각해 내기</li><li>여러 가지 풀이법의 절충점 파악하고 설명하기</li><li>컴공 개념을 바탕으로 장단점 따져보기 (예: Time, Space Complexity, 자료 구조 성격 등등)</li><li>코드 작성 전 엣지 케이스를 대입해 보고 알고리즘이 맞는지 미리 확인하기</li><li>코드 작성하고 예시 대입해 보기</li><li>생각 설명할 때 키워드 사용하기</li></ul> 3️⃣ 면접 후<ul><li>틀렸든 맞았든 상관없이 출제된 문제를 면접 후에 혼자 따로 다시 풀어보기</li><li>풀어본 후 스스로 테스트 케이스 작성해 보기</li><li>가능하다면 채용 담당자에게 피드백 요청하고 강점과 약점 파악하기 (단, 회사 정책상 피드백 공유가 불가능한 곳이 많음)</li></ul> -------------설계 면접-------------1️⃣ 면접 전<ul><li>다양한 설계법을 찾아 보고 공부하기</li><li>면접관이 아닌 직장 동료와 화이트보딩 세션 한다고 생각하기 (긴장감 푸는데 도움 됨)</li><li>면접 공부하는 게 아니라 실무에 도움 되는 설계 공부하기 (시간이 더 걸리더라도 상위 개념만 익히지 말고 하위 개념도 공부하자)</li></ul> 2️⃣ 면접 중<ul><li>문제의 요구 사항을 정확하게 파악하기</li><li>Functional 요구 사항 파악하기</li><li>Non-Functional 요구 사항 파악하기 (예: Consistency, Availability, Durability 등등 요구 사항)</li><li>시간 확인하며 중요한 내용을 다 파악하고 언급했는지 확인하기. 특정 부분에서 너무 시간 끌면 설계를 시간 내에 다 못 끝내기 때문에, 마음속으로 타임라인을 만들어서 시간을 체크하며 설계하는 것이 좋다</li><li>면접관이 원하는 설계 방향이 있을지도 모르므로 주기적으로 올바른 방향으로 가고 있는지 면접관에게 확인하기</li><li>설명이 겉돌지 않도록 해야 한다. 그러려면 설계 개념을 충분히 내 것으로 만들어야 한다</li><li>절충점을 충분히 파악하자 (여러 가지 설계 옵션의 절충점 파악이 가장 중요함)</li><li>절충점을 파악하고 특정 옵션을 선택할 때 이유를 설명하자</li></ul> 3️⃣ 면접 후<ul><li>설계 방식이 꼭 한 가지만 있는 건 아니다. 내가 사용한 방법 말고 다른 방법이 있는지 찾아보자</li><li>한 시간 내에 끝낸 설계는 부족한 부분이 많을 수 있다. 출제된 설계 문제를 혼자 그려 보고 조사해 보며 다시 풀어 보자. 다시 설계해 볼 때는 온라인에 찾아보며 언급하지 않았거나 몰랐던 개념이 있는지 확인한다. 그 부분을 다시 공부하고 다음에 까먹지 않도록 메모해 두자</li></ul> -------------행동 면접-------------<ul><li>행동 면접 예시 작성하기 (시리즈의 지난 글 참고)</li><li>작성한 예시를 바탕으로 말하기 연습 미리 해보기</li><li>스토리텔링 스킬이 부족하다면 모의 면접을 통해 피드백 받기</li><li>STAR 방법으로 말하기 연습하기</li><li>회사가 원하는 인재상과 기업 문화에 관해 리서치해 보고 연관 있는 예시 말하기</li></ul> ------------- 다음 포스팅에는 최종 합격 후 해야 할 몇 가지를 기록 삼아 적어 볼게요. 🔗 시리즈<ol><li>1탄: 아마존 퇴사와 빅테크 이직 준비 https://careerly.co.kr/comments/95006</li><li>2탄:취업 준비 시 같이 준비해야 할 것들 https://careerly.co.kr/comments/95038</li><li>3탄: 이직 준비하면서 배운 점 https://careerly.co.kr/comments/95092</li><li>4탄: [현재글] 알고리즘, 시스템 설계, 행동 면접 팁</li><li>5탄: 최종 합격 후 꼭 해야 할 일 https://careerly.co.kr/comments/95312</li></ol>

알아 두면 쓸모 있는 알고리즘, 시스템 설계, 행동 면접 팁

감사합니다 ㅎㅎ 다음 주에 코딩 인터뷰 있는데 잘 참고하겠습니다

1950년대 미국과 1960년대 서유럽에서 시작된 마케팅과 풍요가 어떻게 사회적으로 불필요한 제품을 만들고 해를 끼쳤는지를 설명했다. 소비주의 디자인에 대한 그린 디자인, 제3세계와 장애인 등을 위한 책임 있는 ...

알라딘

👉 오늘은 개인적인 애호가 담긴 디자인 책 “사회를 위한 디자인”을 소개합니다. 이 책은 디자인의 사회적 역할과 영향에 대해 깊이 있는 통찰을 제공합니다. 특히 디자인과 디자이너의 역할이 어떻게 사회적 맥락에서 이해되고 적용되어야 하는지 탐구하는 부분은 나온 지 오래된 책임에도 여전히 유효합니다.

🌱 저자인 나이젤 휘틀리는 디자인이 단순히 물리적인 제품의 형태를 결정하는 것을 넘어서, 사회적, 문화적 가치를 반영하고 형성하는 중요한 역할을 할 수 있다고 주장합니다. 책은 얼핏 디자인 자체를 반대하는 인상을 줍니다. 그런데 깊숙이 들어가면 소비주의 디자인을 반대하며 오히려 디자인이 사회에 유용한 힘이 될 수 있다는 것을 굳게 믿는다는 점에서 친디자인적인 책이라고 할 수 있습니다.

🌳 이 책은 '그린 디자인'처럼 당연히 옳은 것처럼 보이는 디자인도 다시 볼 것을 제안합니다. 환경을 생각하는 것이 일종의 라이프스타일로서 상품을 포장하는 패션이 될 수도 있다는 점입니다. 패스트푸드 포장지를 플라스틱재에서 종이로 바꾼 것은 환경적으로 올바르게 보이지만, 생산에 드는 에너지 및 폐기 비용에 있어서는 친환경적이지 않습니다. 이같이 그린 디자인이 이미지 정치에 머무를 수 있다는 점도 흥미롭습니다.

https://www.aladin.co.kr/m/mproduct.aspx?ItemId=510178

👉 오늘은 개인적인 애호가 담긴 디자인 책 “사회를 위한 디자인”을 소개합니다. 이 책은 디자인의 사회적 역할과 영향에 대해 깊이 있는 통찰을 제공합니다. 특히&nbsp;디자인과 디자이너의 역할이 어떻게 사회적 맥락에서 이해되고 적용되어야 하는지 탐구하는 부분은 나온 지 오래된 책임에도 여전히 유효합니다. 🌱 저자인 나이젤 휘틀리는 디자인이 단순히 물리적인 제품의 형태를 결정하는 것을 넘어서, 사회적, 문화적 가치를 반영하고 형성하는 중요한 역할을 할 수 있다고 주장합니다. 책은 얼핏 디자인 자체를 반대하는 인상을 줍니다. 그런데 깊숙이 들어가면 소비주의 디자인을 반대하며 오히려 디자인이 사회에 유용한 힘이 될 수 있다는 것을 굳게 믿는다는 점에서 친디자인적인 책이라고 할 수 있습니다. 🌳 이 책은 '그린 디자인'처럼 당연히 옳은 것처럼 보이는 디자인도 다시 볼 것을 제안합니다. 환경을 생각하는 것이 일종의 라이프스타일로서 상품을 포장하는 패션이 될 수도 있다는 점입니다. 패스트푸드 포장지를 플라스틱재에서 종이로 바꾼 것은 환경적으로 올바르게 보이지만, 생산에 드는 에너지 및 폐기 비용에 있어서는 친환경적이지 않습니다. 이같이 그린 디자인이 이미지 정치에 머무를 수 있다는 점도 흥미롭습니다. https://www.aladin.co.kr/m/mproduct.aspx?ItemId=510178

aladin

🌎디자인의 사회적 역할: ‘사회를 위한 디자인’ 책 리뷰

안녕하세요, 저는 오랜 경력의 백엔드 개발자입니다. 개발과는 별개로 건강을 위한 취미로 달리기를 시작한지 2년이 좀 넘었습니다. 달리기로 치자면 3년차 주니어 러너인 셈이지요. 가만히 보니까 제가 달리기를 하면서 배우고 있는 점들이 개발자 커리어에도 비슷하게 통할 것 같은 부분이 꽤 있더라구요. 그래서, 개발자 경력을 돌이켜봤을 때, 3년차 이하 개발자분들에게 도움이 될지도 모르는 팁을 공유해보려 합니다.

충분한 시간이 필요합니다

개발자하기로 마음 먹었으면 하루 빨리 실력있는 개발자가 되고 싶은 게 당연합니다. 달리기도 시작할 때는 꾸준히 운동하는 것만이 목표였지만, 어느새 잘뛰고 싶어지더라구요. 하지만 달리기라는 게 하루아침에 잘 뛰어지지가 않습니다. 충분한 기간을 두고 조금씩 늘려가야지, 급한 마음에 서둘러 마일리지를 늘리다가는 부상을 입기 십상입니다. 마음만 급하고 스트레스만 받고, 정작 실력은 늘지 않는 문제에 빠지는 거죠. 뛰기 시작해서 3개월만에 마라톤을 뛰고 싶을 수도 있지만, 그건 무리한 생각입니다. 되는 사람도 있겠지만, 대부분의 사람들은 그러다가는 부상을 입고 말 거예요.

개발자도 그렇습니다. 부트캠프 나오고 몇 개월만에 개발자 되고, 2년차에는 수퍼 주니어가 되고 싶은 게 기본입니다만, 그게 그렇게 짧은 시간에 되는 게 아닙니다. 꾸준히, 매일매일, 매주매주 마일리지를 쌓아나가다보면 어느새 실력있는 개발자가 되는 게 기본 루트일 것 같습니다.
초보 시절에는 초보임을 인정하고 급하지 않게 꾸준히 훈련하는 것이 중요하겠습니다.

내가 직접 해야 합니다

유튜브에 워낙 고품질의 정보가 많기 때문에 달리기도 배울만한 채널이 많습니다. 수많은 달리기 유튜브 채널들을 보며 어떻게 훈련해야 하는지, 달리기 자세는 어떻게 해야 하는지, 신발은 어떤 걸 신으면 좋은지 수두룩한 정보를 구할 수 있습니다. 그런 유익한 정보도 중요하지만, 정작 가장 중요한 것은, 나가서 뛰는 행위 자체입니다. 그 모든 걸 압도하는 중요한 부분이 본인이 달리는 거리입니다.

개발도 마찬가지입니다. 개발서적을 학습하고, 온라인 강의를 수강하고, 질문과 답변으로 학습하고 이런 일들이 꽤 도움이 되지만, 정말 정작 중요한 것은 내가 직접 개발해보는 행위입니다. 개발하는 행위 자체를 달리기 마일리지라고 치고 꾸준히 매일매일 쌓아가야 합니다. 꾸준히 하면서, 보조적으로 서적을 보며 수강도 하는 것이 맞겠습니다. 만날 책이나 강의만 보고 있는 것은, 유튜브에서 달리기 영상 보면서 끄덕끄덕하면서 정작 나가서 뛰지는 않는 행위나 마찬가지입니다. 말짱 꽝이죠.

훌륭한 다수의 의견이 내게는 중요치 않을 수 있습니다

나보다 나아보이는 다수의 개발자들이 이렇다저렇다 좋은 정보들을 줄 때가 많은데, 정작 그 정보들이 내게는 유효하지 않을 수도 있습니다.

달리기로 예를들면, 저같은 초보들이 흔히 빠지는 함정이, 신발은 뭘 신어야 하는지, 케이던스는 얼마로 뛰어야 좋은지, 발 착지법은 어떻게 가져가야 하는지, 물은 얼마마다 마셔야하는지, 팔동작은 어떻게 흔들어야 하는지, 별 사소한 팁들이 많습니다. 게다가 친절하게도 이 모든 정보들을 시시콜콜 알려주는 사람들이 많아요.

그런데, 열심히 정보를 취합하다보면, 어쩌면 저 정보들의 의미없겠다 싶을 때가 있습니다. 예를들어 케이던스를 놓고 보자면, 180정도가 가장 효율적이라고 하는데, 잘 뛰는 선수들이 180을 내는 거지, 내가 뛰는 속도에서 내 신체에서 과연 180이 최적인가는 의문이 있습니다. 그러니까, 선수급이 마라톤을 2시간 초반에 뛰는 속도에서 최적인건데, 내가 2시간대에 마라톤을 뛸 수 있을리 만무합니다. 내가 그런 부차적 지표에 기준을 삼아서 노력하는 것은 무의미할 수도 있겠다 싶습니다.

그런데 어설픈 상식수준에서는 그게 그럴싸해 보이잖아요? 엘리트 선수들 보면 보통 180케이던스를 유지하더라. 그리고 실험한 결과를 보면 케이던스가 180근처인 게 가장 효과적이더라라는 결과들도 있겠죠. 근데 그게 그렇다고 억지로 케이던스를 180에 맞추는 게, 초보인 내 입장에서 달리기 마일리지보다 더 중요하냐?는 건 의심해봐야 하겠습니다.

개발자 입장에서, 뭐는 이렇게 해야하고 저건 이렇게 해야 한다는 주장들을 접할 때가 많은데요, 은근 빈번하게 별 쓸데 없는 고민에 시간 낭비하고 있는 경우가 많습니다. 한번쯤 정말 도움이 되는 얘기인가 고민해 볼 필요가 있다고 생각해요. 구글 개발자들은 이렇게 한다드라. 오 이런, 난 구글 개발자가 아니고 우리 회사는 구글이 아니며, 구글처럼 되어야할 이유도 없습니다. 정작 구글에서는 또 앞으로 어떻게 해야 한다드라 하면서 앞길을 가고 있을 겁니다.

달리기만 할 수는 없습니다

하루라도 빨리 좋은 개발자가 되기위해, 잠 줄여가며 노력하고 싶을 때도 있습니다. 하지만, 이게 장기전이기 때문에 단거리 달리기 하듯 계속 달릴 수는 없어요. 게다가 달리기 실력이 느는 것은 훈련시간 자체가 아니라, 훈련 후에 잘먹고 잘 쉴 때, 특히 잘 때 늡니다. 잘 자야 한다는 얘기예요. 잘 시간 줄여서 달리는 건, 잘 몰라서 하는 바보 같은 일이죠.

개발도, 너무 개발만 몰입해서는 개발실력이 늘리 없습니다. 잘 자는 건 당연하고, 개발 외의 공부들도 병행해 줘야 합니다. 잠 줄여서 개발 공부한다? 이것도 어리석은 일입니다. 공부했으면 잘 자야 머리속에서 정리가 되는 거죠.

재미가 있으면 훨씬 편합니다

처음에는 작심삼일을 여러번 하겠다고 달리기를 이악물고 시작했습니다. 의지박약인 내가 꾸준히 달리리면 정신 바짝차리고 열심히 해야 하는 거죠. 아무리 강한 의지력을 발휘한다고 해도, 사람인 이상 한계가 있습니다. 의지력만으로 1주일에 60K를 뛴다? 불가능한 일이라고 보겠습니다. 그럼 어떻게 이 지경(?)이 됐냐? 달리기 자체가 재밌어졌기 때문입니다. 재밌으면 지속하기가 훨씬 편합니다. 달리기가 재밌을 줄은 몰랐습니다.

남들은 개발을 어떻게 시작하게 됐는지는 몰라도, 적어도 제가 보기에 대단히 재밌는 활동입니다. 이 재미를 찾지 못하면 꾸준히 하기 너무 힘들지 않겠어요? 달리기는 하다 말면 그만이지만, 직업 개발자가 되기로 했다면 내 커리어 수십년 동안 해야 하는데, 이걸 이 악물고 꾸준히 열심히 한다? 너무 어려운 길이죠. 재미를 붙여서 하는 게 맞겠습니다. 재미가 있으면 누가 시키지 않아도 열심히 하겠죠.

그러니 그냥 막무가내로 열심히만 할 게 아니라, 재밌게 하는 방법을 고민해봐야 하겠습니다. 흔한 자료들은 "재미"에는 큰 중심을 두지 않기 때문에, 아쉽게도 각자 스스로 재미 포인트를 찾아야 하는 상황인 것 같습니다. 억지로 열심히 해서 잘하는 사람들도 많겠지만, 나도 꼭 그래야 하는 건 아닙니다. 재밌게해서 잘해도 되는 거 잖아요, 아니 재밌다면 더 좋은 거잖아요.

확실한 것은, 재미있는 것은 맞습니다. 그러니까 제가 이렇게 오랫동안 하고 있는 거겠죠. 정확히 말하자면, 재미 없으면 안하는 것이 맞겠습니다. 왜 힘들게 재미 없는 걸 계속 공부하며 노력을 해야 하나요? 늘 재밌어야 하는 건 아니지만, 꾸준히 할만큼 재밌는 포인트는 이따금씩이라도 반드시 있어야 합니다.

비교는 정신건강에 해롭습니다

달리기는 기록이 정확히 드러나기 때문에 남들과 비교하기 쉽습니다. 나는 어느 정도 속도로 얼마나 뛸 수 있는데, 저 사람은 어떻지? 내가 더 잘 뛰나? 저 사람이 더 잘 뛰나? 이런 비교는 내 달리기 본연의 목적과 다를 수 있습니다. 더 빠르고 느리고를 기준으로 삼으면 항상 누군가는 나보다 빠르기 마련이고 그럼 난 또 그 사람보다 못한 사람이 되는 논리에 빠지게 되는 거죠. 대회를 나가더라도 "완주"에 중점을 둔다면 참가자 대부분이 즐거운 결과를 누릴 수 있는데, "1등"을 노린다면, 그 1등은 행복할지 몰라도 나머지 절대 다수의 참가자들은 들러리가 되는 거 아닐까요?

개발자가 되려는데 남들보다 잘하는 개발자, 최고의 개발자가 되는 것이 목표라면, 이건 스스로를 이미 고문하는 감옥에 가두고 시작하는 꼴입니다.

달리기로 치자면, 지난 달의 나보다 잘 뛰게 되었을 때의 기쁨을 만끽한다거나, 아니면 꾸준히 뛰는 것만으로 만족할 수 있다면 지속적으로 즐겁게 달릴 수 있습니다. 애초에 달리기를 시작한 목적도 건강에 도움이 되는 활동이라는 것이기 때문에 그 목적은 대단히 초과달성하고 있는 거죠.

개발자로 치자면, 어떤 기준을 갖고 방향을 잡을지 스스로 잘 고민해보면 좋겠습니다.

꾸준함이 제일 중요합니다

달리기 실력이 느는 가장 중요한 팩터는 꾸준히 달리는 행위입니다. 어느 날 반짝 열심히 달린다거나, 어느 날 하루 오래 달린다고 해서, 갑자기 실력이 늘지 않습니다. 오랫동안 꾸준히 지속적으로 노력해야(즐겨야) 어느 순간 실력이 늡니다.

개발도 꾸준히 수련해야 합니다. 어느날 반짝 노력하거나 비기를 획득한다고 되는 게 아니니 끈기를 갖고, 재미를 붙여 오랫동안 열심히 할 마음으로 지내면 좋다고 생각해요.

내가 그리 대단치 않습니다

달리기 시작할 때는, 제가 그래도 어려서 육상 선수였는데 조금만 하면 잘 할 줄 알았습니다. 근데 뭐 당연하게도 한참 못 뛰더라구요. 오래달리기는 그야말로 마일리지가 깡패입니다. 많이 뛰면 뛴 만큼 잘하게 되어있습니다. 마일리지를 일단 채워두고 거기서 실력이 나누어지기야 하겠지만, 일단 초보된 입장에서는 오로지 달리기 마일리지만이 핵심입니다. 평소 다른 운동을 잘했건 어려서 육상선수였건 말건 이딴 건 아무런 도움이 되지 않습니다. 그저 초보된 입장에서 차근차근 쌓아 올려야 합니다.

개발도 그렇습니다. 우리가 어떤 다른 분야에서 날고 기었다 한들, 새로 시작했으면 생초보입니다. 겸손하게 난 아무것도 아니라는 시작점에서 차근히 여유롭게 나아가면 됩니다. 지나치게 기죽을 필요도 없지만, 그렇다고 강한 에고를 내세워서 좋을 것도 없겠습니다.

이상, 달리기와 개발을 좀 억지로 엮어서 팁을 적어보았습니다. 뛰어난 러너도 아니고 훌륭한 개발자도 아니면서 이렇다저렇다 적으니 부끄럽습니다만, 공감되는 부분이 있으셨으면 좋겠습니다. 어떻게 생각하시는지 댓글 남겨주시면 제게도 큰 도움이 되겠습니다.

(아래 사진은 얼마전 제주 사계해안에서 일출 때 10K 개인기록 세운 날입니다 ㅎ)

안녕하세요, 저는 오랜 경력의 백엔드 개발자입니다. 개발과는 별개로 건강을 위한 취미로 달리기를 시작한지 2년이 좀 넘었습니다. 달리기로 치자면 3년차 주니어 러너인 셈이지요. 가만히 보니까 제가 달리기를 하면서 배우고 있는 점들이 개발자 커리어에도 비슷하게 통할 것 같은 부분이 꽤 있더라구요. 그래서, 개발자 경력을 돌이켜봤을 때, 3년차 이하 개발자분들에게 도움이 될지도 모르는 팁을 공유해보려 합니다. 충분한 시간이 필요합니다 개발자하기로 마음 먹었으면 하루 빨리 실력있는 개발자가 되고 싶은 게 당연합니다. 달리기도 시작할 때는 꾸준히 운동하는 것만이 목표였지만, 어느새 잘뛰고 싶어지더라구요. 하지만 달리기라는 게 하루아침에 잘 뛰어지지가 않습니다. 충분한 기간을 두고 조금씩 늘려가야지, 급한 마음에 서둘러 마일리지를 늘리다가는 부상을 입기 십상입니다. 마음만 급하고 스트레스만 받고, 정작 실력은 늘지 않는 문제에 빠지는 거죠. 뛰기 시작해서 3개월만에 마라톤을 뛰고 싶을 수도 있지만, 그건 무리한 생각입니다. 되는 사람도 있겠지만, 대부분의 사람들은 그러다가는 부상을 입고 말 거예요. 개발자도 그렇습니다. 부트캠프 나오고 몇 개월만에 개발자 되고, 2년차에는 수퍼 주니어가 되고 싶은 게 기본입니다만, 그게 그렇게 짧은 시간에 되는 게 아닙니다. 꾸준히, 매일매일, 매주매주 마일리지를 쌓아나가다보면 어느새 실력있는 개발자가 되는 게 기본 루트일 것 같습니다.초보 시절에는 초보임을 인정하고 급하지 않게 꾸준히 훈련하는 것이 중요하겠습니다. 내가 직접 해야 합니다 유튜브에 워낙 고품질의 정보가 많기 때문에 달리기도 배울만한 채널이 많습니다. 수많은 달리기 유튜브 채널들을 보며 어떻게 훈련해야 하는지, 달리기 자세는 어떻게 해야 하는지, 신발은 어떤 걸 신으면 좋은지 수두룩한 정보를 구할 수 있습니다. 그런 유익한 정보도 중요하지만, 정작 가장 중요한 것은, 나가서 뛰는 행위 자체입니다. 그 모든 걸 압도하는 중요한 부분이 본인이 달리는 거리입니다. 개발도 마찬가지입니다. 개발서적을 학습하고, 온라인 강의를 수강하고, 질문과 답변으로 학습하고 이런 일들이 꽤 도움이 되지만, 정말 정작 중요한 것은 내가 직접 개발해보는 행위입니다. 개발하는 행위 자체를 달리기 마일리지라고 치고 꾸준히 매일매일 쌓아가야 합니다. 꾸준히 하면서, 보조적으로 서적을 보며 수강도 하는 것이 맞겠습니다. 만날 책이나 강의만 보고 있는 것은, 유튜브에서 달리기 영상 보면서 끄덕끄덕하면서 정작 나가서 뛰지는 않는 행위나 마찬가지입니다. 말짱 꽝이죠. 훌륭한 다수의 의견이 내게는 중요치 않을 수 있습니다 나보다 나아보이는 다수의 개발자들이 이렇다저렇다 좋은 정보들을 줄 때가 많은데, 정작 그 정보들이 내게는 유효하지 않을 수도 있습니다. 달리기로 예를들면, 저같은 초보들이 흔히 빠지는 함정이, 신발은 뭘 신어야 하는지, 케이던스는 얼마로 뛰어야 좋은지, 발 착지법은 어떻게 가져가야 하는지, 물은 얼마마다 마셔야하는지, 팔동작은 어떻게 흔들어야 하는지, 별 사소한 팁들이 많습니다. 게다가 친절하게도 이 모든 정보들을 시시콜콜 알려주는 사람들이 많아요. 그런데, 열심히 정보를 취합하다보면, 어쩌면 저 정보들의 의미없겠다 싶을 때가 있습니다. 예를들어 케이던스를 놓고 보자면, 180정도가 가장 효율적이라고 하는데, 잘 뛰는 선수들이 180을 내는 거지, 내가 뛰는 속도에서 내 신체에서 과연 180이 최적인가는 의문이 있습니다. 그러니까, 선수급이 마라톤을 2시간 초반에 뛰는 속도에서 최적인건데, 내가 2시간대에 마라톤을 뛸 수 있을리 만무합니다. 내가 그런 부차적 지표에 기준을 삼아서 노력하는 것은 무의미할 수도 있겠다 싶습니다. 그런데 어설픈 상식수준에서는 그게 그럴싸해 보이잖아요? 엘리트 선수들 보면 보통 180케이던스를 유지하더라. 그리고 실험한 결과를 보면 케이던스가 180근처인 게 가장 효과적이더라라는 결과들도 있겠죠. 근데 그게 그렇다고 억지로 케이던스를 180에 맞추는 게, 초보인 내 입장에서 달리기 마일리지보다 더 중요하냐?는 건 의심해봐야 하겠습니다. 개발자 입장에서, 뭐는 이렇게 해야하고 저건 이렇게 해야 한다는 주장들을 접할 때가 많은데요, 은근 빈번하게 별 쓸데 없는 고민에 시간 낭비하고 있는 경우가 많습니다. 한번쯤 정말 도움이 되는 얘기인가 고민해 볼 필요가 있다고 생각해요. 구글 개발자들은 이렇게 한다드라. 오 이런, 난 구글 개발자가 아니고 우리 회사는 구글이 아니며, 구글처럼 되어야할 이유도 없습니다. 정작 구글에서는 또 앞으로 어떻게 해야 한다드라 하면서 앞길을 가고 있을 겁니다. 달리기만 할 수는 없습니다 하루라도 빨리 좋은 개발자가 되기위해, 잠 줄여가며 노력하고 싶을 때도 있습니다. 하지만, 이게 장기전이기 때문에 단거리 달리기 하듯 계속 달릴 수는 없어요. 게다가 달리기 실력이 느는 것은 훈련시간 자체가 아니라, 훈련 후에 잘먹고 잘 쉴 때, 특히 잘 때 늡니다. 잘 자야 한다는 얘기예요. 잘 시간 줄여서 달리는 건, 잘 몰라서 하는 바보 같은 일이죠. 개발도, 너무 개발만 몰입해서는 개발실력이 늘리 없습니다. 잘 자는 건 당연하고, 개발 외의 공부들도 병행해 줘야 합니다. 잠 줄여서 개발 공부한다? 이것도 어리석은 일입니다. 공부했으면 잘 자야 머리속에서 정리가 되는 거죠. 재미가 있으면 훨씬 편합니다 처음에는 작심삼일을 여러번 하겠다고 달리기를 이악물고 시작했습니다. 의지박약인 내가 꾸준히 달리리면 정신 바짝차리고 열심히 해야 하는 거죠. 아무리 강한 의지력을 발휘한다고 해도, 사람인 이상 한계가 있습니다. 의지력만으로 1주일에 60K를 뛴다? 불가능한 일이라고 보겠습니다. 그럼 어떻게 이 지경(?)이 됐냐? 달리기 자체가 재밌어졌기 때문입니다. 재밌으면 지속하기가 훨씬 편합니다. 달리기가 재밌을 줄은 몰랐습니다. 남들은 개발을 어떻게 시작하게 됐는지는 몰라도, 적어도 제가 보기에 대단히 재밌는 활동입니다. 이 재미를 찾지 못하면 꾸준히 하기 너무 힘들지 않겠어요? 달리기는 하다 말면 그만이지만, 직업 개발자가 되기로 했다면 내 커리어 수십년 동안 해야 하는데, 이걸 이 악물고 꾸준히 열심히 한다? 너무 어려운 길이죠. 재미를 붙여서 하는 게 맞겠습니다. 재미가 있으면 누가 시키지 않아도 열심히 하겠죠. 그러니 그냥 막무가내로 열심히만 할 게 아니라, 재밌게 하는 방법을 고민해봐야 하겠습니다. 흔한 자료들은 "재미"에는 큰 중심을 두지 않기 때문에, 아쉽게도 각자 스스로 재미 포인트를 찾아야 하는 상황인 것 같습니다. 억지로 열심히 해서 잘하는 사람들도 많겠지만, 나도 꼭 그래야 하는 건 아닙니다. 재밌게해서 잘해도 되는 거 잖아요, 아니 재밌다면 더 좋은 거잖아요. 확실한 것은, 재미있는 것은 맞습니다. 그러니까 제가 이렇게 오랫동안 하고 있는 거겠죠. 정확히 말하자면, 재미 없으면 안하는 것이 맞겠습니다. 왜 힘들게 재미 없는 걸 계속 공부하며 노력을 해야 하나요? 늘 재밌어야 하는 건 아니지만, 꾸준히 할만큼 재밌는 포인트는 이따금씩이라도 반드시 있어야 합니다. 비교는 정신건강에 해롭습니다 달리기는 기록이 정확히 드러나기 때문에 남들과 비교하기 쉽습니다. 나는 어느 정도 속도로 얼마나 뛸 수 있는데, 저 사람은 어떻지? 내가 더 잘 뛰나? 저 사람이 더 잘 뛰나? 이런 비교는 내 달리기 본연의 목적과 다를 수 있습니다. 더 빠르고 느리고를 기준으로 삼으면 항상 누군가는 나보다 빠르기 마련이고 그럼 난 또 그 사람보다 못한 사람이 되는 논리에 빠지게 되는 거죠. 대회를 나가더라도 "완주"에 중점을 둔다면 참가자 대부분이 즐거운 결과를 누릴 수 있는데, "1등"을 노린다면, 그 1등은 행복할지 몰라도 나머지 절대 다수의 참가자들은 들러리가 되는 거 아닐까요? 개발자가 되려는데 남들보다 잘하는 개발자, 최고의 개발자가 되는 것이 목표라면, 이건 스스로를 이미 고문하는 감옥에 가두고 시작하는 꼴입니다. 달리기로 치자면, 지난 달의 나보다 잘 뛰게 되었을 때의 기쁨을 만끽한다거나, 아니면 꾸준히 뛰는 것만으로 만족할 수 있다면 지속적으로 즐겁게 달릴 수 있습니다. 애초에 달리기를 시작한 목적도 건강에 도움이 되는 활동이라는 것이기 때문에 그 목적은 대단히 초과달성하고 있는 거죠. 개발자로 치자면, 어떤 기준을 갖고 방향을 잡을지 스스로 잘 고민해보면 좋겠습니다. 꾸준함이 제일 중요합니다 달리기 실력이 느는 가장 중요한 팩터는 꾸준히 달리는 행위입니다. 어느 날 반짝 열심히 달린다거나, 어느 날 하루 오래 달린다고 해서, 갑자기 실력이 늘지 않습니다. 오랫동안 꾸준히 지속적으로 노력해야(즐겨야) 어느 순간 실력이 늡니다. 개발도 꾸준히 수련해야 합니다. 어느날 반짝 노력하거나 비기를 획득한다고 되는 게 아니니 끈기를 갖고, 재미를 붙여 오랫동안 열심히 할 마음으로 지내면 좋다고 생각해요. 내가 그리 대단치 않습니다 달리기 시작할 때는, 제가 그래도 어려서 육상 선수였는데 조금만 하면 잘 할 줄 알았습니다. 근데 뭐 당연하게도 한참 못 뛰더라구요. 오래달리기는 그야말로 마일리지가 깡패입니다. 많이 뛰면 뛴 만큼 잘하게 되어있습니다. 마일리지를 일단 채워두고 거기서 실력이 나누어지기야 하겠지만, 일단 초보된 입장에서는 오로지 달리기 마일리지만이 핵심입니다. 평소 다른 운동을 잘했건 어려서 육상선수였건 말건 이딴 건 아무런 도움이 되지 않습니다. 그저 초보된 입장에서 차근차근 쌓아 올려야 합니다. 개발도 그렇습니다. 우리가 어떤 다른 분야에서 날고 기었다 한들, 새로 시작했으면 생초보입니다. 겸손하게 난 아무것도 아니라는 시작점에서 차근히 여유롭게 나아가면 됩니다. 지나치게 기죽을 필요도 없지만, 그렇다고 강한 에고를 내세워서 좋을 것도 없겠습니다. 이상, 달리기와 개발을 좀 억지로 엮어서 팁을 적어보았습니다. 뛰어난 러너도 아니고 훌륭한 개발자도 아니면서 이렇다저렇다 적으니 부끄럽습니다만, 공감되는 부분이 있으셨으면 좋겠습니다. 어떻게 생각하시는지 댓글 남겨주시면 제게도 큰 도움이 되겠습니다. (아래 사진은 얼마전 제주 사계해안에서 일출 때 10K 개인기록 세운 날입니다 ㅎ)

달리기에서 배우는 괜찮은 개발자 되는 법

항상 양질의 글들을 올려주셔서 잘 보고있습니다 감사합니다

원문 : https&#x3A;//cpojer.net/posts/dependency-managers-dont-manage-your-dependencies

[번역] 의존성 관리자는 의존성을 관리하지 않습니다

오늘 소개해드릴 글은 라인플러스의 손수림님이 번역해주신 글입니다. 이 글은 자바스크립트 인프라 시리즈의 첫 번째 글로 자바스크립트 의존성 관리자의 근본적인 문제점에 대해 이야기를 하고 있습니다. 글의 내용이 다소 어렵지만 의존성이 내부에서 어떤 식으로 관리가 되고 있는지와 이러한 문제점들을 피하여 의존성을 제어할 수 있는 가이드를 제공하고 있어 관심 있으신 분들에게는 도움이 될 것 같습니다. :)

 * 글 링크: https://velog.io/@surim014/dependency-managers-dont-manage-your-dependencies

오늘 소개해드릴 글은 라인플러스의 손수림님이 번역해주신 글입니다. 이 글은 자바스크립트 인프라 시리즈의 첫 번째 글로 자바스크립트 의존성 관리자의 근본적인 문제점에 대해 이야기를 하고 있습니다. 글의 내용이 다소 어렵지만 의존성이 내부에서 어떤 식으로 관리가 되고 있는지와 이러한 문제점들을 피하여 의존성을 제어할 수 있는 가이드를 제공하고 있어 관심 있으신 분들에게는 도움이 될 것 같습니다. :) <ul><li>글 링크: https://velog.io/@surim014/dependency-managers-dont-manage-your-dependencies</li></ul>

Velog

의존성 관리자는 의존성을 관리하지 않습니다

1️⃣ 개발 공부하는 것처럼 취업 공부도 꾸준히 해야 한다

이직 준비하면서 많이 해보지 않은 리트코드 문제 풀기와 전혀 구현해 본 적 없는 시스템을 설계를 해야 할 수 있어요. 그래서 취업 공부를 꾸준히 해주는 게 좋습니다. 일주일에 리트코드 문제 3개씩 풀기 또는 설계 관련 책과 글을 2시간씩 읽기처럼 작은 습관을 기르는 게 좋아요. 확실히 리트코드 문제를 꾸준히 풀어 주고 설계 관련 글을 읽어 주면 취업 준비하는 데 수월해요.

그리고 특히 요즘처럼 고용 시장이 불안정할 때 취업 공부 습관을 가지면 좋을 것 같아요.

2️⃣ 리트코드 문제를 그대로 제출하기보다 응용하는 쪽이 훨씬 많았다

이번에 세어보지 않았지만, 리트코드와 동일한 문제가 나온 경우는 아주 적었어요. 리트코드 문제를 응용한 문제가 훨씬 더 많았습니다. 물론 제가 리트코드 플랫폼에 있는 문제를 다 풀어 본 게 아니라 모를 수도 있지만, 직접 확인했을 때 리트코드 풀랫폼에 안 보이던 문제가 많았어요. 따라서 코딩테스트를 준비할 때 솔루션을 외우는 건 도움 되지 않습니다. 대신 문제의 핵심과 알고리즘 개념을 정확하게 파악하고 문제 해결 능력을 기르는 게 좋아요.

3️⃣ 어떤 경력을 쌓았는지에 따라 취업 기회가 달라진다

취업 시장이 안 좋을수록 내가 어떤 경력을 쌓았는지에 따라 기회가 많을 수 있고 반대로 적을 수 있어요. 업계에서 중요하게 여기는 스킬을 갖추었다면 고용 시장이 어려워도 기회의 문이 상대적으로 많아요. 반대로 그렇지 않으면 이력서 스캔 단계에서 바로 탈락하는 경우가 아주 많습니다.

그리고 구인 공고에 업계에서 필요로 하는 기술을 갖고 있다면 지원 요건에 맞는 포지션이 상대적으로 많다는 걸 느낄 수 있습니다.

4️⃣ 현 직급보다 한 단계 높은 직급으로 면접 보기

실제 쌓은 경력과 실력이 뒷받침된다면 해외 취업의 경우 현 직급보다 한 단계 이상 높은 직급으로 면접 보는 게 좋습니다. 예를 들어 아마존에서 L6였다면 애플의 IC5 이상 직급으로 면접 보는 게 좋아요. 하지만 회사마다 직급별 요구되는 연차가 있어서 경력이 길지 않다면 기회조차 주지 않을 수 있습니다. 다만 가능하다면 한 단계 높은 직급으로 하는 게 좋습니다.

하지만 여기서 중요한 건 직함은 중요하지 않아요. 회사마다 직급별 직함이 다양하게 존재하고, 연봉과 업무 범위에 중요한 것은 직함이 아니라 직급입니다. 해외 취업할 때 직함이 높아서 면접 보고 입사했다가 후회할 수 있어요. 직함이 부풀려진 회사가 꽤 있기에 상대적으로 연봉과 업무 범위가 상당히 적을 수 있습니다. levels.fyi에서 회사별 직급을 비교 분석 꼭 해보세요.

그리고 직급보다 더 중요한 건 업무 범위와 성장 기회 그리고 쌓을 수 있는 경력입니다. 아무리 직급이 높아도 도움 되지 않은 기술을 쌓거나 개발 경력을 쌓을 수 없는 프로젝트를 맡으면 성장형 개발자가 될 수 없는 것 같아요. 팀이 어떤 기술을 구현하고 어떤 개발 기회가 있는지 그리고 비지니스 영향력이 있는지 파악해 보세요.

5️⃣ 퇴사를 잘하는 것이 중요하다

최종 면접까지 통과한 후 과거 직장 동료의 레퍼런스를 꼼꼼하게 확인하는 곳이 꽤 있었어요. 과거 관리자의 레퍼런스를 받아 오라고 한 곳도 있었습니다. 따라서 퇴사를 잘하고 전/현 직장 동료와 잘 지내는 게 중요합니다.

그뿐만 아니라 과거 함께 일했던 사람이 내가 미래에 일하고자 하는 회사에 근무할 수도 있어요. 더 나아가 팀의 관리자가 되어 필요한 개인 기여자를 고용하는 하이어링 매니저(hiring manager)가 될 수도 있어요. 그들을 통해 다른 지원자보다 면접 기회를 더 빨리 얻게 됩니다.

따라서 퇴사를 잘하고 함께 일했던 사람과 연락하며 지내는 게 중요합니다.

6️⃣ 미리 연봉 협상하고 면접하는 곳이 있다

어떤 회사의 경우 생각하는 예상하는 연봉 범위를 미리 알려 달라고 했어요. 그리고 어떤 회사는 levels.fyi에 나온 연봉 데이터보다 낮은 연봉 범위를 알리는 곳이 있었어요. 예전에는 면접을 다 끝내고 합격한 후 연봉 협상을 했던 것 같은데, 이번에는 의외로 1~2차 면접에 합격하고 최종 면접하기 전에 미리 연봉 범위를 조율하는 곳이 있었어요. 그리고 최종 합격해도 미리 알려준 예상 연봉 범위보다 더 줄 수 없다며 그래도 최종 면접을 진행하고 싶냐고 단호하게 말하는 곳이 있었어요.

그리고 반면에 levels.fyi에 나온 평균 연봉보다 생각보다 훨씬 많이 주는 곳이 있었어요. 따라서 levels.fyi 플랫폼은 '대충 연봉 범위를 알 수 있다'라는 정도로만 생각하시고 그 숫자에 너무 얽매이지 않는 것이 좋습니다.

7️⃣ 공부보다 중요한 건 '어떤 경력을 쌓았는가?'다

취업 공부하면 당연히 도움 되지만, 그것보다 중요한 건 어떤 경력을 쌓았는지가 아주 중요합니다. 아무리 열심히 공부해도, 실무를 통해 기술 실력을 쌓은 사람과 아닌 사람의 차이가 경력직일수록 크게 보입니다. 그래서 커리어 쌓을 때 늘 성장하고 있는지 체크하는 게 좋아요. 제자리 걸음하고 있거나, 크게 성장하지 않는다면 이직할 때 불리할 수 있어요.

8️⃣ 경력직일수록 자격 요건을 깐깐하게 본다

7번 어떤 경력을 쌓았는지 중요한 이유가 경력직일수록 자격 요건에 부합하는지 깐깐하게 봅니다. 실제 필요한 개발 실력과 경력을 가졌는지 아닌지를 꼼꼼하게 물어보는 경우가 많았어요. 특히 면접관도 경력이 많은 사람일 가능성이 크기때문에 행동 면접이나 설계 면접에서 기술 부분을 아주 심도있게 파고드는 경우가 꽤 많았어요. 주니어나 중니어 시절에는 상위레벨 정도만 이야기해도 되었지만, 경력이 많으면 하위레벨의 개념까지 깊게 파고드는 곳이 꽤 많이 있었습니다(또는 요즘 고용 시장이 어려워서 지원자가 많아서 깐깐하게 본 걸 수도 있음).

9️⃣ 다양한 면접 프로세스가 존재한다

예전에 이직 준비했을 때는 면접 프로세스가 다 비슷했던 것 같은데, 최근에 해보니 프로세스가 다양화되었다는 걸 느꼈어요.

예를 들어, 보통 해외 취업의 면접 과정은 대개 다음과 같습니다.
 * 이력서 통과
 * 채용 담당자와 통화 (30분에서 1시간)
 * 코딩테스트 면접 (1시간)
 * 최종 면접 (보통 4~5시간)

하지만 이번에 이직하면서 느낀 건 코딩테스트 면접이 1차 이상 있는 곳이 있었고, 1차 면접에 코딩테스트가 아니라 시스템 설계 테스트하는 곳도 있었어요. 채용 담당자와 통화하고 코딩테스트하기 전에 하이어링 매니저와 행동 면접 인터뷰를 먼저 보는 곳도 있었어요. 그리고 최종 면접이 총 7시간 걸리는 곳도 있었습니다 (대신 최종 면접 경우 여러 날에 나누어서 볼 수 있음).

그래서, 대충 제가 겪었던 모든 프로세스를 다 나열해 보면 다음과 같습니다.
 * 이력서 통과
 * 채용 담당자와 통화
 * 하이어링 매니저와 행동 면접
 * 1차 코딩 및 시스템 설계 테스트
 * (회사에 따라) 2차, 3차, 4차 코딩 및 시스템 설계 테스트
 * 최종 면접 (4~7시간)

-------------

최근에 이직이나 취업 준비해 본 분이라면 여러분이 배운 점과 중요하게 생각한 점도 댓글에 공유해 주세요. 다음 포스팅에는 면접 관련 팁 몇 가지 공유해 볼게요.

🔗 시리즈
 1. 1탄: 아마존 퇴사와 빅테크 이직 준비 https://careerly.co.kr/comments/95006
 2. 2탄: 취업 준비 시 같이 준비해야 할 것들 https://careerly.co.kr/comments/95038
 3. 3탄: [현재글] 이직 준비하면서 배운 점
 4. 4탄: 알고리즘, 시스템 설계, 행동 면접 팁 https://careerly.co.kr/comments/95187
 5. 5탄: 최종 합격 후 꼭 해야 할 일 https://careerly.co.kr/comments/95312

🪴 함께 읽으면 좋은 글

개발자가 된 후 저지른 실수들
https://careerly.co.kr/comments/94020

성장형 개발자가 피해야 할 실수
https://careerly.co.kr/comments/91571

1️⃣ 개발 공부하는 것처럼 취업 공부도 꾸준히 해야 한다 이직 준비하면서 많이 해보지 않은 리트코드 문제 풀기와 전혀 구현해 본 적 없는 시스템을 설계를 해야 할 수 있어요. 그래서 취업 공부를 꾸준히 해주는 게 좋습니다. 일주일에 리트코드 문제 3개씩 풀기 또는 설계 관련 책과 글을 2시간씩 읽기처럼 작은 습관을 기르는 게 좋아요. 확실히 리트코드 문제를 꾸준히 풀어 주고 설계 관련 글을 읽어 주면 취업 준비하는 데 수월해요. 그리고 특히 요즘처럼 고용 시장이 불안정할 때 취업 공부 습관을 가지면 좋을 것 같아요. 2️⃣ 리트코드 문제를 그대로 제출하기보다 응용하는 쪽이 훨씬 많았다 이번에 세어보지 않았지만, 리트코드와 동일한 문제가 나온 경우는 아주 적었어요. 리트코드 문제를 응용한 문제가 훨씬 더 많았습니다. 물론 제가 리트코드 플랫폼에 있는 문제를 다 풀어 본 게 아니라 모를 수도 있지만, 직접 확인했을 때 리트코드 풀랫폼에 안 보이던 문제가 많았어요. 따라서 코딩테스트를 준비할 때 솔루션을 외우는 건 도움 되지 않습니다. 대신 문제의 핵심과 알고리즘 개념을 정확하게 파악하고 문제 해결 능력을 기르는 게 좋아요. 3️⃣ 어떤 경력을 쌓았는지에 따라 취업 기회가 달라진다 취업 시장이 안 좋을수록 내가 어떤 경력을 쌓았는지에 따라 기회가 많을 수 있고 반대로 적을 수 있어요. 업계에서 중요하게 여기는 스킬을 갖추었다면 고용 시장이 어려워도 기회의 문이 상대적으로 많아요. 반대로 그렇지 않으면 이력서 스캔 단계에서 바로 탈락하는 경우가 아주 많습니다. 그리고 구인 공고에 업계에서 필요로 하는 기술을 갖고 있다면 지원 요건에 맞는 포지션이 상대적으로 많다는 걸 느낄 수 있습니다. 4️⃣ 현 직급보다 한 단계 높은 직급으로 면접 보기 실제 쌓은 경력과 실력이 뒷받침된다면 해외 취업의 경우 현 직급보다 한 단계 이상 높은 직급으로 면접 보는 게 좋습니다. 예를 들어 아마존에서 L6였다면 애플의 IC5 이상 직급으로 면접 보는 게 좋아요. 하지만 회사마다 직급별 요구되는 연차가 있어서 경력이 길지 않다면 기회조차 주지 않을 수 있습니다. 다만 가능하다면 한 단계 높은 직급으로 하는 게 좋습니다. 하지만 여기서 중요한 건 직함은 중요하지 않아요. 회사마다 직급별 직함이 다양하게 존재하고, 연봉과 업무 범위에 중요한 것은 직함이 아니라 직급입니다. 해외 취업할 때 직함이 높아서 면접 보고 입사했다가 후회할 수 있어요. 직함이 부풀려진 회사가 꽤 있기에 상대적으로 연봉과 업무 범위가 상당히 적을 수 있습니다. levels.fyi에서 회사별 직급을 비교 분석 꼭 해보세요. 그리고 직급보다 더 중요한 건 업무 범위와 성장 기회 그리고 쌓을 수 있는 경력입니다. 아무리 직급이 높아도 도움 되지 않은 기술을 쌓거나 개발 경력을 쌓을 수 없는 프로젝트를 맡으면 성장형 개발자가 될 수 없는 것 같아요. 팀이 어떤 기술을 구현하고 어떤 개발 기회가 있는지 그리고 비지니스 영향력이 있는지 파악해 보세요. 5️⃣ 퇴사를 잘하는 것이 중요하다 최종 면접까지 통과한 후 과거 직장 동료의 레퍼런스를 꼼꼼하게 확인하는 곳이 꽤 있었어요. 과거 관리자의 레퍼런스를 받아 오라고 한 곳도 있었습니다. 따라서 퇴사를 잘하고 전/현 직장 동료와 잘 지내는 게 중요합니다. 그뿐만 아니라 과거 함께 일했던 사람이 내가 미래에 일하고자 하는 회사에 근무할 수도 있어요. 더 나아가 팀의 관리자가 되어 필요한 개인 기여자를 고용하는 하이어링 매니저(hiring manager)가 될 수도 있어요. 그들을 통해 다른 지원자보다 면접 기회를 더 빨리 얻게 됩니다. 따라서 퇴사를 잘하고 함께 일했던 사람과 연락하며 지내는 게 중요합니다. 6️⃣ 미리 연봉 협상하고 면접하는 곳이 있다 어떤 회사의 경우 생각하는 예상하는 연봉 범위를 미리 알려 달라고 했어요. 그리고 어떤 회사는 levels.fyi에 나온 연봉 데이터보다 낮은 연봉 범위를 알리는 곳이 있었어요. 예전에는 면접을 다 끝내고 합격한 후 연봉 협상을 했던 것 같은데, 이번에는 의외로 1~2차 면접에 합격하고 최종 면접하기 전에 미리 연봉 범위를 조율하는 곳이 있었어요. 그리고 최종 합격해도 미리 알려준 예상 연봉 범위보다 더 줄 수 없다며 그래도 최종 면접을 진행하고 싶냐고 단호하게 말하는 곳이 있었어요. 그리고 반면에 levels.fyi에 나온 평균 연봉보다 생각보다 훨씬 많이 주는 곳이 있었어요. 따라서 levels.fyi 플랫폼은 '대충 연봉 범위를 알 수 있다'라는 정도로만 생각하시고 그 숫자에 너무 얽매이지 않는 것이 좋습니다. 7️⃣ 공부보다 중요한 건 '어떤 경력을 쌓았는가?'다 취업 공부하면 당연히 도움 되지만, 그것보다 중요한 건 어떤 경력을 쌓았는지가 아주 중요합니다. 아무리 열심히 공부해도, 실무를 통해 기술 실력을 쌓은 사람과 아닌 사람의 차이가 경력직일수록 크게 보입니다. 그래서 커리어 쌓을 때 늘 성장하고 있는지 체크하는 게 좋아요. 제자리 걸음하고 있거나, 크게 성장하지 않는다면 이직할 때 불리할 수 있어요. 8️⃣ 경력직일수록 자격 요건을 깐깐하게 본다 7번 어떤 경력을 쌓았는지 중요한 이유가 경력직일수록 자격 요건에 부합하는지 깐깐하게 봅니다. 실제 필요한 개발 실력과 경력을 가졌는지 아닌지를 꼼꼼하게 물어보는 경우가 많았어요. 특히 면접관도 경력이 많은 사람일 가능성이 크기때문에 행동 면접이나 설계 면접에서 기술 부분을 아주 심도있게 파고드는 경우가 꽤 많았어요. 주니어나 중니어 시절에는 상위레벨 정도만 이야기해도 되었지만, 경력이 많으면 하위레벨의 개념까지 깊게 파고드는 곳이 꽤 많이 있었습니다(또는 요즘 고용 시장이 어려워서 지원자가 많아서 깐깐하게 본 걸 수도 있음). 9️⃣ 다양한 면접 프로세스가 존재한다 예전에 이직 준비했을 때는 면접 프로세스가 다 비슷했던 것 같은데, 최근에 해보니 프로세스가 다양화되었다는 걸 느꼈어요. 예를 들어, 보통 해외 취업의 면접 과정은 대개 다음과 같습니다.<ul><li>이력서 통과</li><li>채용 담당자와 통화 (30분에서 1시간)</li><li>코딩테스트 면접 (1시간)</li><li>최종 면접 (보통 4~5시간)</li></ul> 하지만 이번에 이직하면서 느낀 건 코딩테스트 면접이 1차 이상 있는 곳이 있었고, 1차 면접에 코딩테스트가 아니라 시스템 설계 테스트하는 곳도 있었어요. 채용 담당자와 통화하고 코딩테스트하기 전에 하이어링 매니저와 행동 면접 인터뷰를 먼저 보는 곳도 있었어요. 그리고 최종 면접이 총 7시간 걸리는 곳도 있었습니다 (대신 최종 면접 경우 여러 날에 나누어서 볼 수 있음). 그래서, 대충 제가 겪었던 모든 프로세스를 다 나열해 보면 다음과 같습니다.<ul><li>이력서 통과</li><li>채용 담당자와 통화</li><li>하이어링 매니저와 행동 면접</li><li>1차 코딩 및 시스템 설계 테스트</li><li>(회사에 따라) 2차, 3차, 4차 코딩 및 시스템 설계 테스트</li><li>최종 면접 (4~7시간)</li></ul> ------------- 최근에 이직이나 취업 준비해 본 분이라면 여러분이 배운 점과 중요하게 생각한 점도 댓글에 공유해 주세요. 다음 포스팅에는 면접 관련 팁 몇 가지 공유해 볼게요. 🔗 시리즈<ol><li>1탄: 아마존 퇴사와 빅테크 이직 준비 https://careerly.co.kr/comments/95006</li><li>2탄: 취업 준비 시 같이 준비해야 할 것들 https://careerly.co.kr/comments/95038</li><li>3탄: [현재글] 이직 준비하면서 배운 점</li><li>4탄: 알고리즘, 시스템 설계, 행동 면접 팁 https://careerly.co.kr/comments/95187</li><li>5탄: 최종 합격 후 꼭 해야 할 일 https://careerly.co.kr/comments/95312</li></ol> 🪴 함께 읽으면 좋은 글 개발자가 된 후 저지른 실수들https://careerly.co.kr/comments/94020 성장형 개발자가 피해야 할 실수https://careerly.co.kr/comments/91571

이직 준비를 통해 배운 점 9가지

좋은 글 잘 읽었습니다.
4번은 무척 흥미롭네요.
그리고 3번은 국내에 경우에는 역시 스프링, 대규모 트래픽 처리 경험자군요 ㅎㅎ

프레임워크를 바라보는 관점에 대해 개발자에게 좋은 관점이 되어줄 좋은 글이라고 생각합니다. 한번씩 읽어보세요! 🙂

---
https://velog.io/@woohm402/framework-is-detail

프레임워크는 어떤 장단점이 있으며 왜 소스코드의 바깥쪽 원에 위치해야만 하는 세부사항인지, 프레임워크라는 강력한 도구를 어떻게 대해야 하는지에 대한 개인적인 생각을 정리해 봤습니다 🙂

프레임워크를 바라보는 관점에 대해 개발자에게 좋은 관점이 되어줄 좋은 글이라고 생각합니다. 한번씩 읽어보세요! 🙂 ---https://velog.io/@woohm402/framework-is-detail 프레임워크는 어떤 장단점이 있으며 왜 소스코드의 바깥쪽 원에 위치해야만 하는 세부사항인지, 프레임워크라는 강력한 도구를 어떻게 대해야 하는지에 대한 개인적인 생각을 정리해 봤습니다 🙂

Get started with Flutter. Widgets, examples, updates, and API docs to help you write your first Flutter app.

Flutter documentation

플러터(Flutter)는 구글이 2017년에 출시한 크로스 플랫폼 개발 프레임워크입니다. 프레임워크를 통해 개발자들은 단일 코드베이스로 안드로이드, iOS, 윈도우, macOS, 그리고 웹 브라우저를 위한 애플리케이션을 개발할 수 있습니다.(magic)
다음은 플러터의 특징 입니다.

 1. Dart 언어의 사용: 플러터는 구글이 개발한 Dart 언어를 사용합니다. Dart는 자바스크립트 대용품으로 만든 언어라서 자바스크립트와 유사한 문법을 가지고 있어 손쉽게 접근이 가능합니다. 웹개발을 하려면 HTML, CSS, JS를 알아야 하고, ReactNative는 React를 알아야 하지만 플러터는 Dart만 알면 됩니다.
    
 2. 뛰어난 성능: 플러터는 소스코드를 직접 네이티브 CPU 기계 코드로 컴파일됩니다. JavaScript브릿지를 사용하는 리액트 네이티브보다 더 우수한 성능을 제공합니다.
    
 3. 모듈화된 위젯 시스템: 플러터는 고도로 모듈화된 위젯 시스템을 제공하여, 사용자 인터페이스를 쉽고 빠르게 구현할 수 있습니다.네이티브 요소에 의존적인 리액트 네이티브 보다 플랫폼 간 일관성을 유지하는 데 도움이 될 수 있으며, 개발 프로세스를 간소화하고 가속화 할 수 있습니다.

다만 플러터(Flutter)는 리액트 네이티브(React Native)의 핵심 기능 중 하나인 코드 푸시(code push) 기능을 기본적으로 제공하지 않는다는 점에서 차이가 있는데요. 코드 푸시란 애플리케이션의 일부를 사용자가 앱을 직접 업데이트하지 않고도 원격으로 업데이트할 수 있는 기능을 말합니다. 다만 아직 개발 초기 단계에 있으나, 'Shorebird'라는 도구를 통해 비슷한 기능을 구현할 수 있다고 합니다.

따라서, 프로젝트에서 코드 푸시 기능이 중요한 요소라면 리액트 네이티브가 더 적합할 수 있습니다. 하지만 사용자 친화적인 UI, 빠른 개발 사이클, 그리고 원활한 크로스 플랫폼 지원이 중점이라면 플러터가 더 매력적인 선택일 수도 있을것 같습니다.

https://docs.flutter.dev/

플러터(Flutter)는 구글이 2017년에 출시한 크로스 플랫폼 개발 프레임워크입니다. 프레임워크를 통해 개발자들은 단일 코드베이스로 안드로이드, iOS, 윈도우, macOS, 그리고 웹 브라우저를 위한 애플리케이션을 개발할 수 있습니다.<s>(magic)</s>다음은 플러터의 특징 입니다. <ol><li>Dart 언어의 사용: 플러터는 구글이 개발한 Dart 언어를 사용합니다. Dart는 자바스크립트 대용품으로 만든 언어라서 자바스크립트와 유사한 문법을 가지고 있어 손쉽게 접근이 가능합니다. 웹개발을 하려면 HTML, CSS, JS를 알아야 하고, ReactNative는 React를 알아야 하지만 플러터는 Dart만 알면 됩니다. </li><li>뛰어난 성능: 플러터는 소스코드를 직접 네이티브 CPU 기계 코드로 컴파일됩니다. JavaScript브릿지를 사용하는 리액트 네이티브보다 더 우수한 성능을 제공합니다. </li><li>모듈화된 위젯 시스템: 플러터는 고도로 모듈화된 위젯 시스템을 제공하여, 사용자 인터페이스를 쉽고 빠르게 구현할 수 있습니다.네이티브 요소에 의존적인 리액트 네이티브 보다 플랫폼 간 일관성을 유지하는 데 도움이 될 수 있으며, 개발 프로세스를 간소화하고 가속화 할 수 있습니다.</li></ol> 다만 플러터(Flutter)는 리액트 네이티브(React Native)의 핵심 기능 중 하나인 코드 푸시(code push) 기능을 기본적으로 제공하지 않는다는 점에서 차이가 있는데요. 코드 푸시란 애플리케이션의 일부를 사용자가 앱을 직접 업데이트하지 않고도 원격으로 업데이트할 수 있는 기능을 말합니다. 다만 아직 개발 초기 단계에 있으나, 'Shorebird'라는 도구를 통해 비슷한 기능을 구현할 수 있다고 합니다. 따라서, 프로젝트에서 코드 푸시 기능이 중요한 요소라면 리액트 네이티브가 더 적합할 수 있습니다. 하지만 사용자 친화적인 UI, 빠른 개발 사이클, 그리고 원활한 크로스 플랫폼 지원이 중점이라면 플러터가 더 매력적인 선택일 수도 있을것 같습니다. https://docs.flutter.dev/

Flutter

효과적인 앱 개발을 위한 플러터(Flutter)

1. 회사가 내가 아니다. 삼성전자에 다닌다고, 네카라쿠배 당토에 다닌다고 혹은 또다른 OO에 다닌다고 내가 그 회사가 아니다. 2. 일하는 회사가 핫하거나 빠르게 성장하고 있다면, 좋은 일이다. 그 Halo effect를 유리하게 활용하는 것도 좋다. 내 안목이 탁월했든 운이든 어쨋든 잘된 일이다. 나 자신이 성장하며 회사의 성장에 기여하는 것도 자부

회사가 내가 아니다

오래전부터 생각해오던 내용과 소름 끼치게 동일한 글을 발견해서 공유합니다. 주니어 시절(아마 2~3년차) 회사에 이름에 그늘 삼아 제 능력이 녹슬어 가는지도 모른 체 시간을 낭비하듯 보내던 적이 있었습니다. 그러다 "회사 딱지를 떼면 난 뭐가 남지?"라는 생각에 뒤통수를 맞은 느낌으로 외부 활동을 해왔던 것 같고 블로그, 토이 프로젝트, 스터디에 이어 지금까지 살아오는 것 같습니다. 물론, 회사가 안정적이고 성장 가능성이 뚜렷하다면 "나 OO에 다녀~"라는 생각으로 약간은 안일한 마음이 들 수도 있겠지만 부모님 시대와는 다르게 요즘은 평생직장이라는 수식어는 어울리지 않을 정도로 세상이 변화하고 있고 결국은 본인 스스로를 본인이 챙겨야 하는 시대인 건 확실해 보입니다.
"회사가 내가 아니다"라는 제목은 다소 자극적이기도 하고 오해가 될 수도 있을 만한 글이지만 이 글에서 이야기하고자 하는 내용에 저의 생각을 조금 더 가미하자면, 결국 스스로 홀로서기 할 수 있을 정도의 능력을 갖춘 본인이 돼야 하고 그게 회사에 다니는 직장인이라면 그러한 능력을 회사에서도 기여하는 순서가 맞지 않을까 생각이 됩니다. 특히, 개발자는 기술적 고립이 되지 않기 위해 부단히 노력해야 합니다. 회사 내에서는 잘하는 것처럼 생각이 될 수 있지만 다른 회사 분들과 마주하다 보면 우물속 개구리였구나 라는걸 몸소 체감할 수 있으니까요.

https://brunch.co.kr/@naieekim/79

오래전부터 생각해오던 내용과 소름 끼치게 동일한 글을 발견해서 공유합니다. 주니어 시절(아마 2~3년차) 회사에 이름에 그늘 삼아 제 능력이 녹슬어 가는지도 모른 체 시간을 낭비하듯 보내던 적이 있었습니다. 그러다 "회사 딱지를 떼면 난 뭐가 남지?"라는 생각에 뒤통수를 맞은 느낌으로 외부 활동을 해왔던 것 같고 블로그, 토이 프로젝트, 스터디에 이어 지금까지 살아오는 것 같습니다. 물론, 회사가 안정적이고 성장 가능성이 뚜렷하다면 "나 OO에 다녀~"라는 생각으로 약간은 안일한 마음이 들 수도 있겠지만 부모님 시대와는 다르게 요즘은 평생직장이라는 수식어는 어울리지 않을 정도로 세상이 변화하고 있고 결국은 본인 스스로를 본인이 챙겨야 하는 시대인 건 확실해 보입니다."회사가 내가 아니다"라는 제목은 다소 자극적이기도 하고 오해가 될 수도 있을 만한 글이지만 이 글에서 이야기하고자 하는 내용에 저의 생각을 조금 더 가미하자면, 결국 스스로 홀로서기 할 수 있을 정도의 능력을 갖춘 본인이 돼야 하고 그게 회사에 다니는 직장인이라면 그러한 능력을 회사에서도 기여하는 순서가 맞지 않을까 생각이 됩니다. 특히, 개발자는 기술적 고립이 되지 않기 위해 부단히 노력해야 합니다. 회사 내에서는 잘하는 것처럼 생각이 될 수 있지만 다른 회사 분들과 마주하다 보면 우물속 개구리였구나 라는걸 몸소 체감할 수 있으니까요. https://brunch.co.kr/@naieekim/79

Manage GraphqQL APIs Using the Postman GraphQL client (Sponsored) The Postman GraphQL client offers a simple yet powerful way to work with GraphQL APIs. With Postman's GraphQL client, you can: Explore GraphQL schemas easily Create code-ready queries

79 Engineering Blogs To Level Up Your System Design Skills

항상 좋은 글이 많이 올라오는 bytebytego에서 추천하는 테크 블로그 리스트가 올라왔네요!!
모두 영어 블로그이긴 하지만 이제 우리에겐 ChatGPT가 있으니!! ㅎㅎ

여러 블로그 중에 LINE 블로그가 있는것도 기분이 좋네요 :)))))

https://blog.bytebytego.com/p/79-engineering-blogs-to-level-up?ref=dailydev

항상 좋은 글이 많이 올라오는 bytebytego에서 추천하는 테크 블로그 리스트가 올라왔네요!! 모두 영어 블로그이긴 하지만 이제 우리에겐 ChatGPT가 있으니!! ㅎㅎ 여러 블로그 중에 LINE 블로그가 있는것도 기분이 좋네요 :))))) https://blog.bytebytego.com/p/79-engineering-blogs-to-level-up?ref=dailydev

Bytebytego

시스템 디자인 스킬을 배울 수 있는 테크 블로그 79

제목은 어그로를 좀 끌어보았습니다.

커리어리 Q&A에서 어설픈 답변을 종종 남기고 있습니다. 주제넘게 이렇다 저렇다 말하고 나면, 과연 이게 도움이 되는 말일까 자문하게 되기도 합니다.

어쨌건, 커리어 관련 고민을 토로하는 글들을 보면, 어떨 땐 답답하기도 하고, 어떨 땐 과거의 내가 감정이입되기도 해서 괜한 참견을 하게되는 것 같습니다.

공통적으로 느껴지는 것 중 하나는, 커리어 관련 고민이라는 게, 어쩌면 그보다 더 중요한 고민들에서 시작된 고통이라는 생각이 들더라구요.

우리가 개발자가 되고자 하거나, 아니면 이미 개발자이면서 더 나은 개발자가 되려고 여기를 기웃거리는 건데, 그만큼, 아니, 그보다 더 중요한 거는 몸건강과 정신건강이 아닐까 해요. 몸건강은 잘먹고 잘자고 운동하고 이런 게 기본일 테고, 정신 건강은 일기를 쓰든 상담을 받든 여행을 하든, 명상을 하든 종교에 심취하든 다양한 방법들이 있겠죠.

운동으로는 달리기를 시작해서 어느덧 2000K를 넘게 뛰었습니다. 건강을 위해 시작했던 달리기가 이제 좀 지나치다 싶을 정도로 많이 뛰고 있어요. 지난달은 210K, 이번 달은 240K정도 뛸 것 같습니다. 본격 러너라기에 실력은 부족해도 마일리지는 충분한 것 같습니다. 어쩌면 내년에는 풀코스 마라톤을 완주할 수 있을 것 같아요. 몸건강도 좋아졌고, 뛰다보면 정신적으로도 꽤 상쾌해집니다. 모종의 호르몬이 나오나봐요. 거의 매일 1시간씩을 달리기에 투자하는 게 미련한 짓인 것 같기도 한데, 결국 건강해지면 그 이상의 가치를 하겠죠. 아니 솔직히 말할게요. 이제 그냥 달리기가 즐거워졌어요. 이보다 많이 뛰면 오히려 건강에 해가 되는 게 아닐까 걱정을 해야할 판입니다. 딱히 꾸준히 운동하고 있는 게 아직 없으시다면, 달리기 추천드려봅니다.

멘탈을 위해서는 명상쪽에 점점 더 많은 관심이 가고 있는데, 점점 더 제가 뭘 잘못 생각하고 있는지... 아니 잘못된 부분에 집중하고 있는지를 알게되어가는 중인 것 같습니다. 아직 달리기 만큼 심취하지는 못했기에 뭐라 적기는 어렵습니다만, 우리의 많은 고통이 스스로부터 야기된 점이라는 게 인상적인 것 같습니다. 마치 외부의 환경, 그러니까, 개발자 취업문이 얼어붙었다거나, 난 좋게보는 기술을 쟤는 무시한다거나 하는 외부의 상황들이 나에게 고통을 주는 것 같지만, 그건 착각이라는 게 공통된 명상가(?)들의 시각으로 이해되더라구요.

암튼, 괜한 참견... 아니, 스스로에게 다시 다짐해보는 것은, 외부 상황들을 고통으로 바라보는 일을 그만두고, 현재 상황 그대로에서 잘해보자는 거랄까요?

기술적, 커리어 고민들은 사실 그 고민에서 출발해서 문제를 해결하려 들 게 아니라, 한차원 더 높은 시각에서 멘탈을 챙겨보자는 제안입니다. 저부터 잘해볼게요. 화이팅입니다.

<s>제목은 어그로를 좀 끌어보았습니다.</s> 커리어리 Q&amp;A에서 어설픈 답변을 종종 남기고 있습니다. 주제넘게 이렇다 저렇다 말하고 나면, 과연 이게 도움이 되는 말일까 자문하게 되기도 합니다. 어쨌건, 커리어 관련 고민을 토로하는 글들을 보면, 어떨 땐 답답하기도 하고, 어떨 땐 과거의 내가 감정이입되기도 해서 괜한 참견을 하게되는 것 같습니다. 공통적으로 느껴지는 것 중 하나는, 커리어 관련 고민이라는 게, 어쩌면 그보다 더 중요한 고민들에서 시작된 고통이라는 생각이 들더라구요. 우리가 개발자가 되고자 하거나, 아니면 이미 개발자이면서 더 나은 개발자가 되려고 여기를 기웃거리는 건데, 그만큼, 아니, 그보다 더 중요한 거는 몸건강과 정신건강이 아닐까 해요. 몸건강은 잘먹고 잘자고 운동하고 이런 게 기본일 테고, 정신 건강은 일기를 쓰든 상담을 받든 여행을 하든, 명상을 하든 종교에 심취하든 다양한 방법들이 있겠죠. 운동으로는 달리기를 시작해서 어느덧 2000K를 넘게 뛰었습니다. 건강을 위해 시작했던 달리기가 이제 좀 지나치다 싶을 정도로 많이 뛰고 있어요. 지난달은 210K, 이번 달은 240K정도 뛸 것 같습니다. 본격 러너라기에 실력은 부족해도 마일리지는 충분한 것 같습니다. 어쩌면 내년에는 풀코스 마라톤을 완주할 수 있을 것 같아요. 몸건강도 좋아졌고, 뛰다보면 정신적으로도 꽤 상쾌해집니다. 모종의 호르몬이 나오나봐요. 거의 매일 1시간씩을 달리기에 투자하는 게 미련한 짓인 것 같기도 한데, 결국 건강해지면 그 이상의 가치를 하겠죠. 아니 솔직히 말할게요. 이제 그냥 달리기가 즐거워졌어요. 이보다 많이 뛰면 오히려 건강에 해가 되는 게 아닐까 걱정을 해야할 판입니다. 딱히 꾸준히 운동하고 있는 게 아직 없으시다면, 달리기 추천드려봅니다. 멘탈을 위해서는 명상쪽에 점점 더 많은 관심이 가고 있는데, 점점 더 제가 뭘 잘못 생각하고 있는지... 아니 잘못된 부분에 집중하고 있는지를 알게되어가는 중인 것 같습니다. 아직 달리기 만큼 심취하지는 못했기에 뭐라 적기는 어렵습니다만, 우리의 많은 고통이 스스로부터 야기된 점이라는 게 인상적인 것 같습니다. 마치 외부의 환경, 그러니까, 개발자 취업문이 얼어붙었다거나, 난 좋게보는 기술을 쟤는 무시한다거나 하는 외부의 상황들이 나에게 고통을 주는 것 같지만, 그건 착각이라는 게 공통된 명상가(?)들의 시각으로 이해되더라구요. 암튼, 괜한 참견... 아니, 스스로에게 다시 다짐해보는 것은, 외부 상황들을 고통으로 바라보는 일을 그만두고, 현재 상황 그대로에서 잘해보자는 거랄까요? 기술적, 커리어 고민들은 사실 그 고민에서 출발해서 문제를 해결하려 들 게 아니라, 한차원 더 높은 시각에서 멘탈을 챙겨보자는 제안입니다. 저부터 잘해볼게요. 화이팅입니다.

니가 지금 자바를 공부하고 있을 때가 아니야

https://microsoft.github.io/AI-For-Beginners/

AI를 마스터하기 위한 Microsoft의 무료 강좌 6개 입니다!

초보자를 위한 AI 커리큘럼 https://t.co/ZJoF6sSeNc
 * 인공 지능(AI)을 탐구하는 12주, 24레슨 커리큘럼입니다. 심볼릭 AI, 신경망, 컴퓨터 비전, 자연어 처리 등을 다룹니다. 실습 수업, 퀴즈 및 실습이 포함되어 있습니다.

인공 지능 입문 https://t.co/pRgkJwigbQ
 * 이 과정은 인공지능의 핵심 개념을 이해하는 데 도움이 됩니다. 프로젝트 관리자, 제품 관리자, 디렉터, 임원 및 AI 분야에서 경력을 시작하는 학생을 위해 만든 것입니다.

생성형 AI란 무엇인가 https://t.co/kfWWPS5qMG
 * 제너레이티브 AI 전문가인 피나르 세이한 데미르닥이 생성형 AI의 기본 사항을 설명합니다.
   * 생성형 AI무엇인지
   * 어떻게 동작하는지
   * 모델별 차이
   * 미래 예측과 윤리적 시사점

생성형 AI: 사려깊은 온라인 검색의 진화 https://t.co/EgNl8WCCZ1
 * 생성형 AI 기반 추론 엔진의 핵심 개념과 검색 엔진 전략과의 차이점에 대해 자세히 알아봅니다.

Microsoft Bing Chat으로 업무 간소화하기 https://t.co/zGhxRKYLg9
 * Bing Chat을 효과적으로 사용하는 방법을 알려드립니다.

생성 AI 시대의 윤리 https://t.co/5KUXaQaK47
 * 생성 AI 도구 및 제품을 배포할 때 윤리적 문제를 해결하는 방법을 알아봅시다.

개인적으로는 초보자를 위한 AI 커리큘럼이 가장 마음에 드는군요!
무료 코스이므로 시간 되실때 재미있게 보시면 좋을 것 같습니다~!

AI를 마스터하기 위한 Microsoft의 무료 강좌 6개 입니다! 초보자를 위한 AI 커리큘럼 https://t.co/ZJoF6sSeNc<ul><li>인공 지능(AI)을 탐구하는 12주, 24레슨 커리큘럼입니다. 심볼릭 AI, 신경망, 컴퓨터 비전, 자연어 처리 등을 다룹니다. 실습 수업, 퀴즈 및 실습이 포함되어 있습니다.</li></ul> 인공 지능 입문 https://t.co/pRgkJwigbQ<ul><li>이 과정은 인공지능의 핵심 개념을 이해하는 데 도움이 됩니다. 프로젝트 관리자, 제품 관리자, 디렉터, 임원 및 AI 분야에서 경력을 시작하는 학생을 위해 만든 것입니다.</li></ul> 생성형 AI란 무엇인가 https://t.co/kfWWPS5qMG<ul><li>제너레이티브 AI 전문가인 피나르 세이한 데미르닥이 생성형 AI의 기본 사항을 설명합니다.<ul><li>생성형 AI무엇인지</li><li>어떻게 동작하는지</li><li>모델별 차이</li><li>미래 예측과 윤리적 시사점</li></ul></li></ul> 생성형 AI: 사려깊은 온라인 검색의 진화 https://t.co/EgNl8WCCZ1<ul><li>생성형 AI 기반 추론 엔진의 핵심 개념과 검색 엔진 전략과의 차이점에 대해 자세히 알아봅니다.</li></ul> Microsoft Bing Chat으로 업무 간소화하기 https://t.co/zGhxRKYLg9<ul><li>Bing Chat을 효과적으로 사용하는 방법을 알려드립니다.</li></ul> 생성 AI 시대의 윤리 https://t.co/5KUXaQaK47<ul><li>생성 AI 도구 및 제품을 배포할 때 윤리적 문제를 해결하는 방법을 알아봅시다.</li></ul> 개인적으로는 초보자를 위한 AI 커리큘럼이 가장 마음에 드는군요!무료 코스이므로 시간 되실때 재미있게 보시면 좋을 것 같습니다~!

t.co

마이크로소프트가 공개한 무료 AI 코스들

CSpell ESLint plugin. Latest version: 8.0.0, last published: 20 days ago. Start using @cspell/eslint-plugin in your project by running `npm i @cspell/eslint-plugin`. There are 8 other projects in the npm registry using @cspell/eslint-plugin.

@cspell/eslint-plugin

코드 작성 과정에서 스펠링 오타는 흔한 일입니다. 영어가 모국어가 아니기에 흔하게 일어날 수 밖에 없죠. 문제는 이런 작은 실수가 때로는 예상치 못한 큰 버그로 이어질 수 있습니다. 경험이 많은 개발자라면, 오타로 인해 발생한 문제를 해결하느라 많은 시간을 소비한 경험이 한 번쯤은 있을 것입니다.

@cspell/eslint-plugin은 ESLint를 기반으로 한 코드 스펠링 체크 플러그인으로, cspell 이란 'Code Spell Checker'의 약자 입니다. 이 플러그인 패키지를 설치하고 .eslintrc.json에 추가하면, 문자열, 주석, JSX 텍스트 등에 대한 스펠링 검사를 다양한 옵션을 통해 수행할 수 있습니다.

코드 리뷰 중에도 오타 수정을 제안하는 일은 흔히 있는데요. 이와 같은 라이브러리의 도움으로 코드의 정확성을 향상시키고 전반적인 생산성을 높일 수 있습니다. 개발자는 작은 실수에 시간을 낭비하는 대신 더 중요한 개발 업무에 집중할 수 있습니다.

https://www.npmjs.com/package/@cspell/eslint-plugin

코드 작성 과정에서 스펠링 오타는 흔한 일입니다. 영어가 모국어가 아니기에 흔하게 일어날 수 밖에 없죠. 문제는 이런 작은 실수가 때로는 예상치 못한 큰 버그로 이어질 수 있습니다. 경험이 많은 개발자라면, 오타로 인해 발생한 문제를 해결하느라 많은 시간을 소비한 경험이 한 번쯤은 있을 것입니다. @cspell/eslint-plugin은 ESLint를 기반으로 한 코드 스펠링 체크 플러그인으로, cspell 이란 'Code Spell Checker'의 약자 입니다. 이 플러그인 패키지를 설치하고 .eslintrc.json에 추가하면, 문자열, 주석, JSX 텍스트 등에 대한 스펠링 검사를 다양한 옵션을 통해 수행할 수 있습니다. 코드 리뷰 중에도 오타 수정을 제안하는 일은 흔히 있는데요. 이와 같은 라이브러리의 도움으로 코드의 정확성을 향상시키고 전반적인 생산성을 높일 수 있습니다. 개발자는 작은 실수에 시간을 낭비하는 대신 더 중요한 개발 업무에 집중할 수 있습니다. https://www.npmjs.com/package/@cspell/eslint-plugin

스펠링 검사: @cspell/eslint-plugin

Learn directly from Andrew Ng about the technology of generative AI, how it works, and what it can (and can't) do Get an overview of AI tools, and learn from real-world examples of generative AI in use today Understand the impacts of generative AI on busi

Generative AI for Everyone

1. 프롬프트엔지니어링의 기초
이 과정에서는 프롬프트 엔지니어링의 기본을 소개하고 고급 프롬프트 기술로 진행합니다.
✔ https://www.deeplearning.ai/courses/generative-ai-for-everyone/

2. 개발자를 위한 ChatGPT 프롬프트 엔지니어링
DeepLearning AI 및 OpenAI를 통한 ChatGPT 프롬프트 엔지니어링에 대한 무료 과정입니다.
✔https://www.deeplearning.ai/short-courses/chatgpt-prompt-engineering-for-developers/

3. Google의 생성형 AI 소개
Gen이 무엇인지, 어떻게 사용되는지, 기존 머신러닝 방법과 어떻게 다른지 설명하는 것을 목표로 합니다.
✔https://www.cloudskillsboost.google/course_templates/536

4. Harvard의 Python 기반 AI 소개
인공 지능에 대한 입문 과정에서 Python에서 기계 학습을 사용하는 방법을 알아보세요.
✔ https://pll.harvard.edu/course/cs50s-introduction-artificial-intelligence-python/2023-05

5. 마이크로소프트의 '생성 AI란 무엇인가?'
Gen AI의 정의, 작동 방식, 나만의 콘텐츠를 만드는 방법, 다양한 유형의 모델, 미래 예측, 윤리 등의 주제를 다루는 Gen AI의 기본 사항입니다.
✔ https://www.linkedin.com/learning/what-is-generative-ai/generative-ai-is-a-tool-in-service-of-humanity

6. 프럼프팅 배우기
60개 이상의 콘텐츠 모듈을 갖춘 종합적인 프롬프트 엔지니어링 과정입니다. 프롬프트 엔지니어링 기술의 초급부터 고급까지 안내합니다.
✔ https://learnprompting.org/docs/intro

7. Google의 책임 있는 AI 소개
Responsible AI가 무엇인지, 왜 중요한지, Google이 이를 자사 제품에 어떻게 구현하는지 알아보세요.
✔ https://www.cloudskillsboost.google/course_templates/554

8. 하버드의 데이터 과학: 기계 학습
훈련 데이터에 대해 알아보고 데이터 집합을 사용하여 잠재적인 예측 관계를 발견하는 방법을 알아봅니다. 또한 영화 추천 시스템 및 데이터 과학 기술을 구축하는 방법도 알아봅니다.
✔ https://pll.harvard.edu/course/data-science-machine-learning

9. LLM 애플리케이션 개발을 위한 LangChain
LangChain을 사용하여 애플리케이션 개발에서 언어 모델의 사용 사례와 기능을 확장하는 데 필수적인 기술을 습득하세요.
✔ https://www.deeplearning.ai/short-courses/langchain-for-llm-application-development/

10. Microsoft Bing Chat을 통한 작업 간소화
Bing Chat이 어떻게 다양한 작업을 수행하고 아이디어 생성 및 데이터 요약부터 일반적인 업무 문제 해결에 이르기까지 전체 작업 흐름을 간소화하는 데 도움이 되는지 알아보세요.
✔ https://www.linkedin.com/learning/streamlining-your-work-with-microsoft-bing-chat/put-your-fingers-to-work-chatting-as-a-productivity-tool

11. Hear Speak를 볼 수 있는 LLM 앱을 만드는 방법!
✔ https://www.singlestore.com/spaces/how-to-build-llm-apps-that-can-see-hear-speak/?utm_source=steve-nouri&utm_medium=influencer&utm_campaign=deck-the-halls-with-dev-and-data&utm_content=hear-see-speak&campaignid=701UJ0000012K2AYAU

12. 마이크로소프트의 AI 기초: 생성형 AI
부조종사와 같은 Gen AI 애플리케이션이 어떻게 효율성을 지원하는지 이해하세요. 프롬프트와 응답을 어떻게 미세 조정할 수 있는지 설명
✔ https://learn.microsoft.com/en-us/training/paths/introduction-generative-ai/

13. 의사결정자를 위한 Amazon의 Gen AI 학습 계획
✔ https://explore.skillbuilder.aws/learn/public/learning_plan/view/1909/generative-ai-learning-plan-for-decision-makers

14. 모두를 위한 생성형 AI
AI 도구에 대한 개요를 확인하고 현재 사용 중인 생성 AI의 실제 사례를 통해 알아보세요.
✔ https://www.deeplearning.ai/courses/generative-ai-for-everyone/

15. AWS의 LLM 포함한 Gen AI
Gen AI 작동 방식에 대한 기초 지식, 실무 기술 및 기능적 이해를 얻으세요.
✔ https://www.coursera.org/learn/generative-ai-with-llms

1. 프롬프트엔지니어링의 기초이 과정에서는 프롬프트 엔지니어링의 기본을 소개하고 고급 프롬프트 기술로 진행합니다.✔ https://www.deeplearning.ai/courses/generative-ai-for-everyone/ 2. 개발자를 위한 ChatGPT 프롬프트 엔지니어링DeepLearning AI 및 OpenAI를 통한 ChatGPT 프롬프트 엔지니어링에 대한 무료 과정입니다.✔https://www.deeplearning.ai/short-courses/chatgpt-prompt-engineering-for-developers/ 3. Google의 생성형 AI 소개Gen이 무엇인지, 어떻게 사용되는지, 기존 머신러닝 방법과 어떻게 다른지 설명하는 것을 목표로 합니다.✔https://www.cloudskillsboost.google/course_templates/536 4. Harvard의 Python 기반 AI 소개인공 지능에 대한 입문 과정에서 Python에서 기계 학습을 사용하는 방법을 알아보세요.✔ https://pll.harvard.edu/course/cs50s-introduction-artificial-intelligence-python/2023-05 5. 마이크로소프트의 '생성 AI란 무엇인가?'Gen AI의 정의, 작동 방식, 나만의 콘텐츠를 만드는 방법, 다양한 유형의 모델, 미래 예측, 윤리 등의 주제를 다루는 Gen AI의 기본 사항입니다.✔ https://www.linkedin.com/learning/what-is-generative-ai/generative-ai-is-a-tool-in-service-of-humanity 6. 프럼프팅 배우기60개 이상의 콘텐츠 모듈을 갖춘 종합적인 프롬프트 엔지니어링 과정입니다. 프롬프트 엔지니어링 기술의 초급부터 고급까지 안내합니다.✔ https://learnprompting.org/docs/intro 7. Google의 책임 있는 AI 소개Responsible AI가 무엇인지, 왜 중요한지, Google이 이를 자사 제품에 어떻게 구현하는지 알아보세요.✔ https://www.cloudskillsboost.google/course_templates/554 8. 하버드의 데이터 과학: 기계 학습훈련 데이터에 대해 알아보고 데이터 집합을 사용하여 잠재적인 예측 관계를 발견하는 방법을 알아봅니다. 또한 영화 추천 시스템 및 데이터 과학 기술을 구축하는 방법도 알아봅니다.✔ https://pll.harvard.edu/course/data-science-machine-learning 9. LLM 애플리케이션 개발을 위한 LangChainLangChain을 사용하여 애플리케이션 개발에서 언어 모델의 사용 사례와 기능을 확장하는 데 필수적인 기술을 습득하세요.✔ https://www.deeplearning.ai/short-courses/langchain-for-llm-application-development/ 10. Microsoft Bing Chat을 통한 작업 간소화Bing Chat이 어떻게 다양한 작업을 수행하고 아이디어 생성 및 데이터 요약부터 일반적인 업무 문제 해결에 이르기까지 전체 작업 흐름을 간소화하는 데 도움이 되는지 알아보세요.✔ https://www.linkedin.com/learning/streamlining-your-work-with-microsoft-bing-chat/put-your-fingers-to-work-chatting-as-a-productivity-tool 11. Hear Speak를 볼 수 있는 LLM 앱을 만드는 방법!✔ https://www.singlestore.com/spaces/how-to-build-llm-apps-that-can-see-hear-speak/?utm_source=steve-nouri&amp;utm_medium=influencer&amp;utm_campaign=deck-the-halls-with-dev-and-data&amp;utm_content=hear-see-speak&amp;campaignid=701UJ0000012K2AYAU 12. 마이크로소프트의 AI 기초: 생성형 AI부조종사와 같은 Gen AI 애플리케이션이 어떻게 효율성을 지원하는지 이해하세요. 프롬프트와 응답을 어떻게 미세 조정할 수 있는지 설명✔ https://learn.microsoft.com/en-us/training/paths/introduction-generative-ai/ 13. 의사결정자를 위한 Amazon의 Gen AI 학습 계획✔ https://explore.skillbuilder.aws/learn/public/learning_plan/view/1909/generative-ai-learning-plan-for-decision-makers 14. 모두를 위한 생성형 AIAI 도구에 대한 개요를 확인하고 현재 사용 중인 생성 AI의 실제 사례를 통해 알아보세요.✔ https://www.deeplearning.ai/courses/generative-ai-for-everyone/ 15. AWS의 LLM 포함한 Gen AIGen AI 작동 방식에 대한 기초 지식, 실무 기술 및 기능적 이해를 얻으세요.✔ https://www.coursera.org/learn/generative-ai-with-llms

Deeplearning

AI를 배우기 위해 추천하고 싶은 상위 15개 무료 강좌

12 Lessons, Get Started Building with Generative AI  🔗 https://microsoft.github.io/generative-ai-for-beginners/ - GitHub - microsoft/generative-ai-for-beginners: 12 Lessons, Get Started Building with Generative AI  🔗 https://microsoft.github.io/generati

GitHub - microsoft/generative-ai-for-beginners: 12 Lessons, Get Started Building with Generative AI  🔗 https://microsoft.github.io/generative-ai-for-beginners/

커리어리 친구들, Microsoft 가 Generative AI for Beginners 강의를 공개했습니다. 생성형 AI 애플리케이션 구축을 시작하는 데 필요한 모든 것을 알려주는 12강 과정이오니 관심 있는 분들은 아래의 깃허브에 들어가시기를 바랍니다. 

🕹️ 강의 목차   

- 생성형 AI 및 LLM 소개  
- 다양한 LLM 탐색 및 비교  
- 책임감 있는 생성형 AI 사용  
- 프롬프트 엔지니어링 기본 이해  
- 고급 프롬프트 작성하기  
- 텍스트 생성 응용 프로그램 구축  
- 채팅 응용 프로그램 구축  
- 검색 앱 벡터 데이터베이스 구축  
- 이미지 생성 응용 프로그램 구축  
- 로우 코드 AI 응용 프로그램 구축  
- 함수 호출을 통한 외부 응용 프로그램 통합  
- AI 응용 프로그램을 위한 UX 디자인

https://aka.ms/genai-beginners

커리어리 친구들, Microsoft 가 Generative AI for Beginners 강의를 공개했습니다.&nbsp;생성형 AI 애플리케이션 구축을 시작하는 데 필요한 모든 것을 알려주는 12강 과정이오니 관심 있는 분들은 아래의 깃허브에 들어가시기를 바랍니다.&nbsp; 🕹️ 강의 목차 &nbsp;&nbsp; - 생성형 AI 및 LLM 소개 &nbsp;- 다양한 LLM 탐색 및 비교 &nbsp;- 책임감 있는 생성형 AI 사용 &nbsp;- 프롬프트 엔지니어링 기본 이해 &nbsp;- 고급 프롬프트 작성하기 &nbsp;- 텍스트 생성 응용 프로그램 구축 &nbsp;- 채팅 응용 프로그램 구축 &nbsp;- 검색 앱 벡터 데이터베이스 구축 &nbsp;- 이미지 생성 응용 프로그램 구축 &nbsp;- 로우 코드 AI 응용 프로그램 구축 &nbsp;- 함수 호출을 통한 외부 응용 프로그램 통합 &nbsp;- AI 응용 프로그램을 위한 UX 디자인 https://aka.ms/genai-beginners

GitHub

<MS, Generative AI for Beginners 강의>

01 . 며칠 전 유튜브 채널 ⟪피식대학⟫에 박진영 님이 출연한 영상을 보게 되었습니다. 그냥 무심코 틀어놓고 멍 때리며 보고 있는 와중에 영상이 끝날 무렵 정신이 번쩍 드는 이야기가 흘러나왔습니다. 그건 협업을 숙명으로 하는 모든 사람에게 고하는 일종의 애티튜드 바이블과도 같았죠. 그래서 영상을 몇 번이나 돌려보며 그의 말들을 메모하기 시작했습니다. (영어로 발언한 관계로 일부는 자막 인용 대신 의역하여 전해드립니다.)

02 . "회사를 이끌면서 느낀 한 가지 사실은 제가 우울해하거나 슬퍼하거나 혹은 기분이 다운되어 보일 때면 저와 관련한 모든 사람들이 이를 불편하게 느낀다는 것이었습니다. 그래서 걱정이 있더라도 저는 농담을 하고 때론 우스꽝스럽게 보이기까지 해야 하죠. 그건 모두가 다 편한 마음으로 일하기 위해서입니다.
이건 저 뿐만 아니라 저희 아티스트들에게도 강조하는 포인트입니다. 스트레이 키즈나 트와이스 같은 어린 친구들 역시 늘 좋은 날만 있을 수는 없죠. 하지만 저는 '네가 우울해 보이고 슬퍼 보이고 다운되어 보이면 그건 모두를 불편하게 만드는 거라는 걸 기억해. 이건 우리의 숙명이기도 해. 아무리 힘들 날이 있어도 우린 농담을 할 수 있어야 하고 주위 사람들이 편하게 일하고 있는지 체크해야 해.'라고 말합니다."

03 . 발언 자체만 두고는 호불호가 갈릴 수도 있을 겁니다. 한편에서는 '어떻게 내 마음이 문드러지는 와중에 내색은커녕 억지로 웃고 농담까지 던질 수 있는 걸까. 그렇게 다른 사람 편하게 맞춰주다 정작 나부터 무너질지 모르는데...'하는 생각이 드는 것도 사실이죠.
하지만 이 발언의 취지는 조금 다른 각도에서 살펴볼 필요가 있습니다. 바로 '협업을 위한 적정 온도'라는 측면에서 말이죠.

04 . 회사와 같은 공식적인 조직이든 아니면 여럿이 함께 모이는 커뮤니티 같은 모임이든 늘 자신의 감정을 있는 그대로 드러내고자 하는 사람들이 존재합니다. 그런 사람들은 자신의 상태를 솔직하게 공유하고 도움을 요청하는 게 아니라 내가 좋으면 같이 웃고, 내가 싫으면 같이 비판하고, 내가 화나면 내 편을 들어주고, 내가 짜증 나면 나를 달래줄 사람을 바라는 케이스가 다반사죠. 다 같이 생활하는 공간임에도 본인 추울 때는 보일러를 틀고 다시 더워지면 냉큼 창문을 열어야 직성이 풀리는 유형인 셈입니다.

05 . 저도 11년 넘게 일을 하며 적지 않은 유형의 인간 군상들을(?) 만나봤습니다. 하지만 저렇게 본인의 감정 온도에 타인을 맞추게 하려는 사람치고 좋은 협업 태도를 갖춘 사람은 단 한 명도 보지 못한 것 같아요. 오히려 빠르게 해결할 수 있는 문제도 더 깊은 진흙탕으로 밀어 넣고 함께 으쌰으쌰하는 순간에도 곳곳에 소금을 뿌려대기 바빴으니 말이죠.

06 . 더 무서운 건 본인은 그런 자신의 태도를 아주 솔직하고 뒤끝 없는 스타일로 규정하고 있더라는 사실입니다. (당연히 뒤끝은 없겠죠... 앞에서 그렇게 다 보여주는데... 🥲) 물론 회사 같은 조직 생활 안에서 갈등을 회피하는 것 역시 큰 문제이긴 마찬가지입니다. 좋은 게 좋다는 태도도, 나는 큰 문제에 휘말리기 싫다는 태도도 환영받지 못하는 건 똑같으니까요.
하지만 그럼에도 자신이 스스럼없이 감정을 드러내는 것은 솔직한 피드백이고 타인이 본인에게 반하는 주장을 하거나 하물며 본인의 기분을 맞춰주지 못하는 것은 불편한 피드백이라 치부하는 것은 협업하는 관계의 기본조차 모르는 행위일지 모릅니다. 그런 사람과 함께 일하고 싶은 동료는 단 한 명도 없을 테니 말이죠.

07 . 그래서 저는 박진영 님의 말이 더 크게 와닿았습니다. 조금 기분이 언짢거나 그날 하루가 유난히 버겁더라도 일단 모두를 위해 적당한 배려 정도는 발휘할 필요가 있다는 게 요지니 말이죠. 특히 본인이 조직을 이끄는 위치에 있는 사람이라면 이는 더더욱 조심해야 할 필요가 있습니다. 동등한 위치에서도 타인이 발산하는 불편한 감정은 고스란히 전해지기 마련인데 지위고하의 차이가 커질수록 리더 한 명이 내뿜는 부정의 기운은 조직 전체를 집어삼키기 때문이죠.

08 . 멀리 갈 것도 없이 제 과거의 기억에 비춰봐도 금방 알 수 있었습니다. 적어도 조직원들을 위해 최소한의 감정 컨트롤이 가능한 리더에게는 오히려 저희가 먼저 다가가 문제 해결을 돕고 위로의 말이라도 전하고 싶었던 것 같거든요. 반대로 자신의 감정 표현이 우선인 리더 앞에서는 그저 서로 '제발 오늘 하루 무사히 지나가라... 적어도 나한테는 불똥이 튀지 않았으면...'이라는 마음만 가득했던 것 같습니다. 일의 본질보다는 그 사람의 기분을 살피는 게 조직원들의 주요 관심사였고 말이죠.

09 . 어쩌면 우리가 협업을 위한 온도를 신경 써야 하는 이유도 여기에 있는 것은 아닐까 싶어요. 춥다고 당장 보일러 앞으로 달려갈 게 아니라 우선 외투 한 겹 껴입고 양말에 슬리퍼부터 챙기다 보면 그것만으로도 전체의 온도를 방해하는 일은 줄어드니 말이죠. 그래서 저 역시도 예전엔 '표정을 못 숨긴다', '감정 표현에 솔직하다' 이런 말을 들으면 나 자신이 투명한 사람인 것마냥 칭찬해 주는 것 같아 나쁘지 않은 반응을 보였지만 지금은 뜨끔한 마음이 앞섭니다. 저의 성급함으로 이 협업의 장을 교란시켜 놓은 것은 아닐지 걱정이 되니까요.

10 . 자신의 의사를 당당히 표현하라는 게 누군가를 매너 없이 쏘아붙이라는 말은 아닐 겁니다. 남 의식하지 말고 본인을 소중히 생각하라는 말 역시 배려의 기본을 팽개치고 네 멋대로 살라고 가르치는 게 결코 아닐 거고요. 그러니 저는 '나의 편함'과 '상대의 불편함', '나의 불편함과 상대의 편함' 사이의 온도를 어느 정도 감지하고 있어야 비로소 협업이라는 게 가능해진다고 생각합니다. 변온 동물이 생존에 유리한 이유도 단순히 외부 환경에 본인을 맞추는 데 있는 것이 아니라 주변의 온도를 감지하고 나는 어떤 수준을 유지해야 하나 하는 그 영특한 태도에서 기인하는 것일 테니 말이죠.

01 . 며칠 전 유튜브 채널 ⟪피식대학⟫에 박진영 님이 출연한 영상을 보게 되었습니다. 그냥 무심코 틀어놓고 멍 때리며 보고 있는 와중에 영상이 끝날 무렵 정신이 번쩍 드는 이야기가 흘러나왔습니다. 그건 협업을 숙명으로 하는 모든 사람에게 고하는 일종의 애티튜드 바이블과도 같았죠. 그래서 영상을 몇 번이나 돌려보며 그의 말들을 메모하기 시작했습니다. (영어로 발언한 관계로 일부는 자막 인용 대신 의역하여 전해드립니다.) 02 . "회사를 이끌면서 느낀 한 가지 사실은 제가 우울해하거나 슬퍼하거나 혹은 기분이 다운되어 보일 때면 저와 관련한 모든 사람들이 이를 불편하게 느낀다는 것이었습니다. 그래서 걱정이 있더라도 저는 농담을 하고 때론 우스꽝스럽게 보이기까지 해야 하죠. 그건 모두가 다 편한 마음으로 일하기 위해서입니다. 이건 저 뿐만 아니라 저희 아티스트들에게도 강조하는 포인트입니다. 스트레이 키즈나 트와이스 같은 어린 친구들 역시 늘 좋은 날만 있을 수는 없죠. 하지만 저는 '네가 우울해 보이고 슬퍼 보이고 다운되어 보이면 그건 모두를 불편하게 만드는 거라는 걸 기억해. 이건 우리의 숙명이기도 해. 아무리 힘들 날이 있어도 우린 농담을 할 수 있어야 하고 주위 사람들이 편하게 일하고 있는지 체크해야 해.'라고 말합니다." 03 . 발언 자체만 두고는 호불호가 갈릴 수도 있을 겁니다. 한편에서는 '어떻게 내 마음이 문드러지는 와중에 내색은커녕 억지로 웃고 농담까지 던질 수 있는 걸까. 그렇게 다른 사람 편하게 맞춰주다 정작 나부터 무너질지 모르는데...'하는 생각이 드는 것도 사실이죠. 하지만 이 발언의 취지는 조금 다른 각도에서 살펴볼 필요가 있습니다. 바로 '협업을 위한 적정 온도'라는 측면에서 말이죠. 04 . 회사와 같은 공식적인 조직이든 아니면 여럿이 함께 모이는 커뮤니티 같은 모임이든 늘 자신의 감정을 있는 그대로 드러내고자 하는 사람들이 존재합니다. 그런 사람들은 자신의 상태를 솔직하게 공유하고 도움을 요청하는 게 아니라 내가 좋으면 같이 웃고, 내가 싫으면 같이 비판하고, 내가 화나면 내 편을 들어주고, 내가 짜증 나면 나를 달래줄 사람을 바라는 케이스가 다반사죠. 다 같이 생활하는 공간임에도 본인 추울 때는 보일러를 틀고 다시 더워지면 냉큼 창문을 열어야 직성이 풀리는 유형인 셈입니다. 05 . 저도 11년 넘게 일을 하며 적지 않은 유형의 인간 군상들을(?) 만나봤습니다. 하지만 저렇게 본인의 감정 온도에 타인을 맞추게 하려는 사람치고 좋은 협업 태도를 갖춘 사람은 단 한 명도 보지 못한 것 같아요. 오히려 빠르게 해결할 수 있는 문제도 더 깊은 진흙탕으로 밀어 넣고 함께 으쌰으쌰하는 순간에도 곳곳에 소금을 뿌려대기 바빴으니 말이죠. 06 . 더 무서운 건 본인은 그런 자신의 태도를 아주 솔직하고 뒤끝 없는 스타일로 규정하고 있더라는 사실입니다. (당연히 뒤끝은 없겠죠... 앞에서 그렇게 다 보여주는데... 🥲) 물론 회사 같은 조직 생활 안에서 갈등을 회피하는 것 역시 큰 문제이긴 마찬가지입니다. 좋은 게 좋다는 태도도, 나는 큰 문제에 휘말리기 싫다는 태도도 환영받지 못하는 건 똑같으니까요. 하지만 그럼에도 자신이 스스럼없이 감정을 드러내는 것은 솔직한 피드백이고 타인이 본인에게 반하는 주장을 하거나 하물며 본인의 기분을 맞춰주지 못하는 것은 불편한 피드백이라 치부하는 것은 협업하는 관계의 기본조차 모르는 행위일지 모릅니다. 그런 사람과 함께 일하고 싶은 동료는 단 한 명도 없을 테니 말이죠. 07 . 그래서 저는 박진영 님의 말이 더 크게 와닿았습니다. 조금 기분이 언짢거나 그날 하루가 유난히 버겁더라도 일단 모두를 위해 적당한 배려 정도는 발휘할 필요가 있다는 게 요지니 말이죠. 특히 본인이 조직을 이끄는 위치에 있는 사람이라면 이는 더더욱 조심해야 할 필요가 있습니다. 동등한 위치에서도 타인이 발산하는 불편한 감정은 고스란히 전해지기 마련인데 지위고하의 차이가 커질수록 리더 한 명이 내뿜는 부정의 기운은 조직 전체를 집어삼키기 때문이죠. 08 . 멀리 갈 것도 없이 제 과거의 기억에 비춰봐도 금방 알 수 있었습니다. 적어도 조직원들을 위해 최소한의 감정 컨트롤이 가능한 리더에게는 오히려 저희가 먼저 다가가 문제 해결을 돕고 위로의 말이라도 전하고 싶었던 것 같거든요. 반대로 자신의 감정 표현이 우선인 리더 앞에서는 그저 서로 '제발 오늘 하루 무사히 지나가라... 적어도 나한테는 불똥이 튀지 않았으면...'이라는 마음만 가득했던 것 같습니다. 일의 본질보다는 그 사람의 기분을 살피는 게 조직원들의 주요 관심사였고 말이죠. 09 . 어쩌면 우리가 협업을 위한 온도를 신경 써야 하는 이유도 여기에 있는 것은 아닐까 싶어요. 춥다고 당장 보일러 앞으로 달려갈 게 아니라 우선 외투 한 겹 껴입고 양말에 슬리퍼부터 챙기다 보면 그것만으로도 전체의 온도를 방해하는 일은 줄어드니 말이죠. 그래서 저 역시도 예전엔 '표정을 못 숨긴다', '감정 표현에 솔직하다' 이런 말을 들으면 나 자신이 투명한 사람인 것마냥 칭찬해 주는 것 같아 나쁘지 않은 반응을 보였지만 지금은 뜨끔한 마음이 앞섭니다. 저의 성급함으로 이 협업의 장을 교란시켜 놓은 것은 아닐지 걱정이 되니까요. 10 . 자신의 의사를 당당히 표현하라는 게 누군가를 매너 없이 쏘아붙이라는 말은 아닐 겁니다. 남 의식하지 말고 본인을 소중히 생각하라는 말 역시 배려의 기본을 팽개치고 네 멋대로 살라고 가르치는 게 결코 아닐 거고요. 그러니 저는 '나의 편함'과 '상대의 불편함', '나의 불편함과 상대의 편함' 사이의 온도를 어느 정도 감지하고 있어야 비로소 협업이라는 게 가능해진다고 생각합니다. 변온 동물이 생존에 유리한 이유도 단순히 외부 환경에 본인을 맞추는 데 있는 것이 아니라 주변의 온도를 감지하고 나는 어떤 수준을 유지해야 하나 하는 그 영특한 태도에서 기인하는 것일 테니 말이죠.

협업을 위한 적정 온도 유지하기

저는 노션으로 개입 업무와 팀 업무를 관리하고 있습니다. 많은 분들이 업무 관리 노트앱으로 노션과 옵시디언을 최고로 꼽으시는 것 같은데요. 개인적으로 노션은 데이터베이스를 만들어 동기화 된 데이터를 기반으로 다양한 페이지로 시스템을 확장하거나 팀원들과 공유할 수 있어 개인과 팀 업무 관리에 최적화되어 있다고 생각합니다.

구글이나 유튜브에 검색을 해보면 팀 관리나 팀장을 위한 노션 템플릿이 많지만 막상 쓰게 되는 것은 없더라고요. 그 이유를 생각해보면;

1. 팀 미팅, 원온원과 관련된 템플릿은 없었어요.
2. 데이터의 연결성을 제대로 활용하는 템플릿은 드물었습니다.
3. 깔끔하고 미니멀한 디자인의 템플릿이 잘 없더라고요.

그래서 저는 제가 직접 템플릿과 시스템을 만들어서 사용하는 편이에요. 최근에는 팀원이 적어져서 잘 쓰지 않지만 팀원이 많을 때는 팀장의 시간을 아껴주고 팀원들과 효과적인 소통을 위해 반드시 필요했습니다. 최근 모임에서 제가 노션으로 개인 업무 관리, 팀 미팅 관리, 원온원 면담 관리 등을 한다고 하니 신기해 하시는 분들이 많더라고요. 그래서 사용하는 노션 시스템을 샘플로 만들어 공유합니다.

👉 Team 샘플 페이지 : https://hyeunjik.notion.site/hyeunjik/Team-5bbf5eb3012841a99854315c3aa5e68e
👉 Flow 샘플 페이지 : https://hyeunjik.notion.site/hyeunjik/Flow-1679cc0cddf34a03bcab2ca6ae7ba25c

저는 'Team'과 'Flow'라는 페이지에 필요한 데이터베이스를 구축하고 연동하여 업무를 관리하는데요. Team 페이지는 팀원들이 모두 초대되어 함께 관리하는 팀 업무 관리 페이지를, Flow는 나만 볼 수 있는 개인 업무 공간을 말합니다.

Team 페이지는 노트, 태스크, 프로젝트, 오브젝티브라는 데이터베이스를 중심으로 팀 전체의 업무의 현황과 우선순위를 한눈에 파악하고, 건설적인 팀 미팅을 운영하는 것에 초점을 맞추고 있습니다. Team 페이지를 보고 팀 미팅에 참석한 팀원이 '이번 주에 해야 할 일이 명확하다'라고 생각하는 것을 목표로요.

Flow 페이지는 Team 페이지에 구축된 데이터베이스를 기반으로 팀장인 '내'가 해야 하는 중요한 업무를 관리하고, 추가적인 Private 데이터베이스를 통해 팀원들과 효과적인 원온원을 하는 것에 초점을 맞추고 있습니다. 원온원 미팅을 가진 팀원이 '나는 좋은 성과를 내기 위해 필요한 충분한 지원을 받고 있고, 팀장이 나의 성장을 관찰하고 있다'는 느낌이 드는 것을 목표로요.

저의 방식이 정답은 아니겠지만 좋은 팀과 개인 업무 관리 솔루션을 찾는 분들께 도움이 되기를 바랍니다.

📌 유튜브에 'notion workspace template', 'notion template for work' 등으로 검색하면 전 세계의 다양한 레퍼런스가 나오니 참고해 주세요 :)

저는 노션으로 개입 업무와 팀 업무를 관리하고 있습니다. 많은 분들이 업무 관리 노트앱으로 노션과 옵시디언을 최고로 꼽으시는 것 같은데요. 개인적으로 노션은 데이터베이스를 만들어 동기화 된 데이터를 기반으로 다양한 페이지로 시스템을 확장하거나 팀원들과 공유할 수 있어 개인과 팀 업무 관리에 최적화되어 있다고 생각합니다. 구글이나 유튜브에 검색을 해보면 팀 관리나 팀장을 위한 노션 템플릿이 많지만 막상 쓰게 되는 것은 없더라고요. 그 이유를 생각해보면; 1. 팀 미팅, 원온원과 관련된 템플릿은 없었어요. 2. 데이터의 연결성을 제대로 활용하는 템플릿은 드물었습니다. 3. 깔끔하고 미니멀한 디자인의 템플릿이 잘 없더라고요. 그래서 저는 제가 직접 템플릿과 시스템을 만들어서 사용하는 편이에요. 최근에는 팀원이 적어져서 잘 쓰지 않지만 팀원이 많을 때는 팀장의 시간을 아껴주고 팀원들과 효과적인 소통을 위해 반드시 필요했습니다. 최근 모임에서 제가 노션으로 개인 업무 관리, 팀 미팅 관리, 원온원 면담 관리 등을 한다고 하니 신기해 하시는 분들이 많더라고요. 그래서 사용하는 노션 시스템을 샘플로 만들어 공유합니다. 👉 Team 샘플 페이지 : https://hyeunjik.notion.site/hyeunjik/Team-5bbf5eb3012841a99854315c3aa5e68e 👉 Flow 샘플 페이지 : https://hyeunjik.notion.site/hyeunjik/Flow-1679cc0cddf34a03bcab2ca6ae7ba25c 저는 'Team'과 'Flow'라는 페이지에 필요한 데이터베이스를 구축하고 연동하여 업무를 관리하는데요. Team 페이지는 팀원들이 모두 초대되어 함께 관리하는 팀 업무 관리 페이지를, Flow는 나만 볼 수 있는 개인 업무 공간을 말합니다. Team 페이지는 노트, 태스크, 프로젝트, 오브젝티브라는 데이터베이스를 중심으로 팀 전체의 업무의 현황과 우선순위를 한눈에 파악하고, 건설적인 팀 미팅을 운영하는 것에 초점을 맞추고 있습니다. Team 페이지를 보고 팀 미팅에 참석한 팀원이 '이번 주에 해야 할 일이 명확하다'라고 생각하는 것을 목표로요. Flow 페이지는 Team 페이지에 구축된 데이터베이스를 기반으로 팀장인 '내'가 해야 하는 중요한 업무를 관리하고, 추가적인 Private 데이터베이스를 통해 팀원들과 효과적인 원온원을 하는 것에 초점을 맞추고 있습니다. 원온원 미팅을 가진 팀원이 '나는 좋은 성과를 내기 위해 필요한 충분한 지원을 받고 있고, 팀장이 나의 성장을 관찰하고 있다'는 느낌이 드는 것을 목표로요. 저의 방식이 정답은 아니겠지만 좋은 팀과 개인 업무 관리 솔루션을 찾는 분들께 도움이 되기를 바랍니다. 📌 유튜브에 'notion workspace template', 'notion template for work' 등으로 검색하면 전 세계의 다양한 레퍼런스가 나오니 참고해 주세요 :)

🎮 메모 덕후가 만든 업무 관리 노션

복지가 좋은 회사가 부러웠습니다.
이런저런 혜택이 많은 회사.
우와 좋다. 나도 저런 회사 다녀보고 싶어.

이런 저에게 누군가 말해줬습니다.
회사의 복지는 직원들이 일을 더 잘하게 도와야 하는 거라고.
복지로 인해서 일을 더 많이, 더 편하게, 더 잘할 수 있어야 한다고.
일하는데 거추장스러운 장애물을 치워준다거나..
더 능력을 발휘할 수 있도록 지원해 주는 것.

생각해 보면 참말이었습니다.
나는 너무 마케팅에 잘 속아 넘어간단 말이야.
복지 마케팅.
우리 회사는 통합 포인트도 주고 통신요금도 할인해 주고.. 헬스장도 보내줘요.
이런 회사들의 채용 공고를 보며 부러워하곤 했습니다.
사실 그런 건 그냥 돈 많이 주면 되는 건데.

가만히 생각해 보면 예전에 이해진 의장님도 비슷한 말을 했습니다.

“여러분의 선배들이 하도 늦게까지 야근하고 힘들게 일해서 출퇴근 때만이라도 편하게 쉬라고 셔틀버스 만든 거예요.”
“너무 피곤하면 눈도 좀 붙이라고 수면실도 만들었고요.”

그런데 이제는 늦게까지 술 먹고 온 사람들이 거기 들어가서 잠을 잔다고.
이때 울분을 토해내신 이후로(2012년 초) 셔틀버스와 이런저런 복지들이 실제로 사라졌습니다.(웃음)

아하.. 이해진 의장님도 직원들이 일을 더 잘할 수 있게 하기 위해서 저런 복지들을 만든 거구나.

저에게 가장 좋은 복지는 구내식당이었습니다.
네이버 다닐 때.
뭐 먹을지 전혀 걱정 없이 살았던 시절.
같이 야근할 동료가 있든 없든 밥 걱정 따위는 안 할 수 있는 회사.
근데 심지어 맛있기까지 해.
지금 생각해도 너무 좋다.

이제는 아이가 있으니 어린이집도 좋은 복지일 것 같습니다.
아이 걱정을 하지 않아야 일을 집중해서 할 수 있을 테니까.

어떤 직원들이 있느냐에 따라 지원해 줘야 할 복지도 달라지기 때문에..
다른 회사의 복지를 무작정 베껴오는 건 돈을 낭비하는 일입니다.

요즘엔 재택근무를 복지로 내세우는 회사들이 있습니다.
직원들이 재택근무로 인해서 일을 더 잘할 수 있겠다 판단이 들면 올바른 지원이겠지만..
성과가 덜 나더라도 누군가를 뽑거나 나가지 않게 하기 위한 목적으로..
직원들이 해달라고 조르니깐 하는 수없이 재택근무를 복지로 내세우는 것은 좀 이상합니다.

단순히 복지포인트 주고, 통신 요금 감면해 주고, 비혼 선언 축하금 주고 하는 회사들보다는..
회사와 직원들의 성장을 진지하게 고민하는 회사에 더 눈이 갑니다.

복지가 좋은 회사가 부러웠습니다. 이런저런 혜택이 많은 회사. 우와 좋다. 나도 저런 회사 다녀보고 싶어. 이런 저에게 누군가 말해줬습니다. 회사의 복지는 직원들이 일을 더 잘하게 도와야 하는 거라고. 복지로 인해서 일을 더 많이, 더 편하게, 더 잘할 수 있어야 한다고. 일하는데 거추장스러운 장애물을 치워준다거나.. 더 능력을 발휘할 수 있도록 지원해 주는 것. 생각해 보면 참말이었습니다. 나는 너무 마케팅에 잘 속아 넘어간단 말이야. 복지 마케팅. 우리 회사는 통합 포인트도 주고 통신요금도 할인해 주고.. 헬스장도 보내줘요. 이런 회사들의 채용 공고를 보며 부러워하곤 했습니다. 사실 그런 건 그냥 돈 많이 주면 되는 건데. 가만히 생각해 보면 예전에 이해진 의장님도 비슷한 말을 했습니다. “여러분의 선배들이 하도 늦게까지 야근하고 힘들게 일해서 출퇴근 때만이라도 편하게 쉬라고 셔틀버스 만든 거예요.” “너무 피곤하면 눈도 좀 붙이라고 수면실도 만들었고요.” 그런데 이제는 늦게까지 술 먹고 온 사람들이 거기 들어가서 잠을 잔다고. 이때 울분을 토해내신 이후로(2012년 초) 셔틀버스와 이런저런 복지들이 실제로 사라졌습니다.(웃음) 아하.. 이해진 의장님도 직원들이 일을 더 잘할 수 있게 하기 위해서 저런 복지들을 만든 거구나. 저에게 가장 좋은 복지는 구내식당이었습니다. 네이버 다닐 때. 뭐 먹을지 전혀 걱정 없이 살았던 시절. 같이 야근할 동료가 있든 없든 밥 걱정 따위는 안 할 수 있는 회사. 근데 심지어 맛있기까지 해. 지금 생각해도 너무 좋다. 이제는 아이가 있으니 어린이집도 좋은 복지일 것 같습니다. 아이 걱정을 하지 않아야 일을 집중해서 할 수 있을 테니까. 어떤 직원들이 있느냐에 따라 지원해 줘야 할 복지도 달라지기 때문에.. 다른 회사의 복지를 무작정 베껴오는 건 돈을 낭비하는 일입니다. 요즘엔 재택근무를 복지로 내세우는 회사들이 있습니다. 직원들이 재택근무로 인해서 일을 더 잘할 수 있겠다 판단이 들면 올바른 지원이겠지만.. 성과가 덜 나더라도 누군가를 뽑거나 나가지 않게 하기 위한 목적으로.. 직원들이 해달라고 조르니깐 하는 수없이 재택근무를 복지로 내세우는 것은 좀 이상합니다. 단순히 복지포인트 주고, 통신 요금 감면해 주고, 비혼 선언 축하금 주고 하는 회사들보다는.. 회사와 직원들의 성장을 진지하게 고민하는 회사에 더 눈이 갑니다.

복지가 좋은 회사

‘워라밸’의 재해석[직장인을 위한 김호의 ‘생존의 방식’]

<🤔일자리, 커리어, 그리고 소명>

"내 해석은 이렇다. 워라밸은 자신이 '남 좋은 일'만 하고 있다는 생각이 들 때 그 중요성이 매우 높아진다. 하지만 자신이 매일 하는 일이 '나를 위한 일'로 느껴지는 상황이 되면 그 중요성은 상대적으로 낮아진다. 이는 직장을 떠나 모험을 하는 사람뿐 아니라 현재 직장을 다니고 있는 사람들에게도 중요한 통찰을 줄 수 있다." 

조직커뮤니케이션 전문가 김호 대표는 일을 하는 이유가 세 가지라고 이야기합니다. 돈을 버는 수단으로서의 일(job), 성공을 위한 수단으로서의 일(career), 삶의 의미를 찾는 수단으로서의 일 (calling). 

세 가지 이유가 삼위일체가 된다면 더할 나위 없겠지요. 우리가 흔히 떠올리는 유명한 창업자나 기업가들, 이를테면 스티브 잡스나 사티아 나델라 같은 이들은 일을 하는 이유를 돈에서 성공으로, 성공에서 의미로 빠르게 전환시킨 이들입니다. 문제는 모든 생활인이 현실에서 세 가지 이유를 동시에 조화시키며 일하기 쉽지 않다는 데 있지요. 

하지만, 적어도 스스로 질문은 해볼 수 있지 않을까요? 눈으로 보면 쉬울 것 같은데, 막상 입으로 내뱉고 나면 답하기가 생각보다 쉽지 않은 그 질문 말입니다. 질문에 대한 답이 나와야 일이 일자리에서 커리어로, 커리어에서 소명으로 나아갈 수 있을 테니까요. 

"당신은 무엇을 원하십니까?" 

《📺함께 보면 좋은 영상》

월간서른 김호 편 - '회사에서 오래 살아남을 수 있는 비결' 
https://www.youtube.com/watch?v=Zq9VHLf3pqE

동아일보

프로덕트 매니저/서비스 기획

한주현

마케팅

운영PM

ader

#고객경험 #운영기획 #CS최소화 #운영정책수립
안녕하세요! 9년차 CX 운영기획자 입니다.
최근 신사업 피엠으로 업무 중입니다 🤹🏻‍♂️

전략기획 PL

전략팀장

어소시에이트

외교학, 경제학, 동양사학 학사

'사람을 향하는' 제품과 서비스를 만들고자 노력합니다. 최근에는 아티스트와 팬을 연결하는 음악 플랫폼 'FLO'의 전략 수립 및 실행 업무를 담당했습니다. FLO 전에는 교육 플랫폼과 소형 디바이스 사업을 개발하는 일을 했습니다. 서울대학교에서 외교학, 경제학, 동양사학을 공부했고, 듀크대학교에서 사회적기업가정신 전공으로 MBA를 받았습니다. MBA 재학 중 워싱턴 DC에 위치한 사회적기업가 투자기관 아쇼카에서 인턴 연구원으로 있으며 다양한 사회혁신 사례를 살펴볼 수 있었던 행운을 누렸고, 이후 더 나은 사회를 만들어가는데 어떻게 동참해야 할 지에 대한 고민을 이어가고 있습니다. 2020년에는 육아에 전념하며 조금 다른 눈으로 세상을 바라볼 계획입니다. <2018 음악산업백서>를 공동 저술했습니다.

배정민

brunch

전략 투자 일을 합니다. ‘사람을 향하는’ 콘텐츠와 서비스를 찾아내고픈 마음으로 삽니다.

작가라는 부캐를 갖고 있습니다. 에세이 《썬데이 파더스 클럽》, 《아들로 산다는 건 아빠로 산다는 건》을 썼습니다. 

댓글 0