👨‍💻 커피한잔 개발자 ✏️ K리그 프로그래머 💼 ex) 카카오, 네이버 📖 건물주의 기쁨과 슬픔. 114 Followers.

Benjamin (@jehokim) on Threads

코딩을 처음 배울 때 가장 어려웠던 단어는 쓰레드였습니다.
쓰레드란 말만 나오면 가슴속이 답답했습니다.

으아, 도대체 쓰레드가 뭐냐고.

교수님들은 다들 칠판에 실을 그리며 코드가 흘러가는 흐름 같은 거라고 말해줬습니다.

‘아니, 코드가 뭘 어딜 흘러가냐고.’
도저히 이해할 수가 없었습니다.

회사에 들어가서야 깨달았습니다.
멀티 쓰레드 프로그램을 실제로 디버깅해보면서.
_beginthreadex 함수와 EnterCriticalSection 함수를 사용해서 버그를 고치는 과정에서 번쩍 깨달음이 왔던 기억이 납니다.

그때까지 저는 스택이 프로세스 당 1개 있는 건 줄로 잘못 알고 있었습니다.
쓰레드 스택이란 표현을 듣는 순간 느낌이 왔습니다.
_beginthreadex를 통해 쓰레드를 하나 생성할 때마다 스택이 함께 생성된다는 것.
그 스택 크기는 1MB라는 것을 알게 되면서 기뻤습니다.
(커널 모드로 전환될 땐 고작 12KB의 커널 스택을 사용한다는 것도 나중에 알게 됐습니다.)

아, 이제야 뭔지 알 것 같아.
지역 변수를 사용하면 멀티 쓰레드에서 문제가 없다느니, 쓰레드 로컬 스토리지가 뭐니 하는 말들이 그제야 이해가 되기 시작했습니다.

어제부터 쓰레드(SNS)를 시작했는데, 쓰레드란 단어를 계속 보다 보니 고통스러워하던 옛날 생각이 나서 주절거려 봤습니다. (웃음)
쓰레드 주소는 여기입니다. 좀 더 가벼운 생각들을 자주 적어보려고 합니다.

https://www.threads.net/@jehokim

코딩을 처음 배울 때 가장 어려웠던 단어는 쓰레드였습니다. 쓰레드란 말만 나오면 가슴속이 답답했습니다. 으아, 도대체 쓰레드가 뭐냐고. 교수님들은 다들 칠판에 실을 그리며 코드가 흘러가는 흐름 같은 거라고 말해줬습니다. ‘아니, 코드가 뭘 어딜 흘러가냐고.’ 도저히 이해할 수가 없었습니다. 회사에 들어가서야 깨달았습니다. 멀티 쓰레드 프로그램을 실제로 디버깅해보면서. _beginthreadex 함수와 EnterCriticalSection 함수를 사용해서 버그를 고치는 과정에서 번쩍 깨달음이 왔던 기억이 납니다. 그때까지 저는 스택이 프로세스 당 1개 있는 건 줄로 잘못 알고 있었습니다. 쓰레드 스택이란 표현을 듣는 순간 느낌이 왔습니다. _beginthreadex를 통해 쓰레드를 하나 생성할 때마다 스택이 함께 생성된다는 것. 그 스택 크기는 1MB라는 것을 알게 되면서 기뻤습니다. (커널 모드로 전환될 땐 고작 12KB의 커널 스택을 사용한다는 것도 나중에 알게 됐습니다.) 아, 이제야 뭔지 알 것 같아. 지역 변수를 사용하면 멀티 쓰레드에서 문제가 없다느니, 쓰레드 로컬 스토리지가 뭐니 하는 말들이 그제야 이해가 되기 시작했습니다. 어제부터 쓰레드(SNS)를 시작했는데, 쓰레드란 단어를 계속 보다 보니 고통스러워하던 옛날 생각이 나서 주절거려 봤습니다. (웃음) 쓰레드 주소는 여기입니다. 좀 더 가벼운 생각들을 자주 적어보려고 합니다. https://www.threads.net/@jehokim

Threads

쓰레드의 추억

문자는 메소포타미아 지역에서 5000년 전쯤 발명된 것으로 보인다. 점토판에 새겨진 기호가 말을 할 수 있다는 사실에 당시 사람들은 놀랐으리라. 문자가 발명되고 오랫동안 오직 소수의 사람만 문자를 사용할 수 있었다.

최초의 인플루언서 누군지 궁금하지? [물리학자 김상욱의 '격물치지']

1. 문자는 메소포타미아 지역에서 5000년 전쯤 발명된 것으로 보인다.

2. (그리고) 문자가 발명되고 오랫동안 오직 소수의 사람만 문자를 사용할 수 있었다. 말하기와 달리, 글쓰기는 엄청난 노력을 통해 습득되는 기술이기 때문이다.

3. (이후) 도시와 국가가 탄생하자, 관리와 통치에 필요한 엄청난 양의 정보를 기억에만 의존할 수 없었을 것이다. (이때) 문자는 국가 운영에 필요한 정보를 저장·관리하는 필수적인 도구였다. (텍스트 = 소프트웨어)

4. (그리고 문명을 건설한) 메소포타미아의 통치자들은 문자의 힘을 (빠르게) 깨달았다. 말이 문자가 되면 변하지 않는다. 변하지 않는 것은 중요하다. ‘금’이 귀한 이유는 철과 달리 녹슬어 변하지 않기 때문이다.

5. 문자(=글)는 단순히 말을 기호로 옮긴 것이 아니다. 문자문화의 사람은 ‘정확성’과 ‘분석적인 능력’을 내면화한다. 구술문화에 리스트나 도표 같은 것은 없다. 여러 가지 사건들을 객관적으로 늘어놓고 체계적으로 분류하는 것은 문자문화에서만 가능하다.

6. (특히) 말로만 이야기하며 일관성을 유지하기는 어렵다. A를 물었을 때 A에 대해 답하는 척하다가 적당히 B로 바꾸어 대답해도 사람들은 종종 눈치채지 못한다. 하지만 글에서 이런 식으로 하면 금방 탄로 난다. 글은 생각을 순서대로 펼쳐놓고 한꺼번에 조망하도록 만들어주기 때문이다.

7. (인류의 역사에) 문자나 글이 없었다면 논리나 수학 같은 고도의 정신 능력이 없었을지 모른다는 뜻이다. 결국 텍스트를 사용하는 문명은 그렇지 못한 문명을 압도해갔다. 텍스트는 힘이다.

8. 텍스트는 힘이고 권력이었기에 누구든 함부로 읽고 쓸 수 없었다. 읽고 쓰는 법을 배우고 싶어도 구할 수 있는 텍스트 자체가 많지 않아 기회는 제한적이었다. 따라서 책은 귀했고, 소수의 사람만 소유할 수 있었다.

9. 하지만 15세기 구텐베르크의 금속활자 인쇄술은 텍스트 역사에 혁명을 가져온다.

10. 인쇄술로 책이 널리 공급되고 글을 읽을 수 있는 사람이 늘어나자 텍스트 권력의 민주화, 나아가 지식 혁명이 시작된다. 새로운 사상, 특히 근대과학의 내용이 책으로 쓰여 널리 보급되기 시작한 것이다.

11. 17~18세기를 지나며 케플러·갈릴레오·뉴턴의 책을 통해 과학 혁명이 시작되고, 볼테르·존 로크·몽테스키외·루소의 책을 통해 계몽주의 사상이 널리 전파된다.

12. 계몽주의는 미국의 독립과 프랑스 혁명이 일어나는 데 큰 영향을 미쳤다. 따라서 책이야말로 민주주의 탄생에 가장 중요한 물건이었다고 할 수 있다.

13. (그리고 이는 인류의 역사나 문명에만 국한되는 일이 아니다. 개인의 삶도 텍스트, 그러니까 글쓰기와 읽기에 가까워질 때 혁명이 일어난다)

1. 문자는 메소포타미아 지역에서 5000년 전쯤 발명된 것으로 보인다. 2. (그리고) 문자가 발명되고 오랫동안 오직 소수의 사람만 문자를 사용할 수 있었다. 말하기와 달리, 글쓰기는 엄청난 노력을 통해 습득되는 기술이기 때문이다. 3. (이후) 도시와 국가가 탄생하자, 관리와 통치에 필요한 엄청난 양의 정보를 기억에만 의존할 수 없었을 것이다. (이때) 문자는 국가 운영에 필요한 정보를 저장·관리하는 필수적인 도구였다. (텍스트 = 소프트웨어) 4. (그리고 문명을 건설한) 메소포타미아의 통치자들은 문자의 힘을 (빠르게) 깨달았다. 말이 문자가 되면 변하지 않는다. 변하지 않는 것은 중요하다. ‘금’이 귀한 이유는 철과 달리 녹슬어 변하지 않기 때문이다. 5. 문자(=글)는 단순히 말을 기호로 옮긴 것이 아니다. 문자문화의 사람은 ‘정확성’과 ‘분석적인 능력’을 내면화한다. 구술문화에 리스트나 도표 같은 것은 없다. 여러 가지 사건들을 객관적으로 늘어놓고 체계적으로 분류하는 것은 문자문화에서만 가능하다. 6. (특히) 말로만 이야기하며 일관성을 유지하기는 어렵다. A를 물었을 때 A에 대해 답하는 척하다가 적당히 B로 바꾸어 대답해도 사람들은 종종 눈치채지 못한다. 하지만 글에서 이런 식으로 하면 금방 탄로 난다. 글은 생각을 순서대로 펼쳐놓고 한꺼번에 조망하도록 만들어주기 때문이다. 7. (인류의 역사에) 문자나 글이 없었다면 논리나 수학 같은 고도의 정신 능력이 없었을지 모른다는 뜻이다. 결국 텍스트를 사용하는 문명은 그렇지 못한 문명을 압도해갔다. 텍스트는 힘이다. 8. 텍스트는 힘이고 권력이었기에 누구든 함부로 읽고 쓸 수 없었다. 읽고 쓰는 법을 배우고 싶어도 구할 수 있는 텍스트 자체가 많지 않아 기회는 제한적이었다. 따라서 책은 귀했고, 소수의 사람만 소유할 수 있었다. 9. 하지만 15세기 구텐베르크의 금속활자 인쇄술은 텍스트 역사에 혁명을 가져온다. 10. 인쇄술로 책이 널리 공급되고 글을 읽을 수 있는 사람이 늘어나자 텍스트 권력의 민주화, 나아가 지식 혁명이 시작된다. 새로운 사상, 특히 근대과학의 내용이 책으로 쓰여 널리 보급되기 시작한 것이다. 11. 17~18세기를 지나며 케플러·갈릴레오·뉴턴의 책을 통해 과학 혁명이 시작되고, 볼테르·존 로크·몽테스키외·루소의 책을 통해 계몽주의 사상이 널리 전파된다. 12. 계몽주의는 미국의 독립과 프랑스 혁명이 일어나는 데 큰 영향을 미쳤다. 따라서 책이야말로 민주주의 탄생에 가장 중요한 물건이었다고 할 수 있다. 13. (그리고 이는 인류의 역사나 문명에만 국한되는 일이 아니다. 개인의 삶도 텍스트, 그러니까 글쓰기와 읽기에 가까워질 때 혁명이 일어난다)

Naver

텍스트는 인류와 개인의 발전을 이끌어온 초강력 소프트웨어입니다 ㄷㄷ

간만에 책 홍보 🤭 많이 팔아주시라고 얼굴 한 번 팔아봅니다. ☺️ 많이 팔아주세요. 굽신굽신 🙇🏻🙇🏻‍♀️ 아참! 전자책도 출간되었습니다! #교보문고 #예스24 #알라딘 출간 완료! #리디북스 진행중 (이미지의 내용은 출판사 인터뷰 일부입니다) #LLM #AI #ChatGPT #프롬프트엔지니어링 #최고의프롬프트엔지니어링강의

간만에 책 홍보 🤭 많이 팔아주시라고 얼굴 한 번 팔아봅니다. ☺️ 많이 팔아주세요. 굽신굽신 🙇🏻🙇🏻‍♀️ 아참! 전자책도 출간되었습니다! #교보문고 #예스24 #알라딘 출간 완료! #리디북스 진행중 (이미지의 내용은 출판사 인터뷰 일부입니다) #LLM #AI #ChatGPT #프롬프트엔지니어링 #최고의프롬프트엔지니어링강의

My email inbox is clogged up daily with large, unnecessary images and attachments-an impact of superfast broadband and cloud storage.

We're sending way too many emails-and it's hurting the planet

여러분의 이메일 인박스는 어떤가요? 제 지메일은 수많은 뉴스레터로 가득가득 한데요. 나중에 읽어야지- 라며 쌓이고, 이제는 다 지우기 버거울 정도로 정말 많아졌습니다.

