아이젠하워 매트릭스

  • 업무의 우선순위를 먼저 해야 할 일, 계획해야 할 일, 위임할 일, 하지 않아도 될 일 4단계로 분류

업무 우선순위

  1. 자신의 업무를 모두 나열
  2. 각 업무의 긴급성과 중요도 판단
  3. 업무를 4개의 카테고리로 분류
    1. 긴급하고 중요한 일 - 먼저 해야할 일
    2. 긴급하지 않지만 중요한 일 - 계획해야 할 일
    3. 긴급하지 않지만, 중요하지 않은 일 - 위임할 일
    4. 긴급하지도, 중요하지 않은 일 - 하지 않아도 될 일
  4. 아이젠하워 매트릭스에 따라 우선순위 확인하고, 일정 계획

아이젠하워 매트릭스

 

아이젠하워 매트릭스

  1. 중요하고 급한 일 - 먼저 한다
    명확한 결과가 따르며 장기 목표에도 영향을 주는 업무로서, 가장 먼저 해야 하는 업무입니다.
    이 카테고리 안의 업무들은 미루지 않고 바로 처리하는 것이 좋습니다.
  2. 중요하지만 급하지 않은 일 - 계획한다
    장기 목표에 영향을 미치지만 당장 처리하지 않아도 되는 일입니다.
    긴급하지 않기 때문에 신중하게 준비하고 계획하여 완성도를 높일 수 있습니다.
    중요하고 급한 일을 해결한 뒤 이 카테고리 안의 업무를 처리합니다.
    이 업무들을 마냥 미뤄두지는 않도록 주의해야 하며, 집중력을 발휘하여 수행할 수 있도록 합니다.
  3. 중요하지 않지만 급한 일 - 위임한다
    바로 처리되어야 하지만 장기 목표에는 영향을 미치지 않는 업무입니다.
    이러한 업무는 에너지 소모가 많지만 특별한 기술은 요하지 않는 잔업인 경우가 많습니다.
    꼭 본인이 직접 하지 않아도 되는 일이기 때문에, 다른 사람에게 위임하거나 대체 시스템을 마련하도록 합니다.
  4. 중요하지도 급하지도 않은 일 - 하지 않는다
    목표를 달성하는 데 방해가 되는 일입니다.
    업무 목록에서 삭제하도록 합니다.

긴급한 일과 중요한 일을 구별하는 법

  • 긴급한 일
    • 즉시 해야 하는 일로, 기한 안에 처리하지 못하면 명확한 결과가 나타납니다.
      • 예) 기한이 임박한일, 장애, 긴급 지시사항, CS 이슈 등
  • 중요한 일
    • 당장 하지 않아도 되지만, 장기적인 목표에 도움이 되는 일입니다.
      • 예) 신 기능 스터디, 프로젝트 계획, 3rd Party 솔루션 도입

참고자료

https://1891ghaon.tistory.com/117

 


업무의 우선순위 7단계

  1. 모든 업무가 포함된 하나의 작업 목록을 만들기
    1. 효과적으로 우선순위 정하는 첫 단계는 업무의 전체 범위를 파악하는 것부터 시작합니다.
    2. 모든 업무가 기록되면 각 업무의 중요성, 긴급성, 소요 시간, 보상을 적습니다.
  2. 중요한 사항 식별하기 : 진정한 목표 이해하기
    1. 우선순위를 정하는 일은 즉각적인 '시간 관리 전략'처럼 보일 수 있지만 장기적인 '목표 달성 전략'이기도 합니다.
    2. 설정된 목표(큰 그림)를 위해 자신이 어떤 일을 하고 있는지 이해해야 미래 결과와 가장 관련이 있는 업무파악할 수 있습니다.
    3. 최종 목표에 영향을 주지 않는 작업으로 하루를 채우는 것은 시간 낭비입니다.
      항상 목표를 염두해 두고 있어야 합니다.
  3. 긴급한 사항을 강조 표시하기
    • 할 일 목록에서 마감일이 눈에 띄도록 하면 신속하게 완료해야 하는 작업을 알 수 있습니다.
    • 공식적으로 필요하지 않은 경우에도 마감일을 설정해야 합니다. 그렇지 않으면 중요한 작업을 계속 미루게 될 것입니다.
  4. 중요성 긴급성을 바탕으로 우선순위를 정한다.(아이젠하워 매트릭스)
    • 중요하고 긴급한 일 : 먼저 수행합니다.
    • 중요하지만 긴급하지 않은 일 : 전략적 계획을 세우고 완료일을 정합니다.
    • 긴급하지만 중요하지 않은 일 : 일을 축소하거나 권한을 위임합니다.
    • 긴급하지도 중요하지도 않은 일 : 할 일 목록에서 삭제합니다.
  5. 우선순위가 겹치는 것은 피한다
  6. 한 번에 하나의 중요한 작업에 집중해야 합니다.
    여러 가지의 우선 순위를 계속 시도하고 관리하는 것은 성과 저하로 이어집니다.
  7. 시간과 노력을 고려한다
  8. 할 일 목록이 너무 많아 부담스럽다면 최소한의 시간과 노력이 드는 작업에 우선순위를 두고 신속하게 진행하세요.
    작업을 정리하면 여유와 함께 작업을 추진할 수 있는 성취감이 생깁니다.
  9. 끊임없이 검토하고 현실을 반영해라
  10. 업무 목록과 우선순위자주 검토하는 것이 '통제력 및 집중력 유지'에 중요합니다.

 

참고자료

 

 
728x90
반응형
 

인터넷 속도를 측정하기 위해서 fast.com등 여러 사이트를 이용한다.

맥 터미널에서 명령어 하나로 간단하게 인터넷 속도를 측정할 수 있다.

networkQuality

 
728x90
반응형

'OS > MacOS' 카테고리의 다른 글

맥(mac)에서 텍스트 파일 인코딩 변경하기  (0) 2024.01.15

윈도우를 사용하는 분들과 협업을 하다보면 윈도우에서 작성된 텍스트 파일이 UTF-8이 아닌 MS-949 (CP-949) 인코딩으로 작성된 파일을 받을 때가 있다. 국제 표준인 UTF-8을 이용해 주시면 감사하겠지만, 어쩔 수 없이 내가 인코딩을 변경 해 줘야 한다.

CP-949에서 UTF-8로 인코딩을 변경하는 것은 터미널에서 간단하게 처리 할 수 있다.

iconv -c -f {원본 인코딩} -t {변환 인코딩} {원본 파일} > {저장 파일}

 
 
728x90
반응형

'OS > MacOS' 카테고리의 다른 글

mac(맥)에서 인터넷 속도 측정하기  (0) 2024.01.15
728x90
반응형

건강관리

솔직히 자신 있게 운동을 많이 했다고는 할 수 없다.
날이 좋을 때는 일주일에 4회까지도 러닝을 나갔으나, 야외에서 하는 러닝의 특성상 눈/비가 오면 못 나가고, 겨울이 되고 추워지니 또 나가기가 쉽지 않다.
건강을 위해 헬스장을 다니는 것이 좋겠지만, 그러자니 너무 진부하기도 하고 운동기구 차례를 기다리느라 시간 낭비하는 것을 별로 좋아하지 않다보니...
그렇지만 24년에는 23년보다 더 건강을 챙기는 해가 되어야 한다.

여행과 문화생활

2022년에는 분기에 2회 이상 전시회를 다녔으나, 올해는 그 정도로 전시를 많이 다니지는 않았다.
그렇지만 해외 뮤지션들의 굵직한 내한 공연을 3회 다녀왔으니 아무래도 작년보다 더 문화생활을 즐겼다고 생각한다.

그리고 미뤄뒀던 국내 여행도 이번 달에 여수를 다녀왔고 맛있는 것도 많이 먹고 왔다.

