2023년 1분기 당시 학교와 회사 일정으로 시간이 부족하여 회고를 작성하지 못해서 부득이하게 분기가 아닌 반기 회고로 작성하게되었다.
상반기 동안 내가 주요하게 맡은 작업은 크게 4가지이다.
새로 개발한 준비물 결제 플로우에서 발생한 다양한 문제를 해결했다.
주로 QA나 코드 리뷰 단계에서 미처 발견하지 못한 엣지 케이스에서 발생한 문제였는데 몇가지 기억에 남는 것들이 있다.
준비물을 선택할 때 해당 준비물에 옵션을 선택할 수 있는데, 그 옵션의 수가 많아지면 아래 화면 처럼 구매하기 버튼이 유저에게 바로 보이지 않고 스크롤을 페이지 아래까지 내려야 확인할 수 있는 문제가 있었다.
아래처럼 많은 옵션을 가진 준비물이 거의 없고 정책 상 앞으로 생기지 않을 것이라 고려하지 개발하면서 깊이 고려하지 못했던 것 같다.
그러나 어떠한 경우라도 구매하기 버튼이 노출되지 않은 것은 매출에 치명적인 문제로 이어진다.
당시에는 이러한 상황이 생기지 않을거라 생각해도 노련한 엔지니어는 옵션 선택하는 요소들을 감싸는 부모 요소에 max-height와 overflow auto를 설정하였을거라 생각한다.
이 문제를 계기로 더 노련한 엔지니어가 되어서 같은 실수를 반복하지 않고 다양한 e2e 테스트 케이스를 고려할 수 있게 되었다.
Before | After |
---|---|
![]() | ![]() |
구독 상품을 선택할 때 사용할 사용할 수 있는 툴팁을 개발하고 Hackle에 remote config 기능을 연동하여 config 설정 값에 따라 원격으로 툴팁에 보여질 내용 등을 수정할 수 있는 JSON Schema를 디자인했다.
JSON 값(설정 값)에서 Service Region 별로 보여줄 상품, 서비스 내 특정 PATH를 거쳐서 상품 선택 페이지에 도달해야 노출되는 상품, 노출될 상품에 툴팁에 노출 여부와 툴팁에 노출할 텍스트를 설정할 수 있도록 설계했다.
개발 후 5개월이 지난 지금까지 유지보수 거쳐 활발히 활용되고 있어서 기쁘다.
Merchant 서비스는 기존 몽고디비에서 관리되고 있는 복잡한 구조에 준비물 키트 구조를 단순한 형태로 RDB로 관리하고 네이버 스마트 스토어 상품 등록 어드민, 쿠팡 상품 등록 어드민 등과 같이 새로운 어드민 서비스를 개발하는 매우 큰 작업이다.
프론트엔드 작업으로는 상품 조회, 등록, 수정 어드민을 개발하는 것이였다.
동료 프론트엔드 엔지니어 2명과 함께 작업을 했으며 나는 주로 상품 조회, 등록, 수정 기능에 전반적인 설계를 했고 기능 개발을 동료들과 분담해서 작업했다.
기억에 남는 작업으로는 스프레드시트처럼 셀 별로 데이터를 수정 할 수 있는 테이블을 개발하는 작업이 있었다.
그 중 동료와 페어프로그래밍을 통해 2가지 문제를 개선한것이 기억에 남는다.
첫번째는 테이블 셀 내부 인풋에 수정할 값을 타이핑 할 때 마다 테이블 전체가 리랜더링 되는 문제이다.
이는 테이블 셀 UI에 특징을 고려하지 못해 적절하지 않은 시점에 테이블 상태를 업데이트 시켜서 성능 저하로 이어지게 하는 좋지 않은 코드가 원인이였다.
인풋에 타이핑 할 때 마다 수정이 일어나는 것이 아닌 수정이 끝나는 시점에 1회만 업데이트 할 수 있도록 페어 프로그래밍을 진행해서 해결했다.
두번째는 테이블 셀 별로 사용해야할 업데이트 Mutation(API)들이 각각 존재하는 상황에서 하나의 Container 컴포넌트 내에서 모든 Mutation 함수 로직들을 작성하고 prop으로 내려주는 구조를 개선하는 것이였다.
이는 관리해야할 Mutation, 즉 그 Mutation을 실행하는 로직들이 많아질수록 매우 복잡해지고 관심사가 다른 로직들이 한 곳에 모이게 되어 한 로직을 수정하면 의도치 않게 다른 관심사에 로직에 영향이 가기 쉬워진다.
결과적으로 유지보수가 어려워지게 되고 미래에 우리팀이 힘들어지는 코드였다.
페어 프로그래밍을 통해 Mutation 별로 각각의 Container 컴포넌트를 제공하여 각 Container에는 해당 데이터의 상태 업데이트 Mutation에 대한 관심사만을 로직으로 작성하여 제공할 수 있도록 수정했다.
관심사에 맞춰 컴포넌트를 최대한 나누는 것을 통해 컴포넌트의 의존성을 낮추는 것은 변화에 유연하게 대응할 수 있는 컴포넌트 설계에 있어서 매우 중요하다는 것을 동료 엔지니어에게 효과적으로 전달할 수 있는 좋은 계기였다.
하지만 회사 내부적인 문제로 오픈되지 못하고 프로젝트가 홀딩되었다. ㅜㅜ..
프리미엄 클래스는 구독하면 모든 클래스를 수강할 수 있었던 클래스101 구독 서비스에 특정 클래스는 추가로 수강권을 결제해야만 수강할 수 있는 클래스를 의미한다.
프리미엄 클래스는 유명인의 클래스를 비싼 가격에 판매하는 방식이라 객단가가 매우 높고 유명인에 클래스이기 때문에 수요도 확실하다.
나는 사용자가 프리미엄 클래스를 구매할 수 있도록 이벤트 페이지에서 구매하기 버튼을 누르면 바로 결제 페이지로 이동하여 수강권을 구매할 수 있도록 개발했다.
여기서 수강권이 일종에 준비물이기 때문에 결제를 하기 위해선 준비물을 선택하는 과정이 필요한데, 그 과정 없이 바로 결제 페이지로 이동 시키기 위해 준비물을 자동 선택할 수 있도록 하는 로직을 작성하여 자동 선택된 준비물의 상태를 localstorage에 저장해서 사용했다.
또한 기존 구독 서비스 내에서 수강권이라는 개념이 없어서 수강권 데이터가 클라이언트에 노출되고 있지 않았는데 추가적인 API 연동 작업을 해서 결제 페이지, 결제 완료 페이지 등의 노출하는 작업을 했다.
런칭 후 일주일 간 약 5,000만원 이상 매출에 기여했고 목표한 ROI를 달성했다.
사내 동료, 상향, 하향 전방위 평가를 통한 2022.4Q ~ 2023.1Q Performance review 내용과 주관적인 생각을 기준으로 상반기에 내가 성장한 점은 다음과 같다.
먼저, 변화의 유연하게 대응할 수 있는 컴포넌트란 무엇일까?
나는 다음과 같이 표현할 수 있다고 생각한다.
2023년 상반기에 여러가지 컴포넌트를 개발하면서 변화의 유연한 컴포넌트 개발에 집중했고, 동료들에게 강조했었다.
그 이유는 우리가 만들어가는 클래스101 제품은 하루가 다르게 바뀌어가는 요구사항에 어떻게든 대응해야 했기 때문이다.
그렇지 못하면 변화하는 요구사항에 대응하기 위해 계속해서 기존 컴포넌트를 재사용하지 못할 것이고 그것은 개발자들에 피로감과 퍼포먼스 하락으로 이어질 것이 자명했기 때문이다.
사실 커머스 프론트엔드는 2022년 4월 부터 구독 서비스로 전환하기 시작하면서 퀄리티 높은 개발보다 기능 구현이 우선 시 되었던 상황 탓에 변화에 유연하지 못한 컴포넌트를 많이 탄생(?)시켰던 것 같다.
그 부작용이 2022년 4분기 부터 작용하여 커머스 프론트엔드 개발에 큰 피로감으로 다가오기 시작했고 계속해서 이러다간 더이상 유지보수가 불가능할 것 같은 불안감이 엄습했었다.
발등에 불이 떨어진 것 같은 위기감을 느껴서 변화의 유연한 컴포넌트 개발에 집중했고 강조했었던 것 같다.
결과적으로 이 위기감이 팀에 잘 전파되어 컴포넌트를 개발할 때 컴포넌트 퀄리티(변화의 유연성)가 엄격하게 리뷰되고 있는 편인 것 같다.
코드 리뷰 과정에 관해서도 긍정적인 평가를 받았다.
톰은 문제를 논리적으로 자신의 것으로 재해석하여 이해합니다.
요구사항이나 해결할 이슈를 자신의 논리로 이해한 후 재해석하여 원 저자로 부터 확인을 받습니다.
이러한 논리적인 사고를 기반으로 통료의 코드를 꼼꼼히 보고 의견을 줍니다.
톰의 의견은 대부분 설득력을 갖고 개선의 여지가 있음을 알게 합니다.
항상 주장에는 논리적 근거가 있어야 상대방에게 나의 주장을 설득 시킬 수 있다고 생각하며 이를 간과하지 않으려고 노력하고 있다. 이는 동료의 코드를 리뷰하거나 프로젝트 담당자와의 의사소통에 있어서 매우 중요하게 작용할 것인데, 특히 엔지니어는 코드리뷰 과정에서 매일 마주할 것이다.
예를 들어 이러한 코드 리뷰 사례가 있었다.
// 리뷰된 코드
배열.map(async 배열 원소 => {
const { bucketName, keyName, fileName } = 다운로드파일;
if (bucketName && keyName) {
const { signedUrl } = await this.awsS3Service.getSignedUrl(
bucketName as S3_BUCKET,
keyName,
600,
{
ResponseContentDisposition: `attachment; filename="${fileName}"`
}
);
return {
...생략
};
}
return ...생략;
});
{동료}
forEach, map 같은 iterator 들은 비동기 작업이 끝나는 걸 대기하지 않아 async / await 이 제대로 동작하지 않는다고 해요.
참고) https://kyounghwan01.github.io/blog/JS/JSbasic/for-await-of/#for-await-of
해결책으로 for of, Promise.all 을 주로 얘기하네요.
{나}
map이 async/await가 보장되지 않음에도 async/await를 사용한 이유는
const { signedUrl } = await this.awsS3Service.getSignedUrl(
bucketName as S3_BUCKET,
keyName,
600,
{
ResponseContentDisposition: `attachment; filename="${fileName}"`
}
);
이 코드에서 signedUrl 가져오는 로직 then을 사용하지 않고 로직을 쉽게 작성하기 위해서에요.
{동료}
promise 를 resolve 해줄 수도 없는데 async await 쓰는 건 더 이상한데요...
type 때문에 동작 안 하는 키워드 쓰는 건 아닌 거 같아요
{나}
위 if 절이 map 콜백 함수 내부에 있다고 해서 async/await 자체가 동작하지 않는게 아닙니다.
좀 더 풀어서 설명해드리면 map에 콜백 함수가 async 함수이고 async 함수는 항상 promise를 반환하니까 map에 결과 값이 promise 배열이 되어서 await 할 수 없는거에요.
await는 promise 객체 외엔 그 값 그대로 전달하니까요.
그러니까 map에 전달된 콜백 함수 입장에선 async/await가 동작하지 않는게 아닙니다.
정리하면 variants 배열 내부 값에 promise 객체를 resolve하지 않아도 되는 상황에서 map 내부 콜백 함수에 if 절 내부에 비동기 로직에 대한 흐름을 제어하기 위해 async/await를 사용한 것이 제 의도였습니다.
{동료}
맞아요 콜백에서도 await 동작이 안 된다고 잘못 생각했네요. 설명 감사합니다!
이처럼 코드 리뷰 과정에서 본인의 주장에 논리적인 근거를 들어 설명할 수 있어야만 원활한 커뮤니케이션이 가능하고 그 과정에서 효율적인 협업, 높은 품질의 코드, 지식의 전파가 이루어 질 수 있다.
민첩하게 커뮤니케이션하려고 노력했다.
실제로 동료들이 어떻게 개발하고 있는지 상세하게 공유되고 있어야 잘못된 부분을 빠르게 발견하고 수정할 수 있는데 이 관점에서 민첩한 커뮤니케이션 능력이 부족함을 느꼈다.
이 부분을 개선하기 위해선 pull request를 할 때 본인이 무엇을 개발했는지, 어떤 점이 고민이고 어떤 점을 중점적으로 리뷰 해주었으면 좋겠는지를 보다 상세하게 적어 의사소통의 효율성을 높히려 노력했다.
효과적인 커뮤니케이션에 대해 다음과 같은 피드백을 받았다.
적은 리소스로 의사소통을 한다면 효율적인 의사소통일 것입니다.
그러나 효율만 따진다면 수신자 입장에서 접수되지 못하는 의사소통은 의미가 없을 겁니다.
효과적인 커뮤니케이션 스킬에 대해서도 관심을 가질 필요가 있습니다.
효과적인 의사소통은 언어, 행동, 문자, 타이밍 등 복잡한 요소들이 관련되어 있습니다.
그 중 특별히 공감하고 있다는 신호를 지속적으로 보내는 연습이 필요합니다.
문자로 소통하는 경우, reaction을 표현한다거나, 리뷰 할 때에 잘 한 것과 부족한 것을 같이 얘기한다거나 하는 습관이 필요합니다.
효과적이지 못하면 효율적이지 못하다는 것을 깨달았다.
내가 적은 비용으로 의사소통 한다고 해서 상대방에게 내용이 전달되지 않는다면 의사소통이 되지 않는 것이다.
즉, 수신자를 고려한 발신자로서 의사소통해야만 효과적인 의사소통이 이루어질 수 있다는 것을 간과했던 것 같다.
소프트웨어 설계 도구를 활용하여 의사소통 할 수 있어야한다는 피드백을 받았다.
이전에 작업한 설계 내용을 보면 표기법이 표준(UML)과 달라서 헷갈리는 경우가 있었습니다.
디자인을 리뷰하려면 설계도가 필요할 것이고 결국 모델로 표현되어야 할텐데, 표기법에 대한 상이하게 이해를 한다면 리뷰가 어려울 수 있습니다.
커머스 프론트 개발자들 간에 리뷰할 때에 UML 기법을 활용하여 표기하고 리뷰하면좋을 것 같습니다.
설계도구는 Lucidchart, StarUML, Enterprise Architect 같은 도구를 활용해보길 권합니다.
학교... 전반적으로 수업이 재미가 없고 시간이 아깝다고 느껴졌다.
하지만 좋은 사람들을 만날 수 있는 기회가 많은 곳임은 확실하다고 느껴진다.
2023년도 1학기는 학교 수업 보단 학교 내 IT 동아리 데브팡에서 진행한 IT 컨퍼런스 활동에 많은 리소스를 할애했다.
또 이번 학기에는 승마 수업을 들었는데 새로운 경험을 할 수 있어서 즐거웠다.
나는 사람에게 주어진 환경이 행사하는 영향력이 매우 크다고 생각한다.
그렇기 때문에 IT에 관심 있는 뛰어난 사람들이 많은 환경이 성장에 있어서 긍정적인 영향력을 행사 할 것이라고 생각한다.
대학교에는 이미 개발자로 활동하는 사람, 개발에 관심이 있는 사람, 꼭 개발이 아니더라도 IT에 관심 있는 사람이 많았다.
이렇게 좋은 사람들을 활용하여 서로에 성장에 있어서 긍정적인 영향력을 행사 할 수 있는 환경을 만들고 싶었다.
우리 학교에 학과 강의가 객관적으로 대부분 질이 낮아 IT에 관심이 있는 사람들이 성장하기엔 매우 부족한 상황이기도 했다.
그래서 각자 가지고 있는 지식과 생각 등을 공유하는 여러 활동들을 통해 참여자 모두 정신적, 기술적으로 성장을 목적으로 활동하는 IT 동아리 데브팡을 만들었다.
데브팡 동아리 소개 페이지
내가 집중한 활동으로는 IT 컨퍼런스 활동이다.
나는 컨퍼런스 활동에서 성장에 도움을 줄 수 있는 감사한 분들을 만날 수 있는 기회가 많고 좋은 발표를 들으면 성장에 긍정적인 인사이트를 얻을 수 있다고 생각한다.
생각해보면 학교 뿐만 아니라 회사, 친구, 가족 등 우리 주변엔 서로의 성장에 도움을 줄 수 있는 좋은 사람들이 이 사람들이 모여서 좋은 네트워킹 활동을 한다면 서로에게 정말 좋은 성장에 기회일 것이라고 생각했다.
그래서 주제넘게도 주변에 내가 신뢰하는 뛰어난 지인분들에게 연사로 참여를 부탁하여 IT 컨퍼런스를 진행했고 부탁한 분들 모두 흔쾌히 수락해주셨다.
결과적으로 다음의 컨퍼런스가 완성되었다.
컨퍼런스 활동에 대한 구체적인 회고가 담긴 글은 추후에 따로 작성할 예정이다.
고생하신 운영진들, 연사분들, 참여자분들 너무 감사하다.
항상 유익하고 재밌는 이야기를 해주셔서 너무나 좋은 강교수님 모임도 주기적으로 가지고 있다.
이번 모임 일정은 1차 장어덮밥, 2차 제철 사시미와 사케, 3차 위스키였다.
주기적으로 또 뵐 것 같다!
사시미, 안키모, 케비어도 정말 맛있었지만 사케가 정말 깔끔하고 맛있었다!
사케가 너무 마음에 들어서 이후에 회사 지인한테도 대접하러 재방문했다 ㅎㅎ
교수님이 추천해주신 위스키가 향이 조금 강했지만, 끝 향으로 살짝 탄향이 올라와서 매력적이었다.
이번 학기엔 어떤 재밌는 꿀 강의가 있을까 찾다가 발견한 승마 수업..
꿀강의인 만큼 경재률이 매우 치열했고 이거 때문에 이러닝 꿀강의를 놓쳤다..
이것이 옳은 선택이었는지 아직도 의문이다... ㅋㅋ;
이 수업도 교양 스키와 마찬가지로 학기 중에 수업을 하지 않고 학기 말에 승마장가서 1박 2일 동안 말타고 오면 된다!
말을 태어나서 처음 타봤는데... 생각보다 진짜 힘들다.. 말도 진짜 엄청 커서 가까이 가면 꽤 무섭다..
그래도 재밌고 새로운 경험도하고 현역 대학생들과 술도 마시고 재밌었던 것 같다 ㅋㅋㅋㅋㅋ
2023년 3월 31일 오전 8시 경에 친할머니가 돌아가셨다.
사실 곧 돌아가실 것이라는 것을 우리 가족 모두가 알고 있었다.
노화로 건강이 많이 좋지 못하셨고 병문안을 가도 나를 못알아보시는 경우가 많으셨다.
유치원 때부터 13살까지 할머니와 함께 살아서 어린 시절엔 할머니와 지낸 시간이 부모님과 지낸 시간 보다 훨씬 길다.
지금 생각해보면 정말 말을 안듣고 속을 썩이는 손자였던 것 같다.
매일 집을 어지르고 저금통에서 동전을 빼서 쓰기도하고 자주 투정만 부렸던 것이 기억난다.
그럼에도 항상 할머니는 나에게 좋은 것을 먹이려고 좋은 옷을 입히려 하고 부모님한테 혼 날 때면 혼내지 말라고 말려주시는 분이셨다.
유치원 때 할머니 손잡고 유치원 등원을 하던게 어렴풋이 기억이 난다.
유치원에 갔다오면 할머니가 밥에 달걀 프라이를 얹어서 주시던게 기억이 난다.
피자가 먹고 싶다고 하면 언제든 사주셨던게 기억이 난다.
학원을 갔다 집에 돌아오면 항상 방에서 화투를 치시며 밥은 먹었냐고 하시는 모습이 기억 난다.
내가 말을 안들어서 속상해 우시던 모습이 기억 난다.
밤이면 아파트 정자에서 할머니와 함께 퇴근하는 아빠를 기다렸던게 기억이 난다.
나는 할머니가 돌아가실 때까지 키워준 은혜를 갚지 못한 손자였다.
병문안에 갔을 때 할머니가 나를 기억하지 못하셨던게 할머니의 건강 문제일까? 자주 방문하지 못했던 나의 문제일까?
학교, 회사를 다닌다며 바쁘다는 같잖은 핑계로 자주 방문하지 못했던 내 잘못이고 불효이다.
돌아가셨다는 소식을 듣고 처음엔 실감이 나지 않았다.
아무런 생각이 안났던 것 같다.
영안실에 입관하실 때 너무도 왜소해진 할머니의 모습을 보며 마지막 인사를 드릴 때 할머니와의 추억이 머릿속에 떠올라 너무도 슬프고 죄송했다.
어린 시절 추억을 떠올리며 다시는 뵐 수 있는 기회가 없다는 것이 답답하고 슬펐다.
살아계실 때 키워줘서 고맙다, 사랑한다는 말을 전해드리지 못한걸 평생 후회할 것 같다.
클래스101에 벌써 2년이 지났다.
엔지니어링 조직은 내가 성장할 수 있는 환경에 적합하다고 생각한다.
하지만 클래스101에 BM에 진심으로 공감이 되지 않는다.
항상 유튜브를 보는게 더 이득 아닌가? 이걸 돈주고 수강할 만큼에 가치가 있나? 라는 의문이 든다.
물론 엄청나게 유명한 사람들의 강의를 돈주고 듣는 것은 그럴 수 있다고 생각한다.
근데 그 강의들은 유명한 사람을 섭외하는데 많은 돈이 들어서 실제로 돈을 많이 버는 것에 유의미한 효과가 있는지 의문이다.
근본적으로 클래스를 제작하는데 너무 비용이 많이 들어서 인풋 대비 아웃풋, 즉 마진을 남기기 어려울 것 같다는 생각이 머릿속을 떠나지 않는다.
뭔가 특정 카테고리에 특화된 BM으로 방향을 틀어야 하지 않을까?
잘 모르겠다..
아무튼 그래서 이직을 해야하는지 많은 고민이 된다.
지금까진 회사가 적자여도 투자금으로 버텼지만 결국엔 흑자를 달성하지 못하면 망할 것이 자명하고 낮은 금리와 여러가지 상황들로 인한 자금 유동성이 막히고 경기가 매우 좋지 못해서 회사가 쉽지 않아 보인다..
좋은 사람을 많이 만나기 위해선 나부터 좋은 사람이 되어야겠다는 생각이 들었다.
우연히 친구와 교보문고를 들렸는데 몇년 전부터 계~~속 베트스셀러로 전시되어 있던 데일카네기의 인간관계론이 눈에 보여서 바로 구매해서 읽게 되었다.
이 책에 내용은 내가 사람을 대할 때 좋지 못한 습관에 대해 모든 것을 지적하고 있었다.
책 내용 중 읽고나서 당장 고쳐야겠다고 생각한 내용들이 있었는데 다음과 같다.
그러나 나는 상대방을 비난하고자 하는 생각이 먼저 드는 경우가 자주 있었다.
비난은 아무런 쓸모가 없다. 사람들을 방어적으로 만들고, 스스로를 정당화하도록 만들기 때문이다. 비난은 위험하다. 사람들이 소중히 여기는 자부심에 상처를 입히고, 자존감을 훼손하며, 적개심을 불러일으키기 때문이다.
잘못을 저지른 사람은 자신이 아닌 다른 모든 사람들을 비난한다. 우리 모두가 그렇다.
우리가 고쳐 보려고 하고 비난하려고 하는 사람은 아마도 자신을 정당화할 뿐 아니라 도리어 우리를 비난할 것이라는 점을 깨닫도록 하자.
사람들을 비난하는 대신 이해하려고 노력해 보자. 왜 그 사람들이 그런 일을 했는지 이해하려고 애써 보자. 비판보다는 훨씬 더 도움이 되고 재미있을 것이다. 그러다 보면 공감, 관용, 친절도 몸에 배게 된다. "모든 것을 알게 되면 모든 것을 용서하게 된다."
비판을 해야만 한다면 ... 칭찬과 진심에서 우러나온 감사로 대화를 시작하라.
생각해보면 나 또한 칭찬, 인정, 격려를 통해 성장했었던 것 같다.
그런데 정작 나는 내가 좋아하고 잘됐으면 하는 사람들에게 칭찬, 인정, 격려에 대해 인색했다.
칭찬해야한다! 칭찬은 고래도 춤추게 한다는 말이 있듯이 칭찬이야말로 타인에게 긍정적인 영향력을 행사할 수 있는 아주 좋은 기술이다.
듀이는 인간 본성의 가장 깊은 충동은 '중요한 사람이 되고픈 욕망'이라고 말했다.
윌리엄 제임스는 말했다. "인간 본성의 가장 깊은 곳에 있는 원리는 인정받고 싶은 갈망이다."
슈와브는 말했다. ... "사람이 가지고 있는 최고의 능력을 끌어내는 방법은 인정과 격려입니다."
"다른 사람을 솔직하게, 진심으로 인정하고 칭찬하라." 그러면 사람들은 당신의 말을 소중하게 받아들이고, 평생에 걸쳐 그 말을 보물처럼 여기고 반복할 것이다. 당신이 그 말을 잊은 다음에도 몇 년씩이나 반복할 것이다.
비난 대신 칭찬을 사용하는게 어떨까? 약간이라도 나아지는 구석이 있다면 칭찬을 해 주도록 하자. 그러면 다른 사람들은 격려를 받으며 자신을 계속 더 나아지게 만드는 셈이다.
약간의 발전만 있어도 칭찬하고, 발전이 있을 때마다 칭찬하라. "진심으로 인정하고, 칭찬을 아끼지 마라."
나는 어려서부터 사람들에게 관심을 별로 두지 않았다.
나는 그저 나에게만 관심이 많았던 것 같다.
그런데.. 좋은 사람들을 많이 만나고 싶다면 이 생각은 매우 오만한 생각이였다.
내가 다른 사람에게 관심을 보이지 않는데, 어떻게 먼저 다가와 주길 바라는가?
당신이 다른 사람에게 관심을 가지면, 단 두 달 만에 다른 사람들이 당신에게 관심을 갖도록 노력하며 이 년 동안 얻을 수 있는 친구보다 훨씬 더 많은 친구를 얻을 수 있다.
사람들은 당신에게 관심이 없다. 사람들은 내게도 물론 관심이 없다. 사람들은 자신에게만 관심이 있다. 아침에도, 점심에도, 그리고 저녁에도.
정육점 주인이건, 빵을 만드는 사람이건, 왕좌에 앉아 있는 왕이건 간에 우리 모두는 우리를 존경하는 사람들을 좋아한다.
다른 사람에게 진심으로 관심을 가져라.
나는 살면서 표정변화가 거의 없다는 이야기를 많이 들었다.
인상도 좋지 못해 차갑고 무서운 분위기라는 소리도 자주 들었다.
웃음이 없다면 상대방에게 좋은 인상을 남기기란 매우 어려운 일이다.
일단 웃어야 한다 웃는 얼굴에 침은 못뱉는다...
셰익스피어가 말했다. "본질적으로 좋고 나쁜 건 없다. 우리의 생각이 어떤 것을 좋거나 나쁜 것으로 만든다."
올바른 정신적 태도를 가져라. 용기 있는 태도, 솔직한 태도, 유쾌한 태도 말이다.
웃는 얼굴을 가지지 못한 사람은 상점을 열어선 안된다.
크리스마스 시즌의 미소의 가치
미소는 한푼도 들지 않아요. 하지만 많은 결과를 만들어 내죠.
미소는 받는 사람을 부자로 만들어 줘요. 하지만 그걸 준다고 해서 그 만큼 가난해지는 게 아니죠.
미소는 순식간에 벌어지는 일이지만, 그 기억은 평생 지속되기도 해요.
미소 없이 지낼 수 있을 정도로 부자인 사람은 세상에 없고, 아무리 가난한 사람도 마소가 주는 기쁨으로 부자가 될 수 있어요.
미소는 집에서는 행복하게 만들어주고, 일에서는 호의를 낳고, 친구들 간에는 우정의 징표가 되지요.
미소는 피곤하고 지친 사람들에게는 안식, 실망한 사람에게는 빛, 슬픈 사람들에게는 햇살, 어려운 상황에 처한 사람들에게는 최고의 해독제죠.
하지만 미소는 돈 주고 살 수도, 구걸 할 수도, 빌릴 수도, 훔칠 수도 없어요. 한사람이 다른 사람에게 그냥 주기전까지는 이 세상 물건이 아니기 때문이죠.
크리스마스 시즌 막바지에 우리 직원들이 너무 피곤해 미소를 짖지 못하면, 미소를 남겨 주시곘어요? 더 이상 미소를 짖지 못하는 사람이야말로 미소를 가장 필요로 하거든요!
데일카네기 선생님은 지금으로부터 87년 전에 현재까지도 여전히 정확하게 적용되는 인간관계에 대한 통찰을 이미 깨닫고 책으로 공유하셨다는게 정말 놀랍다.
이 책의 내용을 모두 숙달할 때까지 반복해서 읽을 것이다.
장기적인 자산의 증식을 위해 현재 가진 자산의 약 20퍼 정도를 주식과 달러로 분배했다.
이것을 올해까지 40퍼 정도로 늘릴 계획이다.
하지만 어떤 방식으로 자산의 40퍼를 유동성을 전환 시킬지는 의문이다.
처음엔 500만원으로 시작했던 유동성 자산이 어느세 2000만원 이상이 되었고 올해까지 3 ~ 4천만원 정도로 점진적으로 늘리는 것이 목표이다.