제 1막

SSAFY에서 사실 개발도 배웠지만, 무엇보다 "협업 / 팀활동"을 가장 많이 배웠습니다.

"실제 환경에서 진행될 수 있는 4번의 프로젝트"경험 때문입니다. 한번은 "코로나"로 인해서, 소통 자체도 어려운 상황에 있었는데 , 오히려 이때 불편했던 친구와 굉장히 가까워졌다. 

커뮤니케이션 잘하는 방법  

- 자신과 상대방의 커뮤니케이션 스타일을 파악한다. 
- 상대방이 당신에게 망설임 없이 소통 할 수 있게 하라.  (상대가 나를 왜 어려워하는지 파악해야한다)  
- 동료와 친밀한 관계를 형성하고 공감한다. ( 프로젝트를 하다보면, 서로가 좋아하는 노래를 같이 들으면서 일을 하면 재밌다.  )  

저의 강점이  상대를 보통 "편안하게 하고 신뢰감 가는 유형"이라고 생각한다. 소통을 하기 위해서는 상대방을 파악하고 거기에 맞춘다. 우선, 불편한 "이유"가 뭔지 생각한다. 왜 마음 터놓고 소통이 어려운지 찾는다. 

=> 보통 그 친구와 어울리는 친구들의 유형을 봄. => 비슷하게 행동하면 됨.  or 물어 봄.   

=> 내가 하는 고민을 "가장 친한 친구들도 했을 것이라고 생각하기 때문" 

=> 방향성만 잡고 상대방에 맞혀서 "말을 하려고 해본다"

=> 그래도 불편한 사람은 불편하지만, 팀 목적 달성하는데까지 어려움을 겪은 적은 없다. 

소통을 힘들게 하는 유형.

3가지 
- ( 자기 주장이 강한 유형 / 부정적인 유형 )

팀원의 의견을 존중하면 대부분 해결 되었음.

- ( 말이 너무 많은 친구, 핵심 파악이 어려움 ) 

핵심이 없고, 미사어구가 많아서 ,경청을 힘들게 하는 유형 => 되물어보고 요약 한번 부탁. !

- ( 말을 굉장히 어렵게 하는 사람 ) 

아는게 많아서, 말을 어렵게 하는 유형. => 되물어보면, 이런 것도 이해못했어? 라는 느낌을 비추기 때문에 더 어려움.

+ 협업 툴( 메러 모스트, 슬랙, ) : 이것을 이용해서 좀 더 어려운걸 해결함. 

갈등 경험

대부분 기획 단계인 "아이디어 도출하는 과정"에서 팀원들과의 갈등이 많이 있었습니다. 저는 이 단계에서 발생하는 갈등은 오히려 팀의 발전에 더욱 도움이 된다고 생각합니다. 이 단계에서 갈등이 나오고 이를 맞춰가는 과정에서 서로가 만족할 만한 프로젝트를 진행하기 위한 아이디어가 나온다고 생각하기 때문입니다. 그 이후, 개발단계에서 서로가 팀 목적을 더 다지고 개발할 수 있었기 때문에 적극적으로 참여했습니다.  

레디스를 가장 쉽게 실습할 수 있는 것이 "채팅"
카카오톡, 라인에서 다 쓴다. 
인증 정보를 보관할 때 ( JWT 토큰 ) : 데이터를 저장할 때 만료 시간 지정 가능. 
랭킹 ( 게임에서 필요한 실시간 랭킹 ) 

1. 관심사 분리

(코드 레벨에서 관심사 분리, 함수 기능별로 쪼개면 된다.) (함수는 함수끼리 독립적이고, 서로 엮여있을 필요없다.) (백엔드 Servlet filter - controller -service -repository)

• 각 계층에서 어떤 일을 하는지 관심없다.
• 각 계층에서 수정이 필요할 때 다른 계층에 영향을 미치지 않는다.
• 내가 알아야 하는 건 오직 내가 호출하는 녀석뿐이다.
• 주니어 개발자도 쉽게 기능 개발을 위해서 투입될 수 있다.
• 코드를 이상하게 짰다고 해서 다른 계층과 기능으로 전파되지 않는다.
• 엔터프라이즈 코드(서버 코드)가 어떻게 동작하는지 개별 개발자의 관심사가 아니다.
• 문제가 생겨도 문제가 생긴 지점을 찾기 쉽다.
• 대규모 프로젝트 개발에 유리하다.

( 개발자 간의 관심 분리 )

• 프론트엔드가 아직 안 나와서 테스트를 못하고 있다...?
• Swagger 쓰는 이유? 백엔드, 프론트엔드 없이 테스트 해볼 수 있다. / 역할 분리

블랙박스식 개발