이렇게 쌓인 뉴스레터, 광고 이메일, 노티성 이메일.... 아무리 작은 단위라지만 쌓이고 쌓여서 벌써 제 인박스에 몇기가는 광고인 것 같습니다. 이메일을 지우는게 얼마나 대단하겠냐 하겠지만...ChatGPT의 등장으로 컨텐츠 만들기는 쉬워지고, 이메일 보내는 것은 너무 쉬워지면서 작게 모인 메일들이 이제는 꽤나 버거울 정도로 빠르게 쌓이는 것 같습니다.

 * 디지털 탄소 발자국: 특히 대용량 첨부 파일과 이미지를 포함한 이메일은 탄소 배출에 상당한 기여를 합니다. 이러한 이메일을 전송, 수신 및 저장하는 데 필요한 에너지가 누적되어 환경에 영향을 미칩니다.
 * 이메일의 양: 매일 보내지는 엄청난 양의 이메일, 특히 불필요한 이메일들이 문제를 악화시킵니다. 이메일의 양을 줄이는 것이 에너지 소비를 줄이고, 그 결과 탄소 배출을 줄이는 데 도움이 됩니다.
 * 효율성과 인식: 더 효율적인 커뮤니케이션을 장려하고 디지털 활동이 환경에 미치는 영향을 인식시키는 것이 중요합니다. 이메일 빈도를 줄이고 더 효율적인 파일 공유 방법을 선택하는 간단한 행동들이 변화를 만들 수 있습니다.
   

오늘은 하루를 마무리 하며, 잘 읽지 않는 뉴스레터는 끊고, 광고는 unsubscribe 해봐야겠네요.

https://www.fastcompany.com/91147687/we-send-way-too-many-emails-and-its-hurting-the-planet

여러분의 이메일 인박스는 어떤가요? 제 지메일은 수많은 뉴스레터로 가득가득 한데요. 나중에 읽어야지- 라며 쌓이고, 이제는 다 지우기 버거울 정도로 정말 많아졌습니다. 이렇게 쌓인 뉴스레터, 광고 이메일, 노티성 이메일.... 아무리 작은 단위라지만 쌓이고 쌓여서 벌써 제 인박스에 몇기가는 광고인 것 같습니다. 이메일을 지우는게 얼마나 대단하겠냐 하겠지만...ChatGPT의 등장으로 컨텐츠 만들기는 쉬워지고, 이메일 보내는 것은 너무 쉬워지면서 작게 모인 메일들이 이제는 꽤나 버거울 정도로 빠르게 쌓이는 것 같습니다. <ul ><li>디지털 탄소 발자국: 특히 대용량 첨부 파일과 이미지를 포함한 이메일은 탄소 배출에 상당한 기여를 합니다. 이러한 이메일을 전송, 수신 및 저장하는 데 필요한 에너지가 누적되어 환경에 영향을 미칩니다.</li><li>이메일의 양: 매일 보내지는 엄청난 양의 이메일, 특히 불필요한 이메일들이 문제를 악화시킵니다. 이메일의 양을 줄이는 것이 에너지 소비를 줄이고, 그 결과 탄소 배출을 줄이는 데 도움이 됩니다.</li><li>효율성과 인식: 더 효율적인 커뮤니케이션을 장려하고 디지털 활동이 환경에 미치는 영향을 인식시키는 것이 중요합니다. 이메일 빈도를 줄이고 더 효율적인 파일 공유 방법을 선택하는 간단한 행동들이 변화를 만들 수 있습니다. </li></ul> 오늘은 하루를 마무리 하며, 잘 읽지 않는 뉴스레터는 끊고, 광고는 unsubscribe 해봐야겠네요. https://www.fastcompany.com/91147687/we-send-way-too-many-emails-and-its-hurting-the-planet

Fast Company

너무 많은 이메일로 우리는 지구를 괴롭히고 있습니다.

좋은 퇴사는 어떤 걸까요? 더 이상 함께하지 못한다는 사실에 아쉬워하면서도, 새로운 시작을 응원받는다면 좋은 퇴사가 아닐까요.

좋은 퇴사를 위해선 무엇보다 솔직해야 한다는 생각이 듭니다. 회사를 떠나는 이유와 다음 행보에 대해 알릴 수 있다면 좋겠죠.

저는 솔직하지 못한 퇴사를 한 경험이 있습니다. 제가 처한 상황과 고민을 털어놓지 못했죠. 그 때문에 동료들을 실망하게 하고 서운하게 만들었던 것 같습니다.

처음이라 모든 게 서툴렀습니다. 어디까지 말해도 좋은지, 얼마나 솔직해야 하는지 몰랐죠. 제 이야기를 듣는 동료와 관계가 틀어질까 걱정됐습니다. 솔직하지 못했던 이유입니다.

하지만 돌이켜보니 솔직했어야 했다는 생각이 듭니다.

우리가 일하는 업계는 생각보다 좁아서, 결국엔 다시 만납니다. 멀리 보고 관계를 쌓아가야 하죠.

솔직함은 잠깐의 불편할 수 있어도 멀리 보면 진정한 관계를 만들어주는 좋은 태도입니다. 좋은 퇴사, 좋은 관계를 위해 솔직하게 자신의 고민을 나눠보는 건 어떨까요.

좋은 퇴사는 어떤 걸까요? 더 이상 함께하지 못한다는 사실에 아쉬워하면서도, 새로운 시작을 응원받는다면 좋은 퇴사가 아닐까요. 좋은 퇴사를 위해선 무엇보다 솔직해야 한다는 생각이 듭니다. 회사를 떠나는 이유와 다음 행보에 대해 알릴 수 있다면 좋겠죠. 저는 솔직하지 못한 퇴사를 한 경험이 있습니다. 제가 처한 상황과 고민을 털어놓지 못했죠. 그 때문에 동료들을 실망하게 하고 서운하게 만들었던 것 같습니다. 처음이라 모든 게 서툴렀습니다. 어디까지 말해도 좋은지, 얼마나 솔직해야 하는지 몰랐죠. 제 이야기를 듣는 동료와 관계가 틀어질까 걱정됐습니다. 솔직하지 못했던 이유입니다. 하지만 돌이켜보니 솔직했어야 했다는 생각이 듭니다. 우리가 일하는 업계는 생각보다 좁아서, 결국엔 다시 만납니다. 멀리 보고 관계를 쌓아가야 하죠. 솔직함은 잠깐의 불편할 수 있어도 멀리 보면 진정한 관계를 만들어주는 좋은 태도입니다. 좋은 퇴사, 좋은 관계를 위해 솔직하게 자신의 고민을 나눠보는 건 어떨까요.

좋은 퇴사를 위하여

A first person account of how modern open identity standards are made

From Idea to Standard How the JWT Profile for OAuth 2.0 Access Tokens Became RFC9068

2021년 글이지만 최근에 OAuth나 JWT를 직접 구현하지 않아서 모르고 있다가 다른 글을 통해서 발견한 글입니다.

글을 쓴 사람은 Auth0 직원인데 OAuth 2에는 Access Token의 형태는 정의하지 않고 있기 때문에 각 회사에서 Access Token의 형태가 달라졌기 때문에 여러 서비스를 지원할 때 어려움이 있어서 이부분에 대한 조사를 시작했다고 합니다.

보통 OAuth 2에서는 권한을 검증하는 인가 서버와 실제 리소스를 사용하는 리소스 서버가 분리되어 있기 마련인데 한 조직내에서라면 리소스 서버가 인가 서버에 접속할 수 있기 때문에 쉽게 리소스 서버에 들어온 Access Token이 유효한지 검증할 수 있습니다.

하지만 서드 파티와의 연동을 한다면 리소스 서버가 인가 서버와 상태를 공유할 수 없기 때문에 Access Token를 검증할 다른 방법이 필요하게 되는데 이때 JWT를 사용하면 편하게 쓸 수 있습니다.

조사한 결과 대부분의 서비스에서 JWT의 데이터는 비슷했지만 클레임 형태, 즉, JWT에 포함되는 각 필드면의 이름이 약간씩 달랐기 때문에 이를 통일 시킬수 있다고 생각해서 조사한 내용을 IETF에서 제안을 올리게 되었다고 합니다.

참석자들도 대부분 비슷한 문제를 겪고 있었기 때문에 동의를 얻고 이후 IETF 표준화 프로세스를 거쳐서 RFC 9068 JWT Profile for OAuth 2.0 Access Token 표준이 되었고 이를 통해 OAuth의 JWT 토큰의 형태를 통일시킬 수 있게 되었습니다.

https://auth0.com/blog/how-the-jwt-profile-for-oauth-20-access-tokens-became-rfc9068/

2021년 글이지만 최근에 OAuth나 JWT를 직접 구현하지 않아서 모르고 있다가 다른 글을 통해서 발견한 글입니다. 글을 쓴 사람은 Auth0 직원인데 OAuth 2에는 Access Token의 형태는 정의하지 않고 있기 때문에 각 회사에서 Access Token의 형태가 달라졌기 때문에 여러 서비스를 지원할 때 어려움이 있어서 이부분에 대한 조사를 시작했다고 합니다. 보통 OAuth 2에서는 권한을 검증하는 인가 서버와 실제 리소스를 사용하는 리소스 서버가 분리되어 있기 마련인데 한 조직내에서라면 리소스 서버가 인가 서버에 접속할 수 있기 때문에 쉽게 리소스 서버에 들어온 Access Token이 유효한지 검증할 수 있습니다. 하지만 서드 파티와의 연동을 한다면 리소스 서버가 인가 서버와 상태를 공유할 수 없기 때문에 Access Token를 검증할 다른 방법이 필요하게 되는데 이때 JWT를 사용하면 편하게 쓸 수 있습니다. 조사한 결과 대부분의 서비스에서 JWT의 데이터는 비슷했지만 클레임 형태, 즉, JWT에 포함되는 각 필드면의 이름이 약간씩 달랐기 때문에 이를 통일 시킬수 있다고 생각해서 조사한 내용을 IETF에서 제안을 올리게 되었다고 합니다. 참석자들도 대부분 비슷한 문제를 겪고 있었기 때문에 동의를 얻고 이후 IETF 표준화 프로세스를 거쳐서 RFC 9068 JWT Profile for OAuth 2.0 Access Token 표준이 되었고 이를 통해 OAuth의 JWT 토큰의 형태를 통일시킬 수 있게 되었습니다. https://auth0.com/blog/how-the-jwt-profile-for-oauth-20-access-tokens-became-rfc9068/

Auth0 - Blog

★제11회 브런치북 대상 수상작★ "100만 원으로 팔지 못하면 1억으로도 팔 수 없다!" '최소 비용'으로 '최대 효율'을 만드는 실무형 마케터의 노하우

100만 원 마케팅

'100만 원으로 팔지 못하면 1억으로도 팔 수 없다!'
'이제 사람들은 ‘나이키, 애플이 왜 성공했는지’ 정도는 알고 있다. 한정된 예산으로 최대 효율을 내야 하는 실무자는 대기업 사례보다 당장 이번 예산을 어떻게 써야 할지가 고민이다.'

본질적인 질문과 현실적인 이야기로 소개하는 이 책은,
마케팅과 관련된 산업, 회사, 서비스, 직무에서 일하는 모든 사람들에게 아주 좋은 교과서입니다!

물건이 좋다면 광고가 적어도 고객들은 알아서 찾아오고,
광고가 아무리 좋아도 물건이 좋지 않다면, 혹은 불편하다면 전환율이 좋지 않습니다.

그리고 물건/서비스에 따라 광고의 형태, 광고비는 다르게 접근해야 합니다.

예를 들어,
내가 나를 위해 요리를 하는 것과,
내가 친구를 위해 요리를 하는 것과,
가까운 사람들에게 대접하기 위한 요리를 하는 것과,
음식점에서 아르바이트하며 요리하는 것과,
음식점 사장님이 되어 요리하는 것과,
프랜차이즈를 1~2개씩 내며 요리하는 것과,
전국적인 프랜차이즈를 내며 요리를 연구하는 것과,
요리 레시피 자체를 연구하는 것..
모두가 다르게 접근해서 홍보해야만 하는 것처럼, 상황에 따라 다른 형태, 전략, 광고비로 접근해야 합니다.

저자는 100만원으로 광고를 시작하며, 카카오 광고 100만원 실패, 네이버 광고 100만원 실패, 구글 스마트 디스플레이 700만원 실패.. 를 겪으며 적은 광고비로 조합해보기도 하고, 광고비를 1000만원, 5000만원, 1억으로 늘려나가며 겪었던 경험하며 한 고민들을 자세히 설명해줍니다.

그리고 틱톡, 인공지능 광고 등 온라인 광고를 넘어 변화하는 세상의 광고에 대해서도 설명해주고, 마케터로 어떻게 성장과 발전할 수 있는지 본질적인 이야기를 전해줍니다.

최근 저도 마케팅의 중요함을 절실히 느끼고 있는데요,
마케팅 업무를 해보지 않은 저에게도 아주 쉽고 재밌게, 현실적인 내용까지 이해할 수 있는 좋은 서적이었습니다. :)

* 도서를 제공해 주신 출판사 한빛미디어에 감사를 표합니다 🙏🏻

https://www.hanbit.co.kr/store/books/look.php?p_code=B3545929340

