여러분은 오늘 컨디션을 표현해본다면 어떻게 하시겠어요? 개인마다 답이 다를 수 있죠. 좋다, 나쁘다를 비롯하여 1~100에 대입하여 표현할 수도 있고요. 배달상황도 마찬가지에요. 지금 비가 오는데 배달상황이 어떻지? 이처럼 주관적인 배달상황을 측정 가능한 지표로 새롭게 정의한 "배달 인프라 레벨"구축 경험담을 풀어볼게요😊 늘 그렇듯, 사용자 인터뷰를 시작으로 문제정의 하기 딜리버리서비스팀에서는 배달 도메인을 담당하고 있고, 주 사용자로는 라이더 및

실시간 배달 상황이 궁금해! 배달 인프라 레벨 구축 경험담 | 우아한형제들 기술블로그

배민의 배달 인프라 레벨 구축 경험담 글입니다.

배달 상황을 모니터링해서 배달이 잘 진행되도록 하는 운영이 존재할텐데, 이것을 어떻게 만들까에 대해 담은 글입니다.

지표, 문제 정의에 대해 잘 나와서 읽어보셔도 좋을 것 같네요. 8개의 지표를 하나로 표현하려면 어떻게 해야할까?에 대해서도 나와있어요.

저는 타다에서 비슷하게 운행에 대한 상황을 어떻게 볼 것인가에 대해 고민한 적이 있어서 그 때의 경험이 떠올라서 유익하게 읽었습니다

문제
 * 문제점 1. 모니터링을 위해 운영자가 확인하고 판단해야하는 지표가 많다
 * 문제점 2. 실시간으로 변하는 지역 상황을 즉각 인지하는 데 한계가 있다
 * 문제점 3. 지표의 기준이 일관되지 않고 상황마다 바뀐다(외부 변수 등)

시시각각 달라지는 배달상황을 측정가능한 지표 : 배달 인프라 레벨
 * Lv 1 ~ 9로 표현

https://techblog.woowahan.com/18254/

배민의 배달 인프라 레벨 구축 경험담 글입니다. 배달 상황을 모니터링해서 배달이 잘 진행되도록 하는 운영이 존재할텐데, 이것을 어떻게 만들까에 대해 담은 글입니다. 지표, 문제 정의에 대해 잘 나와서 읽어보셔도 좋을 것 같네요. 8개의 지표를 하나로 표현하려면 어떻게 해야할까?에 대해서도 나와있어요. 저는 타다에서 비슷하게 운행에 대한 상황을 어떻게 볼 것인가에 대해 고민한 적이 있어서 그 때의 경험이 떠올라서 유익하게 읽었습니다 문제<ul ><li>문제점 1. 모니터링을 위해 운영자가 확인하고 판단해야하는 지표가 많다</li><li>문제점 2. 실시간으로 변하는 지역 상황을 즉각 인지하는 데 한계가 있다</li><li>문제점 3. 지표의 기준이 일관되지 않고 상황마다 바뀐다(외부 변수 등)</li></ul> 시시각각 달라지는 배달상황을 측정가능한 지표 : 배달 인프라 레벨<ul ><li>Lv 1 ~ 9로 표현</li></ul> https://techblog.woowahan.com/18254/

우아한형제들 기술블로그  |

실시간 배달 상황이 궁금해! 배달 인프라 레벨 구축 경험담

내가 실리콘밸리로 우연찮게 넘어가게 된 때는 만 31살이 되었을 때였다. 그 전까지 한번도 미국에서 살 꺼라 생각하지 않았기에 영어 회화 공부는 해본 적이 없었다. 미국에 넘어가 작은 스타트업에서 일하면서 보통 오전 10시전에 출근해서 새벽 1시 정도까지 일하고 퇴근하는 힘든 나날이었지만 집에 가면 와이프와 프렌즈 받아쓰기와 따라하기를 하며 나름 공부를 꾸준히 했는데 그렇다고 금방 늘지는 않았고 발음은 사실 고칠 수 있는 것이 아니었다.

하지만 깨달은 것이 하나가 있었는데 말하는 것 보다 더 중요한 것은 듣기 능력이란 점이었다. 내가 계속 한국에 살았다면 다른 사람이 하는 말은 그렇게 집중해서 듣지 않았을 텐데 영어로 이야기하다보니 일단 내가 하고 싶은 말을 하기 보다는 다른 사람이 하는 말을 먼저 이해하려는 노력을 할 수 밖에 없었고, 그게 의도했던 것은 아니지만 의사소통 능력을 키우는데 커다란 도움이 되었다. 즉 내 목적을 관철하기 위해 상대의 이야기를 듣기보다는 상대가 하는 말을 이해하려는 노력이 어쩌다 보니 의사소통 능력을 키우는데 도움이 되었다는 것이다.

다음은 현란한 말로 승부를 볼 수가 없다보니 내가 전달하고자 하는 것이 무엇인지 집중하는 습관을 갖게 되었고 말이 많이 하는 것보다는 명확하게 하는 습관이 생겼다. 또한 말만 중요한 것이 아니라 말을 하는 톤과 바디 랭귀지가 사실은 말 만큼 중요하다는 점도 알게 되었다.

언어란 결국 사람들간의 의사 소통이다. 내가 나만의 이득을 이야기하는 것이 아니라 상대를 이해하려고 하고 공동의 이익을 만들려 하는 사람인가가 중요하다. 개발자로서 사실 영어는 처음에 그렇게 중요하지 않지만 레벨이 올라갈수록 중요해지며 이는 현란하게 발음을 하고 그러는 것이 아닌 어눌하고 문법이 틀려도 본인의 의견을 명확하게 표현할 수 있으면 된다. 그보다 더 중요한 것은 긍정적인 태도를 갖는 팀플레이어로 결과를 내는 사람이 되어야 한다는 점이다. 난 영어를 못해서 일을 잘 못해라고 하며 영어의 미숙함 뒤에 숨는 사람들을 실리콘밸리에 가끔 보게 되는데 그 단계를 벗어나는 간절함이 먼저 필요하다.

내가 실리콘밸리로 우연찮게 넘어가게 된 때는 만 31살이 되었을 때였다. 그 전까지 한번도 미국에서 살 꺼라 생각하지 않았기에 영어 회화 공부는 해본 적이 없었다. 미국에 넘어가 작은 스타트업에서 일하면서 보통 오전 10시전에 출근해서 새벽 1시 정도까지 일하고 퇴근하는 힘든 나날이었지만 집에 가면 와이프와 프렌즈 받아쓰기와 따라하기를 하며 나름 공부를 꾸준히 했는데 그렇다고 금방 늘지는 않았고 발음은 사실 고칠 수 있는 것이 아니었다. 하지만 깨달은 것이 하나가 있었는데 말하는 것 보다 더 중요한 것은 듣기 능력이란 점이었다. 내가 계속 한국에 살았다면 다른 사람이 하는 말은 그렇게 집중해서 듣지 않았을 텐데 영어로 이야기하다보니 일단 내가 하고 싶은 말을 하기 보다는 다른 사람이 하는 말을 먼저 이해하려는 노력을 할 수 밖에 없었고, 그게 의도했던 것은 아니지만 의사소통 능력을 키우는데 커다란 도움이 되었다. 즉 내 목적을 관철하기 위해 상대의 이야기를 듣기보다는 상대가 하는 말을 이해하려는 노력이 어쩌다 보니 의사소통 능력을 키우는데 도움이 되었다는 것이다. 다음은 현란한 말로 승부를 볼 수가 없다보니 내가 전달하고자 하는 것이 무엇인지 집중하는 습관을 갖게 되었고 말이 많이 하는 것보다는 명확하게 하는 습관이 생겼다. 또한 말만 중요한 것이 아니라 말을 하는 톤과 바디 랭귀지가 사실은 말 만큼 중요하다는 점도 알게 되었다. 언어란 결국 사람들간의 의사 소통이다. 내가 나만의 이득을 이야기하는 것이 아니라 상대를 이해하려고 하고 공동의 이익을 만들려 하는 사람인가가 중요하다. 개발자로서 사실 영어는 처음에 그렇게 중요하지 않지만 레벨이 올라갈수록 중요해지며 이는 현란하게 발음을 하고 그러는 것이 아닌 어눌하고 문법이 틀려도 본인의 의견을 명확하게 표현할 수 있으면 된다. 그보다 더 중요한 것은 긍정적인 태도를 갖는 팀플레이어로 결과를 내는 사람이 되어야 한다는 점이다. 난 영어를 못해서 일을 잘 못해라고 하며 영어의 미숙함 뒤에 숨는 사람들을 실리콘밸리에 가끔 보게 되는데 그 단계를 벗어나는 간절함이 먼저 필요하다.

(실리콘밸리에서 일할 때) 영어를 못할 때의 장점

2024 FEConf 현장 영상을 준비했어요! 이번 행사에는 당근 부스 운영진으로 참여했어요. 다른 후원사 부스를 체험하면서 경품도 받고 네트워킹 부스도 즐기고 왔어요. 제가 스트레스와 불안감을 관리하는 방법은 영상 후반부에 나와요! 재미있게 보셨다면 좋아요와 댓글로 응원해주세요 😊 다음 영상으로 또 찾아올게요!

개발자가 스트레스와 불안감을 동시에 잡는 방법 | 2024 FEConf 탐방기

"스트레스를 푸는 취미가 있으신가요?"

2024 FEConf는 발표 세션과 후원사 부스를 비롯해 아이 돌봄 공간, 네트워킹 부스까지 마련되어 즐길 거리가 가득했습니다.

네트워킹 부스에선 스트레스를 푸는 취미가 있냐는 질문을 받았습니다. 저는 '글쓰기'가 스트레스를 푸는 취미라고 답했습니다.

처음에는 글쓰기가 스트레스를 받는 일이라고 생각했는데 가만 생각해 보니 스트레스를 줄여주는 활동이라는 걸 깨닫게 됐습니다. 자세한 내용은 첨부한 영상을 통해 확인해 주세요.

여러분은 어떤가요? 어떤 방식으로 스트레스를 풀고 계신가요?

https://youtu.be/ug1nLShB5DA?si=XN_Rww49HjeDw_7u

"스트레스를 푸는 취미가 있으신가요?" 2024 FEConf는 발표 세션과 후원사 부스를 비롯해 아이 돌봄 공간, 네트워킹 부스까지 마련되어 즐길 거리가 가득했습니다. 네트워킹 부스에선 스트레스를 푸는 취미가 있냐는 질문을 받았습니다. 저는 '글쓰기'가 스트레스를 푸는 취미라고 답했습니다. 처음에는 글쓰기가 스트레스를 받는 일이라고 생각했는데 가만 생각해 보니 스트레스를 줄여주는 활동이라는 걸 깨닫게 됐습니다. 자세한 내용은 첨부한 영상을 통해 확인해 주세요. 여러분은 어떤가요? 어떤 방식으로 스트레스를 풀고 계신가요? https://youtu.be/ug1nLShB5DA?si=XN_Rww49HjeDw_7u

www.youtube.com

개발자의 스트레스 해소법

대부분의 한국인은 '열심히' 살고 '열심히' 일한다. 그중에서도 한국의 리더들은 당연히 그보다도 더 열심히 산다. 수많은 연구가 한국인들이 얼마나 열심히 사는가에 대한 현상을 보고하고 있다. 그래서 한국인에게 열심히

뭐든 지루할때까지 해야 당신의 창의력이 커진다 [김경일의 CEO 심리학]

1. 대부분의 한국인은 열심히 살고, 열심히 일한다. 그중에서도 한국의 리더들은 당연히 그보다도 더 열심히 산다.

2. 수많은 연구가 ‘한국인들이 얼마나 열심히 사는가’에 대해 보고하고 있다. 그래서 한국인에게 열심히 산다는 것은 그 자체로서 일종의 '선(善)'이다.

3. 심지어 그 '열심히'로 인해 자신의 주위에 있는 소중한 사람들에게 피해가 가는 것조차 일종의 미덕처럼 여겨지는 경우도 있다.

4. (물론) 혼신의 힘을 다해 무엇인가를 추구하고 목표로 삼은 것을 이뤄내는 것은 중요하다. 하지만 열심히 한다는 것만으로 모든 것을 해결할 수 있다고 생각하는 것은 큰 오산이다.

5. 열심의 반대에 있는 상태에 대한 경험이, (오히려) 새로운 돌파구를 찾는 실마리가 되는 경우가 많기 때문이다.

6. 그 경험의 이름은 놀랍게도 '지루함'이다. 필자(=김경일 교수)는 '얼마나 쉬어야 하냐'는 질문에 항상 이렇게 대답하곤 한다. '게임이나 TV 시청같이 몸은 쉬지만 뇌는 열심히 일해야 하는 것들을 전혀 하지 않은 채, 제대로 된 휴식을 취하며 지루함을 느낄 때까지'라고 말이다.

7. 심리학자들은 지루함에 대해 매우 오랫동안 연구를 진행해왔다. 일반적으로 지루함은, '시간이 오래 걸리거나 같은 상태가 오래 계속되어 따분하고 싫증이 나는 상태'를 의미한다.

8. 당연히 좋거나 건전한 경험이 아니라고 생각하기 쉽다. 하지만 일리노이대 스프링필드 캠퍼스 명예교수인 샤흐람 헤시마트 박사를 비롯한 수많은 연구자는 ‘지루할 때까지 어떤 경험을 유지하는 것은 매우 중요하다’고 강조한다.

9. 특히 정신적 에너지를 많이 사용하는 사람일수록 휴식을 취할 때 종종 지루한 느낌이 들 때까지 쉬어야만 정신적으로 더 건강해지며 주의력이 향상된다.

10. 심지어 창의적인 것을 만들어내거나 관심을 유지할 수 있는 역량이 발휘된다. 게다가 어떤 일을 할 때 지루한 수준까지 해야만 새로운 목표를 만들어내는 것이 가능해진다는 것은 심리학 연구에서 자주 발견되는 현상이다.

11. (그렇다면) 왜 휴식이든 일이든 지루함을 느낄 때까지 해야 하는 것일까? 그건 우리의 뇌의 한 영역인 ‘해마(hippocampus)’가 다른 길을 찾기 위한 준비를 시작하는 시점이 바로 이 순간이기 때문이다. 그리고 그 다른 길이 생산적이고 창의적인 것이어야 할 때, 해마의 역할은 더욱 결정적이다.

12. 어린 시절부터 지루함을 느끼기도 전에 (혹은 지루함이 조금만 예상돼도) 다른 무언가를 즉각적으로 하는 일이 반복되면 충동적인 성격이 형성된다. 반면, 이 지루함을 견디는 법을 배운 아동들은 사회 생활을 성공적으로 하고 생산적인 삶을 추구할 확률이 높아진다.

13. (그래서) 심리학자들이 (지루함을 느낄 정도로) 충분한 양의 휴식의 필요성을 강조하는 것이다.

14. (그러니 충분히 열심히 일했다면, 아주 잠시 동안은 지루할 정도로 쉬어주어야 한다. 그리고 지루함의 시간이 아무리 길어도, 열심히 일한 시간에 비하면 얼마 되지 않을 것이다)

15. (하지만 그 얼마의 시간이 여러분의 삶에 활력을 충전해주고, 열심히 일한 시간을 더 효율적이고 창의적으로 만들어줄 것이다)

1. 대부분의 한국인은 열심히 살고, 열심히 일한다. 그중에서도 한국의 리더들은 당연히 그보다도 더 열심히 산다. 2. 수많은 연구가 ‘한국인들이 얼마나 열심히 사는가’에 대해 보고하고 있다. 그래서 한국인에게 열심히 산다는 것은 그 자체로서 일종의 '선(善)'이다. 3. 심지어 그 '열심히'로 인해 자신의 주위에 있는 소중한 사람들에게 피해가 가는 것조차 일종의 미덕처럼 여겨지는 경우도 있다. 4. (물론) 혼신의 힘을 다해 무엇인가를 추구하고 목표로 삼은 것을 이뤄내는 것은 중요하다. 하지만 열심히 한다는 것만으로 모든 것을 해결할 수 있다고 생각하는 것은 큰 오산이다. 5. 열심의 반대에 있는 상태에 대한 경험이, (오히려) 새로운 돌파구를 찾는 실마리가 되는 경우가 많기 때문이다. 6. 그 경험의 이름은 놀랍게도 '지루함'이다. 필자(=김경일 교수)는 '얼마나 쉬어야 하냐'는 질문에 항상 이렇게 대답하곤 한다. '게임이나 TV 시청같이 몸은 쉬지만 뇌는 열심히 일해야 하는 것들을 전혀 하지 않은 채, 제대로 된 휴식을 취하며 지루함을 느낄 때까지'라고 말이다. 7. 심리학자들은 지루함에 대해 매우 오랫동안 연구를 진행해왔다. 일반적으로 지루함은, '시간이 오래 걸리거나 같은 상태가 오래 계속되어 따분하고 싫증이 나는 상태'를 의미한다. 8. 당연히 좋거나 건전한 경험이 아니라고 생각하기 쉽다. 하지만 일리노이대 스프링필드 캠퍼스 명예교수인 샤흐람 헤시마트 박사를 비롯한 수많은 연구자는 ‘지루할 때까지 어떤 경험을 유지하는 것은 매우 중요하다’고 강조한다. 9. 특히 정신적 에너지를 많이 사용하는 사람일수록 휴식을 취할 때 종종 지루한 느낌이 들 때까지 쉬어야만 정신적으로 더 건강해지며 주의력이 향상된다. 10. 심지어 창의적인 것을 만들어내거나 관심을 유지할 수 있는 역량이 발휘된다. 게다가 어떤 일을 할 때 지루한 수준까지 해야만 새로운 목표를 만들어내는 것이 가능해진다는 것은 심리학 연구에서 자주 발견되는 현상이다. 11. (그렇다면) 왜 휴식이든 일이든 지루함을 느낄 때까지 해야 하는 것일까? 그건 우리의 뇌의 한 영역인 ‘해마(hippocampus)’가 다른 길을 찾기 위한 준비를 시작하는 시점이 바로 이 순간이기 때문이다. 그리고 그 다른 길이 생산적이고 창의적인 것이어야 할 때, 해마의 역할은 더욱 결정적이다. 12. 어린 시절부터 지루함을 느끼기도 전에 (혹은 지루함이 조금만 예상돼도) 다른 무언가를 즉각적으로 하는 일이 반복되면 충동적인 성격이 형성된다. 반면, 이 지루함을 견디는 법을 배운 아동들은 사회 생활을 성공적으로 하고 생산적인 삶을 추구할 확률이 높아진다. 13. (그래서) 심리학자들이 (지루함을 느낄 정도로) 충분한 양의 휴식의 필요성을 강조하는 것이다. 14. (그러니 충분히 열심히 일했다면, 아주 잠시 동안은 지루할 정도로 쉬어주어야 한다. 그리고 지루함의 시간이 아무리 길어도, 열심히 일한 시간에 비하면 얼마 되지 않을 것이다) 15. (하지만 그 얼마의 시간이 여러분의 삶에 활력을 충전해주고, 열심히 일한 시간을 더 효율적이고 창의적으로 만들어줄 것이다)