나름 청춘을 잘 즐겼다고 자신할 수 있지만, 그만큼 이직이나 공부에 신경 쓰지 않을 건가 싶은 생각도 들기도 하고... 뭐든지 트레이드 오프기 때문에 후회는 없다.
2024년에도 문화생활을 놓치지 않고 꾸준히 하겠다.

Bruno MarsEdward Hopper

 

 

소비 패턴에 대한 성찰

올해 저축을 많이 못 했다. 회사에서 번 돈을 회사에 잔뜩 써버렸다.
아무래도 담당 중인 업무가 쇼핑몰 서비스 운영이기도 하고, 마케팅에 당했다고 해야 하나 아니면 직원 할인의 늪에 빠져버렸다고 해야 하나.
아무튼 옷을 너무 많이 샀다.

경제가 어렵다고 그 경제를 내가 살리는 미친 짓은 그만둬야 한다.

생활을 이루는 필수 3요소는 의식주인데, 그중에 의가 직원할인이라는 이유로 비교적 저렴하게 양질의 상품을 얻을 수 있다 보니 자꾸 지르게 되는 것도 있는 것 같다. 사실 회사 옷을 입다가 저렴한 보세 상품을 보면 확실히 질이 떨어지는 게 눈에 보인다. 그리고 주변 직원들이 아무리 후줄근하게 입고 출근해도 잘 꾸미고 오는 것을 보면 남루하게 출근하는 날에는 뭔가 의기소침해지는 나를 보기도 한다.

그래도 어쩌겠는가? 옷의 질을 올리다 내 노년에 삶의 질이 낮아질 수 있음을 경계해야 한다.

개그맨 박영진 그랬다 "사장님이 미쳤어요"에서 사장님은 멀쩡하고 "미친 건 나"라고. 90% 할인은 내가 물건을 구매할 확률이 90%라는 것.
24년에는 소비를 경계하고 저축을 가까이하겠다..

연애

나 연애한다.


이직? 어쩌면 보다 많은 면접 경험

블로그의 목적이 일하면서 얻게 된 지식과 이직에 대한 기록이니 이직 준비 과정에서 얻은 경험을 정리한다.

2023년은 월평균 1.5회의 면접을 봤고 이 경험으로 얻은 것이 은근히 많다. 떨어진 곳도 많고 처우 협상에서 엎어지거나 최종 합격했지만, 내가 거절한 곳도 있다. 그럼 이런 과정에서 얻은 것이 무엇이냐?

상반기에는 이력서 점검을 주력으로 했다. 서류 지원을 100건 이상, 그 중 코테는 10회, 코테에서 면접으로 이어진 것은 3건으로 코테 성적이 별로 좋지 않다. (어쩌면 코테 후 서류 검토라서 서류에서 떨어졌을 수 있다는 생각도 하고 있다.) 서류 100건 중 60건은 개선해 나간 이력서에 대한 검증이라고 생각한다.
물론 이력서에 기업에서 원하는 기술 스펙이 없어서 떨어진 것도 있고, 혹은 학력에서 걸러졌을 수도 있다고 생각한다.
아무튼 이력서를 지금으로써는 나름 잘 정리했다고 생각한다.
부족한 건 역시나 나의 기초지식면접 스킬, 해당 기업에서 원하는 기술 스택, 면접과 시험을 응시하는 내 실력이라는 결론이다.

20개 조금 안 되는 회사에 면접을 봤는데, 기술 면접에서 말아 먹은 곳이 많았다. 내가 한 일들 기반으로 쓴 이력서이지만 그 안에서 실제로 내가 알지 못한 기술적인 것들이 많았다. 기초 지식이 부족한 것에 대해서는 개략적으로 정리를 했지만, 블로그에 남기진 않았다.
그래서 24년 상반기 목표 중 하나는 이력서에 적은 프로젝트에 대한 디테일한 정리도 포함된다.

처우 협상에서 엎어진 곳도 8곳이나 된다. 나는 내 연봉이 높은 편이라고 생각 못 했는데, 생각보다 연차치고는 많이 받는 편이었나 보다. 지금 연봉보다 깎으려는 곳이 나 동결하려는 곳도 더러 있었다.

붙은 곳도 있지만 가지 않은 곳도 있다. 많은 경험은 아니지만 경험적으로 1차 면접에서 기술 질문보다는 컬쳐핏, 인성 질문 위주로 사람을 뽑는 회사는 그만한 이유가 있다고 생각한다. 기술적 도전과 성장보다는 지원 부서로써의 역할이 큰 것 같더라. 혹은 사람을 뽑은 경험이 많지 않아 어떤 질문을 해야 하는지 모르는 것일 수도 있다. 어쩌면 편견일 수 있다.

아무튼 기술, 컬쳐핏, 인성 세 가지 질문이 균형 있게 확인하는 면접관들이 뭔가 그 회사에 대한 신뢰가 더 생긴다고 해야 하나. 면접을 보고 붙는 것도 쉽지 않지만, 면접을 보면서 그 회사로 이직할 것인가 말 것인가 결정하는 것 또한 쉽지 않다.

8월부터 매달 꾸준히 원티드 프리온보딩 특강을 듣는데, 그중 한 연사가 한 말이 기억에 많이 남는다.

  • 회사를 본인 기준으로 아래와 같이 3개 등급으로 나눈다.
    1. 면접을 본다면 100% 붙을 회사. (만만한 회사)
    2. 지금 다니는 곳과 비슷해서 붙어도 안 갈 가능성이 높은 회사.
    3. 가고 싶은 회사
  • 나눈 기준에서 1, 2단계의 회사에 면접 경험을 많이 쌓는다.
  • 면접 과정에서 기술 질문, 컬쳐핏 질문, 인성 질문에 대한 대답 스킬을 쌓는다.
    • 1, 2 단계의 회사에서 의외로 고전할 수도 있다.
  • 3단계의 회사로 이직 한다.

상반기에 가고 싶은 회사의 면접을 말아먹고 느낀 것이, 사람에게 기회는 오지만 그 기회를 잡을 준비가 되어있지 않으면 원하는 것을 얻을 수 없다고 생각했다. 그리고 연사의 이 말을 듣고 내가 원하는 기회를 잡기 위해 여기저기 면접을 많이 보는 노력이 허투루 하는 것은 아니라고 생각했다.

그리고 면접을 많이 보다 보니 확실히 나중에 내가 사람을 뽑을 땐 어떤 질문을 해야 할까도 생각해 보게 된다.

24년에도 2023년 만큼 면접을 보는게 목표다.

공부

면접을 준비해서, 혹은 나의 역량 강화를 위해 공부를 열심히 하긴 했으나, 해도 해도 모자란 게 공부다.
이게 참 어려운 게 다기망양이라는 것. CS, 코테, 사용해 보지 않은 기술, 지금껏 사용했지만, 더 깊게 공부해야 하는 Java와 Spring, 시스템의 근간인 DB와 Infra, Architect 8가지 항목을 적절히 분배해서 공부해야 하는데, 그게 참 어렵다...

24년 공부 계획은 좀 다시 세워봐야겠다.

일단 구매한 인프런 인강부터 다 봐야지...


Merry Crisis and a Happy New Fear

즐거운 위기와 행복한 새로운 두려움이 문장은 2008년 그리스 금융위기 당시에 시위대가 썼던 문장이라고 한다.

다른 배경은 뒤로 하고 나는 이 문구가 새로운 앞날에 대한 모험과 도전을 이야기하는 것 같아서 좋다.

위기를 즐기고, 새로움에 대한 두려움을 행복하게 즐긴다. 그리고 그 안에서 크게 성장하길...

 

 
 
728x90
반응형

'커리어 디버깅' 카테고리의 다른 글