'100만 원으로 팔지 못하면 1억으로도 팔 수 없다!''이제 사람들은 ‘나이키, 애플이 왜 성공했는지’ 정도는 알고 있다. 한정된 예산으로 최대 효율을 내야 하는 실무자는 대기업 사례보다 당장 이번 예산을 어떻게 써야 할지가 고민이다.' 본질적인 질문과 현실적인 이야기로 소개하는 이 책은,마케팅과 관련된 산업, 회사, 서비스, 직무에서 일하는 모든 사람들에게 아주 좋은 교과서입니다! 물건이 좋다면 광고가 적어도 고객들은 알아서 찾아오고,광고가 아무리 좋아도 물건이 좋지 않다면, 혹은 불편하다면 전환율이 좋지 않습니다. 그리고 물건/서비스에 따라 광고의 형태, 광고비는 다르게 접근해야 합니다. 예를 들어,내가 나를 위해 요리를 하는 것과,내가 친구를 위해 요리를 하는 것과,가까운 사람들에게 대접하기 위한 요리를 하는 것과,음식점에서 아르바이트하며 요리하는 것과,음식점 사장님이 되어 요리하는 것과,프랜차이즈를 1~2개씩 내며 요리하는 것과,전국적인 프랜차이즈를 내며 요리를 연구하는 것과,요리 레시피 자체를 연구하는 것..모두가 다르게 접근해서 홍보해야만 하는 것처럼, 상황에 따라 다른 형태, 전략, 광고비로 접근해야 합니다. 저자는 100만원으로 광고를 시작하며, 카카오 광고 100만원 실패, 네이버 광고 100만원 실패, 구글 스마트 디스플레이 700만원 실패.. 를 겪으며 적은 광고비로 조합해보기도 하고, 광고비를 1000만원, 5000만원, 1억으로 늘려나가며 겪었던 경험하며 한 고민들을 자세히 설명해줍니다. 그리고 틱톡, 인공지능 광고 등 온라인 광고를 넘어 변화하는 세상의 광고에 대해서도 설명해주고, 마케터로 어떻게 성장과 발전할 수 있는지 본질적인 이야기를 전해줍니다. 최근 저도 마케팅의 중요함을 절실히 느끼고 있는데요,마케팅 업무를 해보지 않은 저에게도 아주 쉽고 재밌게, 현실적인 내용까지 이해할 수 있는 좋은 서적이었습니다. :) * 도서를 제공해 주신 출판사 한빛미디어에 감사를 표합니다 🙏🏻 https://www.hanbit.co.kr/store/books/look.php?p_code=B3545929340

Hanbit

[마케터라면 꼭 읽어야 할 책] 100만원 마케팅 💵

Slack에서 코드 리뷰 요청하는 알림을 확인하고 PR을 열어보았습니다. 제법 많은 양의 코드가 추가되었는데 테스트 코드가 전혀 없더군요.

테스트를 하지 않아 낭비될 "우리"의 시간

Slack에서 코드 리뷰 요청하는 알림을 확인하고 PR을 열어보았습니다. 제법 많은 양의 코드가 추가되었는데 테스트 코드가 전혀 없더군요. 그래서 저는 PR을 승인하지 않고, 추가한 코드에 대한 테스트 코드를 작성해 달라는 짧은 코멘트를 남겼습니다.

다음 날, 코드 리뷰를 요청했던 개발자가 속한 팀의 stand-up 미팅에 참석했습니다. 그런데 그 친구가 PM(Project Manager)에게 약간 원망조로 얘기를 하더군요. 어제 자기는 빨리 코딩을 하고 팀원들에게 리뷰를 요청했지만, 아무도 승인해주지 않아서 배포를 할 수가 없었다고요. 저 뿐만 아니라 다른 팀원들도 그 PR을 승인하기가 불편했었나 봅니다. 최근에 테스트없는 코드를 배포했다가 옆 팀에서 장애가 있었거든요. 자초지종을 모르는 PM은 우선순위가 높은 티켓이니 오늘까지 꼭 코드 리뷰를 해달라고 팀을 독려하였습니다.

테스트 작성에 대해 꼭 대화를 좀 나누고 싶어서, 그 개발자와 one-on-one 미팅을 잡았습니다. 제가 테스트 코드를 추가하지 않는 이유에 대해 물으니, 테스트를 작성할 시간이 없을 정도로 긴급한 변경 사항이라고 판단해 테스트를 생략했다고 하더군요.

저는 우선 그 친구의 좋은 의도에 대해서 감사하다고 말했습니다. 어찌됐든 팀을 위하는 마음으로 한 일이니까요. 그리고 우리는 테스트 작성에 대해서 본격적인 대화를 시작하였습니다. 저는 우선 질문을 하였습니다.

"How much time do you think YOU have saved on the PR by skipping writing tests?" (테스트 작성을 생략해서 너의 시간을 얼만큼 아꼈다고 생각해?)

그 친구는 조금 머뭇하더니 대답합니다.

"Well... I don't know. Probably, a couple of hours?" (글쎄... 잘 모르겠는데, 아마도 한 두시간?)

저는 질문을 이어 갔습니다.

"Have you ever thought about how much time WE will waste in the future by choosing not to write tests today?" (혹시 오늘 테스트를 작성하지 않기로 해서, 미래에 우리가 낭비하게 될 시간에 대해서는 생각해봤어?)

그 친구는 제 질문의 의도를 바로 이해하지 못하는 눈치였습니다.

"What? What are you talking about? 🤷"

그래서 아래와 같이 테스트를 작성하지 않음로써 팀이 치뤄야하는 댓가에 대해서 안 되는 영어로 열심히 제 생각을 말해주었습니다.

(다 영어로 써볼려고 하다가 너무 길어서, 여기부터는 그냥 한글로 갈 께요 ㅋㅋ 😂)

"우선 테스트가 없는 코드는 리뷰하는데는 시간이 더 오래 걸리기 마련이야. 해당 코드가 어떤 용도로 작성이 되었는지 파악하기가 힘들고, 리뷰어(reviewer) 입장에서 코드를 눈으로만 읽고 선뜻 승인 버튼을 누르기 어려워. 혹시 문제가 생기면 공동 책임이잖아. 그래서 나처럼 한 번에 승인하지 않고 코멘트를 남기는 사람도 생기고. 이 것은 결국은 PR 작성자와 PR 리뷰어 모두에게 시간적인 손해야."

"QA 입장에서 생각해볼까? 다른 PR들처럼 자동화된 테스트가 없으니 QA는 코드가 상용 환경에서 잘 동작할 거라는 확신을 갖기 어려워. 결국 다른 PR 보다 매뉴얼 테스팅에 더 신경을 쓰게 될꺼야. QA 시간에도 손해가 일어나네?"

"나중에 다른 팀원이 이 코드를 수정할 일이 생겼다고 생각해보자. 주니어 개발자들은 경험이 많지 않아서 테스트를 보완하지 않고 그냥 코드를 수정하게 될 가능성이 커. 이럴 경우, 새로운 기능은 잘 되는데 기존에 잘 되던 기능에 문제가 생기는 경우가 많지. 만약 상용 환경에서 심각한 버그가 생기면 팀 전체가 하던 일은 멈추고 그 문제를 해결하는데 매달려야할 수도 있어. 당연히 진행 중이던 프로젝트 일정에 차질에 발생하겠지?"

"이런 일을 많이 당해본 나같은 개발자들은 테스트없는 코드 수정하는 게 얼마나 위험한 일인지 알고 있어. 그래서 수정하려는 코드에 테스트가 없다면 우선 테스트를 먼저 작성하지. 알다시피 본인이 작성하지 않은 코드에 대한 테스트를 작성하는 게 그렇게 유쾌한 경험은 아니야. 주어진 일을 제쳐두고 테스트하려는 코드를 먼저 이해해야 하니, 최초 코드 작성자를 원망하게 되는 경우도 많지. 어떤 방향으로든 다른 개발자에게도 피해가 가겠지?"

"자, 정리를 해보면, 테스트를 작성하지 않아서 오늘 너는 한 두시간을 아꼈을지 몰라도, 앞으로 우리 팀은 그 테스트가 없는 코드 때문에 그 보다 몇 배의 시간을 낭비할 수도 있어. 그래서 나는 너가 테스트를 작성하지 않는 이유가 완전히 납득이 가지 않는 건 아니지만, 과연 그 것이 진정 팀을 위한 일인지는 의문이 들어."

다행이도 그 친구는 금방 설득이 되었고, 저는 짝 프로그래밍(Pair-programming)을 제안하였습니다. 함께 테스트를 작성하면서 우리는 코드에서 몇 가지 아찔한 버그를 찾아서 고칠 수 있었고, 테스트를 작성하기 쉽도록 코드 설계도 조금 개선할 수 있습니다. 실제로 우리가 테스트를 작성하는데 필요한 시간은 30분 남짓이면 족했습니다. 그 친구의 시간 30분, 제 시간 30분, 우리는 오늘 총 1시간을 투자하여 팀차원에서 낭비될 수 있었던 많은 시간을 절약하였다고 생각합니다.

그 친구는 다시 코드 리뷰를 요청하였고, 금방 팀 동료로부터 승인을 받을 수 있었습니다. 얼마 지나지 않아 그 친구가 테스트를 작성해야하는 이유에 대해서 일깨워줘서 고맙다는 메시지를 보내왔습니다. 알고보니 작년에 매니저로 부터 시니어 개발자가 되려면 성과가 더 많아야겠다는 피드백을 받았다네요. 그 이후로 초조해져서 테스트를 작성하는데 소홀해진 것 같다고 하네요. 그 친구가 터놓고 얘기를 해줘서 고마웠습니다. 다음 one-on-one 미팅에서는 quality를 희생하지 않고 speed를 올릴 수 있는 방법에 대해서 대화를 나누기로 했습니다.

여러분도 빡빡한 일정을 핑계로 테스트를 작성하지 않고 코드 리뷰를 요청하는 동료 개발자가 있으신가요? 테스트를 생략함으로써 개인 시간을 당장 얼마나 아낄 수 있는지, 그리고 나중에 다른 팀원들이 얼만큼의 시간을 지불해야하는지에 대해서 한번 꼭 열린 대화를 나누어 보셨으면 좋겠습니다. 😃

Slack에서 코드 리뷰 요청하는 알림을 확인하고 PR을 열어보았습니다. 제법 많은 양의 코드가 추가되었는데 테스트 코드가 전혀 없더군요. 그래서 저는 PR을 승인하지 않고, 추가한 코드에 대한 테스트 코드를 작성해 달라는 짧은 코멘트를 남겼습니다. 다음 날, 코드 리뷰를 요청했던 개발자가 속한 팀의 stand-up 미팅에 참석했습니다. 그런데 그 친구가 PM(Project Manager)에게 약간 원망조로 얘기를 하더군요. 어제 자기는 빨리 코딩을 하고 팀원들에게 리뷰를 요청했지만, 아무도 승인해주지 않아서 배포를 할 수가 없었다고요. 저 뿐만 아니라 다른 팀원들도 그 PR을 승인하기가 불편했었나 봅니다. 최근에 테스트없는 코드를 배포했다가 옆 팀에서 장애가 있었거든요. 자초지종을 모르는 PM은 우선순위가 높은 티켓이니 오늘까지 꼭 코드 리뷰를 해달라고 팀을 독려하였습니다. 테스트 작성에 대해 꼭 대화를 좀 나누고 싶어서, 그 개발자와 one-on-one 미팅을 잡았습니다. 제가 테스트 코드를 추가하지 않는 이유에 대해 물으니, 테스트를 작성할 시간이 없을 정도로 긴급한 변경 사항이라고 판단해 테스트를 생략했다고 하더군요. 저는 우선 그 친구의 좋은 의도에 대해서 감사하다고 말했습니다. 어찌됐든 팀을 위하는 마음으로 한 일이니까요. 그리고 우리는 테스트 작성에 대해서 본격적인 대화를 시작하였습니다. 저는 우선 질문을 하였습니다. "How much time do you think YOU have saved on the PR by skipping writing tests?" (테스트 작성을 생략해서 너의 시간을 얼만큼 아꼈다고 생각해?) 그 친구는 조금 머뭇하더니 대답합니다. "Well... I don't know. Probably, a couple of hours?" (글쎄... 잘 모르겠는데, 아마도 한 두시간?) 저는 질문을 이어 갔습니다. "Have you ever thought about how much time WE will waste in the future by choosing not to write tests today?" (혹시 오늘 테스트를 작성하지 않기로 해서, 미래에 우리가 낭비하게 될 시간에 대해서는 생각해봤어?) 그 친구는 제 질문의 의도를 바로 이해하지 못하는 눈치였습니다. "What? What are you talking about? 🤷" 그래서 아래와 같이 테스트를 작성하지 않음로써 팀이 치뤄야하는 댓가에 대해서 안 되는 영어로 열심히 제 생각을 말해주었습니다. (다 영어로 써볼려고 하다가 너무 길어서, 여기부터는 그냥 한글로 갈 께요 ㅋㅋ 😂) "우선 테스트가 없는 코드는 리뷰하는데는 시간이 더 오래 걸리기 마련이야. 해당 코드가 어떤 용도로 작성이 되었는지 파악하기가 힘들고, 리뷰어(reviewer) 입장에서 코드를 눈으로만 읽고 선뜻 승인 버튼을 누르기 어려워. 혹시 문제가 생기면 공동 책임이잖아. 그래서 나처럼 한 번에 승인하지 않고 코멘트를 남기는 사람도 생기고. 이 것은 결국은 PR 작성자와 PR 리뷰어 모두에게 시간적인 손해야." "QA 입장에서 생각해볼까? 다른 PR들처럼 자동화된 테스트가 없으니 QA는 코드가 상용 환경에서 잘 동작할 거라는 확신을 갖기 어려워. 결국 다른 PR 보다 매뉴얼 테스팅에 더 신경을 쓰게 될꺼야. QA 시간에도 손해가 일어나네?" "나중에 다른 팀원이 이 코드를 수정할 일이 생겼다고 생각해보자. 주니어 개발자들은 경험이 많지 않아서 테스트를 보완하지 않고 그냥 코드를 수정하게 될 가능성이 커. 이럴 경우, 새로운 기능은 잘 되는데 기존에 잘 되던 기능에 문제가 생기는 경우가 많지. 만약 상용 환경에서 심각한 버그가 생기면 팀 전체가 하던 일은 멈추고 그 문제를 해결하는데 매달려야할 수도 있어. 당연히 진행 중이던 프로젝트 일정에 차질에 발생하겠지?" "이런 일을 많이 당해본 나같은 개발자들은 테스트없는 코드 수정하는 게 얼마나 위험한 일인지 알고 있어. 그래서 수정하려는 코드에 테스트가 없다면 우선 테스트를 먼저 작성하지. 알다시피 본인이 작성하지 않은 코드에 대한 테스트를 작성하는 게 그렇게 유쾌한 경험은 아니야. 주어진 일을 제쳐두고 테스트하려는 코드를 먼저 이해해야 하니, 최초 코드 작성자를 원망하게 되는 경우도 많지. 어떤 방향으로든 다른 개발자에게도 피해가 가겠지?" "자, 정리를 해보면, 테스트를 작성하지 않아서 오늘 너는 한 두시간을 아꼈을지 몰라도, 앞으로 우리 팀은 그 테스트가 없는 코드 때문에 그 보다 몇 배의 시간을 낭비할 수도 있어. 그래서 나는 너가 테스트를 작성하지 않는 이유가 완전히 납득이 가지 않는 건 아니지만, 과연 그 것이 진정 팀을 위한 일인지는 의문이 들어." 다행이도 그 친구는 금방 설득이 되었고, 저는 짝 프로그래밍(Pair-programming)을 제안하였습니다. 함께 테스트를 작성하면서 우리는 코드에서 몇 가지 아찔한 버그를 찾아서 고칠 수 있었고, 테스트를 작성하기 쉽도록 코드 설계도 조금 개선할 수 있습니다. 실제로 우리가 테스트를 작성하는데 필요한 시간은 30분 남짓이면 족했습니다. 그 친구의 시간 30분, 제 시간 30분, 우리는 오늘 총 1시간을 투자하여 팀차원에서 낭비될 수 있었던 많은 시간을 절약하였다고 생각합니다. 그 친구는 다시 코드 리뷰를 요청하였고, 금방 팀 동료로부터 승인을 받을 수 있었습니다. 얼마 지나지 않아 그 친구가 테스트를 작성해야하는 이유에 대해서 일깨워줘서 고맙다는 메시지를 보내왔습니다. 알고보니 작년에 매니저로 부터 시니어 개발자가 되려면 성과가 더 많아야겠다는 피드백을 받았다네요. 그 이후로 초조해져서 테스트를 작성하는데 소홀해진 것 같다고 하네요. 그 친구가 터놓고 얘기를 해줘서 고마웠습니다. 다음 one-on-one 미팅에서는 quality를 희생하지 않고 speed를 올릴 수 있는 방법에 대해서 대화를 나누기로 했습니다. 여러분도 빡빡한 일정을 핑계로 테스트를 작성하지 않고 코드 리뷰를 요청하는 동료 개발자가 있으신가요? 테스트를 생략함으로써 개인 시간을 당장 얼마나 아낄 수 있는지, 그리고 나중에 다른 팀원들이 얼만큼의 시간을 지불해야하는지에 대해서 한번 꼭 열린 대화를 나누어 보셨으면 좋겠습니다. 😃