n.news.naver.com

열심히만 한다고 문제가 해결될 것이라고 생각한다면, 그건 오산입니다

1
기업 임원들은 투자 결정을 내려야 할 때마다 두 가지 대안을 갖고 고민한다. 첫 번째는 완전히 신제품을 만들 때 드는 총비용이다. 두 번째는 기존에 있는 것을 최대한 활용할 수 있는지이다. 그럴 경우 한계비용과 한계수익에만 신경을 쓰면 된다.

2
그런데 거의 항상 한계비용 논리가 총비용 논리를 이긴다. 반면 신생기업의 경우 제품 메뉴에 한계비용 항목이 존재하지 않는다. 시장에 처음 등장한 기업에게는 총비용이 한계비용과 같다.

3
100% 지키기가 98% 지키기보다 더 쉽다. 이번 한 번만의 선택은 그것이 인생을 뒤바꿔 놓을 선택처럼 느껴지지 않는다. 한계비용이 항상 낮다. 그러나 이런 결정들이 쌓여서 훨씬 더 큰 그림으로 모습이 바뀌면서 우리를 결코 원하지 않았던 사람으로 변신시킬 수 있다. 한계비용을 쓰겠다는 본능은 우리에게서 우리가 취하는 행동에 뒤따르는 실제 비용을 감춘다.

4
우리는 투자했을 때 드는 비용을 즉시 확인할 수 있겠지만 투자하지 않음으로써 드는 비용을 정확히 산출하기란 정말로 힘들다. 한계비용이란 렌즈를 통해서 모든 결정을 내리는 기업은 궁극적으로 대가를 치른다.

5
미래예측 능력을 갖추는 것은 인생에서 성공하기 위한 필수 조건이다. 그런데 대개 우리는 과거 경험에 의존해 미래를 예측하게 되며, 이런 방법은 인생을 살면서 모든 것을 경험할 수 없다는 데 한계가 있다.

6
따라서 미리 경험을 하지 않아도 어떠한 일들이 일어날지 예측하는 것이 매우 중요한데, 이것이 바로 이론의 가치다. 즉, 많은 세월의 공격을 잘 견뎌낸 이론은 인과관계를 제시해 줌으로써 미래를 예측하는 데 도움을 주고 각자 처한 환경에 맞는 좋은 선택을 할 수 있도록 한다.

7
좋은 이론은 변덕을 부리지 않으며, 특징 기업이나 개인에게만 적용되는 예외의 경우도 없다. 무슨 일이 일어나는지, 왜 그런 일이 일어나는지를 설명해 주는, 보편적인 진술이 바로 좋은 이론이다. 그래서 의사결정을 할 때는 사람보다 이론을 믿어야 한다.

- 클레이튼 크리스텐슨, 하버드 인생학 특강 중

8
뭔가를 하겠다는 결정의 미래는 예측하기 쉽다. 투자되는 비용과 시간, 효용과 리스크가 명확하다. 보통은 그에 따라서 판단을 한다. 반대로 그것을 하지 않았을 때의 비용은 알 수 없다. 그래서 그 선택지를 보통 고려하지 못한다. 불완전한 결정이 될 확률이 높다.

9
무엇을 해야 하는가?라는 질문도 비슷하다. 보통 무엇을 해야 하지?라는 생각은 쉽게 한다. 하지만 지금 하고 있는 일 중에, 무엇을 하지 말아야 하지? 란 생각은 잘 못한다.

10
모든 일은 균형을 찾아가려는 성질이 있는 것 같다. 마치 흔들리는 시계 추처럼. 모든 부정적인 일에도 긍정적인 부분이 있다. 반대로 마찬가지고.

11
그래서 결정의 순간 늘 균형을 생각한다. 내가 지금 고려하는 선택지의 무게감만큼 반대편에 있는 것은 무엇일까. 놓친 건 없을까. 선택지는 보통 균형을 이룬다. 안 보인다면 내가 뭔가 놓친 것이다. 더 나은 결정을 하려면 반대편을 꼭 생각해 봐야 한다.

1기업 임원들은 투자 결정을 내려야 할 때마다 두 가지 대안을 갖고 고민한다. 첫 번째는 완전히 신제품을 만들 때 드는 총비용이다. 두 번째는 기존에 있는 것을 최대한 활용할 수 있는지이다. 그럴 경우 한계비용과 한계수익에만 신경을 쓰면 된다.​​2그런데 거의 항상 한계비용 논리가 총비용 논리를 이긴다. 반면 신생기업의 경우 제품 메뉴에 한계비용 항목이 존재하지 않는다. 시장에 처음 등장한 기업에게는 총비용이 한계비용과 같다.​​​3100% 지키기가 98% 지키기보다 더 쉽다. 이번 한 번만의 선택은 그것이 인생을 뒤바꿔 놓을 선택처럼 느껴지지 않는다. 한계비용이 항상 낮다. 그러나 이런 결정들이 쌓여서 훨씬 더 큰 그림으로 모습이 바뀌면서 우리를 결코 원하지 않았던 사람으로 변신시킬 수 있다. 한계비용을 쓰겠다는 본능은 우리에게서 우리가 취하는 행동에 뒤따르는 실제 비용을 감춘다.​​4우리는 투자했을 때 드는 비용을 즉시 확인할 수 있겠지만 투자하지 않음으로써 드는 비용을 정확히 산출하기란 정말로 힘들다. 한계비용이란 렌즈를 통해서 모든 결정을 내리는 기업은 궁극적으로 대가를 치른다.​​5미래예측 능력을 갖추는 것은 인생에서 성공하기 위한 필수 조건이다. 그런데 대개 우리는 과거 경험에 의존해 미래를 예측하게 되며, 이런 방법은 인생을 살면서 모든 것을 경험할 수 없다는 데 한계가 있다.​ ​6따라서 미리 경험을 하지 않아도 어떠한 일들이 일어날지 예측하는 것이 매우 중요한데, 이것이 바로 이론의 가치다. 즉, 많은 세월의 공격을 잘 견뎌낸 이론은 인과관계를 제시해 줌으로써 미래를 예측하는 데 도움을 주고 각자 처한 환경에 맞는 좋은 선택을 할 수 있도록 한다.​​​7좋은 이론은 변덕을 부리지 않으며, 특징 기업이나 개인에게만 적용되는 예외의 경우도 없다. 무슨 일이 일어나는지, 왜 그런 일이 일어나는지를 설명해 주는, 보편적인 진술이 바로 좋은 이론이다. 그래서 의사결정을 할 때는 사람보다 이론을 믿어야 한다.​- 클레이튼 크리스텐슨, 하버드 인생학 특강 중​​​8뭔가를 하겠다는 결정의 미래는 예측하기 쉽다. 투자되는 비용과 시간, 효용과 리스크가 명확하다. 보통은 그에 따라서 판단을 한다. 반대로 그것을 하지 않았을 때의 비용은 알 수 없다. 그래서 그 선택지를 보통 고려하지 못한다. 불완전한 결정이 될 확률이 높다.​​​9무엇을 해야 하는가?라는 질문도 비슷하다. 보통 무엇을 해야 하지?라는 생각은 쉽게 한다. 하지만 지금 하고 있는 일 중에, 무엇을 하지 말아야 하지? 란 생각은 잘 못한다.​​​10모든 일은 균형을 찾아가려는 성질이 있는 것 같다. 마치 흔들리는 시계 추처럼. 모든 부정적인 일에도 긍정적인 부분이 있다. 반대로 마찬가지고.​​​11그래서 결정의 순간 늘 균형을 생각한다. 내가 지금 고려하는 선택지의 무게감만큼 반대편에 있는 것은 무엇일까. 놓친 건 없을까. 선택지는 보통 균형을 이룬다. 안 보인다면 내가 뭔가 놓친 것이다. 더 나은 결정을 하려면 반대편을 꼭 생각해 봐야 한다.

무엇을 해야 하지? 말고 무엇을 하지 말아야 하지?를 생각하라

https://blog.naver.com/madaboutit/223170951532

딥페이크 불법 합성물이 제작되고 유포되는 온상인 된 텔레그램이 방송통신심의위원회가 긴급 삭제 요청한 디지털 성범죄 영상물을 모두 삭제한 것으로 파악됐다. 방심위는 3일 “텔레그램 측이 지난 1일 긴급 삭제 요청한 디

텔레그램, 고개 숙였다…성범죄물 25건 삭제하고 사과

텔레그램이 방송통신심의위원회가 긴급 삭제 요청한 디지털 성범죄 영상물을 모두 삭제했습니다. 텔레그램 동아시아 지역 관계자의 조치고요. 국내에서 심각성을 알린 많은 시민들의 성과라고 봅니다. BBC를 비롯해서 많은 헤외 미디어에서도 다룬 덕분이 아닌가 싶고요. 국내에서 관련 기사를 신중히 고려해서 다루지 못한 곳들에는, 시민 중 한 사람으로서 손가락질을 하고 질타를 날리고 싶네요. 이후에도 텔레그램과 방심위가 핫라인을 구축해서 딥페이크 성착취물 문제를 해결한다고 하니, 늦었지만 좀 다행이라고 보고요. 무엇보다 피해자 분들이 진심으로 심리치료 등을 잘 받을 수 있는 조치가 이뤄지면 좋겠습니다. 사회적인 문제, 즉 모두의 문제라는 점을 인지하고서요. https://n.news.naver.com/mnews/article/081/0003477304?sid=105

텔레그램이 방송통신심의위원회가 긴급 삭제 요청한 디지털 성범죄 영상물을 모두 삭제했습니다. 텔레그램 동아시아 지역 관계자의 조치고요. 국내에서 심각성을 알린 많은 시민들의 성과라고 봅니다. BBC를 비롯해서 많은 헤외 미디어에서도 다룬 덕분이 아닌가 싶고요. 국내에서 관련 기사를 신중히 고려해서 다루지 못한 곳들에는, 시민 중 한 사람으로서 손가락질을 하고 질타를 날리고 싶네요. 이후에도 텔레그램과 방심위가 핫라인을 구축해서 딥페이크 성착취물 문제를 해결한다고 하니, 늦었지만 좀 다행이라고 보고요. 무엇보다 피해자 분들이 진심으로 심리치료 등을 잘 받을 수 있는 조치가 이뤄지면 좋겠습니다. 사회적인 문제, 즉 모두의 문제라는 점을 인지하고서요. https://n.news.naver.com/mnews/article/081/0003477304?sid=105

유데미 개발 챌린지 : 클론코딩편

✅ 잘못된 클론 코딩

게임 업계에서 개발자들의 포트폴리오로 자주 나오는 요소는 클론 코딩입니다. 본인이 좋아하는 게임을 만들어보기도 하고, 지원하는 회사와 가장 밀접한 프로젝트를 만들어서 제출하기도 합니다. 물론 아주 잘 만든 분들도 있지만, 대부분은 제출한 클론 코드가 안 좋은 결과를 만드는 경우가 많습니다.

어떤 경우일까요? 제가 경험한 사례를 좀 공유해보려고 합니다.

❇️사례 1. 스크린샷뿐인 모작

3년 전쯤 마인크래프트 모작을 제출한 분이 있었습니다.

마치 마인크래프트처럼 보이는 월드와 블록들이 있는 스크린샷이 있었습니다. 정말 똑같다(?)는 생각이 들 정도로 잘 구성된 스샷이었습니다. 그리고, 내용에는 이 모작을 만드는데 몇 주가 걸렸고, 만들 때 어떤 엔진을 사용했는지 기입해 두셨습니다.

당연히 이분은 탈락했습니다.

모작을 할 때 중요한 것은, 이게 얼마나 걸렸고, 무슨 엔진을 썼는지보다, 어떻게 구현했는지가 가장 중요합니다.

그런 관점에서 비슷해 보이는 단편적인 스크린샷은 오히려 전혀 매력적이지 않습니다.
오히려, 블록이 2개밖에 없더라도, 혹은 블록이 화이트 박스 형태더라도, 절차적으로 생성되는 월드나 직접 배치하는 샌드박스가 있다면, 훨씬 높은 점수를 줄 것 같습니다.

❇️사례 2. 핵심을 벗어난 모작

두 번째 사례는 캔디크러시 사가와 같은 매치3 퍼즐 게임 모작을 제출한 분이었습니다. 데모도 같이 보내주셨고, 본인이 작성한 핵심 소스 코드도 제출해 주셨습니다.

허나 아쉽게도 이분도 탈락했습니다.

가장 큰 이유는 데모를 플레이할 때 연쇄가 잘 되지 않는 점이었습니다.
3-매치 게임의 핵심은 레벨 디자인도 중요하지만, 한번 매치가 되어 블록이 사라지면 그 자리를 다른 블록들이 채우면서 발생하는 연쇄작용에 있습니다. 그 연쇄작용하는 코드가 미완성 상태였고, 실제로 제출된 코드에서 연쇄 구현이 제대로 되지 않았음을 볼 수 있었습니다.

비슷한 사례로, 간혹 액션 게임 쪽에서 채용을 할 때 마영전 모작이나 리니지 모작도 자주 볼 수 있는데, 거의 대부분 탈락 처리됩니다.

우선, 마영전 모작의 경우 클라이언트-서버 구조를 굉장히 강조하는 분들이 많습니다. 사실 왜 그걸 강조하는지 잘 모르겠습니다. (어쩌면 학원에서 그렇게 시켰을 수도 있겠죠.) 마영전의 핵심은 멀티플레이 논타겟 액션입니다. 제가 본 마영전 모작 중에서는 아쉽게도 마영전의 논타겟 액션 동기화를 본인만의 방식으로 만들어서 설명해주신 분이 없었습니다.

리니지 모작도 마찬가지입니다. MMO 서버-클라이언트 구조라고 강조하는 분들을 많이 봅니다. 정말 놀랍게도, 만드는데 2주밖에 안 걸렸다는 분도 있었는데… 어필 포인트가 너무 어긋나서 할 말을 잃었던 것 같습니다. 실제로 그런 분들 중에서 MMO의 핵심 요소 중 하나인 월드 채널링이나 MMO에서 퀘스트와 같은 콘텐츠를 본인만의 방식으로 만들어서 설명해주신 분들은 없었습니다.

✅클론 코딩을 포트폴리오로 만드는 방법

위의 잘못된 클론 코딩 사례가 거의 포트폴리오에 있는 클론 코딩의 90%를 차지하기 때문에, 클론 코딩을 포트폴리오로 만드는 방법은 생각보다 쉽습니다. 바로 안티패턴을 피하는 것이죠.

우선, 클론할 게임의 핵심을 아는 것부터 시작해야 합니다.
마인크래프트, 오버워치, 3-매치, 마영전, 리니지 등 다양한 게임들의 핵심은 모두 다릅니다. 그리고 주니어 개발자 입장에서 이런 핵심을 관통하기란 쉽지 않은 것도 사실입니다. 그러나 조금만 검색해보면 나오는 것도 맞습니다.

두 번째는 핵심 기믹만 모작하는 것도 가치가 있다는 것입니다.
예를들면, 포탈2의 들어가는 포탈/나가는 포탈은 다양한 기술적 챌린지(렌더링, 공간 이동)가 있습니다. 총게임들의 Netcode(예측, 보간)들도 꽤 좋은 챌린지가 됩니다. 그래서 이런 기믹들은 만들어서 포트폴리오에 넣으면 게임플레이 프로그래머로 홍보하기 좋습니다.

개인적으로 이런 핵심 요소를 클론한 유튜브 하나를 추천해드리면, Mix and Jam 이 있습니다.