[회고] 2023년 상반기  (0) 2023.07.02
[면접 회고] 20230530 COY 면접 회고  (0) 2023.05.30
[면접 회고] 20230420 EI사 1차  (0) 2023.04.20
[면접 회고] W사  (0) 2023.02.27
[면접 회고] C사  (0) 2023.02.27

캐시 설계 전략

  Caching은 H/W, S/W 전반에 걸쳐 사용되는 기술이다.
  DB - application 뿐 아니라 클라이언트나 CDN에서도 캐싱을 사용한다.
  이 글에서는 DB - Web Application의 캐싱만 다룬다.

서비스 응답시간에 큰 영향을 미치는 부분은 주로 네트워크 통신과 DB I/O이다. 캐싱을 통하면 DB I/O로 인해 발생하는 오버헤드를 줄일 수 있다.

서론

Caching?

캐시는 빠른 응답과 비용 절약을 위해 사용하는 임시 데이터다.

  • 클라이언트의 요청으로 특정 데이터가 필요한 경우 서버는 DB에 질의한 뒤 결과를 반환한다.
  • 만약 요청하는 데이터의 캐시가 존재한다면 DB에 질의하지 않고 캐시로부터 데이터가 반환된다.
  • 캐기사 없다면? DB에 질의가 수행되어 반횐되고 그 결과를 캐싱한다.

캐시의 관리

캐시는 임시 데이터다. 따라서 캐시를 저장할 때 캐시가 만료되는 시간 (expire time || TTL; Time To Live)를 명시한다.
캐시는 해당 시간 내에서만 유효하고 만료 시간이 경과하면 사용할 수 없다.

캐시에 만료되는 시간을 두는 이유는 캐시가 실시간 데이터가 아니기 때문이다. 만약 원본 데이터가 바뀐다면 캐시된 내용도 바뀌어야 한다.

캐시를 사용하는 이유

캐시를 사용하면 DB에서 데이터를 읽을 때 발생하는 I/O 오버헤드를 줄일 수 있다. 캐시는 보통 Redis와 같은 In-Memory DB를 사용한다.
In-Memory DB는 메모리를 사용하기 때문에 일반적인 RDBMS보다 데이터를 읽는 속도가 빠르다. 따라서 캐시는 DB에서 데이터를 읽는 것 보다 월등히 속도가 빠르다.

모든 데이터를 캐싱하는 건?

In-Memory DB를 사용하면 요청을 빠르게 처리할 수 있지만, 메모리 특성상 데이터 소실의 위험이 있다. 또한 메모리 사용은 비용이 발생하기 때문에 방대한 양의 데이터를 모두 메모리에 적재하는 것은 큰 비용이 든다.

캐시 설계 전략이 필요한 이유

따라서 데이터의 특성에 따라 DB와 캐시를 적절히 사용하는 것이 매우 중요하다. 캐싱 전략을 올바르게 수립하면 적은 비용으로 큰 퍼포먼스 향상을 기대할 수 있다.


What to Cache

어떤 데이터를 캐싱하는 것이 좋을지 생각해 보아야 한다. 캐싱하기 좋은 데이터의 특성은 다음과 같다.

  1. 자주 바뀌지 않는 데이터
  2. 자주 사용되는 데이터
  3. 자주 같은 결과를 반환하는 데이터
  4. 오래 걸리는 연산의 결과

자주 바뀌지 않는 데이터

자주 바뀌지 않는 데이터의 경우, 한 번 캐시로 저장하면 메모리에서 읽어 빠르게 사용가능하다.
원본 데이터가 바뀌면 캐시도 바뀌어야 한다. 자주 바뀌지 않는 데이터의 캐시는 오랫동안 사용이 가능하기 때문에 캐싱하는 것이 효율적이다.

자주 사용되는 데이터

자주 사용되는 데이터는 캐싱하기 좋다. 한 번 캐싱해 놓으면 캐시를 사용하여 다수의 요청을 효율적으로 처리할 수 있다.
다만, 자주 사용될 지라도 매번 결과 값이 다르면 오히려 캐싱하지 않는 것이 낫다. 만약 일정시간 동안 데이터가 변하지 않는 것이 보장되면 해당 시간만큼의 TTL로 짧은 캐시를 생성하면 된다.
예를 들어 검색처럼 새로 요청하더라도 일정 시간 동안 같은 결과가 반환되는 경우에 해당한다.

자주 같은 결과를 반환하는 데이터

자주 같은 결과를 반환하는 데이터의 경우도 캐싱을 적용하기 좋다. 예를 들어 특정 arguments의 조합에 따라 결과가 일정한 경우 해당된다.
이런 경우는 각 arguments의 조합을 key로 연산 결과를 캐싱하면 된다.

오래 걸리는 연산의 결과

무거운 연산이 반복적으로 계산되어야 한다면 연산의 특성에 맞게 결과를 캐시하는 것이 효율적이다.
또는 사전에 별도의 프로세스에서 작업을 수행하여 결과를 미리 캐싱해 놓을 수 있다.

이 밖에도 일반적인 쿼리나 연산보다 캐싱할 때의 비용이 더 적다면 캐싱을 사용할 수 있다.
로그 분석이나 프로파일링을 통해 캐시를 적용할 함수나 API를 찾을 수 있다. 그러나 모든 사항을 고려하여 캐싱을 적용할지, TTL은 얼마나 적용할지 등은 개발자의 선택이 중요하다.


캐싱 전략 패턴의 종류

캐시를 이용하게 되면 닥쳐오는 문제점이 바로 데이터 정합성의 문제이다. 같은 종류의 데이터라도 두 저장소에 저장된 값이 서로 다른 현상이 일어날 수 밖에 없는 것이다.
따라서 적절한 캐시 읽기 전략(Read Cache Strategy)과 캐시 쓰기 전략(Write Cache Strategy)를 통해, 캐시와 DB간의 데이터 불일치 문제를 극복하면서도 빠른 성능을 잃지 않게 하기위해 연구를 할 필요가 있다.

캐시 읽기 전략 (Read Cache Strategy)

Look Aside Pattern

  • Cache Aside 패턴이라고도 불림.
  • 데이터를 찾을 때 우선 캐시에 저장된 데이터가 있는지 우선 확인, 캐시에 데이터가 없으면 DB에서 조회함.
  • 반복적인 읽기가 많은 호출에 적합.
  • 캐시와 DB가 분리되어 가용되기 때문에 원하는 데이터만 별도로 구성하여 캐시에 저장.
  • 캐시와 DB가 분리되기 때문에 캐시 장애 대비 구성이 되어 있음.
    만일 Cache Store가 다운되더라도 DB에서 데이터를 가져올 수 있어 서비스 자체는 문제가 없음.
  • 대신 Cache Store에 붙어있던 connection이 많았다면, Cache Store가 다운된 순간 DB로 몰려 부하발생 가능.

일반적으로 사용되는 기본적인 캐시 전략. 이 방식은 캐시에 장애가 발생하더라도 DB에 질의를 실행함으로 캐시 장애로 인한 서비스 문제는 대비할 수 있지만, Cache Store와 DB간 정합성 유지 문제가 발생할 수 있음.
반복적으로 동일 쿼리를 수행하는 서비스에 적합, 단건 호출 빈도가 높은 서비스에는 비적합.
이런 경우 DB에서 캐시로 데이터를 미리 넣어주는 작업을 하기도 하는데 이를 Cache Warming이라고 함.

Read Through 패턴

  • 캐시에서만 데이터를 읽어오는 전략 (inline cache)
  • Look Aside와 비슷하지만 데이터 동기화를 라이브러리 또는 캐시 제공자에게 위임하는 방식이라는 차이가 있음.
  • 따라서 데이터를 조회하는데 전체적으로 속도가 느림.
  • 또한 데이터 조회를 전적으로 캐시에만 의지하므로 Cache Store가 다운될 경우 서비스 이용에 차질이 생길수 있음.
  • 캐시와 DB간의 데이터 동기화가 항상 이루어져 데이터 정합성 문제에서 벗어날 수 있음.
  • 읽기가 많은 호출에 적합