Linkedin

실리콘밸리 관련해서 종종 듣는 질문들 중에 다음과 같은 것들이 있다.

 * 실리콘밸리 개발자들은 얼마나 뛰어난가요?
 * 제가 가면 경쟁할 수 있나요?
   
   
과연 사람이 다른 걸까? 환경이 다른 걸까? 물론 실리콘밸리에는 세계각국에서 좋은 인재들이 몰려든다. 하지만 이 인재라는 정의에는 포함되는 중요한 포인트 하나는 "도전"하는 사람들이 온다는 점이다. 일단 그 부분을 인지하는 것이 중요하다. 지금 내가 사는 나라에서 부족함을 못 느끼거나 도전에 관심이 없는 사람이라면 굳이 모험을 하지 않는다.

한국에서 학사, 석사 마치고 5년 일하고 미국에서 24년째 일하고 있다. 지난 2년 동안 한국 회사("그렙")에서 일을 해보고 굉장히 많은 한국 개발자 및 IT 인력과 접점이 생기면서 어떤 부분이 다른지 좀더 이해하게 되었다. 한국에 계신 분들께 조금 아쉬운 부분들은 아래와 같은 포인트들인데 이건 개인이 가진 문제라기 보다는 사회 전반적인 아쉬움이라 생각된다. 결국은 나이에 관한 부담과 수능으로 제2의 천성이 되어버린 선행학습이 문제가 아닌가 싶다.

조금더 구체적으로 내가 느낀 아쉬움을 적어보면 아래와 같다. 이는 실리콘밸리에는 전혀 존재하지 않는 것들이라고 하면 거짓말이고 상대적으로 한국에서 더 많이 보인다는 거다.

 1. 기술 지향적 (전문성 트랩)
 2. 부캐에 관한 조바심
 3. 대기업에 관한 너무 큰 기대

하나씩 이야기해보자

기술 지향적 (전문성 트랩)

나에게 맞는 환경을 찾아 현재에 집중하기 보다는 전문성이라는 트랩에 빠져 본인이 맡은 일을 어떻게 잘 할까 고민하고 거기에 필요한 일을 학습하기 보다는 유행의 선두에 서서 새로 생기는 기술을 맹목적으로 알고 싶어한다. 이는 끝이 없기에 이 트랩에 빠지면 삶이 아주 고단해지고 항상 뒤쳐진다는 두려움과 조바심을 갖게 된다. 더 큰 문제는 뜨는 기술을 안다는 것이 내 커리어를 더 안전하게 만들고 행복하게 만들지 않는다는 점이다. 다른 사람들과 소통할 줄 알고 결과를 내고 좋은 평판을 만들고 영향력을 갖는 것이 내 커리어를 안전하게 만들고 행복하게 만드는 지름길 아닌 지름길이다.

부캐에 관한 조바심

SNS의 폐해가 아닌가 싶은데 나 빼고 모든 사람들이 뭔가 부캐를 하고 있고 본캐만 믿고 살면 미래가 너무 불안하다는 생각을 많이 한다. 커리어 초반에는 사실 부캐를 하고 싶어도 부캐를 할 경험치가 있기 힘들다. 정말 해보고 싶은 부캐가 있다면 그걸 본캐로 열심히 해보는 것이 맞지 않나 싶다. "질투", "시기", "부러움"은 가장 나쁜 감정이며 이는 비교로부터 시작한다. 이런 감정을 떨구기 쉽지 않고 이런 감정은 사실 실리콘밸리에 살면 더 심하게 드는 감정이기도 하지만 적어도 실리콘밸리에 부캐에 대한 열풍이 있다고 생각하지는 않는다.

대기업에 관한 너무 큰 기대

대기업을 가지 말라는 이야기가 아니다. 능력이 되면 가서 나에게 맞는지 판단하면 된다. 문제가 되는 부분은 마치 대기업을 가면 내 커리어가 완성될 꺼라 너무 큰 기대를 하는 거다. 기대가 크면 실망도 크다. 인생의 행복은 기대 관리다. 이는 사람에 대한 기대일 수도 있고 내가 하는 일에 대한 기대일 수도 있다. 긴 커리어에서 대기업이건 아주 작은 스타트업이건 내가 앞으로 다닐 10-20개 회사들 중의 하나일 뿐 그 이상도 그 이하도 아니다. 내 커리어를 완성시킬 수 있는 것은 나 자신이며 평정심과 꾸준함이 중요한 이유다.

요약하자면 개인이 갖고 있는 능력이 실리콘밸리에서 일하는 사람들이 더 뛰어나다고 생각하지 않는다. 다만 도전하는 사람들이 모이는 곳이며 실패를 인정하고 다양성을 존중하는 환경이다 보니 나이를 덜 생각하고 공부로 승부보기 보다는 행동으로 승부를 보려는 사람들이 많다는 점이 다를 뿐이다. 즉 환경이 다른 것이다.

혹시라도 내가 나이가 많다고 느껴지거나, 뭔가 문제가 생기면 공부를 통해 해결하겠다라는 생각이 먼저 든다면 그 부분을 이제부터 의식적으로 고쳐볼 필요가 있으며 이는 환경을 바꾸면 쉽게 변할 수 있는 부분이다.

관련 유튜브 영상을 만들었는데 댓글 참고

실리콘밸리 관련해서 종종 듣는 질문들 중에 다음과 같은 것들이 있다. <ul ><li>실리콘밸리 개발자들은 얼마나 뛰어난가요?</li><li>제가 가면 경쟁할 수 있나요? </li></ul>과연 사람이 다른 걸까? 환경이 다른 걸까? 물론 실리콘밸리에는 세계각국에서 좋은 인재들이 몰려든다. 하지만 이 인재라는 정의에는 포함되는 중요한 포인트 하나는 "도전"하는 사람들이 온다는 점이다. 일단 그 부분을 인지하는 것이 중요하다. 지금 내가 사는 나라에서 부족함을 못 느끼거나 도전에 관심이 없는 사람이라면 굳이 모험을 하지 않는다. 한국에서 학사, 석사 마치고 5년 일하고 미국에서 24년째 일하고 있다. 지난 2년 동안 한국 회사("그렙")에서 일을 해보고 굉장히 많은 한국 개발자 및 IT 인력과 접점이 생기면서 어떤 부분이 다른지 좀더 이해하게 되었다. 한국에 계신 분들께 조금 아쉬운 부분들은 아래와 같은 포인트들인데 이건 개인이 가진 문제라기 보다는 사회 전반적인 아쉬움이라 생각된다. 결국은 나이에 관한 부담과 수능으로 제2의 천성이 되어버린 선행학습이 문제가 아닌가 싶다. 조금더 구체적으로 내가 느낀 아쉬움을 적어보면 아래와 같다. 이는 실리콘밸리에는 전혀 존재하지 않는 것들이라고 하면 거짓말이고 상대적으로 한국에서 더 많이 보인다는 거다. <ol ><li>기술 지향적 (전문성 트랩)</li><li>부캐에 관한 조바심</li><li>대기업에 관한 너무 큰 기대</li></ol> 하나씩 이야기해보자 기술 지향적 (전문성 트랩) 나에게 맞는 환경을 찾아 현재에 집중하기 보다는 전문성이라는 트랩에 빠져 본인이 맡은 일을 어떻게 잘 할까 고민하고 거기에 필요한 일을 학습하기 보다는 유행의 선두에 서서 새로 생기는 기술을 맹목적으로 알고 싶어한다. 이는 끝이 없기에 이 트랩에 빠지면 삶이 아주 고단해지고 항상 뒤쳐진다는 두려움과 조바심을 갖게 된다. 더 큰 문제는 뜨는 기술을 안다는 것이 내 커리어를 더 안전하게 만들고 행복하게 만들지 않는다는 점이다. 다른 사람들과 소통할 줄 알고 결과를 내고 좋은 평판을 만들고 영향력을 갖는 것이 내 커리어를 안전하게 만들고 행복하게 만드는 지름길 아닌 지름길이다. 부캐에 관한 조바심 SNS의 폐해가 아닌가 싶은데 나 빼고 모든 사람들이 뭔가 부캐를 하고 있고 본캐만 믿고 살면 미래가 너무 불안하다는 생각을 많이 한다. 커리어 초반에는 사실 부캐를 하고 싶어도 부캐를 할 경험치가 있기 힘들다. 정말 해보고 싶은 부캐가 있다면 그걸 본캐로 열심히 해보는 것이 맞지 않나 싶다. "질투", "시기", "부러움"은 가장 나쁜 감정이며 이는 비교로부터 시작한다. 이런 감정을 떨구기 쉽지 않고 이런 감정은 사실 실리콘밸리에 살면 더 심하게 드는 감정이기도 하지만 적어도 실리콘밸리에 부캐에 대한 열풍이 있다고 생각하지는 않는다. 대기업에 관한 너무 큰 기대 대기업을 가지 말라는 이야기가 아니다. 능력이 되면 가서 나에게 맞는지 판단하면 된다. 문제가 되는 부분은 마치 대기업을 가면 내 커리어가 완성될 꺼라 너무 큰 기대를 하는 거다. 기대가 크면 실망도 크다. 인생의 행복은 기대 관리다. 이는 사람에 대한 기대일 수도 있고 내가 하는 일에 대한 기대일 수도 있다. 긴 커리어에서 대기업이건 아주 작은 스타트업이건 내가 앞으로 다닐 10-20개 회사들 중의 하나일 뿐 그 이상도 그 이하도 아니다. 내 커리어를 완성시킬 수 있는 것은 나 자신이며 평정심과 꾸준함이 중요한 이유다. 요약하자면 개인이 갖고 있는 능력이 실리콘밸리에서 일하는 사람들이 더 뛰어나다고 생각하지 않는다. 다만 도전하는 사람들이 모이는 곳이며 실패를 인정하고 다양성을 존중하는 환경이다 보니 나이를 덜 생각하고 공부로 승부보기 보다는 행동으로 승부를 보려는 사람들이 많다는 점이 다를 뿐이다. 즉 환경이 다른 것이다. 혹시라도 내가 나이가 많다고 느껴지거나, 뭔가 문제가 생기면 공부를 통해 해결하겠다라는 생각이 먼저 든다면 그 부분을 이제부터 의식적으로 고쳐볼 필요가 있으며 이는 환경을 바꾸면 쉽게 변할 수 있는 부분이다. 관련 유튜브 영상을 만들었는데 댓글 참고