제가 생각했을 때 클론코딩의 모범사례에 가깝고, 클론 코딩에 대한 좋은 예를 보실 수 있습니다.

✅마무리하며,

클론 코딩은 분명히 개발자로서의 역량을 보여줄 수 있는 좋은 방법입니다. 하지만 그 과정에서 중요한 것은 단순히 게임을 흉내 내는 것이 아니라, 게임의 핵심 메커니즘을 이해하고 그것을 구현하는 능력을 보여주는 것입니다. 단순히 비슷해 보이는 결과물을 만드는 것보다, 그 안에 숨겨진 원리를 이해하고 자신만의 방식으로 풀어내는 것이 더 중요합니다.

✅더불어 이벤트 홍보(?)

그래서, 이번에 저와 함께 클론 코딩을 도전해볼 사람을 찾습니다!! :)

[챌린지 개요]
😀현직 개발자 멘토와 함께 4주 동안 클론코딩 챌린지 도전할 사람 찾습니다!
각 분야별 유데미 멘토들과 함께 클론코딩부터 코드리뷰까지 할 수 있는 기회!

💪이번 챌린지는 [프론트엔드 / 백엔드 / 게임개발] 진행 됩니다 :)
유데미 개발 챌린지에서 개발자 커리어를 시작해보세요!

🥇챌린지 참여 혜택 무엇이 있나요?
 * 현직 개발자와 라이브 특강
 * 주차별 미션 제공
 * 멘토와 1:1 커피챗 (미션 과제 우수자 선정자)
 * 참가 혜택 : 유데미 개발 강의 할인 쿠폰팩, 지난 챌린지 특강 제공

💌챌린지 자세히 보러가기 :
https://udemy.wjtb.co.kr/event/id/272
🌞친구와 함께 신청하면 배민 상품권 제공!
https://forms.gle/2fxpfmh68ioELCwG8

모집/신청 기간 : 2024년 8월 19일(월) ~ 9월 22일(일)
챌린지 진행 기간 : 2024년 9월 23일(월) ~ 10월 18일(금)
제가 맡은 게임 개발 챌린지 주제는 “뱀파이어 서바이벌(뱀서류) 클론코딩"으로,
라이브 특강에서 포트폴리오가 되는 모작 만들기, 현업에서 사용하는 게임 프로그래밍 디자인 패턴과 테크닉, 수강생 코드리뷰까지 함께 다뤄볼 예정입니다.
많은 관심과 참여 부탁 드립니다.
감사합니다.

✅ 잘못된 클론 코딩 게임 업계에서 개발자들의 포트폴리오로 자주 나오는 요소는 클론 코딩입니다. 본인이 좋아하는 게임을 만들어보기도 하고, 지원하는 회사와 가장 밀접한 프로젝트를 만들어서 제출하기도 합니다. 물론 아주 잘 만든 분들도 있지만, 대부분은 제출한 클론 코드가 안 좋은 결과를 만드는 경우가 많습니다. 어떤 경우일까요? 제가 경험한 사례를 좀 공유해보려고 합니다. ❇️사례 1. 스크린샷뿐인 모작 3년 전쯤 마인크래프트 모작을 제출한 분이 있었습니다. 마치 마인크래프트처럼 보이는 월드와 블록들이 있는 스크린샷이 있었습니다. 정말 똑같다(?)는 생각이 들 정도로 잘 구성된 스샷이었습니다. 그리고, 내용에는 이 모작을 만드는데 몇 주가 걸렸고, 만들 때 어떤 엔진을 사용했는지 기입해 두셨습니다. 당연히 이분은 탈락했습니다. 모작을 할 때 중요한 것은, 이게 얼마나 걸렸고, 무슨 엔진을 썼는지보다, 어떻게 구현했는지가 가장 중요합니다. 그런 관점에서 비슷해 보이는 단편적인 스크린샷은 오히려 전혀 매력적이지 않습니다.오히려, 블록이 2개밖에 없더라도, 혹은 블록이 화이트 박스 형태더라도, 절차적으로 생성되는 월드나 직접 배치하는 샌드박스가 있다면, 훨씬 높은 점수를 줄 것 같습니다. ❇️사례 2. 핵심을 벗어난 모작 두 번째 사례는 캔디크러시 사가와 같은 매치3 퍼즐 게임 모작을 제출한 분이었습니다. 데모도 같이 보내주셨고, 본인이 작성한 핵심 소스 코드도 제출해 주셨습니다. 허나 아쉽게도 이분도 탈락했습니다. 가장 큰 이유는 데모를 플레이할 때 연쇄가 잘 되지 않는 점이었습니다.3-매치 게임의 핵심은 레벨 디자인도 중요하지만, 한번 매치가 되어 블록이 사라지면 그 자리를 다른 블록들이 채우면서 발생하는 연쇄작용에 있습니다. 그 연쇄작용하는 코드가 미완성 상태였고, 실제로 제출된 코드에서 연쇄 구현이 제대로 되지 않았음을 볼 수 있었습니다. 비슷한 사례로, 간혹 액션 게임 쪽에서 채용을 할 때 마영전 모작이나 리니지 모작도 자주 볼 수 있는데, 거의 대부분 탈락 처리됩니다. 우선, 마영전 모작의 경우 클라이언트-서버 구조를 굉장히 강조하는 분들이 많습니다. 사실 왜 그걸 강조하는지 잘 모르겠습니다. (어쩌면 학원에서 그렇게 시켰을 수도 있겠죠.) 마영전의 핵심은 멀티플레이 논타겟 액션입니다. 제가 본 마영전 모작 중에서는 아쉽게도 마영전의 논타겟 액션 동기화를 본인만의 방식으로 만들어서 설명해주신 분이 없었습니다. 리니지 모작도 마찬가지입니다. MMO 서버-클라이언트 구조라고 강조하는 분들을 많이 봅니다. 정말 놀랍게도, 만드는데 2주밖에 안 걸렸다는 분도 있었는데… 어필 포인트가 너무 어긋나서 할 말을 잃었던 것 같습니다. 실제로 그런 분들 중에서 MMO의 핵심 요소 중 하나인 월드 채널링이나 MMO에서 퀘스트와 같은 콘텐츠를 본인만의 방식으로 만들어서 설명해주신 분들은 없었습니다. ✅클론 코딩을 포트폴리오로 만드는 방법 위의 잘못된 클론 코딩 사례가 거의 포트폴리오에 있는 클론 코딩의 90%를 차지하기 때문에, 클론 코딩을 포트폴리오로 만드는 방법은 생각보다 쉽습니다. 바로 안티패턴을 피하는 것이죠. 우선, 클론할 게임의 핵심을 아는 것부터 시작해야 합니다.마인크래프트, 오버워치, 3-매치, 마영전, 리니지 등 다양한 게임들의 핵심은 모두 다릅니다. 그리고 주니어 개발자 입장에서 이런 핵심을 관통하기란 쉽지 않은 것도 사실입니다. 그러나 조금만 검색해보면 나오는 것도 맞습니다. 두 번째는 핵심 기믹만 모작하는 것도 가치가 있다는 것입니다.예를들면, 포탈2의 들어가는 포탈/나가는 포탈은 다양한 기술적 챌린지(렌더링, 공간 이동)가 있습니다. 총게임들의 Netcode(예측, 보간)들도 꽤 좋은 챌린지가 됩니다. 그래서 이런 기믹들은 만들어서 포트폴리오에 넣으면 게임플레이 프로그래머로 홍보하기 좋습니다. 개인적으로 이런 핵심 요소를 클론한 유튜브 하나를 추천해드리면, Mix and Jam 이 있습니다. 제가 생각했을 때 클론코딩의 모범사례에 가깝고, 클론 코딩에 대한 좋은 예를 보실 수 있습니다. ✅마무리하며, 클론 코딩은 분명히 개발자로서의 역량을 보여줄 수 있는 좋은 방법입니다. 하지만 그 과정에서 중요한 것은 단순히 게임을 흉내 내는 것이 아니라, 게임의 핵심 메커니즘을 이해하고 그것을 구현하는 능력을 보여주는 것입니다. 단순히 비슷해 보이는 결과물을 만드는 것보다, 그 안에 숨겨진 원리를 이해하고 자신만의 방식으로 풀어내는 것이 더 중요합니다. ✅더불어 이벤트 홍보(?) 그래서, 이번에 저와 함께 클론 코딩을 도전해볼 사람을 찾습니다!! :) [챌린지 개요]😀현직 개발자 멘토와 함께 4주 동안 클론코딩 챌린지 도전할 사람 찾습니다!각 분야별 유데미 멘토들과 함께 클론코딩부터 코드리뷰까지 할 수 있는 기회! 💪이번 챌린지는 [프론트엔드 / 백엔드 / 게임개발] 진행 됩니다 :)유데미 개발 챌린지에서 개발자 커리어를 시작해보세요! 🥇챌린지 참여 혜택 무엇이 있나요?<ul><li>현직 개발자와 라이브 특강</li><li>주차별 미션 제공</li><li>멘토와 1:1 커피챗 (미션 과제 우수자 선정자)</li><li>참가 혜택 : 유데미 개발 강의 할인 쿠폰팩, 지난 챌린지 특강 제공</li></ul> 💌챌린지 자세히 보러가기 : https://udemy.wjtb.co.kr/event/id/272🌞친구와 함께 신청하면 배민 상품권 제공! https://forms.gle/2fxpfmh68ioELCwG8 모집/신청 기간 : 2024년 8월 19일(월) ~ 9월 22일(일)챌린지 진행 기간 : 2024년 9월 23일(월) ~ 10월 18일(금)제가 맡은 게임 개발 챌린지 주제는 “뱀파이어 서바이벌(뱀서류) 클론코딩"으로,라이브 특강에서 포트폴리오가 되는 모작 만들기, 현업에서 사용하는 게임 프로그래밍 디자인 패턴과 테크닉, 수강생 코드리뷰까지 함께 다뤄볼 예정입니다.많은 관심과 참여 부탁 드립니다.감사합니다.

udemy.wjtb.co.kr

게임개발자를 위한 클론코딩

입사하려고 준비한 포트폴리오에 게임 클론 코딩을 스샷 붙여넣기로 얼버무린 프로젝트를 보여주는게 가능한가...;;

Since the dawn of computing, humans have sought to estimate how long it takes to build software, and for just as long, they've consistently failed. Estimating even medium-sized projects is devilishly difficult, and estimating large projects is virtually i

Software estimates have never worked and never will

9월의 시작입니다. 9월동안 어떠한 프로젝트들이 진행될 것인지, 그리고 앞으로의 한 주는 어떤일들을 할지 아마 여러 미팅들이 잡혀있을 것 같은데요. 그런 과제 정리에 있어서 얼마나 걸릴지 일정 추정하는 것을 빼놓을 수 없을 것 같습니다.

하지만 항상 이 추정은 맞을 듯 안맞을 듯, 꼭 하루 이틀은 더 걸리게 되고, 다른 사람의 일정이 밀리면서 나의 일정도 밀리고, 맞을 듯 안맞을 듯 항상 고민스럽습니다. 이런 일정 추정의 어려움은 dhh에게도 동일한가봅니다.

블로그 글에서 소프트웨어 개발의 본질적인 복잡성과 불확실성 때문에, 추정이 실질적으로 무의미하다고 주장합니다.
 * 소프트웨어 개발에서의 추정은 종종 비현실적이며, 실제 작업의 복잡성을 반영하지 못합니다. 이는 개발자들이 실제로 필요한 작업을 수행하는 데 방해가 됩니다.
 * 애자일 방법론이 도입되었지만, 실제로는 관리자의 요구에 의해 비효율적인 프로세스가 강화되는 경향이 있습니다. 이로 인해 개발자들은 불필요한 압박을 받으며, 창의적인 작업을 수행하기 어려워집니다.
 * 많은 기업들이 애자일을 도입했지만, 실제로는 개발자들에게 도움이 되기보다는 관리자의 통제를 강화하는 수단으로 사용됩니다. 이는 개발자들의 동기를 저하시킬 뿐만 아니라, 팀의 생산성에도 부정적인 영향을 미칠 수 있습니다.
 * 소프트웨어 개발의 복잡성을 이해하고, 추정 대신 더 유연한 접근 방식을 채택해야 한다고 강조합니다. 이는 개발자들이 더 나은 결과를 도출할 수 있도록 돕는 방법이 될 것입니다.

소프트웨어 개발의 세계는 복잡하고 예측할 수 없는 요소로 가득 차 있습니다. 이러한 환경에서 정확한 추정치를 요구하는 것은 마치 바람을 잡으려는 시도와도 같다고 합니다.

https://world.hey.com/dhh/software-estimates-have-never-worked-and-never-will-a41a9c71

9월의 시작입니다. 9월동안 어떠한 프로젝트들이 진행될 것인지, 그리고 앞으로의 한 주는 어떤일들을 할지 아마 여러 미팅들이 잡혀있을 것 같은데요. 그런 과제 정리에 있어서 얼마나 걸릴지 일정 추정하는 것을 빼놓을 수 없을 것 같습니다. 하지만 항상 이 추정은 맞을 듯 안맞을 듯, 꼭 하루 이틀은 더 걸리게 되고, 다른 사람의 일정이 밀리면서 나의 일정도 밀리고, 맞을 듯 안맞을 듯 항상 고민스럽습니다. 이런 일정 추정의 어려움은 dhh에게도 동일한가봅니다. 블로그 글에서 소프트웨어 개발의 본질적인 복잡성과 불확실성 때문에, 추정이 실질적으로 무의미하다고 주장합니다.<ul ><li>소프트웨어 개발에서의 추정은 종종 비현실적이며, 실제 작업의 복잡성을 반영하지 못합니다. 이는 개발자들이 실제로 필요한 작업을 수행하는 데 방해가 됩니다.</li><li>애자일 방법론이 도입되었지만, 실제로는 관리자의 요구에 의해 비효율적인 프로세스가 강화되는 경향이 있습니다. 이로 인해 개발자들은 불필요한 압박을 받으며, 창의적인 작업을 수행하기 어려워집니다.</li><li>많은 기업들이 애자일을 도입했지만, 실제로는 개발자들에게 도움이 되기보다는 관리자의 통제를 강화하는 수단으로 사용됩니다. 이는 개발자들의 동기를 저하시킬 뿐만 아니라, 팀의 생산성에도 부정적인 영향을 미칠 수 있습니다. </li><li>소프트웨어 개발의 복잡성을 이해하고, 추정 대신 더 유연한 접근 방식을 채택해야 한다고 강조합니다. 이는 개발자들이 더 나은 결과를 도출할 수 있도록 돕는 방법이 될 것입니다.</li></ul> 소프트웨어 개발의 세계는 복잡하고 예측할 수 없는 요소로 가득 차 있습니다. 이러한 환경에서 정확한 추정치를 요구하는 것은 마치 바람을 잡으려는 시도와도 같다고 합니다. https://world.hey.com/dhh/software-estimates-have-never-worked-and-never-will-a41a9c71

일정 추정은 효과가 없고 앞으로도 없을 것입니다.

01 . 프리드리히 니체가 쓴 ⟪선악의 저편⟫에는 이런 말이 나옵니다.
'괴물과 싸우는 사람은 스스로 괴물이 되지 않도록 주의해야 한다. 우리가 괴물의 심연을 오랫동안 들여다보면, 심연 또한 우리를 들여다보기 때문이다.'
부당한 것들에 저항하는 행위 자체는 매우 중요하고 용감한 것이지만 그 대상을 다룰 때는 오히려 부당한 방법을 사용하지 않도록 주의해야 한다는 말입니다. '저들이 저토록 나쁜데 어떻게 좋게 해결할 수 있나?'라는 생각에 심취하면 나 역시 그들과 다르지 않은 괴물이 되어간단 거죠.

02 . 사회를 나와보면 좋은 사람만큼 나쁜 사람도 많다는 걸 절실히 체감하게 됩니다. 솔직히 말하면 적당히 좋고, 적당히 나쁜 중간인 사람을 찾는 게 현실적으론 더 어려운 일인지도 모르죠. 지금 여러분들께서 떠올릴 수 있는 주위 사람들만 봐도 '좋은 사람' 혹은 '그렇지 않은 사람'의 범주에 바로 포함시킬 수 있는 인물들이 많을 테니까요, 지극히 개인적인 잣대고 그들의 속 사정을 하나하나 헤아리지 못하는 데서 오는 오류라고 하더라도 사회생활을 함에 있어 인간관계에 대한 가치관을 가지고 산다는 건 사실 꽤나 중요한 문제입니다.

03 . 마냥 짧지도, 마냥 길지도 않은 정도의 사회생활을 해오며 배운 것 중 하나는 나쁜 사람들은 혼자 활동하지 않는다는 사실이었습니다. 그들은 늘 자신의 행동을 합리화하는 데 바빴고, 합리화의 과정이 끝나면 누군가로부터 동의나 공감을 얻어내는 데 주력했기 때문이죠. 쉽게 말해 '내가 하는 이 언행들은 합당한 목표나 이유가 있는 것이고, 여기에 뜻을 같이 해주는 사람도 적지 않다'는 사실을 은연중에 공표하는 것이었습니다.
때문에 전혀 우발적이지도, 감정적이지도 않으며 오히려 나쁜 것들을 행해 끝없는 빌드업(?) 하는 부류의 사람들에 가까웠죠. 심지어는 나쁜 행위가 끝나고 나면 그 행위에 동참한 사람들이 죄책감을 갖지 않도록 케어해주는 행위까지 잊지 않았으니까요.