Cache Aside 방식과 비슷하지만, Cache Store에 저장하는 주체가 Server인가 혹은 Data Store 자체인가의 차이가 있음.
직접적인 DB 접근을 최소화 하고, Read에 대한 소모되는 자원을 최소화할 수 있음.
하지만 캐시에 문제가 발생하는 경우 바로 서비스 중단이 되기 때문에 Cache Store의 Replication 또는 Cluster구성하여 가용성을 높여야 함.

캐시 쓰기 전략 (Write Cache Strategy)

Write Back 패턴

  • Write Behinde 패턴이라고도 불림.
  • 캐시와 DB 동기화를 비동기하기 때문에 동기화 과정이 생략.
  • 데이터를 저장할 때 DB에 바로 질의하지 않고, 캐시에 모아서 일정 주기 배치 작업을 통해 DB에 반영.
  • 캐시에 모아놨다 DB에 쓰기 때문에 쓰기 커넥션 회수 비용과 부하를 줄일 수 있음.
  • Write가 빈번하면 서 Read를 하는데 많은 양의 리소스가 소모되는 서비스에 적합.
  • 데이터 정합성 확보.
  • 자주 사용되지 않는 불필요할 리소스 저장.
  • 캐시에서 오류발생시 데이터 영구소실의 가능성.

데이터를 저장할 때 DB가 아닌 캐시에 먼저 저장하여 모아놓았다가 특정 시점마다 DB로 쓰는 방식으로 일종의 Queue 역할을 겸하게 됨.
캐시에 데이터를 모았다 한 번에 DB에 저장하기 때문에 DB 쓰기 횟수 비용과 부하를 줄일 수 있지만, 데이터를 옮기기 전에 캐시 장애가 발생하면 데이터 유실이 발생할 수 있다는 단점이 존재.
반대로 DB에 장애가 발생하더라고 지속적인 서비스 제공을 보장하기도 함.
Replication이나 Cluster 구조를 적용하면 Cache Store 서비스의 가용성을 높일 수 있고, Read Through와 결함하변 가장 최근에 업데이트 된 데이터를 항상 캐시에서 사용할 수 있음.

Write Through 패턴

  • DB와 Cache에 동시에 데이터를 저장하는 전략.
  • 데이터를 저장할 때 먼저 캐시에 저장한 다음 DB에 저장.
  • Read Trough와 마찬가지로 DB 동기화 작업을 캐시에 위임.
  • DB와 캐시가 항상 동기화 되어 있어, 캐시의 데이터는 항상 최신 상태로 유지.
  • 캐시와 백업 저장소에 업데이트를 같이 하여 데이터 일관성 유지.
  • 데이터 유실이 발생하면 안 되는 상황에 적합.
  • 자주 사용되지 않는 불필요한 리소스 저장.
  • 매 요청마다 두번의 Write 가 발생함으로 빈번한 생성, 수정이 발생하는 서비스에서는 성능 이슈 발생.
  • 기억장치 속도가 느릴 경우, 데이터를 기록할 때 CPU가 대기하는 시간이 필요하기 때문에 성능 감소.

Cache Store와 DB에 동시에 반영하는 방식. 항상 동기화 되어 있고 항상 최신정보를 가지고 있다는 장접이 있음.
저장할 때마다 2개 과정을 거치기 때문에 상대적으로 느림.

Write Around 패턴

  • 모든 데이터는 DB에 저장
  • Cache Miss가 발생하는 경우에만 DB와 캐시에 데이터 저장
  • DB와 Cache Store의 데이터가 다를 수 있음.

Cache Miss가 발생하기 전에 DB에 저장된 데이터가 수정되었을 때, 사용자가 조회하는 Cache Store와 DB 간의 데이터 불일치 발생.


Cache 읽기 + 쓰기 전략 조합

  • Look Aside + Write Around
  • Read Through + Write Around
  • Read Through + Write Through

캐시 저장시 참고

  • Cache Hit Ratio : 캐시 사용의 정중도. 적중율이 높을 수록 CPU와 주기억장치 속도 차이로 인한 병목현상을 최소화할 수 있다.
    자주 사용되면서 자주 변경되지 않는 데이터를 캐시에 저장할 경우 높은 성능 향상을 이뤄낼 수 있다.
  • 지역성 (Locality) : Cache Hit Ratio는 캐시의 Locality, 즉 지역성에 의해 높아진다. 지역성이란 데이터 접근이 시간적 혹은 공간적으로 가깝게 일어나는 것을 의미함.
    • 시간적 지역성 : 최근에 엑세스 된 프로그램이나 데이터가 가까운 미래에 다시 엑세스 될 가능성이 높은을 의미.
    • 공간적 지역성 : 기억장치 내에 인접하여 저장된 데이터들이 연속적으로 엑세스 될 가능성이 높음을 의미.
    • 순차적 지역성 : 분기가 발생하지 않는 이상 명령어들이 기억장치에 저장된 수서대로 인출되어 실행됨을 의미
  • 일반적으로 캐시는 메모리에 저장되는 형태를 선호한다.
  • 메모리 저장소(Cache Store)는 대표적으로 Redis와 MemCached가 있으며, 메모리를 1차 저장소로 사용하기 때문에 디스크와 달리 제약적인 저장 공간을 사용한다.
  • 자주 사용되는 데이터를 어떻게 뽑아 캐시에 저장하고 자주 사용되지 않는 데이터는 어떻게 제거해 갈것이냐를 지속적으로 고민해야 할 필요성이 있다.
  • 캐시는 자주 사용되며 자주 변경되지 않는 데이터를 기준으로 하는 것이 좋다.
  • 캐시는 휘발성을 기본으로 하기 때문에 어느 정도 데이터 수집과 저장 주기를 가지도록 설계해야 한다.
  • 유실 또는 정합성이 일부 깨질 수 있다는 점을 항상 고려해야 한다.
  • 레파토 법칙 (8:2 법칙)
    전체 결과의 80%가 전체 원인의 20%에서 일어나는 현상을 가리킨다.
    80%의 활동을 20%의 유저가 하기 때문에 20%의 데이터만 캐시해도 서비스 대부분의 데이터를 커버할 수 있다는 의미다.

캐시 제거시 참고

  • 캐시는 기본적으로 영구 저장소에 저장된 데이터의 복사본으로 동작하는 경우가 많다.
  • 데이터 동기화 작업이 반드시 필요하다는 의미로 개발시 고려해야 한다.
  • 캐시 만료 정책이 제대로 구현되지 않은 경우 클라이언트는 데이터가 변경되었음에도 오래된 정보가 캐싱되어 오래된 정보를 사용할 수 있다는 문제점이 있다.
  • 따라서 캐시 구성시 기본 만료정책을 설정해야 한다.
  • 만료 주기가 너무 짧으면 데이터는 너무 짤리 제거되고 캐시의 이점이 줄어든다.
  • 만료 주기가 너무 길면 데이터 변경의 가능성과 메모리 부족현상, 자주 사용해야 하는 데이터가 제거되는 등의 역효과를 나타낼 수 있다.

Cache Stampede 현상

  • TTL 값이 너무 작게 설정될 경우 발생할 수 있는 현상이다.
  • Cache Miss로 DB에 데이터를 요청한 뒤, 다시 Cache Store에 저장하는 과정을 거칠 경우 모든 application에서 DB에서 값을 찾는 duplicate read가 발생한다.
  • 읽어온 값을 각각 Cache Store에 저장하는 duplicate write도 발생하여 처리량도 다 같이 느려질 뿐 아니라 불필요한 작업이 굉장히 늘어나 폭주장애로 이어질 가능성이 있다.