실리콘밸리 개발자 vs. 한국 개발자

인프런이 만드는 IT인의 축제, 인프콘에 초대합니다

인프콘 2024 - INFCON 2024

1. INFCON
- https://www.inflearn.com/conf/infcon-2024/
- ‘인프런’에서 주최하는 IT 컨퍼런스. 개발자, PM/PO, 디자이너 분야 등
- 2024년 8월 2일(금)
- 유료 / 참가 신청 마감. 추후 인프콘 다시보기 서비스 제공 예정

2. UbuCon Korea 2024
- https://2024.ubuntu-kr.org/ko/
- Ubuntu 코리아 컨퍼런스
- 2024년 8월 10일(토)
- 유료

3. FEConf24
- https://2024.feconf.kr/
- 국내 최대 프론트엔드 컨퍼런스
- 2024년 8월 24일(토)
- 유료

4. Kubernetes Korea Community Day 2024
- https://kcd-korea.net/
- 쿠버네티스에서 주최하는 국내 클라우드 네이티브 기술 컨퍼런스
- 2024년 9월 24일(화)
- 유료

5. OpenInfra Summit Asia 2024
- https://2024.openinfraasia.org/
- 클라우드 네이티브 오픈소스 기술 재단 ‘오픈인프라’ 컨퍼런스
- 2024년 9월 3일(화) ~ 9월 4일(수)
- 유료

6. KWDC 2024
- https://kwdc.dev/2024/
- 국내 애플 개발자 커뮤니티 3곳이 주최하는 한국 Apple 생태계 컨퍼런스
- 2024년 10월 24일(목)
- 유료

7. PyCon KR 2024
- https://2024.pycon.kr/
- 세계 각국의 파이썬 프로그래밍 언어 커뮤니티에서 주관하는 컨퍼런스
- 2024년 10월 25일(금) ~ 10월 27일(일)
- 유료

8. DebConf24
- https://debconf24.debconf.org/
- 데비안 운영체제, 소프트웨어 개발과 관련한 세미나
- 2024년 7월 28일(일) ~ 8월 4일(일)
- 유·무료(일반 무료, 전문가/기업 유료)

9. GopherCon Korea 2024
- https://festa.io/events/5098
- 한국의 Go 언어 사용자 모임 커뮤니티에서 주최하는 컨퍼런스
- 2024년 10월 12일(토) ~ 10월 13일(일)
- 유료

해외 컨퍼런스
1. GitHub Universe 2024
- https://githubuniverse.com/
- 2024년 10월 29일(화) ~ 10월 30일(수) / 미국 샌프란시스코
- 유료 / 온라인 라이브 스트리밍 무료

2. KubeCon + CloudNativeCon North America
- https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/
- 2024년 11월 12일(화) ~ 11월 15일(금) / 미국 유타주 솔트레이크시티
- 유료 / 키노트 라이브 스트리밍 무료

3. AWS re:Invent 2024
- https://reinvent.awsevents.com/
- 2024년 12월 2일(월) ~ 12월 6일(금) / 미국 라스베가스
- 유료 / 온라인 라이브 스트리밍 무료

1. INFCON- https://www.inflearn.com/conf/infcon-2024/- ‘인프런’에서 주최하는 IT 컨퍼런스. 개발자, PM/PO, 디자이너 분야 등- 2024년 8월 2일(금)- 유료 / 참가 신청 마감. 추후 인프콘 다시보기 서비스 제공 예정 2. UbuCon Korea 2024- https://2024.ubuntu-kr.org/ko/- Ubuntu 코리아 컨퍼런스- 2024년 8월 10일(토)- 유료 3. FEConf24- https://2024.feconf.kr/- 국내 최대 프론트엔드 컨퍼런스- 2024년 8월 24일(토)- 유료 4. Kubernetes Korea Community Day 2024- https://kcd-korea.net/- 쿠버네티스에서 주최하는 국내 클라우드 네이티브 기술 컨퍼런스- 2024년 9월 24일(화)- 유료 5. OpenInfra Summit Asia 2024- https://2024.openinfraasia.org/- 클라우드 네이티브 오픈소스 기술 재단 ‘오픈인프라’ 컨퍼런스- 2024년 9월 3일(화) ~ 9월 4일(수)- 유료 6. KWDC 2024- https://kwdc.dev/2024/- 국내 애플 개발자 커뮤니티 3곳이 주최하는 한국 Apple 생태계 컨퍼런스- 2024년 10월 24일(목)- 유료 7. PyCon KR 2024- https://2024.pycon.kr/- 세계 각국의 파이썬 프로그래밍 언어 커뮤니티에서 주관하는 컨퍼런스- 2024년 10월 25일(금) ~ 10월 27일(일)- 유료 8. DebConf24- https://debconf24.debconf.org/- 데비안 운영체제, 소프트웨어 개발과 관련한 세미나- 2024년 7월 28일(일) ~ 8월 4일(일)- 유·무료(일반 무료, 전문가/기업 유료) 9. GopherCon Korea 2024- https://festa.io/events/5098- 한국의 Go 언어 사용자 모임 커뮤니티에서 주최하는 컨퍼런스- 2024년 10월 12일(토) ~ 10월 13일(일)- 유료 해외 컨퍼런스1. GitHub Universe 2024- https://githubuniverse.com/- 2024년 10월 29일(화) ~ 10월 30일(수) / 미국 샌프란시스코- 유료 / 온라인 라이브 스트리밍 무료 2. KubeCon + CloudNativeCon North America- https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/- 2024년 11월 12일(화) ~ 11월 15일(금) / 미국 유타주 솔트레이크시티- 유료 / 키노트 라이브 스트리밍 무료 3. AWS re:Invent 2024- https://reinvent.awsevents.com/- 2024년 12월 2일(월) ~ 12월 6일(금) / 미국 라스베가스- 유료 / 온라인 라이브 스트리밍 무료

인프런

2024 하반기 IT 컨퍼런스

이력서는 중요합니다.
면접관에게는 지원자를 파악하기 위한 첫번째 장소이기 때문입니다.

이런 이력서 작성을 편리하게 도와주는 사이트가 있어서 소개드립니다.
resumemaker.online 인데요.

기존에 작성한 이력서가 있다면 업로드해서 AI가 초안을 작성해주기도 합니다.
컬러나 템플릿등을 설정할 수 도 있고, 꽤 정돈된 형태로 이력서가 나오게 됩니다.

한가지 단점은 한글 폰트를 지원하지 않습니다.
그래도 이력서 작성을 별로 해보시지 않았다면 툴의 도움을 받아서 채워보시는
것도 좋을 것 같습니다.

제가 기존에 써둔 이력서를 업로드 해서 만들어봤는데 퀄리티가 나쁘지 않네요.

이력서는 중요합니다.면접관에게는 지원자를 파악하기 위한 첫번째 장소이기 때문입니다. 이런 이력서 작성을 편리하게 도와주는 사이트가 있어서 소개드립니다.resumemaker.online 인데요. 기존에 작성한 이력서가 있다면 업로드해서 AI가 초안을 작성해주기도 합니다.컬러나 템플릿등을 설정할 수 도 있고, 꽤 정돈된 형태로 이력서가 나오게 됩니다. 한가지 단점은 한글 폰트를 지원하지 않습니다.그래도 이력서 작성을 별로 해보시지 않았다면 툴의 도움을 받아서 채워보시는것도 좋을 것 같습니다. 제가 기존에 써둔 이력서를 업로드 해서 만들어봤는데 퀄리티가 나쁘지 않네요.

이력서를 편하게 만듭시다 - resumemaker

I finally have the feeling that I&rsquo;m a decent programmer, so I thought it would be fun to write some advice with the idea of &ldquo;what would have gotten me to this point faster?&rdquo; I&rsquo;m not claiming this is great advice for everyone, just 

Marcus' Blog


한 개발자가 과거의 나에게 개발자로써 조언을 해준다면? 에 대해 작성해주신 글입니다.
몇 가지는 직접적으로 저에게 도움이 되는 부분도 있어, 일부 저에게 도움되는 부분만 요약해서 공유드립니다.

🤔 계속 발에 총을 쏘고 있다면, 총을 고쳐야한다.
팀에서 시스템에 대해 자주 실수 하는 부분이 있지만, 그 실수를 줄일 방법에 대해 생각하지 않는 경우가 많습니다. 이런 경우 시스템을 개선하여 실수를 줄이는 것이 중요합니다.
이러한 문제들은 해결할 자연스러운 시기가 없었기에 오래 지속되는 경우가 많으니, 생각보다 몇 분 동안만 고민하면 해결 할 수 있는게 많습니다. 이런 문제가 있을 때 자신과 팀의 삶을 더 쉽게 만들 수 있다는 것을 상기시키고 마음가짐을 갖는게 중요합니다.

🪠 품질과 속도 사이의 균형을 맞춰야한다.
구현 속도와 정확성에 대한 자신감 사이에는 항상 트레이드오프가 존재합니다. 현재 상황에서 버그를 출시하는 것이 얼마나 괜찮은지 자문해보고, 이에 대한 답변이 작업 방식에 영향을 미치지 않는다면 지나치게 경직된 것으로 생각하세요.

🪭 톱을 갈고 있는 시간은 거의 항상 가치가 있는 시간이다.
도구를 잘 다루는 것이 중요합니다. 코드를 빠르게 작성하고, 주요 단축키를 알고, 운영체제와 셀에 능숙해야 합니다. 새로운 엔지니어에게서 보이는 가장 큰 그린 플래그 중 하나는 도구 선택과 능숙한 사용에 대한 관심입니다.

🧘🏻‍♂️버그를 한 층 더 깊이 해결하려고 노력해야 한다.
버그를 표면적으로 해결하는 대신, 근본적인 원인을 찾아 해결하는 것이 중요합니다. 최대한 어떤 컴포넌트도 이 버그를 다시 겪지 않도록 해결하려고 노력해보세요.

🏃🏻‍♀️ 버그 조사 시 히스토리를 활용해야 한다.
이상한 버그를 조사할 때, git 히스토리를 활용하는 것이 중요합니다. 예를 들어 메모리 누수 문제를 조사할 때, 특정 커밋 이후에 문제가 발생한 경우가 많으니 참고하세요.

🎆 가끔은 나쁜 코드로 작성하는 쪽으로 오류를 범해봐라.
끔찍한 코드를 작성하는 것도 쉽고, 모든 모범사례를 절대적으로 따르는 코드를 작성하는 것도 정말 쉽습니다. 하지만 이런 코드 작성은 스타트업에 돈이 바닥 날 가능성이 큽니다.
또한 빨리 코드를 작성하게 되면 추후 나쁜 기술 부채로 인해 곤란을 겪게 될 수도 있습니다.
'나쁜' 코드의 의미를 명확하게 하고, 시간과 노력의 균형을 찾아 코드를 작성해보세요.

🏋️ 디버깅 하기 쉽게 만들어야 한다.
디버깅을 쉽게 하기 위한 노력을 하지 않으면, 소프트웨어가 점점 더 복잡해짐에 따라 각 이슈를 디버깅 하는데 엄청난 시간을 소비하게 될 것 입니다. 그렇게 되면 결국 변경 하는 것이 두려워지게 됩니다. 디버깅 시간 중 설정, 재현, 사후 정리에 소요되는 시간을 추적하는 데 주의를 기울이세요.

💁‍♂️ 팀에서 일할 때는 보통 질문을 해야 한다.
경력 초반자들은 '사소한 질문으로 동료를 귀찮게 하는 것' 보다 '모든 것을 스스로 알아내려고 노력하는 것'에 너무 치우쳐 있습니다. 한 시간 넘게 무언가를 알아내기 위해 시간을 허비하지말고 몇 분 만에 답을 찾을 수 있게 항상 질문하세요. 누군가에게 귀찮은 경우는 몇 분 안에 스스로 답을 찾을 수 있었다는 것이 분명할 때 뿐입니다.

👁️ 배포 주기는 매우 중요, 빠르고 자주 배포할 수 있는 방법 고민 필요
프로젝트 배포 속도는 시간이 지남에 따라 복리로 증가해서, 상상할 수 있는 것보다 빠르게 기능을 배포할 수 있게 됩니다. 스타트업은 런웨이가 제한적이고, 프로젝트에는 마감일이 항상 있으니 빠르게 배포하기 위해 여러가지 시도를 해보세요.