04 . 안타깝지만 이런 과정에 동원되는 사람들은 소위 말에 늘 '만만한 사람들'이었습니다.
니체가 말한 것처럼 괴물과 부딪히는 사람들은 크게 두 가지 부류의 사람들이 많습니다. 하나는 같이 괴물이 되어 진흙탕 싸움을 벌이는 종족이고, 다른 하나는 끝까지 본인의 선함을 놓지 않고 정공법을 택하는 사람들이죠. 그러니 악한 사람들의 입장에선 이 두 부류 모두 달가울 수 없습니다. 자기와 전혀 다른 사람과의 싸움도, 자기와 똑같이 나쁜 길을 택한 사람과의 싸움도 버거운 것은 매한가지거든요.

05 . 때문에 제 주위 경험에 비춰봐도 나쁜 사람은 늘 만만한 사람부터 골랐습니다. 옳고 그름에 대한 기준이 선명하지 않은 사람들, 어느 한쪽으로 치우치지는 않지만 타이밍에 따라서 쉽게 양쪽을 오갈 수 있는 사람들, 나쁜 것도 금방 잊고 좋은 것도 금방 잊는 사람들, 누군가의 설득에 쉽게 감화되고 타인의 사정에 극한 공감을 일으키는 사람들이 대부분 그런 유형의 사람들이었습니다. 물론 인간 군상을 일반화한다는 게 애초에 불가능한 일이지만, 적어도 이런 글로 내 생각을 표현할 땐 또 그에 맞는 표현법들이 있는 것이니까요, 제 경험에 기대어 제 기준으로 분류해낸 것임을 감안하고 들어주시면 좋겠습니다.

06 . 그래서 회사 생활을 오래 같이한 동료들 중 일부는 가끔 이런 말을 하기도 합니다. '나는 그때 그 사람이 그렇게까지 나쁜 사람인지도 몰랐고, 우리에게 시킨 지시들이 그렇게까지 나쁜 일인지도 몰랐다'고 말입니다. 이 역시 각자의 가치관을 가늠좌로 놓고 해결해야 할 문제지만 적어도 '뒤돌아보니 나쁜 사람의, 나쁜 지시였던 것 같다'는 걸 인정하는 걸 보면 모두가 느끼는 것을 뒤늦게 깨닫는 사람들도 적지 않았음이 분명합니다. 그리고 그 사람들은 대부분 나쁜 사람이 하는 나쁜 일에 일정 부분이라도 동원된 사람들이었거나 동의 혹은 공감을 해준 사람들이었죠.

07 . 물론 그런 만만한 사람들이 모두 어리석은 것은 아니니 스스로 빠져나올 힘 역시 갖추고 있겠지만 제가 안타까웠던 부분은 누군가는 그런 일로 인해 악하지 않은 사람마저도 나쁜 사람으로 규정하고 기억한다는 사실이었습니다. 가끔은 그 사이에 저와 친한 사람도 끼어있어서 나름의 해명을 해주려고 해도 '애초에 그런 사람의 부당한 지시를 따랐다는 것에서 본인 책임도 있는 것 아닌가요?'라는 반문을 들을 때면 정신이 번쩍 들더라고요. '아, 내가 지금 하는 행동이 오히려 그 사람에게도, 이 사람에게도 더 해가 될 수 있겠구나' 싶었던 겁니다.

08 . 하지만 슬프게도 만만한 사람으로 여겨지는 사람 중에 스스로를 '만만한 사람'으로 생각하는 이는 단 한 명도 없습니다. 그럼에도 불구하고 나쁜 사람이 만만한 사람을 선택하는 과정을 지켜보고 있노라면 왜 그 사람을 선택하는지가 뻔히 보이곤 하죠. 자신의 목표를 감화시키는데도 유리하고, 때론 자신의 의견에 힘을 실어주는 역할도 마다하지 않으며, 무엇보다 자기 손으로 직접 뭔가를 하지 않아도 그 사람을 통해 목적을 달성할 수 있기 때문입니다. 그러니 결코 가볍게 여길 문제는 아닌 거죠.

09 . '만만하다'란 말은 우리말 중에서도 정확한 어원을 찾기 어려운 말 중 하나입니다. 유력한 설은 '찰 만(滿)'자 두 개 이어 붙여서 '이 정도면 적당히 찼고, 부족함이 없는 상태다'를 뜻하는 말이 형용사로 굳어지며 '다루기 쉽고, 접근하기 쉬운 상태 혹은 그런 사람'으로 확대되었다는 가정입니다. 물건이야 이 만만한 상태가 쓸모를 가질지 모르지만 사실 사람에게 있어서는 절대 좋은 평판일 수 없습니다. 무엇보다 이 길을 자의로 택하는 사람이 있을 리 없으니까요.
그렇다고 오늘의 결론이 '모든 아젠다에 있어서 선악 중 하나를 택하라'고 귀결될 수는 없을 겁니다. 우리 삶에 이토록 다양한 문제들을 모조리 심판대에 올린다는 것 역시 불가능한 일이고요.

10 . 하지만 나쁜 사람이 나쁜 일을 할 때 나를 선택한다는 사실을 인지하지 못한다면 이는 자신의 역량도, 인품도, 평판도 모조리 깎아먹는 행위가 됩니다. '끼리끼리는 공학'이라는 가벼운 말로 대체하고 싶은 생각은 없지만 때로는 '나쁜 사람을 걸러내는 능력이 없는 것만으로도 나쁘다'는 평가가 존재하는 만큼 이는 반드시 확보해야 할 능력치 중 하나이기도 하죠.
조금 씁쓸한 이야기들을 풀어놓았지만 한 달의 마지막이 저무는 시점에서 또 한 번 저 스스로를 바로잡게 되는 말인 것 같기도 합니다. 나쁜 사람들의 달콤한 말에 무너질 정도로 어리석은 행동을 한 적은 없는지, 그게 나쁜 행동임을 알면서도 좋은 사람 컴플렉스를 버리고 싶지 않아 거절을 미룬 적은 없는지 일단 저 자신에게 먼저 물어봐야 할 지점이 존재하는 것이니 말이죠.

01 . 프리드리히 니체가 쓴 ⟪선악의 저편⟫에는 이런 말이 나옵니다. '괴물과 싸우는 사람은 스스로 괴물이 되지 않도록 주의해야 한다. 우리가 괴물의 심연을 오랫동안 들여다보면, 심연 또한 우리를 들여다보기 때문이다.'부당한 것들에 저항하는 행위 자체는 매우 중요하고 용감한 것이지만 그 대상을 다룰 때는 오히려 부당한 방법을 사용하지 않도록 주의해야 한다는 말입니다. '저들이 저토록 나쁜데 어떻게 좋게 해결할 수 있나?'라는 생각에 심취하면 나 역시 그들과 다르지 않은 괴물이 되어간단 거죠. 02 . 사회를 나와보면 좋은 사람만큼 나쁜 사람도 많다는 걸 절실히 체감하게 됩니다. 솔직히 말하면 적당히 좋고, 적당히 나쁜 중간인 사람을 찾는 게 현실적으론 더 어려운 일인지도 모르죠. 지금 여러분들께서 떠올릴 수 있는 주위 사람들만 봐도 '좋은 사람' 혹은 '그렇지 않은 사람'의 범주에 바로 포함시킬 수 있는 인물들이 많을 테니까요, 지극히 개인적인 잣대고 그들의 속 사정을 하나하나 헤아리지 못하는 데서 오는 오류라고 하더라도 사회생활을 함에 있어 인간관계에 대한 가치관을 가지고 산다는 건 사실 꽤나 중요한 문제입니다. 03 . 마냥 짧지도, 마냥 길지도 않은 정도의 사회생활을 해오며 배운 것 중 하나는 나쁜 사람들은 혼자 활동하지 않는다는 사실이었습니다. 그들은 늘 자신의 행동을 합리화하는 데 바빴고, 합리화의 과정이 끝나면 누군가로부터 동의나 공감을 얻어내는 데 주력했기 때문이죠. 쉽게 말해 '내가 하는 이 언행들은 합당한 목표나 이유가 있는 것이고, 여기에 뜻을 같이 해주는 사람도 적지 않다'는 사실을 은연중에 공표하는 것이었습니다. 때문에 전혀 우발적이지도, 감정적이지도 않으며 오히려 나쁜 것들을 행해 끝없는 빌드업(?) 하는 부류의 사람들에 가까웠죠. 심지어는 나쁜 행위가 끝나고 나면 그 행위에 동참한 사람들이 죄책감을 갖지 않도록 케어해주는 행위까지 잊지 않았으니까요. 04 . 안타깝지만 이런 과정에 동원되는 사람들은 소위 말에 늘 '만만한 사람들'이었습니다. 니체가 말한 것처럼 괴물과 부딪히는 사람들은 크게 두 가지 부류의 사람들이 많습니다. 하나는 같이 괴물이 되어 진흙탕 싸움을 벌이는 종족이고, 다른 하나는 끝까지 본인의 선함을 놓지 않고 정공법을 택하는 사람들이죠. 그러니 악한 사람들의 입장에선 이 두 부류 모두 달가울 수 없습니다. 자기와 전혀 다른 사람과의 싸움도, 자기와 똑같이 나쁜 길을 택한 사람과의 싸움도 버거운 것은 매한가지거든요. 05 . 때문에 제 주위 경험에 비춰봐도 나쁜 사람은 늘 만만한 사람부터 골랐습니다. 옳고 그름에 대한 기준이 선명하지 않은 사람들, 어느 한쪽으로 치우치지는 않지만 타이밍에 따라서 쉽게 양쪽을 오갈 수 있는 사람들, 나쁜 것도 금방 잊고 좋은 것도 금방 잊는 사람들, 누군가의 설득에 쉽게 감화되고 타인의 사정에 극한 공감을 일으키는 사람들이 대부분 그런 유형의 사람들이었습니다. 물론 인간 군상을 일반화한다는 게 애초에 불가능한 일이지만, 적어도 이런 글로 내 생각을 표현할 땐 또 그에 맞는 표현법들이 있는 것이니까요, 제 경험에 기대어 제 기준으로 분류해낸 것임을 감안하고 들어주시면 좋겠습니다. 06 . 그래서 회사 생활을 오래 같이한 동료들 중 일부는 가끔 이런 말을 하기도 합니다. '나는 그때 그 사람이 그렇게까지 나쁜 사람인지도 몰랐고, 우리에게 시킨 지시들이 그렇게까지 나쁜 일인지도 몰랐다'고 말입니다. 이 역시 각자의 가치관을 가늠좌로 놓고 해결해야 할 문제지만 적어도 '뒤돌아보니 나쁜 사람의, 나쁜 지시였던 것 같다'는 걸 인정하는 걸 보면 모두가 느끼는 것을 뒤늦게 깨닫는 사람들도 적지 않았음이 분명합니다. 그리고 그 사람들은 대부분 나쁜 사람이 하는 나쁜 일에 일정 부분이라도 동원된 사람들이었거나 동의 혹은 공감을 해준 사람들이었죠. 07 . 물론 그런 만만한 사람들이 모두 어리석은 것은 아니니 스스로 빠져나올 힘 역시 갖추고 있겠지만 제가 안타까웠던 부분은 누군가는 그런 일로 인해 악하지 않은 사람마저도 나쁜 사람으로 규정하고 기억한다는 사실이었습니다. 가끔은 그 사이에 저와 친한 사람도 끼어있어서 나름의 해명을 해주려고 해도 '애초에 그런 사람의 부당한 지시를 따랐다는 것에서 본인 책임도 있는 것 아닌가요?'라는 반문을 들을 때면 정신이 번쩍 들더라고요. '아, 내가 지금 하는 행동이 오히려 그 사람에게도, 이 사람에게도 더 해가 될 수 있겠구나' 싶었던 겁니다. 08 . 하지만 슬프게도 만만한 사람으로 여겨지는 사람 중에 스스로를 '만만한 사람'으로 생각하는 이는 단 한 명도 없습니다. 그럼에도 불구하고 나쁜 사람이 만만한 사람을 선택하는 과정을 지켜보고 있노라면 왜 그 사람을 선택하는지가 뻔히 보이곤 하죠. 자신의 목표를 감화시키는데도 유리하고, 때론 자신의 의견에 힘을 실어주는 역할도 마다하지 않으며, 무엇보다 자기 손으로 직접 뭔가를 하지 않아도 그 사람을 통해 목적을 달성할 수 있기 때문입니다. 그러니 결코 가볍게 여길 문제는 아닌 거죠. 09 . '만만하다'란 말은 우리말 중에서도 정확한 어원을 찾기 어려운 말 중 하나입니다. 유력한 설은 '찰 만(滿)'자 두 개 이어 붙여서 '이 정도면 적당히 찼고, 부족함이 없는 상태다'를 뜻하는 말이 형용사로 굳어지며 '다루기 쉽고, 접근하기 쉬운 상태 혹은 그런 사람'으로 확대되었다는 가정입니다. 물건이야 이 만만한 상태가 쓸모를 가질지 모르지만 사실 사람에게 있어서는 절대 좋은 평판일 수 없습니다. 무엇보다 이 길을 자의로 택하는 사람이 있을 리 없으니까요. 그렇다고 오늘의 결론이 '모든 아젠다에 있어서 선악 중 하나를 택하라'고 귀결될 수는 없을 겁니다. 우리 삶에 이토록 다양한 문제들을 모조리 심판대에 올린다는 것 역시 불가능한 일이고요. 10 . 하지만 나쁜 사람이 나쁜 일을 할 때 나를 선택한다는 사실을 인지하지 못한다면 이는 자신의 역량도, 인품도, 평판도 모조리 깎아먹는 행위가 됩니다. '끼리끼리는 공학'이라는 가벼운 말로 대체하고 싶은 생각은 없지만 때로는 '나쁜 사람을 걸러내는 능력이 없는 것만으로도 나쁘다'는 평가가 존재하는 만큼 이는 반드시 확보해야 할 능력치 중 하나이기도 하죠. 조금 씁쓸한 이야기들을 풀어놓았지만 한 달의 마지막이 저무는 시점에서 또 한 번 저 스스로를 바로잡게 되는 말인 것 같기도 합니다. 나쁜 사람들의 달콤한 말에 무너질 정도로 어리석은 행동을 한 적은 없는지, 그게 나쁜 행동임을 알면서도 좋은 사람 컴플렉스를 버리고 싶지 않아 거절을 미룬 적은 없는지 일단 저 자신에게 먼저 물어봐야 할 지점이 존재하는 것이니 말이죠.

나쁜 사람은 만만한 사람부터 고르니까

제발 들어주세요...저 혼자 듣기 아깝습니다🙏 [수강범위] 간단한 SQL문은 작성할 수 있어서 헷갈리는 부분 + 연습 문제 위주로 수강 하였습니다. [수강평] 1. 강의의 구성과 설명이 정갈함 : 제가 들었던 SQL 강의 중에 제일 강의의 짜임이 좋고, 설명도 간략하게 핵심만 알려 주셔서 너무 좋았습니다. 2.

망고맛있어님의 생생한 수강평, 초보자를 위한 BigQuery(SQL) 입문 강... - 인프런 | 수강평

제가 출시했던 강의의 수강평을 보고, 비슷한 경험을 하는 분들에게 도움이 될 것 같아 공유드려요.

망고맛있어님이 작성해주신 수강평이에요. 제가 의도한 부분을 느껴주셔서 감사합니다.

---
제발 들어주세요...저 혼자 듣기 아깝습니다🙏

[수강범위] 간단한 SQL문은 작성할 수 있어서 헷갈리는 부분 + 연습 문제 위주로 수강 하였습니다.

[수강평]
1. 강의의 구성과 설명이 정갈함 : 제가 들었던 SQL 강의 중에 제일 강의의 짜임이 좋고, 설명도 간략하게 핵심만 알려 주셔서 너무 좋았습니다.
2. 헷갈리는 부분, 어려운 부분을 잘 집어 줌 : 현업에서 SQL을 자주 사용하는 건 아니라, 자주 까먹기도 하고 코드를 길게 써볼 일이 별로 없었는데, 강의를 수강 하면서 다시 기본기도 익히고 어려워하는 부분에 대하여 점검할 수 있어 좋았습니다.
3. 실무자를 위한 학습 : 코딩테스트, 형식적인 교육을 위한 학습이 아니라 현업에서 종사하면서 깨달을 수 있는 SQL 쿼리 작성법 위주로 설명해 주셔서 진짜 너무 좋았습니다.
4. 블로그에 정리가 잘되어 있음 : 카일스쿨 원래 잘 알고 있었는데, 강의를 위해 따로 페이지 정리가 되어 있는 걸 보고 감탄했습니다. 심지어 초급자라면 실수 할 수 있는 에러도 친절하게 적어주셔서 학습하는데 도움이 되었습니다. 최고!
5. 무료 ⭐<- 이보다 더 좋은 장점은 없다 : SQL 강의 중 유료가 생각보다 많은데, 이 퀄리티에 심지어 무료라니... 기대 안하고 수강했는데, 퀄리티에 놀라고 무료인 점에 한 번 더 놀라고 갑니다
6. 바라는 점 제가 완강을 한 건 아니어서 못 찾은 걸 수 도 있는데, 연습문제에 대한 정답쿼리를 정리해둔 페이지가 있었으면 좋겠습니다. 영상 보면서 치니까 빼먹는 경우도 있더라구요!