캐시 공유시 참고

  • 캐시는 application의 여러 인스턴스에서 공유하도록 설계한다.
  • 각 application의 인스턴스가 캐시에서 데이터를 읽고 수정할 수 있다.
  • 캐시 업데이트 방식
    1. 캐시 데이터의 변경 직전에 데이터가 검색된 후 변경되지 않았는지 확인해야 한다.
      변경되지 않았다면 업데이트하고 변경되었다면 업데이트 여부를 어플리케이션 레벨에서 결정할 수 있어야 한다.
    2. 캐시 데이터를 업데이트 하기 전에 Lock을 잡는 방식.
      lock을 사용할 경우 조회성 업무를 처리하는 서비스에 Lock으로 인해 대기현상이 발생할 수 있다.

캐시 가용성 참고

캐시를 구성하는 목적은 빠른 성능 확보와 데이터 전달에 있으며 데이터의 영속성 보장하기 위함은 아니다.
데이터의 영속성은 기존 RDBMS에 위임하고, 캐시는 데이터 읽기에 집중하는 것이 성능확보의 지침사항이다.
또한 Cache Store가 장애로 인해 다운 되었을 경우나 서비스가 불가능 할 경우에도 지속적인 서비스가 가능해야 한다. 이는 데이터가 결국 RDBMS에 동일하게 저장되고 유지된다는 점을 뒷바침 한다.

728x90
반응형

참고 페이지의 간소화 버전이다. 아주 조금의 신경을 쓰면 명확하게 전달되는 커밋 메세지를 작성할 수 있다.

commit message 구조

  <타입>[적용 범위(선택 사항)]: <설명>

  [본문(선택 사항)]

  [꼬리말(선택 사항)]

1. 타입

  • commit 이 무엇애 대한 작업인지 키워드를 통해 인지
    • fix: - 버그 수정
    • feat: - 새로운 기능 추가, 기존 기능 변경
    • build: - 빌드 관련 수정
    • ci: - CI 관련 수정
    • docs: - 문서(주석) 수정
    • style: 코드 스타일, 포멧팅 수정
    • refactor: - 코드 리팩토링 (기능 수정 아님. )
    • test: - 테스트 코드 추가, 수정
    • chore: 기타 변경사항 수정 (.gitignore 등)

2. 설명

  • 커밋 메시지 제목
    • 제목은 50자를 넘기지 않고, 마침표를 붙이지 않기
    • 제목에 커밋 타입을 함께 작성
    • 과거 시제를 사용하지 않고 명령조로 작성
    • 제목과 본문은 한 줄 띄워 분리
    • 제목의 첫 글자는 반드시 대문자로
    • 이슈에 관련된 내용이라면 이슈 번호를 붙히기

3. 본문

  • 자세한 설명

4. 꼬릿말

  • 이슈 번호 등

참고 : https://www.conventionalcommits.org/ko/v1.0.0/#%ea%b0%9c%ec%9a%94

728x90
반응형

'VCS' 카테고리의 다른 글

[GIT] 브랜치, 커밋 간 다른 파일 목록 조회  (0) 2022.04.05
[GIT] remote branch 가져오기  (0) 2022.04.05
[TortoiseSVN] Disconnect 방법  (0) 2021.09.10
[GIT] 윈도우에 Git 설치하기  (0) 2020.01.26

이벤트 버블링

아래 코드의 이벤트는 div에 할당되어 있지만, em이나 code 같은 자식 태그를 클릭해도 동작합니다.

  <div onclick="console.log('click div');">
    <em><code>EM</code></em>을 클릭했는데도, <code>div</code>에 할당된 핸들러가 동작합니다.</em>
  </div>

버블링

한 요소에 이벤트가 발생하면, 이 요소에 할당된 핸들러가 동작하고, 이어서 부모 요소의 핸들러가 동작합니다.
가장 최상단의 조상 요소를 만날 때까지 이 과정이 반복되면서 요소 각각에 할당된 핸들러가 동작합니다.

3개의 요소가 FORM > DIV > P 형태로 중첩된 구조에 각각 핸들러가 할당되어 있습니다.

  <form onclick="console.log('click form')">
    FORM
    <div onclick="console.log('click div')">
      DIV
      <br/>
      <p onclick="console.log(p)">P</p>
    </div>
  </form>

가장 안쪽의 p를 클릭하면 순서대로 다음과 같은 일이 벌어집니다.

  1. p에 할당된 onclick 핸들러 동작.
  2. div에 할당된 onclick 핸들러 동작.
  3. form에 할당된 onclick 핸들러 동작.
  4. document 객체를 만날 때까지, 각 요소에 할당된 onclick 핸들러 동작.

이런 동작 방식 때문에 p 요소를 클릭하면 p -> div -> form 순서로 3개의 콘솔 로그가 출력되는 것이조.
이런 흐름을 '이벤트 버블링'이라고 부릅니다.
이벤트가 제일 깊은 곳에 있는 요소에서 시작해 부모 요소를 거슬러 올라가며 발생하는 형세 입니다.

거의 모든 이벤트는 버블링 됩니다.
focus와 같이 버블링 되지 않는 이벤트도 있습니다.

event.target

부모 요소의 핸들러는 이벤트가 정확히 어디서 발생했는지 등에 대한 자세한 정보를 얻을 수 있습니다.
이벤트가 발생한 가장 안쪽의 요소는 타깃(target) 요소라고 불리고, event.target을 사용해 접근할 수 있습니다.
event.target과 this (event.currentTarget)은 다음과 같은 차이가 있습니다.

  • event.target은 실제 이벤트가 시작된 '타켓'요소 입니다. 버블링이 진행되어도 변하지 않습니다.
  • this 는 현재 요소로, 현재 실행중인 핸들러가 할당된 요소를 참조합니다.

버블링 중단하기

이벤트 버블링은 타깃 이벤트에서 시작해서 html 요소를 거쳐 document 객체를 만날 때까지 각 노드에서 모두 발생합니다.
몇몇 이벤트는 window 객체까지 거슬러 올라가기도 합니다. 이 때도 모든 핸들러가 호출됩니다.

핸들러에게 이벤트를 완전히 처리하고 난 후 버블링을 중단하도록 할 수 있습니다.
event.stopPropagation()을 사용하면됩니다.

event.stopImmediatePropagation()

한 요소의 특정 이벤트를 처리하는 핸들러가 여러개인 상황에서, 핸들러 중 하나가 버블링을 멈추더라도 나머지 핸들러는 여전히 동작합니다.
event.stopPropagation()은 위쪽으로 일어나는 버블링은 막아주지만, 다른 핸들러들이 동작하는 건 막지 못합니다.
버블링을 멈추고, 요소에 할당된 다른 핸들러의 동작도 막으려면 event.stopImmediatePropagation()을 사용해야 합니다. 이 메소드를 사용하면 요소에 할당된 특정 이벤트를 처리하는 핸들러들이 모두 동작하지 않습니다.

꼭 필요한 경우를 제외하곤 버블링을 막지 마세요

버블링은 유용합니다. 버블링을 꼭 멈춰야 하는 명백한 상황이 아니면 버블링을 막지 마세요. 아키텍쳐를 잘 고려해서 진짜 막아야 하는 상황에서만 버블링을 막으세요.
event.stopPropagation()은 추후에 문제가 될 수 있는 상황을 만들어 낼 수 있습니다.

  • 예시 시나리오
    1. 중쳡 메뉴를 만들었다 가정합니다. 각 서브메뉴에 해당하는 요소에서 클릭이벤트를 처리하도록 하고, 상위 메뉴의 클릭 이벤트 핸들러는 동작하지 않도록 stopPropagation을 적용합니다.
    2. 사람들이 페이지에서 어디를 클릭했는지 등의 행동 패턴을 분석하기 위해, window내에서 발생하는 클릭 이벤트 전부를 감지하기로 결정합니다. 일부 분석 시스템은 그렇게 분석합니다. 이런 분석 시스템의 코드는 클릭이벤트를 감지하기 위해 document.addEventListener('click', ...)을 사용합니다.
    3. stopPropagation으로 버블링을 막아놓은 영역에선 분석 시스템의 코드가 동작하지 않기 때문에 분석이 제대로 되지 않습니다. 안타깝게도 stopPropagation을 사용한 영역은 죽은 영역(dead zone)이 되어버립니다.