한 개발자가 과거의 나에게 개발자로써 조언을 해준다면? 에 대해 작성해주신 글입니다. 몇 가지는 직접적으로 저에게 도움이 되는 부분도 있어, 일부 저에게 도움되는 부분만 요약해서 공유드립니다. 🤔 계속 발에 총을 쏘고 있다면, 총을 고쳐야한다. 팀에서 시스템에 대해 자주 실수 하는 부분이 있지만, 그 실수를 줄일 방법에 대해 생각하지 않는 경우가 많습니다. 이런 경우 시스템을 개선하여 실수를 줄이는 것이 중요합니다. 이러한 문제들은 해결할 자연스러운 시기가 없었기에 오래 지속되는 경우가 많으니, 생각보다 몇 분 동안만 고민하면 해결 할 수 있는게 많습니다. 이런 문제가 있을 때 자신과 팀의 삶을 더 쉽게 만들 수 있다는 것을 상기시키고 마음가짐을 갖는게 중요합니다. 🪠 품질과 속도 사이의 균형을 맞춰야한다.구현 속도와 정확성에 대한 자신감 사이에는 항상 트레이드오프가 존재합니다. 현재 상황에서 버그를 출시하는 것이 얼마나 괜찮은지 자문해보고, 이에 대한 답변이 작업 방식에 영향을 미치지 않는다면 지나치게 경직된 것으로 생각하세요. 🪭 톱을 갈고 있는 시간은 거의 항상 가치가 있는 시간이다.도구를 잘 다루는 것이 중요합니다. 코드를 빠르게 작성하고, 주요 단축키를 알고, 운영체제와 셀에 능숙해야 합니다. 새로운 엔지니어에게서 보이는 가장 큰 그린 플래그 중 하나는 도구 선택과 능숙한 사용에 대한 관심입니다. 🧘🏻‍♂️버그를 한 층 더 깊이 해결하려고 노력해야 한다.버그를 표면적으로 해결하는 대신, 근본적인 원인을 찾아 해결하는 것이 중요합니다. 최대한 어떤 컴포넌트도 이 버그를 다시 겪지 않도록 해결하려고 노력해보세요. 🏃🏻‍♀️ 버그 조사 시 히스토리를 활용해야 한다.이상한 버그를 조사할 때, git 히스토리를 활용하는 것이 중요합니다. 예를 들어 메모리 누수 문제를 조사할 때, 특정 커밋 이후에 문제가 발생한 경우가 많으니 참고하세요. 🎆 가끔은 나쁜 코드로 작성하는 쪽으로 오류를 범해봐라.끔찍한 코드를 작성하는 것도 쉽고, 모든 모범사례를 절대적으로 따르는 코드를 작성하는 것도 정말 쉽습니다. 하지만 이런 코드 작성은 스타트업에 돈이 바닥 날 가능성이 큽니다. 또한 빨리 코드를 작성하게 되면 추후 나쁜 기술 부채로 인해 곤란을 겪게 될 수도 있습니다.'나쁜' 코드의 의미를 명확하게 하고, 시간과 노력의 균형을 찾아 코드를 작성해보세요. 🏋️ 디버깅 하기 쉽게 만들어야 한다.디버깅을 쉽게 하기 위한 노력을 하지 않으면, 소프트웨어가 점점 더 복잡해짐에 따라 각 이슈를 디버깅 하는데 엄청난 시간을 소비하게 될 것 입니다. 그렇게 되면 결국 변경 하는 것이 두려워지게 됩니다. 디버깅 시간 중 설정, 재현, 사후 정리에 소요되는 시간을 추적하는 데 주의를 기울이세요. 💁‍♂️ 팀에서 일할 때는 보통 질문을 해야 한다.경력 초반자들은 '사소한 질문으로 동료를 귀찮게 하는 것' 보다 '모든 것을 스스로 알아내려고 노력하는 것'에 너무 치우쳐 있습니다. 한 시간 넘게 무언가를 알아내기 위해 시간을 허비하지말고 몇 분 만에 답을 찾을 수 있게 항상 질문하세요. 누군가에게 귀찮은 경우는 몇 분 안에 스스로 답을 찾을 수 있었다는 것이 분명할 때 뿐입니다. 👁️ 배포 주기는 매우 중요, 빠르고 자주 배포할 수 있는 방법 고민 필요프로젝트 배포 속도는 시간이 지남에 따라 복리로 증가해서, 상상할 수 있는 것보다 빠르게 기능을 배포할 수 있게 됩니다. 스타트업은 런웨이가 제한적이고, 프로젝트에는 마감일이 항상 있으니 빠르게 배포하기 위해 여러가지 시도를 해보세요.

mbuffett.com

15년 전 나에게 해주고 싶은 프로그래밍 조언

컴퓨터 공부를 처음 시작한 날이 2004년 8월 25일. 이제 20년이 지났습니다.

죽을 만큼 힘든 날은 없었다

컴퓨터 공부를 처음 시작한 날이 2004년 8월 25일.
이제 20년이 지났습니다.

돌아보면 그렇게 쉽진 않았지만 또 그렇게 어렵지도 않았던 것 같습니다.

매일 조금씩 힘들고 피곤하긴 했지만..
죽을 만큼 힘들다고 생각해 본 날은 없습니다.

마라톤 금메달리스트 황영조 선수가 훈련 중에 자동차가 지나가면 그 바퀴 밑으로 뛰어들어 죽고 싶었다고 말했던 걸 기억합니다. 도대체 어느 정도 힘들어야 죽어버리는 게 낫겠다는 생각을 할 수 있을까?

저에게는 그런 날은 하루도 없었던 것입니다.
이 정도면 뭐 할만한 것 아닌가?

죽을 만큼 힘들게 훈련하진 않더라도,
(그렇게 해야 세계 챔피언이 될 수 있나 봅니다)
적당한 훈련을 매일 오랫동안 해나가면 인생을 편안하게 살 만큼의 성취 정도는 이룰 수 있다는 걸 나중에야 알게 됐습니다.
왜냐면 그것조차 할 수 있는 사람이 별로 없으니까.

이걸 알고 나서 마음이 참 편해졌습니다.
난 분명히 잘될 거야.
더 즐기면서 일할 수 있게 되었습니다.

https://jeho.page/essay/2024/07/17/not-easy-but-not-hard-either.html

컴퓨터 공부를 처음 시작한 날이 2004년 8월 25일. 이제 20년이 지났습니다. 돌아보면 그렇게 쉽진 않았지만 또 그렇게 어렵지도 않았던 것 같습니다. 매일 조금씩 힘들고 피곤하긴 했지만.. 죽을 만큼 힘들다고 생각해 본 날은 없습니다. 마라톤 금메달리스트 황영조 선수가 훈련 중에 자동차가 지나가면 그 바퀴 밑으로 뛰어들어 죽고 싶었다고 말했던 걸 기억합니다. 도대체 어느 정도 힘들어야 죽어버리는 게 낫겠다는 생각을 할 수 있을까? 저에게는 그런 날은 하루도 없었던 것입니다. 이 정도면 뭐 할만한 것 아닌가? 죽을 만큼 힘들게 훈련하진 않더라도, (그렇게 해야 세계 챔피언이 될 수 있나 봅니다) 적당한 훈련을 매일 오랫동안 해나가면 인생을 편안하게 살 만큼의 성취 정도는 이룰 수 있다는 걸 나중에야 알게 됐습니다. 왜냐면 그것조차 할 수 있는 사람이 별로 없으니까. 이걸 알고 나서 마음이 참 편해졌습니다. 난 분명히 잘될 거야. 더 즐기면서 일할 수 있게 되었습니다. https://jeho.page/essay/2024/07/17/not-easy-but-not-hard-either.html

K리그 프로그래머

회계는 지난 수백 년 동안 크게 변하지 않았음그럼에도 불구하고, 금융 시스템을 위한 소프트웨어를 구축하는 올바른 방법에 대해 많은 혼란이 있음이 글에서는 대기업에서 금융 시스템을 구축한 경험을 바탕으로 한 교훈을 공유회계 시스템 구축에 초점을 맞추겠지만, 이 원칙들은 더 일반적인 금융 시스템에도 적용됨기본 금융 용어 정의일반 원장 (General Ledge

금융 시스템 구축을 위한 엔지니어링 원칙 | GeekNews

예전에 회계 시스템 만들때, "아 정말 나는 금융을 하나도 모르는 구나" 하면서 참 고생했던 기억이 있습니다.

숫자 계산을 좋아하는 개발자들이지만, 역사가 긴 금융, 회계 시스템, 환율, 정책, 원리에 대해서 이해하지 않으면 설계에서부터 시작해서, 멱등성 유지, 트랜잭션 등 자칫 고려하지 못하면 큰일 나는 구석들도 많은 아주 흥미로우면서 후덜덜한 영역일 것 같습니다.

news.hada.io/topic?id=15794

블로그 글 뿐만 아니라 저도 설계에 도움 많이 받았던 글들 공유드려봅니다!

 * Martin Fowler - Accounting Patterns : https://martinfowler.com/apsupp/accounting.pdf
   
 * 실제 서비스 API로 만들면 이런 모양이 될꺼다!로 제일 참고하기 좋았던 Twisp Doc (GraphQL) : https://t.co/m78EFpYX7w

예전에 회계 시스템 만들때, "아 정말 나는 금융을 하나도 모르는 구나" 하면서 참 고생했던 기억이 있습니다. 숫자 계산을 좋아하는 개발자들이지만, 역사가 긴 금융, 회계 시스템, 환율, 정책, 원리에 대해서 이해하지 않으면 설계에서부터 시작해서, 멱등성 유지, 트랜잭션 등 자칫 고려하지 못하면 큰일 나는 구석들도 많은 아주 흥미로우면서 후덜덜한 영역일 것 같습니다. news.hada.io/topic?id=15794 블로그 글 뿐만 아니라 저도 설계에 도움 많이 받았던 글들 공유드려봅니다! <ul ><li>Martin Fowler - Accounting Patterns : https://martinfowler.com/apsupp/accounting.pdf </li><li>실제 서비스 API로 만들면 이런 모양이 될꺼다!로 제일 참고하기 좋았던 Twisp Doc (GraphQL) : https://t.co/m78EFpYX7w </li></ul>

GeekNews

금융 시스템 구축을 위한 엔지니어링 원칙

테스트 코드는 왜 써야 할까요? 테스트 코드가 가져오는 베네핏들에는 어떤 것이 있을까요?

모닥불 | EP.3 프론트엔드 개발에서 테스트 자동화, 꼭 해야 할까?

프론트엔드 개발 영역에서 테스트 코드의 필요성은 지속적인 논의의 대상입니다. 사용자 인터페이스와 직접적으로 연결되는 프론트엔드 코드의 특성상, 빈번하고 다양한 변화에 직면하게 되기 때문인데요. 이러한 환경에서 개발자들은 때때로 시간적 제약으로 인해 테스트 코드 작성을 생략하고 즉각적인 개발에 집중하게 되는데요. 이는 단기적으로 생산성 향상으로 느껴질 수 있습니다.
그러나 이러한 접근은 '단기적 효율'과 '장기적 지속가능성' 사이의 균형에 대한 문제를 제기합니다. 테스트 코드 없이 진행되는 개발이 당장은 빠른 결과물 도출로 이어질 수 있지만, 장기적 관점에서는 오히려 생산성 저하와 품질 문제로 이어질 수 있기 때문인데요.
그렇다면 테스트 코드가 어떻게 장기적인 생산성 향상에 기여하는 것일까요? 다음은 테스트 코드가 가져다주는 주요 이점들입니다:
 1. 신속한 피드백 루프: 테스트 코드는 개발자가 변경사항을 즉각적으로 검증할 수 있게 해줍니다. 이는 수동 테스트 과정을 최소화하고, 버그를 조기에 발견하여 수정 비용을 절감시킵니다.
 2. 리팩토링 자신감: 잘 작성된 테스트 코드는 개발자에게 코드 개선에 대한 자신감을 부여합니다. 기존 기능의 정상 작동을 보장하면서 새로운 기능을 추가하거나 라이브러리 업데이트를 할 수 있습니다.
 3. 문서화 효과: 테스트 코드는 실행 가능한 명세서 역할을 합니다. 특히 빠르게 변화하는 스타트업 환경에서, 테스트 코드는 최신 상태의 신뢰할 수 있는 문서가 됩니다.

그렇다면 테스트 코드는 어떻게 작성해야 할까요? 아마 많은 개발자 분들이 실질적으로 궁금해하는 내용일텐데요. 전통적인 테스트 피라미드 접근법은 유닛 테스트를 기반으로, 통합 테스트, 그리고 E2E(End-to-End) 테스트 순으로 구성됩니다. 그러나 실제 개발 에서는 이론과 실제 적용 사이의 간극이 존재하기 마련인데요. 토스의 테스트 전략은 아래와 같은 개념 으로 구성되어 있습니다:
 1. 전략적 선별: 복잡성이 높고 비즈니스에 중요한 기능에 테스트 역량을 집중합니다. 단순한 UI 요소보다는 핵심 비즈니스 로직과 주요 사용자 시나리오에 초점을 맞춤으로써, 테스트의 투자 대비 생산성을 극대화합니다.
 2. 통합 테스트 중심 접근: 페이지 단위의 통합 테스트로 실제 사용자 경험에 더 가까운 테스트 시나리오를 구성합니다. 이러한 방식은 개별 컴포넌트의 기능성뿐만 아니라, 상호작용하여 전체 시스템을 구성하는지 검증할 수 있게 해줍니다.
 3. 생산성과 효율성의 균형: 너무 단순한 테스트는 작성하지 않습니다. 예를 들어, 즉시 확인 가능한 단순 UI 변경사항에 대해서는 별도의 자동화된 테스트를 작성하지 않습니다.

결론적으로, 토스의 프론트엔드 테스트는 기존의 이론적 모델을 맹목적으로 따르기보다는 실질적인 가치를 제공하는 방향으로 접근하고 있습니다. 통합테스트 중심의 실용적 접근을 통해 개발 생산성과 품질 사이의 적절한 균형을 맞추는게 인상적이었습니다.

https://toss.tech/article/firesidechat_frontend_3

프론트엔드 개발 영역에서 테스트 코드의 필요성은 지속적인 논의의 대상입니다. 사용자 인터페이스와 직접적으로 연결되는 프론트엔드 코드의 특성상, 빈번하고 다양한 변화에 직면하게 되기 때문인데요. 이러한 환경에서 개발자들은 때때로 시간적 제약으로 인해 테스트 코드 작성을 생략하고 즉각적인 개발에 집중하게 되는데요. 이는 단기적으로 생산성 향상으로 느껴질 수 있습니다.그러나 이러한 접근은 '단기적 효율'과 '장기적 지속가능성' 사이의 균형에 대한 문제를 제기합니다. 테스트 코드 없이 진행되는 개발이 당장은 빠른 결과물 도출로 이어질 수 있지만, 장기적 관점에서는 오히려 생산성 저하와 품질 문제로 이어질 수 있기 때문인데요.그렇다면 테스트 코드가 어떻게 장기적인 생산성 향상에 기여하는 것일까요? 다음은 테스트 코드가 가져다주는 주요 이점들입니다:<ol ><li>신속한 피드백 루프: 테스트 코드는 개발자가 변경사항을 즉각적으로 검증할 수 있게 해줍니다. 이는 수동 테스트 과정을 최소화하고, 버그를 조기에 발견하여 수정 비용을 절감시킵니다.</li><li>리팩토링 자신감: 잘 작성된 테스트 코드는 개발자에게 코드 개선에 대한 자신감을 부여합니다. 기존 기능의 정상 작동을 보장하면서 새로운 기능을 추가하거나 라이브러리 업데이트를 할 수 있습니다.</li><li>문서화 효과: 테스트 코드는 실행 가능한 명세서 역할을 합니다. 특히 빠르게 변화하는 스타트업 환경에서, 테스트 코드는 최신 상태의 신뢰할 수 있는 문서가 됩니다.</li></ol> 그렇다면 테스트 코드는 어떻게 작성해야 할까요? 아마 많은 개발자 분들이 실질적으로 궁금해하는 내용일텐데요. 전통적인 테스트 피라미드 접근법은 유닛 테스트를 기반으로, 통합 테스트, 그리고 E2E(End-to-End) 테스트 순으로 구성됩니다. 그러나 실제 개발 에서는 이론과 실제 적용 사이의 간극이 존재하기 마련인데요. 토스의 테스트 전략은 아래와 같은 개념 으로 구성되어 있습니다:<ol ><li>전략적 선별: 복잡성이 높고 비즈니스에 중요한 기능에 테스트 역량을 집중합니다. 단순한 UI 요소보다는 핵심 비즈니스 로직과 주요 사용자 시나리오에 초점을 맞춤으로써, 테스트의 투자 대비 생산성을 극대화합니다.</li><li>통합 테스트 중심 접근: 페이지 단위의 통합 테스트로 실제 사용자 경험에 더 가까운 테스트 시나리오를 구성합니다. 이러한 방식은 개별 컴포넌트의 기능성뿐만 아니라, 상호작용하여 전체 시스템을 구성하는지 검증할 수 있게 해줍니다.</li><li>생산성과 효율성의 균형: 너무 단순한 테스트는 작성하지 않습니다. 예를 들어, 즉시 확인 가능한 단순 UI 변경사항에 대해서는 별도의 자동화된 테스트를 작성하지 않습니다.</li></ol> 결론적으로, 토스의 프론트엔드 테스트는 기존의 이론적 모델을 맹목적으로 따르기보다는 실질적인 가치를 제공하는 방향으로 접근하고 있습니다. 통합테스트 중심의 실용적 접근을 통해 개발 생산성과 품질 사이의 적절한 균형을 맞추는게 인상적이었습니다. https://toss.tech/article/firesidechat_frontend_3

Toss

변화하는 UI, 변하지 않는 품질: 토스의 프론트엔드 테스트 전략

원문 : https&#x3A;//dev.to/yoskutik/extremely-reducing-the-size-of-npm-package-3420

[번역] NPM 패키지 크기 대폭 축소하기

오늘 소개해드릴 글은 라인플러스의 손수림님이 번역해주신 글입니다.

이 글에서는 테스트 커버리지, 문서 작성, 유효한 버전 관리, 변경 로그 관리 등 패키지 개발의 다양한 측면을 다루고 있으며 특히 패키지의 크기를 최소화하는 방법에 초점을 맞추고 있습니다.

글은 크게 두 가지 부분로 나뉘어지며 첫 번째 부분에서는 의존성 설정과 빌드 프로세스와 같은 일반적인 팁을, 두 번째 부분에서는 개발자 경험(DX)을 약간 희생하면서도 패키지 크기를 더 작게 만드는 구체적인 코드 작성 방법을 설명합니다.

각종 최적화 팁과 더불어 코드 예제와 설명이 포함되어 있어 패키지 배포에 관심이 있으신 분들은 가볍게 읽어보시는 것을 추천드립니다. :)