[추천대상자]
- SQL입문자
진짜 심플하게 필요한 내용을 잘 설명해 주셔서 입문자들에게 추천합니다!!! 저는 혼자 끙끙거리며 SQL을 독학했는데요! 그 때, 이 강의를 들었으면 시간을 엄청 절약할 수 있었을텐데 하고 아쉬움이 있었습니다. 그 만큼 진짜 강추합니다!

- 코딩테스트 준비생
제가 느끼기에 초급, 중급 정도의 난이도였는데, SQL로 간단한 코딩테스트를 준비하는 분들에게도 도움이 될 것 같습니다. 단순히 쿼리를 짜서 정답을 맞추는 학습이 아니라, 왜 이렇게 짰는지 과정을 익힐 수 있어 코드인터뷰?에서 점수를 좀 얻을 수 있지 않을까 예상해봅니다.

혼자 공부하면서 생각보다 이해가 잘되고, 정리되어 있는 자료를 찾기 어려울 때도 많은데, 그럴 때마다 카일 블로그가 많은 도움이 됩니다. 항상 감사하게 보고 있습니다. 개인적으로 현업에서 사용하는 빅데이터 엔지니어링 도구 사용과 같은 강의도 생겼으면 좋겠습니다! 번창하세요

https://inf.run/Kviqr

제가 출시했던 강의의 수강평을 보고, 비슷한 경험을 하는 분들에게 도움이 될 것 같아 공유드려요. 망고맛있어님이 작성해주신 수강평이에요. 제가 의도한 부분을 느껴주셔서 감사합니다. ---제발 들어주세요...저 혼자 듣기 아깝습니다🙏 [수강범위] 간단한 SQL문은 작성할 수 있어서 헷갈리는 부분 + 연습 문제 위주로 수강 하였습니다. [수강평] 1. 강의의 구성과 설명이 정갈함 : 제가 들었던 SQL 강의 중에 제일 강의의 짜임이 좋고, 설명도 간략하게 핵심만 알려 주셔서 너무 좋았습니다. 2. 헷갈리는 부분, 어려운 부분을 잘 집어 줌 : 현업에서 SQL을 자주 사용하는 건 아니라, 자주 까먹기도 하고 코드를 길게 써볼 일이 별로 없었는데, 강의를 수강 하면서 다시 기본기도 익히고 어려워하는 부분에 대하여 점검할 수 있어 좋았습니다. 3. 실무자를 위한 학습 : 코딩테스트, 형식적인 교육을 위한 학습이 아니라 현업에서 종사하면서 깨달을 수 있는 SQL 쿼리 작성법 위주로 설명해 주셔서 진짜 너무 좋았습니다. 4. 블로그에 정리가 잘되어 있음 : 카일스쿨 원래 잘 알고 있었는데, 강의를 위해 따로 페이지 정리가 되어 있는 걸 보고 감탄했습니다. 심지어 초급자라면 실수 할 수 있는 에러도 친절하게 적어주셔서 학습하는데 도움이 되었습니다. 최고! 5. 무료 ⭐&lt;- 이보다 더 좋은 장점은 없다 : SQL 강의 중 유료가 생각보다 많은데, 이 퀄리티에 심지어 무료라니... 기대 안하고 수강했는데, 퀄리티에 놀라고 무료인 점에 한 번 더 놀라고 갑니다 6. 바라는 점 제가 완강을 한 건 아니어서 못 찾은 걸 수 도 있는데, 연습문제에 대한 정답쿼리를 정리해둔 페이지가 있었으면 좋겠습니다. 영상 보면서 치니까 빼먹는 경우도 있더라구요! [추천대상자]- SQL입문자진짜 심플하게 필요한 내용을 잘 설명해 주셔서 입문자들에게 추천합니다!!! 저는 혼자 끙끙거리며 SQL을 독학했는데요! 그 때, 이 강의를 들었으면 시간을 엄청 절약할 수 있었을텐데 하고 아쉬움이 있었습니다. 그 만큼 진짜 강추합니다! - 코딩테스트 준비생 제가 느끼기에 초급, 중급 정도의 난이도였는데, SQL로 간단한 코딩테스트를 준비하는 분들에게도 도움이 될 것 같습니다. 단순히 쿼리를 짜서 정답을 맞추는 학습이 아니라, 왜 이렇게 짰는지 과정을 익힐 수 있어 코드인터뷰?에서 점수를 좀 얻을 수 있지 않을까 예상해봅니다. 혼자 공부하면서 생각보다 이해가 잘되고, 정리되어 있는 자료를 찾기 어려울 때도 많은데, 그럴 때마다 카일 블로그가 많은 도움이 됩니다. 항상 감사하게 보고 있습니다. 개인적으로 현업에서 사용하는 빅데이터 엔지니어링 도구 사용과 같은 강의도 생겼으면 좋겠습니다! 번창하세요 https://inf.run/Kviqr

인프런

SQL(BigQuery) 무료 강의 수강평

Have you noticed that Git is so integral to working with code that people hardly ever include it in their tech stack or on their CV at all? The assumption is you know it already, or at least enough...

The guide to Git I never had.

개발자로서 우리의 일상은 코드를 읽고, 작성하고, 검토하는 데 집중되어 있습니다. Git은 우리가 사용하는 도구 중 가장 중요한 것 중 하나라고 할 수 있습니다. Git의 기능과 특징을 마스터하는 것은 개발자로서 자신에게 할 수 있는 최고의 투자 중 하나입니다.
 
브랜치 (Branches)
Git 저장소에는 "main" 또는 "master"(deprecated)라는 메인 개발 라인이 있으며, 여기서 여러 브랜치가 분기됩니다. 이 브랜치들은 동시에 여러 기능이나 수정을 병행하여 작업할 수 있도록 해줍니다.

커밋 (Commits)
Git 커밋은 업데이트된 코드를 묶어 특정 시점의 프로젝트 코드를 캡처합니다. 각 커밋은 이전 커밋 이후로 이루어진 변경사항을 기록하며, 프로젝트 개발의 전체적인 역사를 구축합니다.

커밋을 참조할 때는 일반적으로 고유한 암호화 해시 값을 사용합니다.
git show abc123def456789

이 명령어는 해당 해시 값을 가진 커밋의 상세 정보를 보여줍니다.
 
태그 (Tags)
Git 태그는 Git 역사 내에서 주요 이정표를 나타내며, 일반적으로 릴리스, 버전, 또는 중요한 커밋을 표시합니다. 이러한 태그는 프로젝트의 여정에서 특정 시점을 나타내는 데 매우 유용합니다.

헤드 (HEAD)
현재 체크아웃된 브랜치의 가장 최신 커밋은 HEAD에 의해 표시되며, 저장소 내의 모든 참조를 가리킬 수 있는 포인터 역할을 합니다. 특정 브랜치에 있을 때, HEAD는 해당 브랜치의 최신 커밋을 가리킵니다. 가끔 HEAD는 브랜치의 끝이 아닌 특정 커밋을 직접 가리킬 수도 있습니다.
 
스테이지 (Stages)
Git 단계를 이해하는 것은 Git 워크플로우를 이해하는 데 매우 중요합니다. 단계는 파일에 대한 변경사항이 커밋되기 전에 발생하는 논리적 전환을 나타냅니다. Git 단계를 더 자세히 살펴봅시다:

 * 작업 디렉토리 (Working directory) 👷: 작업 디렉토리는 프로젝트 파일을 수정하고 생성하는 곳입니다. 로컬 머신에서 파일의 현재 상태를 나타냅니다.
 * 스테이징 영역 (Staging area) 🚉: 스테이징 영역은 변경사항을 커밋하기 전에 준비하는 대기 영역 또는 사전 커밋 구역입니다.
 * 로컬 저장소 (Local repository) 🗄️: 로컬 저장소는 Git이 커밋된 변경사항을 영구히 저장하는 곳입니다. 프로젝트의 역사를 검토하고, 이전 상태로 되돌리며, 동일한 코드베이스에서 다른 사람들과 협업할 수 있게 해줍니다.
 * 원격 저장소 (Remote repository) 🛫: 원격 저장소는 중앙 서버(예: GitHub, GitLab, Bitbucket)에 위치하며, 프로젝트를 공유하고 다른 사람들과 협업할 수 있는 곳입니다.
 
Git 시작하기
어디서부터 시작해야 할지 고민이라면, Git에서는 작업 공간(workspace)에서 시작해야 합니다. 기존의 저장소(repository)를 포크(fork)하거나 클론(clone)하여 그 작업 공간의 복사본을 가질 수 있습니다. 만약 완전히 새롭게 로컬 폴더에서 시작하고자 한다면, 해당 폴더를 Git 저장소로 만들기 위해 git init 명령어를 사용해야 합니다. 다음 단계로는 자격 증명 설정을 반드시 잊지 말아야 합니다.

브랜치 작업
로컬에서 작업할 때는 현재 어떤 브랜치에 있는지 아는 것이 중요합니다. 다음 명령어들이 유용합니다:
# Will show the changes in the local repository
git branch 
# Or create a branch directly with
git branch feature-branch-name

브랜치 간 전환을 위해서는:
git switch

또한, 브랜치 간 전환뿐만 아니라 다음과 같이 할 수도 있습니다:
git checkout 
# A shortcut to switch to a branch that is yet to be created with the -b flag 
git checkout -b feature-branch-name

저장소의 상태를 확인하려면 다음을 사용하십시오:
git status

현재 브랜치를 항상 명확하게 보기 위해서는 터미널에 브랜치를 표시하는 것이 좋습니다. 이를 도와주는 여러 터미널 애드온이 있습니다.

커밋 작업
커밋을 작업할 때, git commit -m을 사용하여 변경 사항을 기록하고, git amend를 사용하여 가장 최근의 커밋을 수정하며, 커밋 메시지 규칙을 지키는 것이 중요합니다.
git commit -m "의미 있는 메시지"

마지막 커밋에 변경 사항이 있을 때는 새 커밋을 만들지 않고 --amend 플래그를 사용하여 가장 최근 커밋을 수정할 수 있습니다:
# 변경사항을 추가
git add .
git commit --amend

이 명령어는 기본 텍스트 편집기를 열어 필요하면 커밋 메시지를 수정할 수 있게 합니다.
git push origin your_branch --force

기본적으로 자주 커밋하는 것이 더 좋습니다. 이는 진행 상황을 잃거나 스테이징되지 않은 변경사항을 실수로 리셋하는 것을 방지합니다. 이후에 여러 커밋을 합치거나 인터랙티브 리베이스(interactive rebase)를 통해 히스토리를 재작성할 수 있습니다.
 
git log를 사용하여 최근 커밋부터 과거로 거슬러 올라가는 순서로 커밋 목록을 확인할 수 있습니다.
 