이벤트 버블링을 막아야 하는 경우는 거의 없습니다.
버블링을 막아야 해결 되는 문제라면 커스텀 이벤트 등을 사용해 문제를 해결할 수 있습니다.
핸들러의 event 객체에 데이터를 저장해 다른 핸들러에서 읽을 수 있게 하면, 아래쪽에서 무슨 일이 일어나는지를 부모 요소의 핸들러에게 전달할 수 있으므로, 이 방법으로도 이벤트 버블링을 통제할 수 있습니다.

 


참고 : https://ko.javascript.info/bubbling-and-capturing

728x90
반응형

'WEB > CLIENT_SIDE' 카테고리의 다른 글

Webpack과 Babel 그리고 Polyfill  (0) 2020.11.30

2023년 상반기 회고

2023년 상반기...
아등바등 살았지만, 얻은 게 무엇인지 정리 해보려니 굵직한 것은 없는 듯하다.
본격적인 여름에 돌입하는 시점에서 여러 번의 실패 끝에 방황이 다시 시작되었고 마음을 다잡기 위해서 회고하기로 결심했다. 시기적으로 지금 해야 할 시점이기도 하고.

연초에 세운 목표의 중간 점검

Java, Spring 깊게 공부하기

어느 정도는 노력했지만, 사실 목표에 크게 닿지는 못했다고 평가한다. 토비의 스프링도 1권만 1독했을 뿐 2권은 시작하지 못했고, 그 외에도 Java나 Spring의 기초이론을 복습했지만, 면접에서 제대로 설명하지 못했기 때문에 떨어졌으리라 짐작한다. 그래도 미약하게나마 Java 11과 Spring Boot, Spring Batch로 프로젝트를 하면서 이전에는 사용하지 않았던 방식의 업무도 해결했으니 어느 정도는 했다고 볼 수 있지 않을까? 기회가 된다면 코틀린도 겉핥기를 한번 해야겠다.

인강 및 프로그래밍 책 읽기

우선 작년에 결제한 알고리즘 강의를 드디어 완강했다. 사실 한번 봤다고 머리에 다 남는 것은 아니기 때문에 추가적인 공부가 필요한 상태다. 다만 지금 공부할 것들이 너무 많다고 판단되는 시점에서 어떤 것을 선택하고 집중해야 할지 정하지 못했다. 다기망양의 시대에서 회사마다 원하는 스펙이 다르고 그렇다고 한 회사만 노리고 그 스펙에 맞춰 공부한다는 건 말이 안 된다고 생각하기 때문에 이것저것 얉게라도 공부하는 게 맞는지도 모르겠다. 그래도 결국 모든 회사는 잘하는 사람을 원한다는 사실은 변함없을 테니 중요한 과목이나 기술은 기초지식을 탄탄히 해둬야 한다는 사실은 변함없을 테지. 다양한 스택이 필요해 보여 이것저것 인프런에서 결제해 둔 강의가 많은데 생각해 보니 완독한 강의가 몇 없다는 것을 알고, 일단 김영한님의 JPA 로드맵을 3/4분기 혹은 하반기 동안 완강하기로 결심했다.
독서는 많이 했다고는 자신 있게 말할 수 없지만, 출퇴근 시간에 꾸준하게 보고 있다고는 자신할 수 있다. 토비의 스프링, 헤드 퍼스트 디자인 패턴, TDD 실천법과 도구, 클린코드, 읽코좋코, 이펙티브 자바, 디자인 패턴. 6개월 동안 6권은 읽은 듯. 물론 이 역시도 한 번에 소화할 수 없는 지식들 이기 때문에 1 독이라 표현하고 추가로 2독, 3독이 필요하다고 생각한다. 어쨌든 미약하지만 출근길 독서의 습관은 잃지 않도록 해야겠다.

이직

아, 요즘의 나를 정말 무기력하게 만드는 키워드다.
"몇 곳이나 지원했는지"까지 밝히면 내가 너무 무능해 보이니 밝힐 수 없지만 정말 많이 떨어졌다. 물론 개중에 붙었지만 건방지게 입사 거절을 한 회사도 서너 곳 있지만, 코테나 1차 면접에서 떨어진 곳들이 누가 봐도 좋은 기회를 놓친 것이라 속이 많이 쓰리다. 그리고 부끄럽게도 서류에서 떨어진 곳도 많다.
기회는 준비된 사람만 잡을 수 있는 것이라고, 내가 아직 미흡한 점이 많기 때문에 목표를 이루지 못한 것으로 생각하지만, 그래도 정말 무기력해지는 것은 어쩔 수 없다. 작년 8월 말부터 이직 준비와 시도를 시작했다. 나름의 성과나 결과랄 것이 제대로 나오는 데 시간이 걸리기 마련인 것은 잘 알고있다. 이런 성취감이나 노력의 결과가 보이지 않는 시기가 있다. '아주 작은 습관의 힘'이라는 책에서는 이 구간을 낙담의 골짜기라로 표현한다. 나는 이 낙담의 골짜기를 나름 잘 견뎌내는 사람이라고 생각했는데, 올해는 정말 쉽지 않은 듯. 의지를 다시 다잡기 위해 조만간 이직 결심 사유와 내가 원하는 회사에 대해 정리를 해봐야겠다.

여행

분기에 한 번 여행이라는 키워드는 잊은 지 오래됐다. 대신 분기에 한두 번 문화생활은 하는 중. 전시나 공연을 보면서 잠시나마 낯선 경험과 노력에 대한 영감, 의지를 좀 다지게 되는 계기가 되었다.

운동과 건강

연초에 건강에 대한 계획이 있었다는 걸 잊고 있었다. 물론 틈나는 데로 집 앞 공원에서 산책 겸 러닝을 했지만, 작년에 세운 다이어트 목표는 저 멀리 사라지고 오히려 6키로 가량 쪘다...
연초에는 틈나는 데로 운동이라 목표를 설정했지만. 올 하반기는 주 3회 러닝 겸 산책을 필히 해야겠다. 러닝을 할 때 여러 생각들도 정리되고 건강도 챙기고 모로 가도 건강이 제일 중요한 게 아니겠는가...


그 외 주저리

인생이 아직 안정기에 접어들지 못했다는 이유로 후순위로 미뤄두었던 것들이 많다.
내 자신의 건강과 운동, 가족과 주변 친구들 혹은 잊었던, 새로운 인연들에도 노력을 기울여야겠다고 생각을 하게 됐다. 내한 공연을 챙겨 가게 된 계기가 "내가 혹은 아티스트가 언제 갑자기 다른 세상으로 건너갈지 모르니 기회가 있을 때 공연에서 그 바이브를 느껴보자"라는 생각에서였다. 물론 이 생각에서부터 시작된 생각은 아니지만 가족과 주변 사람들 또한 언제까지나 내 옆에 있진 않을 테니 함께 좋은 추억을 만들어 두는 것이 좋겠다고 생각하게 되었다.