> 글 링크 : https://velog.io/@surim014/extremely-reducing-the-size-of-npm-packages

오늘 소개해드릴 글은 라인플러스의 손수림님이 번역해주신 글입니다. 이 글에서는 테스트 커버리지, 문서 작성, 유효한 버전 관리, 변경 로그 관리 등 패키지 개발의 다양한 측면을 다루고 있으며 특히 패키지의 크기를 최소화하는 방법에 초점을 맞추고 있습니다. 글은 크게 두 가지 부분로 나뉘어지며 첫 번째 부분에서는 의존성 설정과 빌드 프로세스와 같은 일반적인 팁을, 두 번째 부분에서는 개발자 경험(DX)을 약간 희생하면서도 패키지 크기를 더 작게 만드는 구체적인 코드 작성 방법을 설명합니다. 각종 최적화 팁과 더불어 코드 예제와 설명이 포함되어 있어 패키지 배포에 관심이 있으신 분들은 가볍게 읽어보시는 것을 추천드립니다. :) &gt; 글 링크 : https://velog.io/@surim014/extremely-reducing-the-size-of-npm-packages

Velog

NPM 패키지 크기 대폭 축소하기

테니스 황제라고 불리는 로저 페더러의 최근 다트머스 졸업 연설. 모든 내용 하나하나가 주옥같았다. 일등 하는 사람들은 항상 배울 것이 있다. 그것도 전 세계 1등이니까. 그 사람이 거기까지 가는 데 있어서 내면적으로 겪은 경험들은... 아주 값진 지혜들을 담고 있다. 모든 내용들이 다 좋았지만, 나는 캡처한 부분이 제일 좋았다.

로저 페더러 다트머스 졸업연설

테니스 황제라고 불리는 로저 페더러의 최근 다트머스 졸업 연설이 인상적이다. 그가 이제 대학을 졸업하고 사회로 나가는 졸업생들과 나눈 세 가지 메시지에 내 생각을 얹어본다.

1) Effortless is a myth. (공짜는 없다)
우린 모두 타고난 각자의 재능이 있다. 기가 막힌 음색을 가지고 태어난 사람도 있고, 숫자에 능한 사람도 있고, 동물적으로 운동감각이 뛰어난 사람도 있다. 성공하려면 타고난 재능을 가지고 있어야 한다는 말도 맞을지 모르겠다. 그래서일까? 우리는 종종 성공한 사람들을 보며 타고난 재능이라고 치부해 버리기도 하고, 쉽게 해내는 (것처럼 보이는) 결과물을 보며 그 자리까지 가기 위해 흘린 피 땀 눈물을 외면해 버리기도 한다.

로저 페더러는 자신이 테니스 선수에게 필요한 재능을 타고났음을 인정하면서(타고난 재능을 커리어와 연결시키는 건 매우 중요하다), 타고난 재능만으로는 성공할 수 없음을 강조한다. "Believe in yourself has to be earned."라며 자신에 대한 믿음은 경기를 승리로 이끄는데 꼭 필요한 재능인데, 이는 타고난 재능이 아니라 각고의 노력으로 얻어내야 하는 재능이라고 말한다. 인내심과 끈기, 과정을 즐길 수 있는 여유, 자기 관리... 이 모든 게 치열한 자신과의 싸움으로 만들어낸 재능이라는 것이다. 나는 개인적으로 "to be earned"라는 말을 좋아한다. 우리의 성공이 타고난 재능으로 결정된다면 억울하고 재미없는 삶이 되겠지만, 내가 노력해서 얻어낸 재능으로 성공을 만들 수 있다면 살아볼 만한 인생이라는 에너지가 생긴다.

나는 최근 일적으로 폭풍 속을 걷는 것 같은 시기를 보내고 있는데, 자기 확신, 회복력, 긍정적 마인드 이 세 재능을 바닥내지 않고 든든하게 키우기 위해 노력 중이다. 새로운 프로젝트를 리딩하고 팀을 매니징하고 의사결정을 내리는데 자기 확신은 필수이다. 그렇지 않으면 매사 불안감이 커져서 잘못된 판단을 내리거나, 결정을 미루거나, 책임을 전가해 버리는 결과를 내기 쉽다. 새로운 일을 시도할 때는 (특히 제로투원을 만들어 낼 때는) 실수나 실패를 했을 때 빠르게 인정하고 회복할 수 있어야 한다. 한 번에 성공하는 게 목표가 아니라 빠르게 실패하고 그걸 발판으로 또다시 시도하거나 피벗을 하면서 방향을 잡아 가는게 중요하기 때문이다. 실수나 실패에 타격이 큰 사람은 오래 버틸 수가 없다. 자기 확신과 회복력은 긍정적 마인드를 베이스로 한다. 괜찮다는 마음, 할 수 있다는 마음, 까짓것 일단 한번 해보지 뭐, 아님 말고! 하는 초긍정 마인드가 성공에 꼭 필요한 재능이고, 이건 타고난 재능이 아니라 치열한 노력으로 만들어진다. "Belive in yourself has to be earned."

각자 가진 재능을 잘 살펴보고 어떤 재능을 더 키워야 하는지 적어보면 어떨까. 성실한 것도, 잘 웃는 것도, 친화력 있는 것도, 책임감이 있는 것도 모두 노력으로 얻어야 하는 재능들이다.

2) It's only a point. (그저 1 포인트일 뿐이다)
테니스의 황제라고 불리는 로저 페더러의 한 세트 평균 승률은 54%. 세계 최고 탑 플레이어이지만 승률은 50% 정도라는 것이다. (야구도 3할이면 최강 타자라고 불린다). 한 포인트는 승부사에게 매우 중요한 순간이지만(그래서 한 포인트를 얻기 위해 최선을 다해야 하지만), 졌을 땐 그저 한 포인트로 진거 일뿐이라는 거다. 진 포인트에 연연하면 다음 포인트를 놓치게 된다. 인생을 살다 보면 1 포인트를 잃게 되는 경우가 흔히 생기는데, 1 포인트는 그저 1 포인트일 뿐. It's OK. It's only a point. 인생 최고의 샷을 만들었다면? 그 또한 1 포인트일 뿐이다.

"When you're playing a point, it has to be the most important thing in the world and it is. But when it's behind you it's behind you. This mindset is really crucial because it frees you to fully commit to the next point and the next point after, with intensity, clarify, and focus. The truth is whatever game you play in life, sometimes you're going to lose; a point, a match, a season, a job.. it's a roller coaster with many ups and downs, but negative energy is wasted energy. You want to become a master at overcoming hard moments. That is a sign of a champion."

월드 챔피언은 모든 경기를 이겨서가 아니라, 자신의 패배를 다루는 법을 잘 알고 훈련한 사람이라고 강조한다.

"The best in the world are not the best because they win every point. But it's because they know they lose again and again and have learned how to deal with it."

어느 날은 일을 잘 해낸 것 같아서 뿌듯하다가, 어느 날은 다 망친 것 같아서 자괴감에 빠질 때도 있다. 동료들에게 칭찬을 듣기도 하고 비난을 받기도 한다. 내가 만든 결과물이 졸작인 것 같아서 다 버리고 싶은 날들이 이어지기도 한다. 성공도 실패도 그저 내 커리어 인생에 1 포인트일 뿐이다. 1포인트로 게임에서 진 것보다, 더 위험한 게 '난 역시 안 되나 봐', '자존심 상해서 그만뒀어', '다시 도전한 엄두가 안 나' 이런 마음으로 이어지는 패배감이다. 그저 1 포인트라는 걸 상기하자. 세계 최강 선수도 승률이 50%이고, 최강 타자도 3할인데, 평범한 내가 매번 성공한다면 그게 더 이상한 거다. 일희일비하지 말자. 그저 1 포인트씩 쌓아가는 거다.

3) Life is bigger than a court.
16살에 테니스 커리어를 시작해서 24년 동안 테니스 코트에서 살았고 테니스에서 인생을 배웠다고 생각했는데, 2022년에 은퇴를 하고 보니 자신이 몰랐던 큰 세상이 있더라는 깨달음.