번역: [https://ducktopia.tistory.com/132]
원문:

개발자로서 우리의 일상은 코드를 읽고, 작성하고, 검토하는 데 집중되어 있습니다. Git은 우리가 사용하는 도구 중 가장 중요한 것 중 하나라고 할 수 있습니다. Git의 기능과 특징을 마스터하는 것은 개발자로서 자신에게 할 수 있는 최고의 투자 중 하나입니다.&nbsp;브랜치 (Branches)Git 저장소에는 "main" 또는 "master"(deprecated)라는 메인 개발 라인이 있으며, 여기서 여러 브랜치가 분기됩니다. 이 브랜치들은 동시에 여러 기능이나 수정을 병행하여 작업할 수 있도록 해줍니다. 커밋 (Commits)Git 커밋은 업데이트된 코드를 묶어 특정 시점의 프로젝트 코드를 캡처합니다. 각 커밋은 이전 커밋 이후로 이루어진 변경사항을 기록하며, 프로젝트 개발의 전체적인 역사를 구축합니다. 커밋을 참조할 때는 일반적으로 고유한 암호화 해시 값을 사용합니다.<pre ><code class="language-bash">git show abc123def456789</code></pre>이 명령어는 해당 해시 값을 가진 커밋의 상세 정보를 보여줍니다.&nbsp;태그 (Tags)Git 태그는 Git 역사 내에서 주요 이정표를 나타내며, 일반적으로 릴리스, 버전, 또는 중요한 커밋을 표시합니다. 이러한 태그는 프로젝트의 여정에서 특정 시점을 나타내는 데 매우 유용합니다. 헤드 (HEAD)현재 체크아웃된 브랜치의 가장 최신 커밋은 HEAD에 의해 표시되며, 저장소 내의 모든 참조를 가리킬 수 있는 포인터 역할을 합니다. 특정 브랜치에 있을 때, HEAD는 해당 브랜치의 최신 커밋을 가리킵니다. 가끔 HEAD는 브랜치의 끝이 아닌 특정 커밋을 직접 가리킬 수도 있습니다.&nbsp;스테이지 (Stages)Git 단계를 이해하는 것은 Git 워크플로우를 이해하는 데 매우 중요합니다. 단계는 파일에 대한 변경사항이 커밋되기 전에 발생하는 논리적 전환을 나타냅니다. Git 단계를 더 자세히 살펴봅시다: <ul ><li>작업 디렉토리 (Working directory) 👷: 작업 디렉토리는 프로젝트 파일을 수정하고 생성하는 곳입니다. 로컬 머신에서 파일의 현재 상태를 나타냅니다.</li><li>스테이징 영역 (Staging area) 🚉: 스테이징 영역은 변경사항을 커밋하기 전에 준비하는 대기 영역 또는 사전 커밋 구역입니다.</li><li>로컬 저장소 (Local repository) 🗄️: 로컬 저장소는 Git이 커밋된 변경사항을 영구히 저장하는 곳입니다. 프로젝트의 역사를 검토하고, 이전 상태로 되돌리며, 동일한 코드베이스에서 다른 사람들과 협업할 수 있게 해줍니다.</li><li>원격 저장소 (Remote repository) 🛫: 원격 저장소는 중앙 서버(예: GitHub, GitLab, Bitbucket)에 위치하며, 프로젝트를 공유하고 다른 사람들과 협업할 수 있는 곳입니다.</li></ul>&nbsp;Git 시작하기어디서부터 시작해야 할지 고민이라면, Git에서는 작업 공간(workspace)에서 시작해야 합니다. 기존의 저장소(repository)를 포크(fork)하거나 클론(clone)하여 그 작업 공간의 복사본을 가질 수 있습니다. 만약 완전히 새롭게 로컬 폴더에서 시작하고자 한다면, 해당 폴더를 Git 저장소로 만들기 위해 git init 명령어를 사용해야 합니다. 다음 단계로는 자격 증명 설정을 반드시 잊지 말아야 합니다. 브랜치 작업로컬에서 작업할 때는 현재 어떤 브랜치에 있는지 아는 것이 중요합니다. 다음 명령어들이 유용합니다:<pre ><code class="language-bash"># Will show the changes in the local repository
git branch 
# Or create a branch directly with
git branch feature-branch-name</code></pre>브랜치 간 전환을 위해서는:<pre ><code class="language-bash">git switch</code></pre>또한, 브랜치 간 전환뿐만 아니라 다음과 같이 할 수도 있습니다:<pre ><code class="language-bash">git checkout 
# A shortcut to switch to a branch that is yet to be created with the -b flag 
git checkout -b feature-branch-name</code></pre>저장소의 상태를 확인하려면 다음을 사용하십시오:<pre ><code class="language-bash">git status</code></pre>현재 브랜치를 항상 명확하게 보기 위해서는 터미널에 브랜치를 표시하는 것이 좋습니다. 이를 도와주는 여러 터미널 애드온이 있습니다. 커밋 작업커밋을 작업할 때, git commit -m을 사용하여 변경 사항을 기록하고, git amend를 사용하여 가장 최근의 커밋을 수정하며, 커밋 메시지 규칙을 지키는 것이 중요합니다.<pre ><code class="language-bash">git commit -m "의미 있는 메시지"</code></pre>마지막 커밋에 변경 사항이 있을 때는 새 커밋을 만들지 않고 --amend 플래그를 사용하여 가장 최근 커밋을 수정할 수 있습니다:<pre ><code class="language-bash"># 변경사항을 추가
git add .
git commit --amend</code></pre>이 명령어는 기본 텍스트 편집기를 열어 필요하면 커밋 메시지를 수정할 수 있게 합니다.<pre ><code class="language-bash">git push origin your_branch --force</code></pre>기본적으로 자주 커밋하는 것이 더 좋습니다. 이는 진행 상황을 잃거나 스테이징되지 않은 변경사항을 실수로 리셋하는 것을 방지합니다. 이후에 여러 커밋을 합치거나 인터랙티브 리베이스(interactive rebase)를 통해 히스토리를 재작성할 수 있습니다.&nbsp;git log를 사용하여 최근 커밋부터 과거로 거슬러 올라가는 순서로 커밋 목록을 확인할 수 있습니다.&nbsp; 번역: [https://ducktopia.tistory.com/132]원문:

Medium

🕊️ [Medium] 내가 원했던, Git 가이드 (1)

카카오페이에서 프론트엔드 개발을 하며 스켈레톤 UI와 사용자 경험 향상에 대해 고민한 내용을 공유합니다.

무조건 스켈레톤 화면을 보여주는게 사용자 경험에 도움이 될까요? | 카카오페이 기술 블로그

웹사이트에서 데이터를 불러올 때, 흔히 '스켈레톤 화면'이라는 로딩 표시를 사용합니다. 하지만 이게 항상 최선의 선택은 아니라는 흥미로운 블로그 글이 있어 공유드립니다.

세계적인 UX리서치 그룹 닐슨 노먼은 1초 미만이 소요되는 항목의 경우 애니메이션을 사용하면 오히려 주의가 산만해진다고 합니다. 이유는 사용자 입장에서는 너무 짧은 시간 이기에 화면에서 어떤 일이 발생했는지 따라갈 수 없기 때문인데요.

스켈레톤 화면의 효과
 1. 빠른 로딩 (100ms 미만):
    * 스켈레톤이 너무 빨리 사라져 화면이 '덜그럭거리는' 느낌을 줍니다.
    * 결론: 이런 경우 스켈레톤을 보여주지 않는 것이 더 깔끔합니다.
 2. 느린 로딩 (300ms 이상):
    * 스켈레톤 화면이 유용하게 작용합니다.
    * 사용자에게 '무언가 로딩 중'이라는 시각적 피드백을 제공합니다.

카카오페이의 해결책: 지연된 스켈레톤
카카오페이는 이 문제를 Suspense와 DeferredComponent라는 유틸리티 컴포넌트로 아래와 같이 해결했습니다. 200ms 까지는 빈 화면을 보여주고 이후에는 스켈레톤을 표시하는 방식인데요.
 * 작동 방식:
   * 0-200ms: 빈 화면 표시
   * 200ms 이후:
     * 데이터 로딩 완료 시 → 즉시 데이터 표시
     * 데이터 로딩 중 → 스켈레톤 표시
 * 예시:
   * 100ms 응답: 200ms 후 바로 데이터 표시 (스켈레톤 없음)
   * 400ms 응답: 200ms 후 스켈레톤 표시, 400ms에 데이터 표시

또한 성능 모니터링 도구(Firebase)를 활용하여 실제 API 응답 시간을 분석하여 대부분의 응답시간이 200ms이내임을 확인하고, 위와 같은 전략으로 '덜그럭거림'이 없는 부드러운 경험을 제공했습니다.

따라서 무조건 스켈레톤을 보여주는것보다는 사용자의 환경과 데이터를 분석하여 선택적으로 스켈레톤을 보여주는 것이 더 나을 수 있습니다. 이렇게 사용자 경험에 대한 연구들을 통해 인사이트를 얻고 데이터를 활용한 가설 및 검증 과정을 통해 더 좋은 사용자 경험을 제공할 수 있습니다.

https://tech.kakaopay.com/post/skeleton-ui-idea/

웹사이트에서 데이터를 불러올 때, 흔히 '스켈레톤 화면'이라는 로딩 표시를 사용합니다. 하지만 이게 항상 최선의 선택은 아니라는 흥미로운 블로그 글이 있어 공유드립니다. 세계적인 UX리서치 그룹 닐슨 노먼은 1초 미만이 소요되는 항목의 경우 애니메이션을 사용하면 오히려 주의가 산만해진다고 합니다. 이유는 사용자 입장에서는 너무 짧은 시간 이기에 화면에서 어떤 일이 발생했는지 따라갈 수 없기 때문인데요. 스켈레톤 화면의 효과<ol ><li>빠른 로딩 (100ms 미만):<ul ><li>스켈레톤이 너무 빨리 사라져 화면이 '덜그럭거리는' 느낌을 줍니다.</li><li>결론: 이런 경우 스켈레톤을 보여주지 않는 것이 더 깔끔합니다.</li></ul></li><li>느린 로딩 (300ms 이상):<ul ><li>스켈레톤 화면이 유용하게 작용합니다.</li><li>사용자에게 '무언가 로딩 중'이라는 시각적 피드백을 제공합니다.</li></ul></li></ol> 카카오페이의 해결책: 지연된 스켈레톤카카오페이는 이 문제를 Suspense와 DeferredComponent라는 유틸리티 컴포넌트로 아래와 같이 해결했습니다. 200ms 까지는 빈 화면을 보여주고 이후에는 스켈레톤을 표시하는 방식인데요.<ul ><li>작동 방식:<ul ><li>0-200ms: 빈 화면 표시</li><li>200ms 이후:<ul ><li>데이터 로딩 완료 시 → 즉시 데이터 표시</li><li>데이터 로딩 중 → 스켈레톤 표시</li></ul></li></ul></li><li>예시:<ul ><li>100ms 응답: 200ms 후 바로 데이터 표시 (스켈레톤 없음)</li><li>400ms 응답: 200ms 후 스켈레톤 표시, 400ms에 데이터 표시</li></ul></li></ul> 또한 성능 모니터링 도구(Firebase)를 활용하여 실제 API 응답 시간을 분석하여 대부분의 응답시간이 200ms이내임을 확인하고, 위와 같은 전략으로 '덜그럭거림'이 없는 부드러운 경험을 제공했습니다. 따라서 무조건 스켈레톤을 보여주는것보다는 사용자의 환경과 데이터를 분석하여 선택적으로 스켈레톤을 보여주는 것이 더 나을 수 있습니다. 이렇게 사용자 경험에 대한 연구들을 통해 인사이트를 얻고 데이터를 활용한 가설 및 검증 과정을 통해 더 좋은 사용자 경험을 제공할 수 있습니다. https://tech.kakaopay.com/post/skeleton-ui-idea/

Kakaopay

스켈레톤 화면: 언제나 좋은 선택일까요?

소프트웨어 개발의 80% 이상은 트러블 슈팅이다. 어쩌면 90% 이상? 그런데 이 트러블 슈팅은 컴퓨터 과학/공학의 기초가 없으면 해결하기가 어렵다.

기초 공부는 알겠다. 그럼 이 트러블 슈팅은 어떻게 배워야하나? 이제는 너무 쉽다.

AI(LLM)에게 개발을 시킨다. 거의 무조건 문제가 생기거나 완벽히 원하는대로 나오지 않는다. 어렵거나 새로운 문제일수록 그렇다. 이걸 해결해보는 과정을 많이 거쳐보면 된다.

AI에게 개발을 시킨다 -> 문제가 생긴다 & 문제를 만든다 -> 문제를 해결한다.

이 방식을 통하면 개발의 많은 과정을 이해하고 익힐 수 있다. 다만, 개발을 시키는 것도 뭘 알아야 시킬 수 있다. (서울대 강의에 썼던 방식이다)

부가적인 효과로 대화를 통해 목적을 달성해가는 스킬을 익힐 수 있고, AI의 결과가 틀릴 수 있다는 것이 몸에 새겨지므로, 늘 의심하고 확인하는 습관을 가질 수 있다.

소프트웨어 개발의 80% 이상은 트러블 슈팅이다. 어쩌면 90% 이상? 그런데 이 트러블 슈팅은 컴퓨터 과학/공학의 기초가 없으면 해결하기가 어렵다. 기초 공부는 알겠다. 그럼 이 트러블 슈팅은 어떻게 배워야하나? 이제는 너무 쉽다. AI(LLM)에게 개발을 시킨다. 거의 무조건 문제가 생기거나 완벽히 원하는대로 나오지 않는다. 어렵거나 새로운 문제일수록 그렇다. 이걸 해결해보는 과정을 많이 거쳐보면 된다. AI에게 개발을 시킨다 -&gt; 문제가 생긴다 &amp; 문제를 만든다 -&gt; 문제를 해결한다. 이 방식을 통하면 개발의 많은 과정을 이해하고 익힐 수 있다. 다만, 개발을 시키는 것도 뭘 알아야 시킬 수 있다. (서울대 강의에 썼던 방식이다) 부가적인 효과로 대화를 통해 목적을 달성해가는 스킬을 익힐 수 있고, AI의 결과가 틀릴 수 있다는 것이 몸에 새겨지므로, 늘 의심하고 확인하는 습관을 가질 수 있다.

소프트웨어 개발의 80% 이상은 트러블 슈팅이다. 어쩌면 90% 

결국은 가독성이 높은 코드가 좋은 코드다. 그래야 나도 나중에 쉽게 다시 기억을 되살릴 수 있고, 다른 사람들이 쉽게 이해하고 내가 그만두거나 다른 일로 넘어갈 때 유지보수가 쉬워진다.

단 코드를 작성할 때 본인이 하는 맡은 업무를 명확히 이해하는 것이 중요하다 ("문제 정의"). 그래야 맡은 일에서 정말 중요한 것들 중심으로 구현을 할 수 있기 때문이다. 문제의 복잡도와 들어가는 시간에는 다른 모든 것들처럼 보통 20:80 법칙이 적용된다. 마지막 20%를 해결하는데 보통 80%의 시간을 쓰게 되기에 20%를 단순하게 해결할 방법을 생각해보는 것이 필요하며 의사 소통을 통해 문제 정의를 잘 한다면 이 부분이 쉬워진다. 내 생각을 정리해보자면

 * 가독성이 높은 단순한 코드를 작성하자 (The simpler the better). 그래야 코드 리뷰부터 시작해서 모든 것이 쉬워진다. 불필요하게 복잡한 코드를 작성하면 본인도 나중에 다시 이해하려면 고생한다.
 * 모듈화 등을 통해 유지보수가 쉬운 코드를 작성하는 것이다. 예를 들어 비슷한 코드가 게으름이나 시간 압박으로 인해 하드코드 형태로 여기저기 흩어져 있다고 하면 유지보수에 큰 어려움을 겪게 될 가능성이 높다.
 * 문제 정의를 잘하는 것이 가장 중요하며 선행되어야 한다. 하지만 주의할 점은 처음 만드는 거라면 요구 조건이 시간을 두고 바뀔 가능성이 높기에 유연하게 만들고 너무 빠르게 최적화하지 않을 필요가 있다.
 * 마지막 20%를 해결하는데 들어가는 노력이 80%임을 인지하고 이 20%의 해결방법을 단순하게 할 방법을 찾아보자.

요약하자면 "읽기 쉽고 유지보수가 쉬운 코드를 작성해서 다른 사람들과의 협업이 쉽도록 만들자"

결국은 가독성이 높은 코드가 좋은 코드다. 그래야 나도 나중에 쉽게 다시 기억을 되살릴 수 있고, 다른 사람들이 쉽게 이해하고 내가 그만두거나 다른 일로 넘어갈 때 유지보수가 쉬워진다. 단 코드를 작성할 때 본인이 하는 맡은 업무를 명확히 이해하는 것이 중요하다 ("문제 정의"). 그래야 맡은 일에서 정말 중요한 것들 중심으로 구현을 할 수 있기 때문이다. 문제의 복잡도와 들어가는 시간에는 다른 모든 것들처럼 보통 20:80 법칙이 적용된다. 마지막 20%를 해결하는데 보통 80%의 시간을 쓰게 되기에 20%를 단순하게 해결할 방법을 생각해보는 것이 필요하며 의사 소통을 통해 문제 정의를 잘 한다면 이 부분이 쉬워진다. 내 생각을 정리해보자면 <ul ><li>가독성이 높은 단순한 코드를 작성하자 (The simpler the better). 그래야 코드 리뷰부터 시작해서 모든 것이 쉬워진다. 불필요하게 복잡한 코드를 작성하면 본인도 나중에 다시 이해하려면 고생한다.</li><li>모듈화 등을 통해 유지보수가 쉬운 코드를 작성하는 것이다. 예를 들어 비슷한 코드가 게으름이나 시간 압박으로 인해 하드코드 형태로 여기저기 흩어져 있다고 하면 유지보수에 큰 어려움을 겪게 될 가능성이 높다.</li><li>문제 정의를 잘하는 것이 가장 중요하며 선행되어야 한다. 하지만 주의할 점은 처음 만드는 거라면 요구 조건이 시간을 두고 바뀔 가능성이 높기에 유연하게 만들고 너무 빠르게 최적화하지 않을 필요가 있다.</li><li>마지막 20%를 해결하는데 들어가는 노력이 80%임을 인지하고 이 20%의 해결방법을 단순하게 할 방법을 찾아보자.</li></ul> 요약하자면 "읽기 쉽고 유지보수가 쉬운 코드를 작성해서 다른 사람들과의 협업이 쉽도록 만들자"

좋은 코드란?

2018년 작성해 오래된 아티컬이긴하지만
그때 고민해본 실제 동작하는 MSA 아키텍트의 프레임을 공유해봅니다.

https://wiki.webnori.com/plugins/servlet/mobile?contentId=16646192#content/view/16646192

2018년 작성해 오래된 아티컬이긴하지만그때 고민해본 실제 동작하는 MSA 아키텍트의 프레임을 공유해봅니다. https://wiki.webnori.com/plugins/servlet/mobile?contentId=16646192#content/view/16646192

MSA with Spring

Java developers tend to use 'java.util.UUID#randomUUID()' API, to generate a UUID (Universally Unique Identifier) number (i.e., 'b8bbcbed-ca07-490c-8711-5118ee0af2f9'). Under certain circumstances...

Java UUID generation - Performance impact

﻿
랜덤으로 유니크한 문자열을 만들기 위해 Java.util.UUID#randomUUID() 라는 메서드를 사용해 보신 적이 있으실 겁니다. 이 글에서는 해당 메서드로 인해 시스템이 느려졌던 사례를 공유합니다.
글의 설명에 따르면, 내부 운영체제에서 entropy를 사용하여 고유번호를 생성한다고 하는데 이는 다양한 시스템의 상태 (마우스 움직임, 하드웨어 팬 소음의 변화, 장치 드라이버의 소음 변화 등)을 활용한다고 하는데요. 이때 운영체제에 이 entropy가 부족할 경우 난수 생성 속도가 느려지고 이는 애플리케이션에 영향을 준다고 합니다. 글에 나와있는 스레드 덤프 리포트를 보면 상당히 흥미로운데요.
무심코 사용하던 코드에서도 결함이 생기는 경우가 종종 있으니 특히나 외부 라이브러리를 사용할 때는 한 번쯤은 추상화되어있는 인터페이스 내부에서 어떤 식으로 돌아가는지 살펴보는 것 또한 중요해 보입니다.

https://medium.com/@RamLakshmanan/java-uuid-generation-performance-impact-cec888b7d9b8

﻿랜덤으로 유니크한 문자열을 만들기 위해 Java.util.UUID#randomUUID() 라는 메서드를 사용해 보신 적이 있으실 겁니다. 이 글에서는 해당 메서드로 인해 시스템이 느려졌던 사례를 공유합니다.글의 설명에 따르면, 내부 운영체제에서 entropy를 사용하여 고유번호를 생성한다고 하는데 이는 다양한 시스템의 상태 (마우스 움직임, 하드웨어 팬 소음의 변화, 장치 드라이버의 소음 변화 등)을 활용한다고 하는데요. 이때 운영체제에 이 entropy가 부족할 경우 난수 생성 속도가 느려지고 이는 애플리케이션에 영향을 준다고 합니다. 글에 나와있는 스레드 덤프 리포트를 보면 상당히 흥미로운데요.무심코 사용하던 코드에서도 결함이 생기는 경우가 종종 있으니 특히나 외부 라이브러리를 사용할 때는 한 번쯤은 추상화되어있는 인터페이스 내부에서 어떤 식으로 돌아가는지 살펴보는 것 또한 중요해 보입니다. https://medium.com/@RamLakshmanan/java-uuid-generation-performance-impact-cec888b7d9b8

Java UUID generation-Performance imp

토스와 애플의 조직문화인 DRI는 무엇일까? DRI를 효과적으로 도입하기 위해 꼭 알아야 할 3가지 요소(결정, 실행, 책임)에 대해 알아보겠습니다. | HR 인사이트

DRI를 도입하기 위한 필수 요소 3가지 - 진짜 나를 빛나게, 스펙터 Specter

애플은 DRI 문화를 도입한 대표적인 사례로 잘알려져있고, 국내에서는 토스가 DRI를 성공적으로 도입한 기업으로 많이 언급되고 있습니다.
DRI 조직문화 관련해서 상세하게 적힌 글이 있어 내용을 공유드립니다.

🏃🏻‍♀️ 그래서 이거 누가 담당하실 건가요?
업무를 진행하다보면 여러 사람의 손을 거쳐야 할 때가 있습니다. 이런 문제는 회사가 여러 사람이 모여 있는 '팀'이기에 발생하고, 특히 다양한 부서에서 함께 프로젝트를 진행하다 보면 의견을 공유하는 과정이 길어지기 마련입니다.
이 과정에서 누가 결정을 내릴 것인지 명확하지 않다면 의견이 엇갈리게 되고, 프로젝트는 지연될 수 밖에 없습니다. 그러다 각자 다른 업무때문에 바빠지면 '다른 누군가가 하겠지' 라는 생각에 누구도 책임을 지지 않으려는 분위기가 형성되면서 실패로 끝날 가능성이 높아집니다.
이러한 문제를 해결하기위해 DRI(Directly Responsible Individual) 개념을 도입한 회사들이 있습니다.

💁‍♂️ DRI란
특정 업무나 프로젝트의 전 과정을 책임지는 개인 (최종의사결정권자)을 의미합니다.
프로젝트의 주요한 결정과 실행, 그리고 최종 결과까지의 책임을 한 사람이 담당하도록 하여 의사결정 과정을 단순화하고, 책임 소재를 명확히 하기위해 도입된 개념입니다.
DRI의 핵심은 한 명의 책임자에게 모든 권한을 위임한다는점입니다.

📈 DRI 도입 이후 직원들에게 일어난 변화
 * 활발한 의사소통: 프로젝트의 권한을 갖는 사람이 업무의 실행 및 결과까지 책임지면서, 업무의 성공여부가 온전히 자신에게 달려있음을 인지하게 되었습니다. 더 나은 결정을 하기위해 더 많은 사람들의 의견에 귀를 기울이고, 팀원들과 활발히 소통하게 되었습니다.
 * 전체 성과 향상: DRI를 통해 모든 구성원이 자신이 맡은 업무와 목표를 더욱 명확하게 이해하게 되었고, 상호 협력할 수 있는 환경이 조성되었습니다. 또한 구체적인 목표를 설정과 함께 책임감이 강화되면서 불필요한 업무에 시간을 낭비하지 않고 더 효율적으로 일할 수 있게 되었습니다.

🏄🏻‍♂️ DRI를 구성하는 요소
 * 결정: DRI는 프로젝트에서 주요한 결정을 내리는 역할을 합니다. 최선의 합리적인 결정을 내리기 위해 정보를 수집하고 분석하며, 필요한 모든 자원을 고려해야 합니다.
 * 실행: DRI는 결정된 사항을 실행하는 것 또한 본인의 주도 하에 진행됩니다. 이 단계에서 자원을 효과적으로 관리하고, 인력을 적절히 배치하며 프로젝트가 계획대로 진행될 수 있도록 모든 과정에 관여합니다.
 * 책임: DRI는 결과가 좋든 나쁘든 그에 따른 모든 책임을 집니다. 결과가 무조건 성공적이어야 한다는 것에 초점을 두는 것이 아닌, 맡고 있는 프로젝트의 처음부터 끝까지 누락된 것은 없는지 살피고, 레슨런을 통해 실패에서 성공을, 성공에서 더 큰 성공을 이루어내기 위해 고민하는 것이 필요합니다.

🎁 DRI 조직 문화를 만들기 위한 필수사항
 * 신뢰와 피드백: DRI는 조직 내 사람들의 의견을 경청하고, 합리적으로 설득할 수 있어야합니다. 피드백을 주고 받을 때에도 신뢰를 바탕으로 '공동의 목표를 달성하기 위해 협력하는 과정'이라는 것을 인지할 수 있어야 합니다.
 * 수평적 의사소통: 팀원들의 다양한 시각이 결합될 때 더 나은 의사결정과 혁신적인 해결책이 도출됩니다. 수평적 의사소통은 또한 팀원들이 서로의 강점과 약점을 이해하고 협력할 수 있는 기회를 제공합니다.
 * DRI형 리더십을 가진 직책자: 프로젝트의 성공 여부는 DRI 개인의 역량과 자질에 의해 크게 좌우됩니다. 기업에 DRI문화를 효과적으로 도입하는 방법은 DRI형 리더십이 있는 직책자가 조직 전체에 퍼뜨리는 것입니다.

애플은 DRI 문화를 도입한 대표적인 사례로 잘알려져있고, 국내에서는 토스가 DRI를 성공적으로 도입한 기업으로 많이 언급되고 있습니다.DRI 조직문화 관련해서 상세하게 적힌 글이 있어 내용을 공유드립니다. 🏃🏻‍♀️ 그래서 이거 누가 담당하실 건가요?업무를 진행하다보면 여러 사람의 손을 거쳐야 할 때가 있습니다. 이런 문제는 회사가 여러 사람이 모여 있는 '팀'이기에 발생하고, 특히 다양한 부서에서 함께 프로젝트를 진행하다 보면 의견을 공유하는 과정이 길어지기 마련입니다.이 과정에서 누가 결정을 내릴 것인지 명확하지 않다면 의견이 엇갈리게 되고, 프로젝트는 지연될 수 밖에 없습니다. 그러다 각자 다른 업무때문에 바빠지면 '다른 누군가가 하겠지' 라는 생각에 누구도 책임을 지지 않으려는 분위기가 형성되면서 실패로 끝날 가능성이 높아집니다.이러한 문제를 해결하기위해 DRI(Directly Responsible Individual) 개념을 도입한 회사들이 있습니다. 💁‍♂️ DRI란특정 업무나 프로젝트의 전 과정을 책임지는 개인 (최종의사결정권자)을 의미합니다.프로젝트의 주요한 결정과 실행, 그리고 최종 결과까지의 책임을 한 사람이 담당하도록 하여 의사결정 과정을 단순화하고, 책임 소재를 명확히 하기위해 도입된 개념입니다.DRI의 핵심은 한 명의 책임자에게 모든 권한을 위임한다는점입니다. 📈 DRI 도입 이후 직원들에게 일어난 변화<ul ><li>활발한 의사소통: 프로젝트의 권한을 갖는 사람이 업무의 실행 및 결과까지 책임지면서, 업무의 성공여부가 온전히 자신에게 달려있음을 인지하게 되었습니다. 더 나은 결정을 하기위해 더 많은 사람들의 의견에 귀를 기울이고, 팀원들과 활발히 소통하게 되었습니다. </li><li>전체 성과 향상: DRI를 통해 모든 구성원이 자신이 맡은 업무와 목표를 더욱 명확하게 이해하게 되었고, 상호 협력할 수 있는 환경이 조성되었습니다. 또한 구체적인 목표를 설정과 함께 책임감이 강화되면서 불필요한 업무에 시간을 낭비하지 않고 더 효율적으로 일할 수 있게 되었습니다.</li></ul> 🏄🏻‍♂️ DRI를 구성하는 요소<ul ><li>결정: DRI는 프로젝트에서 주요한 결정을 내리는 역할을 합니다. 최선의 합리적인 결정을 내리기 위해 정보를 수집하고 분석하며, 필요한 모든 자원을 고려해야 합니다.</li><li>실행: DRI는 결정된 사항을 실행하는 것 또한 본인의 주도 하에 진행됩니다. 이 단계에서 자원을 효과적으로 관리하고, 인력을 적절히 배치하며 프로젝트가 계획대로 진행될 수 있도록 모든 과정에 관여합니다. </li><li>책임: DRI는 결과가 좋든 나쁘든 그에 따른 모든 책임을 집니다. 결과가 무조건 성공적이어야 한다는 것에 초점을 두는 것이 아닌, 맡고 있는 프로젝트의 처음부터 끝까지 누락된 것은 없는지 살피고, 레슨런을 통해 실패에서 성공을, 성공에서 더 큰 성공을 이루어내기 위해 고민하는 것이 필요합니다.</li></ul> 🎁 DRI 조직 문화를 만들기 위한 필수사항<ul ><li>신뢰와 피드백: DRI는 조직 내 사람들의 의견을 경청하고, 합리적으로 설득할 수 있어야합니다. 피드백을 주고 받을 때에도 신뢰를 바탕으로 '공동의 목표를 달성하기 위해 협력하는 과정'이라는 것을 인지할 수 있어야 합니다.</li><li>수평적 의사소통: 팀원들의 다양한 시각이 결합될 때 더 나은 의사결정과 혁신적인 해결책이 도출됩니다. 수평적 의사소통은 또한 팀원들이 서로의 강점과 약점을 이해하고 협력할 수 있는 기회를 제공합니다. </li><li>DRI형 리더십을 가진 직책자: 프로젝트의 성공 여부는 DRI 개인의 역량과 자질에 의해 크게 좌우됩니다. 기업에 DRI문화를 효과적으로 도입하는 방법은 DRI형 리더십이 있는 직책자가 조직 전체에 퍼뜨리는 것입니다. </li></ul>

Specter

토스와 애플 조직문화 DRI

01 . 황정민 배우님의 동생이자 유명한 영화음악 감독이기도 한 황상준 감독님이 얼마 전 유퀴즈에 출연하셔서 이런 말씀을 하셨습니다.
"우리 같은 사람들은 기회가 있을 때 잘하는 게 아니라 늘 잘해야 한다."
그리고 공교롭게 얼마 지나지 않아 출연한 차승원 배우님은 또 이런 이야기를 풀어 놓았죠.
"경쟁력이라는 것도 사실 50점 이하면 안 된다. 필요한 여러 자질들에서 최소한 50점은 되어야 그때부터 의미가 생긴다."

02 . 두 분의 이야기를 종합해 보자면 이렇게 요약할 수 있을 겁니다. '적어도 자신의 성과를 다른 사람에게 선보이고 이를 통해 수익을 창출하는 사람이라면, 늘 꾸준히 잘해야 하며 그 퀄리티는 일반적인 기준을 우회해야 한다'라고 말입니다.
그리고 이렇게 정리하고 나니 살짝 오싹해지기도 합니다. 꼭 배우나 제작자가 아니더라도 우리 같은 회사원들 역시도 똑같은 기준을 적용받고 사는 존재들이라는 게 더욱 명확해지니 말입니다.

03 . 물론 그들도, 우리도 수많은 실패를 합니다. 연예인들이라고 매번 히트작을 낼 수는 없는 것처럼 회사에서 하는 공동 업무나 개인적으로 일구는 사업 혹은 과제들 역시 성공보단 실패의 확률이 훨씬 크기 때문이죠. 그래서 가끔은 '세상은 참 가혹한 환경인데도 사람들은 이 가혹함을 인생이라고 정의하며 살고 있구나'하는 생각이 들 때도 있습니다.

04 . 하지만 '잘한다'는 기준에 대해 조금만 생각해 보면 내부로부터의 평가와 외부로부터의 평가가 각각 존재한다는 사실을 발견할 수 있습니다. 대중이나 소비자처럼 우리가 선보이는 결과물을 평가해 줄 집단이 있나 하면, 반대로 그 결과물까지 어떻게 도달했나를 평가해 줄 내부의 동료들과 관계자들이 있으니 말이죠. 전자가 결과의 평가라면 후자는 과정의 평가라고도 볼 수 있겠네요.

05 . 그리고 이 지점에서 또 하나의 고민이 고개를 듭니다. 그럼 우리는 이 각각의 평가단(?)을 어떻게 관리해야 하며, '잘한다'는 기준을 들이밀었을 땐 이 두 평가단으로부터 어떤 평가를 끌어내는 것이 '잘한다'의 의미인 것인지 알쏭달쏭함이 꼬리를 물고 이어지기 때문입니다. 성과는 기가 막히게 뽑아내지만 그 누구에게도 환영받지 못하는 캐릭터가 있고, 성실한 태도와 모자람 없는 실력을 갖췄음에도 유독 성과로 이어지는 그 연결고리가 약한 사람이 있으니까요, 아마 지금 여러분의 머릿속에도 몇몇 사람들이 마치 O, X 게임을 하듯 편을 나눠 양쪽에 선 모습이 그려질 겁니다.

06 . 누가 더 낫다, 아니다를 평가할 수 없다는 건 여러분도 잘 아실 겁니다. 이건 애초에 두부 자르듯 정확하게 가를 수 없는 문제고 파고 내려가다 보면 결국 개인의 스타일과 선호의 문제로 이어질 가능성이 크기 때문입니다.
다만 만약 누군가 제게 '이런 모든 상황을 감안했을 때 늘, 꾸준히, 기본 이상 잘한다는 건 어떤 의미일까요?'라고 묻는다면 저는 이렇게 대답할 것도 같습니다.
"50 이상을 유지하기 위해서는 나만의 기준이 있어야 하고, 늘 꾸준히 잘하기 위해서는 나만의 방법이 있어야 한다"라고 말입니다.

07 . 이에 대해 황상준 감독님과 차승원 배우님은 각각 이런 말을 들려주셨습니다.
"매일 아침 일어나서 정해진 시간에 음악을 만든다. 그게 꾸준히 잘할 수 있게 해주는 것 같다"라는 말과 "우리 같은 직업은 경쟁력 있는 실력, 경쟁력 있는 가격, 경쟁력 있는 인품, 경쟁력 있는 외형이 필요한데 그중 두 가지만 적절히 조합돼도 괜찮게 인정을 받는다. 나는 경쟁력 있는 가격과 인품이 나를 유지하는 방법이다."라는 말이었죠.

08 . 제 생각도 마찬가지입니다. 일단 대부분 스스로 전문성을 가진 분야는 시간이 지남에 따라 점점 실력이 늘어나고 통찰력 또한 깊어질 거라 생각하지만 꼭 그런 것만은 아닙니다. 당장 어제 통용되던 문법이 오늘은 전혀 통하지 않는 시대가 작금의 현실이고, 어느 분야를 막론하고 늘 나보다 더 나은 사람, 더 경험이 많은 사람은 존재하는 법이니 그들을 뛰어넘을 미친 듯한 경쟁력이 없는 이상 적어도 기본 이상을 해낼 수 있는 나만의 기준 하나쯤은 가지고 있어야 합니다. 그래야 새로운 세상이 다가오고 더 잘하는 사람이 등장해도 '내가 지금 무엇을 더 하고, 덜 해야 하나'를 판단할 수 있기 때문이죠.

09 . 더불어 꾸준히 잘하기 위해서는 내 역량을 풀어내는 나만의 방법이 있어야 합니다. 잘하고 싶은 마음이 굴뚝같아도, 언젠가 쌓이고 쌓인 역량이 '팡'하고 터지는 대기만성의 그날을 기약한다고 해도, 누군가의 평가를 받아야 하는 존재들은 일단 눈앞의 있는 것들을 비교적 잘 해내야 합니다. 때문에 내가 나를 잘 이해해야 하고, 내가 나를 잘 활용할 수 있는 힘을 기르지 않고는 꾸준한 퀄리티를 유지하기는 힘듭니다. 시간이 지날수록 나에 대한 정보들이 나에게 잘 유입되고 처리되도록 하는 것이 엄청난 경쟁력이 되는 이유죠.

10 . 말은 이렇게 했지만 꾸준히, 일정 이상 잘한다는 건 정말정말 어려운 일입니다. 그럼에도 이런 이야기를 글로 한 번 풀어본 가장 중요한 이유는 세상 모두가 내 사정을 속속들이 이해해 주진 않는다는 것이고, 한 번 삐끗하는 것만으로도 다시 기회가 주어지지 않는 꽤 쌀쌀맞은 로직이 동작하는 게 현실이기 때문입니다. 그러니 어쩌겠습니까. 달콤한 말로 위로해 줄 수 없는 순간이라면 덤덤하게 삼켜내기를 택해야 할 때도 있는 거죠. 그래도 한가지 희망적인 것은 이런 고민을 하고 사는 것과 하지 않고 사는 것부터 이미 조금씩 차이를 보이기 시작한다는 겁니다. 그런 의미에서 우리는 늘, 꾸준히, 일정 이상 잘하는 방법을 향해 안테나 정도는 세운 셈인지도 모르겠네요.

01 . 황정민 배우님의 동생이자 유명한 영화음악 감독이기도 한 황상준 감독님이 얼마 전 유퀴즈에 출연하셔서 이런 말씀을 하셨습니다. "우리 같은 사람들은 기회가 있을 때 잘하는 게 아니라 늘 잘해야 한다." 그리고 공교롭게 얼마 지나지 않아 출연한 차승원 배우님은 또 이런 이야기를 풀어 놓았죠. "경쟁력이라는 것도 사실 50점 이하면 안 된다. 필요한 여러 자질들에서 최소한 50점은 되어야 그때부터 의미가 생긴다." 02 . 두 분의 이야기를 종합해 보자면 이렇게 요약할 수 있을 겁니다. '적어도 자신의 성과를 다른 사람에게 선보이고 이를 통해 수익을 창출하는 사람이라면, 늘 꾸준히 잘해야 하며 그 퀄리티는 일반적인 기준을 우회해야 한다'라고 말입니다. 그리고 이렇게 정리하고 나니 살짝 오싹해지기도 합니다. 꼭 배우나 제작자가 아니더라도 우리 같은 회사원들 역시도 똑같은 기준을 적용받고 사는 존재들이라는 게 더욱 명확해지니 말입니다. 03 . 물론 그들도, 우리도 수많은 실패를 합니다. 연예인들이라고 매번 히트작을 낼 수는 없는 것처럼 회사에서 하는 공동 업무나 개인적으로 일구는 사업 혹은 과제들 역시 성공보단 실패의 확률이 훨씬 크기 때문이죠. 그래서 가끔은 '세상은 참 가혹한 환경인데도 사람들은 이 가혹함을 인생이라고 정의하며 살고 있구나'하는 생각이 들 때도 있습니다. 04 . 하지만 '잘한다'는 기준에 대해 조금만 생각해 보면 내부로부터의 평가와 외부로부터의 평가가 각각 존재한다는 사실을 발견할 수 있습니다. 대중이나 소비자처럼 우리가 선보이는 결과물을 평가해 줄 집단이 있나 하면, 반대로 그 결과물까지 어떻게 도달했나를 평가해 줄 내부의 동료들과 관계자들이 있으니 말이죠. 전자가 결과의 평가라면 후자는 과정의 평가라고도 볼 수 있겠네요. 05 . 그리고 이 지점에서 또 하나의 고민이 고개를 듭니다. 그럼 우리는 이 각각의 평가단(?)을 어떻게 관리해야 하며, '잘한다'는 기준을 들이밀었을 땐 이 두 평가단으로부터 어떤 평가를 끌어내는 것이 '잘한다'의 의미인 것인지 알쏭달쏭함이 꼬리를 물고 이어지기 때문입니다. 성과는 기가 막히게 뽑아내지만 그 누구에게도 환영받지 못하는 캐릭터가 있고, 성실한 태도와 모자람 없는 실력을 갖췄음에도 유독 성과로 이어지는 그 연결고리가 약한 사람이 있으니까요, 아마 지금 여러분의 머릿속에도 몇몇 사람들이 마치 O, X 게임을 하듯 편을 나눠 양쪽에 선 모습이 그려질 겁니다. 06 . 누가 더 낫다, 아니다를 평가할 수 없다는 건 여러분도 잘 아실 겁니다. 이건 애초에 두부 자르듯 정확하게 가를 수 없는 문제고 파고 내려가다 보면 결국 개인의 스타일과 선호의 문제로 이어질 가능성이 크기 때문입니다. 다만 만약 누군가 제게 '이런 모든 상황을 감안했을 때 늘, 꾸준히, 기본 이상 잘한다는 건 어떤 의미일까요?'라고 묻는다면 저는 이렇게 대답할 것도 같습니다. "50 이상을 유지하기 위해서는 나만의 기준이 있어야 하고, 늘 꾸준히 잘하기 위해서는 나만의 방법이 있어야 한다"라고 말입니다. 07 . 이에 대해 황상준 감독님과 차승원 배우님은 각각 이런 말을 들려주셨습니다. "매일 아침 일어나서 정해진 시간에 음악을 만든다. 그게 꾸준히 잘할 수 있게 해주는 것 같다"라는 말과 "우리 같은 직업은 경쟁력 있는 실력, 경쟁력 있는 가격, 경쟁력 있는 인품, 경쟁력 있는 외형이 필요한데 그중 두 가지만 적절히 조합돼도 괜찮게 인정을 받는다. 나는 경쟁력 있는 가격과 인품이 나를 유지하는 방법이다."라는 말이었죠. 08 . 제 생각도 마찬가지입니다. 일단 대부분 스스로 전문성을 가진 분야는 시간이 지남에 따라 점점 실력이 늘어나고 통찰력 또한 깊어질 거라 생각하지만 꼭 그런 것만은 아닙니다. 당장 어제 통용되던 문법이 오늘은 전혀 통하지 않는 시대가 작금의 현실이고, 어느 분야를 막론하고 늘 나보다 더 나은 사람, 더 경험이 많은 사람은 존재하는 법이니 그들을 뛰어넘을 미친 듯한 경쟁력이 없는 이상 적어도 기본 이상을 해낼 수 있는 나만의 기준 하나쯤은 가지고 있어야 합니다. 그래야 새로운 세상이 다가오고 더 잘하는 사람이 등장해도 '내가 지금 무엇을 더 하고, 덜 해야 하나'를 판단할 수 있기 때문이죠. 09 . 더불어 꾸준히 잘하기 위해서는 내 역량을 풀어내는 나만의 방법이 있어야 합니다. 잘하고 싶은 마음이 굴뚝같아도, 언젠가 쌓이고 쌓인 역량이 '팡'하고 터지는 대기만성의 그날을 기약한다고 해도, 누군가의 평가를 받아야 하는 존재들은 일단 눈앞의 있는 것들을 비교적 잘 해내야 합니다. 때문에 내가 나를 잘 이해해야 하고, 내가 나를 잘 활용할 수 있는 힘을 기르지 않고는 꾸준한 퀄리티를 유지하기는 힘듭니다. 시간이 지날수록 나에 대한 정보들이 나에게 잘 유입되고 처리되도록 하는 것이 엄청난 경쟁력이 되는 이유죠. 10 . 말은 이렇게 했지만 꾸준히, 일정 이상 잘한다는 건 정말정말 어려운 일입니다. 그럼에도 이런 이야기를 글로 한 번 풀어본 가장 중요한 이유는 세상 모두가 내 사정을 속속들이 이해해 주진 않는다는 것이고, 한 번 삐끗하는 것만으로도 다시 기회가 주어지지 않는 꽤 쌀쌀맞은 로직이 동작하는 게 현실이기 때문입니다. 그러니 어쩌겠습니까. 달콤한 말로 위로해 줄 수 없는 순간이라면 덤덤하게 삼켜내기를 택해야 할 때도 있는 거죠. 그래도 한가지 희망적인 것은 이런 고민을 하고 사는 것과 하지 않고 사는 것부터 이미 조금씩 차이를 보이기 시작한다는 겁니다. 그런 의미에서 우리는 늘, 꾸준히, 일정 이상 잘하는 방법을 향해 안테나 정도는 세운 셈인지도 모르겠네요.

늘, 꾸준히, 일정 기준 이상으로 '잘하기'

An overview of Go syntax and features. Contribute to a8m/golang-cheat-sheet development by creating an account on GitHub.

GitHub - a8m/golang-cheat-sheet: An overview of Go syntax and features.

Golang을 한번 훓었는데 까먹었거나,
책한권 보는 것은 귀찮으신 분은 이거 참고하시면 될 것 같습니다.
목차가 아주 알차네요~

- Basic Syntax (기본 문법)
- Operators (연산자)
- Declarations (선언)
- Functions (함수)
- Built-in Types (내장 타입)
- Type Conversions (타입 변환)
- Packages (패키지)
- Control structures (제어 구조)
- Arrays, Slices, Ranges (배열, 슬라이스, 범위)
- Maps (맵)
- Structs (구조체)
- Pointers (포인터)
- Interfaces (인터페이스)
- Embedding (임베딩)
- Errors (오류 처리)
- Concurrency (동시성)
- Printing (출력)
- Reflection (리플렉션)
- Snippets (코드 스니펫)

https://github.com/a8m/golang-cheat-sheet/tree/master

Golang을 한번 훓었는데 까먹었거나,책한권 보는 것은 귀찮으신 분은 이거 참고하시면 될 것 같습니다.목차가 아주 알차네요~ - Basic Syntax (기본 문법)- Operators (연산자)- Declarations (선언)- Functions (함수)- Built-in Types (내장 타입)- Type Conversions (타입 변환)- Packages (패키지)- Control structures (제어 구조)- Arrays, Slices, Ranges (배열, 슬라이스, 범위)- Maps (맵)- Structs (구조체)- Pointers (포인터)- Interfaces (인터페이스)- Embedding (임베딩)- Errors (오류 처리)- Concurrency (동시성)- Printing (출력)- Reflection (리플렉션)- Snippets (코드 스니펫) https://github.com/a8m/golang-cheat-sheet/tree/master

GitHub

Golang 치트 시트

1
스티브 잡스는 매일 아침 거울 앞에서 스스로에게 물었다. 오늘이 내 삶의 마지막 날이라면, 지금 이 일을 계속할 거냐고.

2
모멘토 모리. 죽음을 기억하라. 죽음은 인간이 만든 최고의 발명품이다. 그 누구도 예외 없다. 사람은 모두 죽는다. 사람의 시간은 유한하다.

3
그럼에도 우리는 시간을 무한한 자원처럼 다룬다. 눈에 보이지 않기 때문이다. 한 시간, 하루, 한 달. 보이지 않는 시간을 단위로 개념화했다. 그럼에도 시간은 잘 와닿지 않는다.

4
우선순위는 보이지 시간에 대한 결정이다. 한정된 시간을 어디에 쓸 것인가. 사람의 삶과 마찬가지로 기업에게도 가장 중요하다.

5
텅 빈 투명한 통이 있다. 여기 다양한 크기의 돌멩이를 담는다. 통은 시간이다. 돌멩이는 우리가 시간을 쓰는 일이다.

6
돌의 크기는 저마다 다르다. 크기는 중요도와 비례한다고 하자. 어떤 걸 먼저 담아야 같은 통에 가장 많은 돌을 채울 수 있을까? 쉽다. 큰 돌을 먼저 담은 다음, 나머지 공간을 작은 돌로 채운다. 가장 밀도가 높다. 시간을 효율적으로 쓴 셈이다.

7
순서를 거꾸로 한다면 어떻게 될까? 작은 돌들을 먼저 채운다. 나중에 큰 돌을 담아본다. 몇 개 들어가지 않는다. 많은 작은 돌들이 이미 꽉 차버렸으니까. 큰일이다. 그래도 돌멩이는 쏟고 다시 담으면 된다. 하지만, 써버린 시간은 되돌릴 수 없다.

8
부와 성공을 이룬 사람은 돈으로 최대한 시간을 산다. 중요하지 않은 결정은 시간을 안 쓴다. 매일 같은 옷을 입고, 같은 식단을 먹는다.

9
기업도 마찬가지다. 기업의 시간은 구성원의 시간이다. 구성원의 수만큼 시간이 있는 셈이다.

10
기업의 시간을 늘리는 방법은 두 가지다. 채용을 해서 구성원의 수를 늘리면 된다. 빠르게 시간을 늘릴 수 있다. 하지만 감당해야 할 대가가 매우 크다. 되돌리기 어려운 결정이다.

11
다른 방법은 시간 사용을 효율화하는 것이다. 높은 역량이 있는 사람을 채용한다. 성과를 내는 과정을 효율화한다.

12
'어떤 일을 할 시간이 없다'라는 말은 사실 '그 일은 우선순위에 없다'라는 말과 같다. 최악은 내가 가진 돌멩이에 우선순위가 없는 것이다. 이 돌, 저 돌 건드리다 결국 하나도 제대로 해내지 못한다. 흐지부지 시간은 계속 흐른다.

13
모래시계처럼 우리의 남은 시간을 눈으로 볼 수 있다면 얼마나 좋을까. 조금은 더 효율적으로 살 수 있지 않을까.

14
시각은 뇌가 다루는 감각의 90%를 차지한다. 그래서 우리는 눈에 안 보이는 걸 덜 중요하게 여긴다.

15
시간, 결정, 건강, 관계. 살면서 점점 더 중요한 것들은 눈에 보이지 않는다는 것을 깨닫는다. 무의식의 흐름대로 살다가도 문득문득 멈춰서 다시 챙겨 본다. 나는 지금 보이지 않는 것들을 잘 챙겨가고 있을까.

1 스티브 잡스는 매일 아침 거울 앞에서 스스로에게 물었다. 오늘이 내 삶의 마지막 날이라면, 지금 이 일을 계속할 거냐고. ​ ​2 모멘토 모리. 죽음을 기억하라. 죽음은 인간이 만든 최고의 발명품이다. 그 누구도 예외 없다. 사람은 모두 죽는다. 사람의 시간은 유한하다. ​ ​3 그럼에도 우리는 시간을 무한한 자원처럼 다룬다. 눈에 보이지 않기 때문이다. 한 시간, 하루, 한 달. 보이지 않는 시간을 단위로 개념화했다. 그럼에도 시간은 잘 와닿지 않는다. ​ ​4 우선순위는 보이지 시간에 대한 결정이다. 한정된 시간을 어디에 쓸 것인가. 사람의 삶과 마찬가지로 기업에게도 가장 중요하다. ​ ​5 텅 빈 투명한 통이 있다. 여기 다양한 크기의 돌멩이를 담는다. 통은 시간이다. 돌멩이는 우리가 시간을 쓰는 일이다. ​ ​6 돌의 크기는 저마다 다르다. 크기는 중요도와 비례한다고 하자. 어떤 걸 먼저 담아야 같은 통에 가장 많은 돌을 채울 수 있을까? 쉽다. 큰 돌을 먼저 담은 다음, 나머지 공간을 작은 돌로 채운다. 가장 밀도가 높다. 시간을 효율적으로 쓴 셈이다. ​7 순서를 거꾸로 한다면 어떻게 될까? 작은 돌들을 먼저 채운다. 나중에 큰 돌을 담아본다. 몇 개 들어가지 않는다. 많은 작은 돌들이 이미 꽉 차버렸으니까. 큰일이다. 그래도 돌멩이는 쏟고 다시 담으면 된다. 하지만, 써버린 시간은 되돌릴 수 없다. ​8 부와 성공을 이룬 사람은 돈으로 최대한 시간을 산다. 중요하지 않은 결정은 시간을 안 쓴다. 매일 같은 옷을 입고, 같은 식단을 먹는다. ​ ​9 기업도 마찬가지다. 기업의 시간은 구성원의 시간이다. 구성원의 수만큼 시간이 있는 셈이다. ​ ​10 기업의 시간을 늘리는 방법은 두 가지다. 채용을 해서 구성원의 수를 늘리면 된다. 빠르게 시간을 늘릴 수 있다. 하지만 감당해야 할 대가가 매우 크다. 되돌리기 어려운 결정이다. ​ ​11 다른 방법은 시간 사용을 효율화하는 것이다. 높은 역량이 있는 사람을 채용한다. 성과를 내는 과정을 효율화한다. ​ ​12 '어떤 일을 할 시간이 없다'라는 말은 사실 '그 일은 우선순위에 없다'라는 말과 같다. 최악은 내가 가진 돌멩이에 우선순위가 없는 것이다. 이 돌, 저 돌 건드리다 결국 하나도 제대로 해내지 못한다. 흐지부지 시간은 계속 흐른다. ​ ​13 모래시계처럼 우리의 남은 시간을 눈으로 볼 수 있다면 얼마나 좋을까. 조금은 더 효율적으로 살 수 있지 않을까. ​ ​14 시각은 뇌가 다루는 감각의 90%를 차지한다. 그래서 우리는 눈에 안 보이는 걸 덜 중요하게 여긴다. ​ ​15 시간, 결정, 건강, 관계. 살면서 점점 더 중요한 것들은 눈에 보이지 않는다는 것을 깨닫는다. 무의식의 흐름대로 살다가도 문득문득 멈춰서 다시 챙겨 본다. 나는 지금 보이지 않는 것들을 잘 챙겨가고 있을까.

< 죽음을 기억하라. 중요한 것들은 눈에 보이지 않는다 >

A collection of design patterns/idioms in Python. Contribute to faif/python-patterns development by creating an account on GitHub.

GitHub - faif/python-patterns: A collection of design patterns/idioms in Python

파이썬을 사용하다가 활용할 수 있는 디자인 패턴이 정리된 GitHub Repo입니다.

위 패턴들을 참고해서 ChatGPT나 Claude 등에게 언제 필요한지 물어보면서 학습하는 것을 추천드려요.

https://github.com/faif/python-patterns

파이썬을 사용하다가 활용할 수 있는 디자인 패턴이 정리된 GitHub Repo입니다. 위 패턴들을 참고해서 ChatGPT나 Claude 등에게 언제 필요한지 물어보면서 학습하는 것을 추천드려요. https://github.com/faif/python-patterns

소프트웨어 엔지니어

김영호

백엔드 엔지니어

권주성

SAIGE Principal Research Engineer

백종혁

파이썬 디자인 패턴이 잘 정리된 GitHub Repository

- 데이터 교육 : 인프런에서 데이터 교육을 진행하고 있습니다. 실무를 하면서 겪은 문제들을 위주로 강의를 진행합니다.
PM을 위한 데이터 리터러시 강의 : https://inf.run/jfWT

- 데이터 팀 코칭 : 데이터 조직의 문제를 같이 해결하며 구성원들의 역량을 발전시킵니다. 데이터팀의 Lead가 없는 경우에 많이 찾아주시며, Lead가 있는 경우에도 데이터 Lead의 고충을 같이 이야기하며 액션 아이템을 도출하기도 합니다. Lead를 처음 경험하는 분이 있는 경우에 진행하는 경우도 있습니다.
고객사 : 글로랑(꾸그), 힐링페이퍼(강남언니), 당근(당근마켓)

- C레벨 코칭 : C레벨분들의 고민을 들으며 고민을 해소하는 과정을 함께 합니다.
고객사 : 마인딩(마이루틴)

코치

Data Business Division
- Growth Coaching Unit Director
- Mentoring, Coaching and Data Training(Data Literacy, SQL etc) for the growth of company members
- Building a Career Framework(Data Analyst/Data Scientist, Data Engineer)
- Counseling 20 to 50 people per month
- Career Coaching
- Coaching those who started the team leader role
- MLOps Platform PO
- Improving the way data collaborates with external organizations(PM, Dev)
- Organizing SOCAR Tech Blog

데이터비즈니스 본부의 그로스코칭 유닛장
- 구성원들의 성장을 위한 일들을 진행합니다
- 커리어 코칭, 조직 문화, 정기 면담, 멘토링
- Engineering Manager 역할을 했습니다

Engineering Manager, 머신러닝 엔지니어

카메라 앱 데이터 분석 & 데이터 엔지니어링
- ETL 파이프라인 구축
- BI 대시보드 구축 및 운영
- 이벤트 로그 설계

데이터 분석가 겸 데이터 엔지니어

태극기 게양 제품 판매
크라우드펀딩 - 와디즈 진행


운영 총괄

계약직

경영학과 학사

변성윤

유튜브

기술 블로그

경영학을 전공하고 데이터 분석, 머신러닝/데이터 엔지니어링을 경험했습니다. 

데이터 분석/데이터 엔지니어링/팀장(피플 매니징)/성장과 관련된 내용들을 주로 소개드릴게요 :)
#개발자 #그로스마인드셋 #끊임없이배우기 #데이터사이언스 #독서 #문제를해결하는 #블로거

파이썬 디자인 패턴이 잘 정리된 GitHub Repository

댓글 0

비슷한 게시물

주간 인기 TOP 10

추천 프로필