인생의 안정기가 아니라는 이유로 연애도 쉬고 있는데, 인간관계에 대한 여러 생각이 스처 지나가고 내 남은 젊음을 생각했을 때 연애도 후순위로 미뤄둘 수 없는 문제라는 결론이 나왔다. 솔직히 누군가 새로운 사람을 만나 서로의 베스트프렌드가 되는 게 쉽지는 않아서 자신은 없고, 조심스러운 성격 때문에 누군가랑 친해지기도 쉽지 않은데, 뭐든 노력하지 않고 얻을 수 있는 것은 없기 때문에 조금의 노력을 해보기로 했다. 일단 사람들이랑 친해지는 것부터...

옷을 좀 그만 사야겠다. 아무래도 회사가 옷 가게다 보니, 특히나 내가 좋아하는 브랜드에서 일을 하게 되니 자꾸 소비하게 된다. 쇼핑중독의 원인은 아무래도 심리적으로 불안함(이직이 안됨)과 과도한 스트레스에 의한 통제력 상실이다. 이미 필요 이상의 옷을 샀고, 줄어든 통장과 넘쳐나는 옷장을 보니 쇼핑과 헤어질 결심을 세웠다.

취미 생활을 좀 해야 겠다는 생각을 하게 됐다. 몇 해 전까지만 해도 혼자서라도 매달 영화 한 편을 보기도 했고, 주말에는 밤세워 미드나 영화를 보기도 했고, 사진을 찍으러 나가기도 했었는데, 그런 취미활동이 삶의 우선순위를 바꾸다 보니 많이 줄었다. 어떻게든 취미생활을 좀 해야 삶의 활력이나 질이 높아지지 않을까? 전시/공연/영화 감상이라도 월 1회는 챙겨야겠다.

MBTI가 ENFJ에서 ENTJ로 바뀌었다. 물론 16분법의 통계가 한 사람의 모든 걸 알려주지는 못하지만, 신빙성 있는 통계라고 생각한다. 일을 하면서 좀 더 효율적으로 해결할 방법을 생각하느라 T로 변하게 된 것이 아닐까 하는 생각을 했는데, 다른 개발자 커뮤니티에서도 많은 F였던 사람들이 T로 변했다고 하더라. 근데 사실 나는 예전부터 E/I, T/F는 자주 오락가락했다. 그리고 그 두 가지보다는 N에서 S로 바뀌었으면 하는 바램이 있다.
김연아 선수의 옛 인터뷰 중 '무슨 생각을 해.. 그냥 하는 거지'라는 말처럼 무언가를 할 때 생각이 너무 많으면 내 목표가 흔들리거나 의지가 꺾이는 등의 사고(accident)가 발생하는 것 같다. 생각이 많아서 이직/공부에 더 깊이 들어가지 못하고, 인간관계에 있어서 너무 조심해지는 것 같다. 이 글은 그 생각들의 타래를 끊기 위해 결론을 짓는 행동이기도 하다.

뭔가 얘기할 주제가 1가지 더 있었던 것 같은데 지금 생각이 안 난다.

 

 
728x90
반응형

'커리어 디버깅' 카테고리의 다른 글

2023년 회고  (0) 2023.12.30
[면접 회고] 20230530 COY 면접 회고  (0) 2023.05.30
[면접 회고] 20230420 EI사 1차  (0) 2023.04.20
[면접 회고] W사  (0) 2023.02.27
[면접 회고] C사  (0) 2023.02.27
  • 4/29일 지원(30일 마감), 5/17 서류 합격 통보, 5/30 1차 면접 진행.
  • google meets 비대면 면접.
  • 호전적인 인상의 면접관님.

지원 ㄱㅅ
면접 전 설명

  • 30~50분 소요
  • 질문의 답이 길어지거나 주제에서 벗어난다면 끊을 것으로 양해
  • 개인적인 질문이 있을 경우 편하게 끊어도 된다

간단한 자기소개

"읽기 좋은 코드가 좋은 코드다"라는 개발 철학에 빠져 문제 해결에 있어 유지보수성 향상과 클린 코드에 가치관을 둔 4년차 개발자입니다.
Java, Spring 환경의 BE 운영/고도화/신규개발을 수행했고, 그 과정에서 만난 코드는 대체로 절차지향적이고 하드코드가 많으며, 중복이 많은 스파게티 코드였습니다. 저는 과업을 수행하는 과정에서 이러한 코드들의 구조를 개선시켰고, 유지보수성을 향상시켰습니다.
또한, 절차지향적인 코드를 작성하는 팀원들을 객체지향적 프로그래밍을 하도록 이끌어낸 경험도 있습니다.
JD 상에 기술 부채 해결과 레거시 코드 개선 및 신규 아키텍쳐에 적용이라는 키워드가 있었는데, 제가 잘 할수 있는 일과 도전해보고 싶은 일이라고 생각해 지원하게 되었습니다.

자사몰이나 앱 사용 해 봤느냐

ㅇㅇ 레벨 3다.
이거 저거 샀다. (구체적으로 명시했음, 글에 작성하면 어딘지 쉽게 알 수 있어서 자체 필터링.)

이건 내가 고쳐볼 수 있겠다 싶은 기능?

앱에서 픽업 기능을 사용하면 종종 튕기는 현상이 있었다. 기회가 주어진다면 개선해 보고싶었다.
그리고 PC 사용을 더 많이 하는 편인데, 개발자 창을 열어보면 불필요한 로그나 콘솔 에러가 좀 있고, 주석상에 어뷰징이 가능할 것 같은 내용이 있었다.
이런 점들을 개선 시켜 보고 싶었다.

스프링 부트 사용?

업무적 사용은 안했고, 공부할 때 써봤다.

그냥 스프링과의 차이는 어떤게 있다고 느꼈는가?

xml 설정은 읽기 편하지 않은 책을 읽는 느낌이고, 옵션을 넣을 때 <>안에 넣어야하는 값과 하위에 넣어야 하는 갑의 구분이 쉽지 않다.
톰캣이 내장되어 있기 때문에 개발 환경과 실행환경의 차이를 줄일 수 있는 게 장점이였던 것 같다.

DI에 대해 설명해 달라

Dependency Injection 의존성 주입. 각각의 클래스 의존 관계를 IoC 컨테이너가 자동으로 주입하는 것.
의존 관계 주입을 개발자가 관리 하지 않기 때문에 비즈니스 로직에 집중할 수 있는 장점이 있다.
의존성 주입은 Service, Repository, Autowired, Component 어노테이션을 사용할 수 있다.

의존성 주입을 할 때 Bean을 만드는데, bean에 대해 설명하라

어....(버벅버벅)...
IoC 컨테이너에게 관리를 위임하는 객체를 Bean이라고 볼수 있다.
IoC 컨테이너는 이 빈의 객체 생성부터 의존성 주입, 초기화, 소멸 등 라이프 싸이클을 관리한다.
(틀린 듯)

Bean의 디자인 패턴은 무엇인가?, 스프링은 보통 이 디자인 패턴으로 되었다고 한다.

bean 객체는 싱글톤으로 객체가 생성이 되고, bean 생성시 factory pattern도 사용한다고 알고 있다.
(틀린 듯)

AOP와 함께 따라다니는 3총사 Filter Interceptor AOP의 실행 순서를 말해보라

request -> filter.doFilter -> dispatcher -> interceptor.preHandle -> controller -> aop -> service -> aop.around -> controller -> interceptor.postHandle -> dispatcher -> filter.doFilter -> response

그 셋의 차이?

셋다 어플리케이션에서 자주 사용되는 로직을 분리하여 처리하는 기능을 제공.
filter는 보통 xss 보안을 위해 사용한다.
interceptor는 로그인, 권한, 로깅, 세션 처리등을 전담한다. aop의 기능을 흉내낸다고 볼 수 있다.
aop는 핵심 로직 사이에 끼어있는 횡단의 관심사, 공통의 로직을 분리해서 모듈화 한것으로....
(말 잇지 못함)