• 과정은 중요하지 않고, input, output에 집중한다.
• 정상적으로 동작하는지만 본다.
• 장점 : 리팩토링이 쉽다, 병목 지점을 찾아내기 쉽다. 기능의 분리가 쉽다.

30만 동시접속하는 배달 주문서비스 시스템을 만든다 어떻게 만들래? 로드 벨런서를 놓고 게이트 웨이를 넣고 분산 네트워크로 만든다.

1. 레디스 DB

관계형 데이터베이스를 느리게 하는 것이 무엇일까? 관계가 복잡할 수록..! 느려진다. ( 댓글 , 좋아요, SNS등등 ) 레디스가 빠른 이유, 관계가 복잡할수록 key-value 구조라 빠르다. -sns는 follow와 게시글의 관계가 핵심이다. -하지만, 이를 관계형 db로 follow table과 feed table을 만든다면?

• 데이터베이스의 병목으로 서비스는 곧 마비가 될 것이다.

왜?

• 내가 팔로우하는 유저들의 리스트를 가져와서, select로 feef in uid(1,3,6...)
• 댓글의 대댓글 ? 대댓글의 가져오고, 좋아요도 가져온단다면... 서버는 망가질 것이다.

그래서redis가 강점을 가진다. 왜? 관계가 없는 비관계형 DB선택 -데이터의 저장은 오직 그것의 관심사만? -혹시나 발생하는 관계를 합치는 것은 DB가 아니라 API 서버가 전담한다. -왜? API 서버는 병목이 적고 증설이 가능하니까! -DB는 대개 유일하다.( 전체가 유일한 하나의 덩어리다) follow(key-value)로 넣어둔다. key만 가져오면된다?

아들러 vs 프로이트, 융

프로이트 - 인과론( 원인, 결과 론 ) ex - 트라우마.

융 - 집단론

아들러 - 목적론( 원인과는 상관없다. ) 

핵심 : 과거와 미래가 아닌 현재 지금을 살아야한다.

책의 핵심 내용 3가지

자기수용 : 난 60인 사람임을 인정해야한다. 난 평범하다 라고 인정하는 것. 

타자신뢰 : 타인을 무조건 믿는 사람이 되어야한다. ( 의심하지 말고 일단 믿어줘라. )

타자공헌 : 타인에게 유익이 될 수 있는 사람이 되어야 한다.

자기 수용:

- 내가 할 수 있는 것 vs 내가 할 수없는 것을 분리하는 것이 첫번째다. 

- 과제의 분리

( 남의 일과 나의 일은 분리해서 생각을 하라 , 상대는 통제가 불가능한 대상이다. )

( 현재에 집중에 가장 최선을 할 수 있는 것을 하는 것이 중요하다 , 현재를 과정으로 즐겨야 한다. )

( 개입보단 지원 ) 

타자 신뢰: 

( 자랑은 나의 열등감을 감추려고 하는 행동이다. ) 

( 타인과의 경쟁이 아니다. 주변을 나의 적으로 만들지 말고 친구로 생각하라. )

( 타인에게 인정받기 원하는 마음을 없애라, 모든걸 나 위주로 생각하라. )

타자 공헌:

( 타인에게 자유를 원한다면, '미움 받을 용기'가 필요하다. ) 

( 타인에게 '기대'를 위해서가 아닌, 내가 타인에게 도움이 될 수 있는 행동을 하라. )

( 10명의 사람이 있다면 7명은 나에게 관심없다 / 1명은 나를 싫어한다 / 2명은 나를 좋아한다 )

나의 현재 상황을 인정하라. 취업을 못했고, 취준이 길어졌다. (현재의 나의 상황을 인정하라) 

남들은 나보다 늦게 취준하고 벌써 취업했는데... (남과 비교하지말라)

[KOR]

이 상황이 시작됐을 때 이렇게까지 나빠질 줄은 정말 몰랐어.

난 몇 주만에 상황이 종료될 줄 알았어.

길어져야 한 달? 근데 누가 알았겠어? 이제 한 달 더 됐는데 나아지지 않고 있어.

그리고 정말 답답한 것은 우리가 할 수 있는게 조심하는 것 말고는 없다는거야.

[ENG]

When this whole thing started, I really didn't think it would get this bad. I thought it would be over(끝났다) in a matter of weeks

( in weeks라고 해도 되지만 in a matter of weeks 라고 하면 단지 몇주만에 라는 짧은 느낌을 준다) 

~나는 뭐뭐할 줄 알았다!!!! => i thought it would be ~~~~!!!! (중요하다 )    

A month at the longest. But who would've known, right? It's been over a month now and it's not letting up.

And it's so frustrating to know that the only thing we can do about it is to be careful.

// frustrating 답답하다. 

// it's so frustrating to know => ~~한 사실이 너무 답답하다. 

-> 원래는 fact that을 쓰지만, 그렇게 연결이 안되기 때문에  to know라고 쓴다.