내가 처한 상황이 절망적이라고 느껴질 때, 내가 손에 쥐고 있는 걸 놓으면 세상이 무너질 것 같은 두려움이 생길 때, 나만 뒤처지고 억울한 것 같다는 생각이 밀려올 때.. 내 눈에 가림막을 하고 무작정 달리고 있는 건 아닌지 멈춰서 살펴봐야 한다. 생각해 보면 내가 만나는 사람들의 숫자도 지극히 제한적이고, 내가 속한 커리어 분야도 매우 협소하고 (게다가 나는 내가 하는 일 외엔 모르는 게 너무 많다), 내가 경험한 세계도 고작 몇몇 나라와 도시들뿐이다. 여행을 하면 내가 모르는 세상과 만나게 되는 게 가장 큰 인생 배움이 된다. 세상은 넓고, 사람들은 다양하고, 삶은 다 각자 다른 모습으로 꽃을 피운다. 인생을 내 커리어 코트에 묶어 놓는다면 경기가 끝났을 때 멘붕이 올 것이다. 커리어는 커리어일 뿐, 인생 전부가 아니다. 꼭 명심하자.

https://www.youtube.com/watch?v=t8v0cHn_LRc

테니스 황제라고 불리는 로저 페더러의 최근 다트머스 졸업 연설이 인상적이다. 그가 이제 대학을 졸업하고 사회로 나가는 졸업생들과 나눈 세 가지 메시지에 내 생각을 얹어본다.​1) Effortless is a myth. (공짜는 없다)우린 모두 타고난 각자의 재능이 있다. 기가 막힌 음색을 가지고 태어난 사람도 있고, 숫자에 능한 사람도 있고, 동물적으로 운동감각이 뛰어난 사람도 있다. 성공하려면 타고난 재능을 가지고 있어야 한다는 말도 맞을지 모르겠다. 그래서일까? 우리는 종종 성공한 사람들을 보며 타고난 재능이라고 치부해 버리기도 하고, 쉽게 해내는 (것처럼 보이는) 결과물을 보며 그 자리까지 가기 위해 흘린 피 땀 눈물을 외면해 버리기도 한다.​로저 페더러는 자신이 테니스 선수에게 필요한 재능을 타고났음을 인정하면서(타고난 재능을 커리어와 연결시키는 건 매우 중요하다), 타고난 재능만으로는 성공할 수 없음을 강조한다. "Believe in yourself has to be earned."라며 자신에 대한 믿음은 경기를 승리로 이끄는데 꼭 필요한 재능인데, 이는 타고난 재능이 아니라 각고의 노력으로 얻어내야 하는 재능이라고 말한다. 인내심과 끈기, 과정을 즐길 수 있는 여유, 자기 관리... 이 모든 게 치열한 자신과의 싸움으로 만들어낸 재능이라는 것이다. 나는 개인적으로 "to be earned"라는 말을 좋아한다. 우리의 성공이 타고난 재능으로 결정된다면 억울하고 재미없는 삶이 되겠지만, 내가 노력해서 얻어낸 재능으로 성공을 만들 수 있다면 살아볼 만한 인생이라는 에너지가 생긴다.​나는 최근 일적으로 폭풍 속을 걷는 것 같은 시기를 보내고 있는데, 자기 확신, 회복력, 긍정적 마인드 이 세 재능을 바닥내지 않고 든든하게 키우기 위해 노력 중이다. 새로운 프로젝트를 리딩하고 팀을 매니징하고 의사결정을 내리는데 자기 확신은 필수이다. 그렇지 않으면 매사 불안감이 커져서 잘못된 판단을 내리거나, 결정을 미루거나, 책임을 전가해 버리는 결과를 내기 쉽다. 새로운 일을 시도할 때는 (특히 제로투원을 만들어 낼 때는) 실수나 실패를 했을 때 빠르게 인정하고 회복할 수 있어야 한다. 한 번에 성공하는 게 목표가 아니라 빠르게 실패하고 그걸 발판으로 또다시 시도하거나 피벗을 하면서 방향을 잡아 가는게 중요하기 때문이다. 실수나 실패에 타격이 큰 사람은 오래 버틸 수가 없다. 자기 확신과 회복력은 긍정적 마인드를 베이스로 한다. 괜찮다는 마음, 할 수 있다는 마음, 까짓것 일단 한번 해보지 뭐, 아님 말고! 하는 초긍정 마인드가 성공에 꼭 필요한 재능이고, 이건 타고난 재능이 아니라 치열한 노력으로 만들어진다. "Belive in yourself has to be earned."​각자 가진 재능을 잘 살펴보고 어떤 재능을 더 키워야 하는지 적어보면 어떨까. 성실한 것도, 잘 웃는 것도, 친화력 있는 것도, 책임감이 있는 것도 모두 노력으로 얻어야 하는 재능들이다.​2) It's only a point. (그저 1 포인트일 뿐이다)테니스의 황제라고 불리는 로저 페더러의 한 세트 평균 승률은 54%. 세계 최고 탑 플레이어이지만 승률은 50% 정도라는 것이다. (야구도 3할이면 최강 타자라고 불린다). 한 포인트는 승부사에게 매우 중요한 순간이지만(그래서 한 포인트를 얻기 위해 최선을 다해야 하지만), 졌을 땐 그저 한 포인트로 진거 일뿐이라는 거다. 진 포인트에 연연하면 다음 포인트를 놓치게 된다. 인생을 살다 보면 1 포인트를 잃게 되는 경우가 흔히 생기는데, 1 포인트는 그저 1 포인트일 뿐. It's OK. It's only a point. 인생 최고의 샷을 만들었다면? 그 또한 1 포인트일 뿐이다.​"When you're playing a point, it has to be the most important thing in the world and it is. But when it's behind you it's behind you. This mindset is really crucial because it frees you to fully commit to the next point and the next point after, with intensity, clarify, and focus. The truth is whatever game you play in life, sometimes you're going to lose; a point, a match, a season, a job.. it's a roller coaster with many ups and downs, but negative energy is wasted energy. You want to become a master at overcoming hard moments. That is a sign of a champion."​월드 챔피언은 모든 경기를 이겨서가 아니라, 자신의 패배를 다루는 법을 잘 알고 훈련한 사람이라고 강조한다.​"The best in the world are not the best because they win every point. But it's because they know they lose again and again and have learned how to deal with it." 어느 날은 일을 잘 해낸 것 같아서 뿌듯하다가, 어느 날은 다 망친 것 같아서 자괴감에 빠질 때도 있다. 동료들에게 칭찬을 듣기도 하고 비난을 받기도 한다. 내가 만든 결과물이 졸작인 것 같아서 다 버리고 싶은 날들이 이어지기도 한다. 성공도 실패도 그저 내 커리어 인생에 1 포인트일 뿐이다. 1포인트로 게임에서 진 것보다, 더 위험한 게 '난 역시 안 되나 봐', '자존심 상해서 그만뒀어', '다시 도전한 엄두가 안 나' 이런 마음으로 이어지는 패배감이다. 그저 1 포인트라는 걸 상기하자. 세계 최강 선수도 승률이 50%이고, 최강 타자도 3할인데, 평범한 내가 매번 성공한다면 그게 더 이상한 거다. 일희일비하지 말자. 그저 1 포인트씩 쌓아가는 거다.​3) Life is bigger than a court.16살에 테니스 커리어를 시작해서 24년 동안 테니스 코트에서 살았고 테니스에서 인생을 배웠다고 생각했는데, 2022년에 은퇴를 하고 보니 자신이 몰랐던 큰 세상이 있더라는 깨달음.​내가 처한 상황이 절망적이라고 느껴질 때, 내가 손에 쥐고 있는 걸 놓으면 세상이 무너질 것 같은 두려움이 생길 때, 나만 뒤처지고 억울한 것 같다는 생각이 밀려올 때.. 내 눈에 가림막을 하고 무작정 달리고 있는 건 아닌지 멈춰서 살펴봐야 한다. 생각해 보면 내가 만나는 사람들의 숫자도 지극히 제한적이고, 내가 속한 커리어 분야도 매우 협소하고 (게다가 나는 내가 하는 일 외엔 모르는 게 너무 많다), 내가 경험한 세계도 고작 몇몇 나라와 도시들뿐이다. 여행을 하면 내가 모르는 세상과 만나게 되는 게 가장 큰 인생 배움이 된다. 세상은 넓고, 사람들은 다양하고, 삶은 다 각자 다른 모습으로 꽃을 피운다. 인생을 내 커리어 코트에 묶어 놓는다면 경기가 끝났을 때 멘붕이 올 것이다. 커리어는 커리어일 뿐, 인생 전부가 아니다. 꼭 명심하자.​https://www.youtube.com/watch?v=t8v0cHn_LRc

YouTube

로저 페더러에게 배우는 성공의 비결

리눅스의 창시자인 리누스 토발즈의 유명한 말 중에 다음과 같은 명언이 있다.

“Talk is cheap, show me the code.”

AI가 대신 코딩해주는 시대에, 이제 이 말은 다음처럼 바뀌어야 하지 않을까 싶다.

“Code is cheap, talk about value.”

리눅스의 창시자인 리누스 토발즈의 유명한 말 중에 다음과 같은 명언이 있다. “Talk is cheap, show me the code.” AI가 대신 코딩해주는 시대에, 이제 이 말은 다음처럼 바뀌어야 하지 않을까 싶다. “Code is cheap, talk about value.”

리눅스의 창시자인 리누스 토발즈의 유명한 말 중에 다음과 같은 명

SCAMPER는 아이디어 발상을 도와주는 창의적 사고도구입니다. 각각의 알파벳은 아이디어를 발전시키기 위한 구체적인 질문을 나타냅니다.

1. Substitute (대체하기): 어떤 요소를 다른 것으로 바꿀 수 있을까?
- 예시: 플라스틱 빨대를 종이 빨대로 대체하기.

2. Combine (결합하기): 두 가지 요소를 결합하면 새로운 것이 나올까?
- 예시: 스마트폰과 카메라 기능 결합.

3. Adapt (적용하기): 다른 분야에서 성공한 아이디어를 적용할 수 있을까?
- 예시: 자동차 좌석의 열선 기능을 사무실 의자에 적용.

4. Modify (변형하기): 기존 아이디어를 어떻게 변형할 수 있을까?
- 예시: 기존 제품의 색상이나 크기 변경.

5. Put to another use (다른 용도로 사용하기): 다른 방식으로 활용할 수 있을까?
- 예시: 와인병을 꽃병으로 사용.

6. Eliminate (제거하기): 불필요한 요소를 제거할 수 있을까?
- 예시: 제품의 복잡한 기능을 제거하고 단순화.

7. Reverse (반대로 생각하기): 순서를 뒤집거나 반대로 해볼 수 있을까?
- 예시: 패키지 배송을 고객이 직접 픽업하게 하기.

SCAMPER는 아이디어 발상을 도와주는 창의적 사고도구입니다. 각각의 알파벳은 아이디어를 발전시키기 위한 구체적인 질문을 나타냅니다. 1. Substitute (대체하기): 어떤 요소를 다른 것으로 바꿀 수 있을까? - 예시: 플라스틱 빨대를 종이 빨대로 대체하기. 2. Combine (결합하기): 두 가지 요소를 결합하면 새로운 것이 나올까? - 예시: 스마트폰과 카메라 기능 결합. 3. Adapt (적용하기): 다른 분야에서 성공한 아이디어를 적용할 수 있을까? - 예시: 자동차 좌석의 열선 기능을 사무실 의자에 적용. 4. Modify (변형하기): 기존 아이디어를 어떻게 변형할 수 있을까? - 예시: 기존 제품의 색상이나 크기 변경. 5. Put to another use (다른 용도로 사용하기): 다른 방식으로 활용할 수 있을까? - 예시: 와인병을 꽃병으로 사용. 6. Eliminate (제거하기): 불필요한 요소를 제거할 수 있을까? - 예시: 제품의 복잡한 기능을 제거하고 단순화. 7. Reverse (반대로 생각하기): 순서를 뒤집거나 반대로 해볼 수 있을까? - 예시: 패키지 배송을 고객이 직접 픽업하게 하기.

아이디어가 잘 안생길 때 쓸 수 있는 프레임워크 SCAMPER 💡

페이스북이 사과를 쪼개고 싶은 이유😡

[ 애플, 페이스북, 구글에게 개인정보란..? ]

애플이 iOS 14부터 개인정보를 강화하고 있는 이유, 페이스북이 지면 광고를 내면서까지 중소사업자의 수호자로 나서고 있는 이유, 구글 크롬에서도 서드파티 쿠키 지원을 포기하는 이유를 알기 쉽게 설명했어요.

각 기업의 다른 입장을 한 번에 파악할 수 있으면서도 한 번쯤 생각해보게 만드는 글이라 공유합니다.

여러분은 개인정보를 위해 얼마를 낼 의향이 있으신가요? 앞으로는 더 자주 생각하게 될 질문이 될지도 모르겠네요.

Stibee

공공기관 쇼핑몰 대리

박준성

데이터

박준혁

마케터

초보마케텅

데이터 분석가

Data Analyst

유고은

미디어 뉴스레터 어거스트 에디터

학부에서 심리학을 전공했고, 데이터를 읽고 분석합니다. 데이터에 담긴 사람들의 마음과 행동에 관심이 많습니다. 그리고 미디어 뉴스레터 어거스트에서 에디터로서 레터를 발행합니다.
#데이터분석 #뉴스레터

댓글 0

비슷한 게시물

주간 인기 TOP 10

추천 프로필