XSS는 무엇인가?

크로스 사이트 스크립트 공격으로, 게시물에 sript 태그를 넣어 다른 사용자에게 공격을 하는 것이고. 이런 script 태그를 막기 위해 xss 방어를 한다.

어떻게?

보통은 <>lt, gt로 치환을 많이 한다.
(원하는 대답은 이게 아닌 것 같은데, 아는게 이것...)

SI 할때 게시판에 특수 문자를 넣었을 때 깨진다 라는 인입을 받으면 어떻게 대처했는가?

예전 기억이라 흐릿한데, filter를 테스트 해서 수정한 기억이 있고. doFilter의 치환을 직접 작성하기도 하지만 naver lucy로 적용한 적도 있다.
(이것도 옳은 대답이 아닌 듯)

Transaction 요소 4가지 설명해 달라

아..(버벅)
독립성과 원자성 등등이 있었던 걸로 기억 나는데 잘 기억이 안난다.
(면접관님 호탕하게 웃음)

RESTfull API가 어떤건지 설명해봐라

Representation state transfer의 약자로 http 프로토콜을 그대로 이용하며 웹의 장정을 이용하고, URI를 통해 대상 객체를 지정, get, post, put, delete의 http method 이용해서 해당 자원의 처리를 하는 방법을 의미한다.

그럼 API 설계를 했을 텐데, RESTfull API 설계 원칙 몇가지를 대봐라

  • /는 계층관계를 나타낸다.
  • uri의 가독성을 위해 _는 지양하고 -를 지향해야 한다.
  • uri는 소문자를 권장한다.
  • 리소스 간의 연관관계가 있다면 /{메인 리소스}/{리소스 id}/{연관 리소스}로 표현한다.

http 응답 코드와 의미를 아는대로 불어라

  • 200
  • 302, 303, 304
  • 401, 404, 415, 405
  • 500

http method 불어라

  • get, post, put, delete
  • trace, option이라는 것도 있는 것으로 알고 있다.

사용 목적은?

  • get select
  • post insert/update
  • put update
  • delete delete

공공기관에서는 put, delete 사용하지 말라고 들었을 텐데 왜그런지 아느냐?

(예전 타사 면접에서 이 얘기 했다가 그게 말이 되냐는 소릴 들었던 경험이 있어서 오히려 반가웠음.)
정확한 기억은 아니지만, web server에 따라 put, delete를 was로 요청이 가는게 아닌 web server가 구종되는 OS 자원을 실제로 삭제하거나 데이터를 넣는 기능이 있다.

해당 내용에 대해서 apache, nginx에서 put, delete를 막는 방법을 아느냐?

흐릿한 기억으로는 설정파일에 allow, not allow로 요청자의 ip나 경로에 따라 해당 메소드를 허용/비허용하는 설정을 했었다.
(왜 이런 것 까지 해봤니?)

MyBatis에서 #과 $의 차이점이 무엇인가?

일반적으로는 #을 사용,
#은 string일 경우 ''를 붙여주고, number type인 경우에는 ''가 없이 쿼리를 만들어 준다.
$를 사용할 경우에는 type 상관 없이 주어진 객체를 '' 없는 스트링으로 넣어주는 것으로 알고 있다.
(정확한 차이를 대답한 것이 아니라 생각됨.)

보안팀에서 $를 사용하면 사용하지 말라고 하지 않던가?

재직하던 곳에서는 조직이 그렇게 나뉘어 져 있지 않아서 그런 일은 없었다.
다만 $를 사용하면 SQL Injection 문제가 있기 때문에 #을 사용해야 하는 것으로 알고있다.

DB는 어떤 것 사용해봤는가?

Oracle 주로 사용, mysql, PostgreSQL, Cubrid, Tibero

index 개선했다고 했는데, index가 어떤 원리기 때문에 쿼리를 개선해주는가?

DB가 데이터를 저장할 때 B+tree로 데이터를 저장하는데, tree와 LinkedList에서 index를 가지고 있는데...
(많이 딜레이 걸림, 대답을 안한 것과 같네)

oracle hint에 대해서 얘기 해봐라

optimizer가 hint를 참조해서 어떤 테이블을 드라이빙 테이블로 사용할지, 어떤 index를 사용할지에 대해서 지정할 수 있다.

index가 많으면 성능향상?

그건 아니져!!
index 자체로도 리소스이기 때문에 적절한 인덱스 설정이 필요하다고 알고 있다.

힘들었던 프로젝트를 꼽으면?

최근에 3자물류 연계, 오래전으로 돌아보면 첫회사에서 같은 팀의 다른 직원들 업무까지 관여를 많이 해야했던 순간이 힘들었다.

어떻게 문제를 해결했나? 자기 일도 아닌 것도 책임 져야 했을 텐데,

스트레스 받는 일이기도 하지만, 신입 직원 같은 경우에는 시간을 투자해서 진행상황 체크와 조언을 했고, 비슷한 연차의 직원 업무같은 경우에는 자율적으로 두고 주간회의를 통해 관리를 했다.

지금도 메니징을 하는 것인가?

아니다, 첫회사고 딱 한 프로젝트만 그런 역할을 했었다.

그럼 후임자를 독려하면서 일을 진행하다 보면 딜레이가 생길수도 있고, 상사와의 갈등이 생길 수도 있는데 어떻게 해결 했는가?

이 경험이 제가 2년 전 한번 겪은 경험이라 경험이 풍부하지 않고 기억이 흐릿하기도 한데, 그때 당시에는 최대한 팀원들을 독려하고, 간식거리를 사준다던지 조언을 좀 더 하는 방향으로 진행했다.
상사에게는 주기적 보고와 어떤 방법으로 해결하겠다와 같은 제시도 하고 했었고 책임지고 혼나는 일을 담당했다.
(면접관님 웃음)

최근에 관심있는 기술 트렌드가 있느냐? 우리가 신기술을 많이 사용해서 트렌드에 민감한 편이다. 그리고 그런 정보는 대게 어디서 얻느냐.

트렌디한 기술을 실제로 사용하진 못했고 블로그나 같이 공부하는 그룹에 동료들에게 정보를 얻는 편.
최신 기술은 아니지만 ELK나 상품 전시 도메인의 꽃은 검색이기 때문에 ES를 사용해보고싶다.
(코틀린을 대답할껄..)

스트레스 관리는 어떻게 하느냐?

잠을 좀 많이 자는 편이고, 영화 보는 것이 취미라 퇴근하고 혼자 영화를 본다던지, 주말에 친구들 만나서 보드게임을 하는 등으로 스트레스 해소를 하고있다.

  • 복지중에 영화 할인있는데 좋겠네

궁금한 것?

  • 합격하게 된다면 어떤 기술을 미리 학습 해 가는게 도움이 될것 같으냐?
    • 현재 코틀린으로 마이그 중이기 때문에 코틀린과 스프링 부트가 좋다.
  • 그럼 이전에 해결했던 이슈나 앞으로 해결해가야 하는 과업은 무엇이 있는가?
    • 너무 깊은 대답은 어렵고, 코틀린 전환 과정중에 아까 얘기 했던 UI/UX 개선이 있다.
    • (전시파트의 꽃은 검색엔진 아냐? ㅠ)

마지막 할말?

면접을 준비하면서 제 자신에 대해서 알게 됬고, 해당 회사가 어떤 회산지도 알게 되서 좋은 시간이였다. 감사하다.

728x90
반응형

'커리어 디버깅' 카테고리의 다른 글

2023년 회고  (0) 2023.12.30
[회고] 2023년 상반기  (0) 2023.07.02
[면접 회고] 20230420 EI사 1차  (0) 2023.04.20
[면접 회고] W사  (0) 2023.02.27
[면접 회고] C사  (0) 2023.02.27

+ Recent posts