아이젠하워 매트릭스

  • 업무의 우선순위를 먼저 해야 할 일, 계획해야 할 일, 위임할 일, 하지 않아도 될 일 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
반응형

건강관리

솔직히 자신 있게 운동을 많이 했다고는 할 수 없다.
날이 좋을 때는 일주일에 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

대기업 계열사 ecommerce 전문 부문 상품/전시 파트 1차 면접, 비대면 화상면접으로 진행 됨.

자기소개

경력기술서 4줄 요약 + 강점으로 소개

이직이 잦았는데 각 회사별 이직 사유를 말해달라

  1. 공간정보 기반 공공기관 SI 사업을 했는데, 매출의 2/3에 해당하는 프로젝트 수주가 실패하고, 회사가 기운이 약해지는 것을 느끼고 이직했다.
  2. 공공기관 si 에이젼시였는데, 기술 성장에 큰 도움이 없는 것이 느껴져서 이직을 결심했다.
  3. 입사 당시 예정된 프로젝트가 있었는데 엎어졌다. 시니어급이 줄 퇴사했고, 그 후로 기존 프로젝트의 개선에 힘썼지만, 시니어급의 부재가 좀 컸다. 그래서 이직을 결심했다.

di ioc에 대해서 설명해보라

DI는 의존성 주입으로, 객체를 직접 생성하는 게 아니라 외부에서 생성한 후 주입하는 방식이다. 결합도가 낮아지고 유연성이 높아진다.

(대답 못 하고 한참 버벅임) IoC는 긴장해서 기억이 안 난다.
(면접 망했음을 느낌)

이력서에 jvm 튜닝이 있던데, 어떻게 했나?

하남시청에서 운영하는 운동장 예약 시스템에서 예약 오픈일마다 서버가 뻗었다. 로그를 확인하니 JVM 문제인 것으로 확인되어 튜닝했고, 서버 메모리가 32기가나 되는데, jvm에서 1기가밖에 사용하지 않길래 4기가까지 확장했다.
heap 영역과 stack 영역, 새로운 객체 영역, 오래된 객체 영역에 대한 값을 테스트 해가면서 튜닝했다.

  • 그럼, 메모리를 많이 주게 되는데 GC가 오래 걸리거나 GC 하면서 뻗지 않는가?

깊은 GC 얕은 GC 설정이 있었던 걸로 기억나는데 정확하게 기억이 안 난다.
(2차로 망했음을 느낌)

Redis 어떻게 사용했는가?

WAS를 2대를 수기 배포를 하는 시스템이었고, 배포할 때 번갈아 가면서 배포하면 한쪽에서 세션이 끊기는 문제가 있었다.
WAS를 spring 설정에서 session clustering을 Redis에 연결해서 해결했다.

jsp는 잘 다루는가?

jsp는 스프링이랑 같이 사용했기 때문에 못 다룰 수가 없다고 생각하다.
(설마 model 1에 절차지향적인가?)

template engine에 대해서 아는가? FE는 좀 잘 다루는지?

이전에 근무한 회사에서 FreeMarker를 사용했고, JS template인 handlebar.js나 jquery template를 사용했다. 첫 회사에서 지도를 SPA로 개발했기 때문에 많이 다뤄봤다.

\pagebreak

infra, be, fe 어느 분야를 더 선호 하는가?

일단 spring be가 더 자신 있다.
그렇지만, 첫 회사에서 JS 많이 다뤄서 FE에도 관심이 있고. 인프라도 흥미가 있다.
어쨌든 spring BE를 더 선호한다.

이력서에 있는 대용량 데이터 처리 고도화에 대해 설명해달라

하루에 배송 추적하는 송장이 2,700건 정도 됐던 걸로 기억하는데, 2,700 건을 리스트에 담아서 한 건씩 건건히 API 조회를 하는 방식이었다.
정보를 제공해 주는 API를 개선할 수 없으니 우리 쪽 프로세스를 개선했다.
대상을 100건씩 쪼개서 spring async annotation으로 비동기 처리를 했다. 그리고 DB insert/update 할 때도 시간 소모가 많기 때문에, 한 트랜잭션에서 100건 쿼리 수행하고 트랜잭션을 닫는 처리를 했다.
MyBatis execute batch 옵션을 사용했는데, 해당 옵션을 사용하면 select 쿼리 결과를 재사용하는 특성이 있어서 select와 insert/update 하는 로직도 분리했다.

  • 혼자 처리한 업무인가?

그렇다.

현재 팀 구성이 어떻게 되는가?, 업무 중 협업은 어떻게 하는가?

총 4명으로 차장급 세 명과 일한다.
업무 이슈를 각자 나눠서 처리하는 중이라 협업할 기회가 없다.
그래도 물어보면 잘 대답해 주신다. 그치만 보통은 구글을 많이 참고하고, 최근에는 chatGPT도 활용한다.
개발 협업은 적은데, 마케팅이나 운영 MD, 기획팀과의 협업은 많이 하는 편이다. 주도적으로 커뮤니케이션을 해서 그들의 매출을 증가시키는 데 도움을 주고 있다.

조회쿼리 성능 개선 어떻게 할 것인가?

최근에 진행 중인 이슈인데, 지금 근무 중인 회사를 기준으로 얘기하자면 oracle DB를 사용 중이다. CPU 사용률이 높아서 Metarial view를 사용해서 조회 성능을 개선하는 중이다.

  • 운영자가 실시간 조회 성능 개선을 요구한다면 어떻게 할 것인가?

(한참 고민함)
현재 재직 중인 회사 쿼리를 기준으로 얘기를 하면, select 절에 있는 함수를 paging 처리 후로 다 빼고, inline sub query나 scalar sub query를 join으로 변경하는 방식으로 진행한다.

(원하는 답이 아닌 것도 알고, 정석적인 방법도 알지만 긴장해서 제대로 답 못함. 3차로 망했다)

\pagebreak

질문 할 것 있는가?

  • 사내 개발정보 공유하는 곳이 있다고 들었는데 얼마나 활성화?
    • 최근에 오픈을 했고, 팀별로 기술 자랑하는 분위기.
      우리는 신생팀이라 아직 발표는 안 했는데, 팀마다 월별로 발표도 한다.
  • git 사용한다고 들었는데, github, gitlab 어떤 것을 사용?
    • gitlab ent. 사용 중.
  • 들어갈 팀에 개발자가 몇 명이나 있고, 연령대 분포는 어떻게 되는지?
    • 개발자가 몇 명인지는 대답 못 듣고, 내가 중간쯤 된다고만 기억 남.
    • 아마 직원이 많아서 몇명이나 되는지 모르거나, 사람이 없어서 숨길 수도 있다고 생각됨.
  • 이전에 해결한 이슈나 앞으로 해결해 나가야 하는 이슈에 대해 알고싶다.
    • 상품, 전시는 검색이 꽃인데, 그쪽 관련해서 당장은 서베이 중이다. 곧 관련 이슈를 진행 할 예정이다.
      (조회 쿼리 대답 못한게 정말 ㅈ됨을 느낌)
  • 기술적인 의사 결정이 필요할 때 결정을 내리는 주체가 개인인지, 팀원 전체인지 알고 싶다.
    • 난감해함 (뭔가 잘못된 질문인가 싶음)
    • 당연히 혼자 결정하진 않는다. 탑다운도 아니고 바텀업도 아니다. 회의를 통해서 결정한다.

https://youtube.com/shorts/8WJOxkySoVc?feature=share

 
 
 
728x90
반응형

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

[회고] 2023년 상반기  (0) 2023.07.02
[면접 회고] 20230530 COY 면접 회고  (0) 2023.05.30
[면접 회고] W사  (0) 2023.02.27
[면접 회고] C사  (0) 2023.02.27
2022년 회고 및 2023년 목표 설정  (0) 2023.01.03
 

Head First Design Patterns는 객체지향 프로그래밍과 디자인 패턴에 대한 입문서다. 이 책 또한 다른 전공 서적과 다르게 쉽게 읽히는 책이다. 그림과 예제 코드를 통해 설명되며, 이러한 방식으로 개념을 쉽게 이해할 수 있었다.  
  
"변하지 않는 사실은 계속 변화한다"라는 문장을 책에서 강조하는데, 현업에서 개발하다 보면 기획내용이나 사용자의 요구사항은 계속 변한다. 어제까지는 분명 A를 얘기했는데, 오늘 저녁에 갑자기 B나 C 또는 H로 요구사항이 바뀔 수 있다. 열심히 다 만들었더라도 요구사항이 추가되거나 변하면 새로운 것을 다시 만들어야 하는 상황이 흔한 것이다. 사실 요구사항의 변화는 SW의 본질이라고 할 수 있다. 그렇기에 변경에 용이한 아키텍쳐를 설계하고 개발하는 것이 개발자의 중요 역량이라고 생각한다. 그게 안 되면 IT로 밥 벌어먹으면 안 된다는 생각. 어쨌거나, 변경에 용이한 코드를 작성하기 위해서는 여러 가지 디자인 패턴이 있고, 예제를 패턴을 적용해 개선해 나가는 예시로 설명해준다.

책에서는 디자인 패턴의 개념과 각 패턴이 어떤 상황에서 사용되는지에 대해 설명한다. 디자인 패턴은 각각 객체 생성, 객체 구조, 인터페이스, 행위 등의 다양한 측면에서 소프트웨어 디자인을 개선하기 위한 것이다. 또한, 이 책은 디자인 패턴을 적용하는 과정에서 발생하는 문제와 해결 방법에 대해 다루며, 이를 통해 디자인 패턴을 적용하는 방법을 익힐 수 있도록 돕는다. 디자인 패턴은 사실 무궁무진하게 많다, java, c, javascript 언어에 따라서도 다른 패턴이 나온다. 이 책에서는 java 계열 실무에서 자주 사용하는 디자인 패턴을 집중해서 다뤄주고 있다. 책은 650여 페이지로 굉장히 두꺼운데, 그림이 대다수를 차지하고 있고, 독자의 가독성을 고려하여 쓴 책이라 쉽게 읽힌다. (글을 잘 쓰는 사람이 개발도 잘한다는 말을 반증하는 것 같다.)

나는 객체 지향을 조금 더 잘 활용해보고 싶은 개발자로 추상화, 캡슐화, 다형성, 상속을 어떻게 하면 더 잘 적용할 수 있을지를 이 책을 통해 심도있게 고민해보았다. 흔히들 코드 재사용을 막기 위해 상속을 사용하는데, 생각지 못한 상황에 반복된 코드를 짤 수밖에 없었던 적이 많다. 그런 상황에 대한 해법들도 이 책을 통해 얻었다.
Head First Design Patterns는 객체지향 프로그래밍과 디자인 패턴에 대한 이해를 쉽게 접근할 수 있도록 돕는다. 이 책으로 습득한 디자인 패턴을 사용하면 더 나은 소프트웨어 디자인을 구현할 수 있을 것으로 기대되고, 이는 개발자로서의 역량 향상에 큰 도움이 될 것 같다.

728x90
반응형
  • "나쁜 코드는 깨진 유리창처럼 계속 나쁜 코드가 만들어지도록 한다."
  • "나쁜 코드는 기술 부채를 만들어 수정을 더 어렵게 하며 결국 조직의 생산성을 저하시킨다."

이 책을 추천 받은 것은 개발 쪽으로 전향한 지 얼마 안되서였던 것 같다. 인터넷에서 추천받았었는지, 아니면 국비지원 학원이 끝나갈 무렵이었는지 정확히는 기억나지 않는다. 그리고 최근에 내가 잘 따르던 선배의 강력한 추천이 한번 더 있었다.
어쨌든 토비의 스프링과 함께 한 번은 봐야지 하던 책이었고, 이번에 드디어 완독을 했다. 아니 1독을 했다고 표현해야겠다.

읽코 좋코가 이 책 보다 조금 더 쉽게 읽힌달까. 나중에 후배들을 맞이하고, 혹은 팀을 이끌어갈 때쯤 2독 3독을 해야 할 책이라고 생각된다. 충분히 많은 도움이 된 좋은 책이지만, 내 경험이 짧아 이해하기 어려운 부분도 많고 확실히 내 수준보다는 더 높았다. 아마도 TDD 라던지, 객체지향 패러다임을 잘 따르는 코드를 본 적이 없어서일까?
아무튼 프로세스를 만들 때 가져야 할 마음 가짐에 대해서 많이 생각하게 되었다. 의미를 가진 코드, 코드의 문맥, 추상화 수준과 왜 그렇게 해야 하는지의 이유도 잘 설명되었다. 코드가 마치 잘 쓰여진 소설처럼 읽힐 수 있도록 작성한다는 마음가짐으로 코딩을 하게 되었다. 단순하게 동작이 목적이 아닌 쉽게 읽힐 수 있도록 고민을 하다 보니 더 직관적이고 객체지향 구조로 코드를 짤 수 있었던 것 같다.

선배가 이 책을 추천할 때, 레거시 코드에 대해 정말 화를 내고 열변을 토했던 것으로 기억한다. 그리고 이 책을 읽으면서 그가 이 책을 추천하면서 왜 그렇게 화를 냈는지 납득했다. 저자는 나쁜 코드가 나쁜 이유에 대해서 여러 예를 들고 그중 기억에 남는 것은 위의 두 문장이다.

나 역시도 나쁜 코드를 혐오한다. 레거시 코드를 유지보수하면서 소스코드의 히스토리를 보면 왜 이런 코드가 생겼는지 납득할 수 있지만, 그렇다면 처음부터 더 좋은 구조로 작성될 순 없었는가 하는 의문이 들곤 한다. 솔직하게 말해서 나쁜 코드를 보면 화도 나고 작성자를 기둥에 묶어두고 싶다는 생각도 든다.
나를 포함한 많은 개발자들이 이 책을 읽고 객체지향 패러다임과 클린코드 원칙들을 따르는, 개발을 잘하는, 후배들에게 좋은 코드를 남기는 시니어가 될 수 있도록 갈고닦기를... 🙏🏻

 
728x90
반응형

읽코좋코

모든 전공 서적들이 빠르게 읽히지 않는데, 다른 전공서적에 비해 쉽게 읽히는 책이며 많은 공감을 하게 되었다. 제목과 내용은 동일하며 주제를 반복 강조하고 있다. 이를 위해 변수명, 함수명, 코드 컨벤션 그리고 리팩토링까지 설명하고 있다.
코드는 이해하기 쉬워야 한다, 다시 말해 코드를 읽는데 드는 비용을 줄여야 한다는 말이다. 코드 파악하는데 드는 비용이 작다는 말은 설계가 명확하고 간결하다는 의미를 내포한다.

이 책을 읽고 실제 코드로 적용할 생각을 하면 머리가 아프지만 읽는 중간 중간 이전에 보았던 코드들이 떠올랐다. 이전에 작성 했던 '성능과 가독성을 높이는 분기처리 방법'을 쓸 때 보다 시야가 더 넓어졌다. "왜?"에 대한 부분이 조금 모호했었는데, 그 부분을 채워주는 내용이였다. 그리고 내가 봐온 레거시 프로젝트들의 코드를 작성했던 개발자들에게 이 책을 던져주고 싶었다.


  1. 코드는 이해하기 쉬워야 한다
    인상 깊었던 내용은 6개월 뒤의 나 자신 또한 쉽게 이해되도록 코드를 작성하라는 내용이였다. 나 역시도 나름의 설명과 주석을 잘 붙여서 만들었다고 생각했지만 1년 뒤 해당 코드를 개선 하면서 다시 분석해 보는 헛수고를 했던 경험이 있었다. 짧은 코드가 더 좋은 코드가 아닌 읽는 순간 바로 이해되는 코드가 좋은 코드라는 뜻이다.
  2. 이름에 정보 담기
    • 구체적인 단어 사용하기
    • 이름 길이(짧은 범위에 잠깐 쓰이면 짧은 변수명, 사용 범위가 넓다면 긴 변수명, 약어 사용 지양하기 등)
    • 포맷팅으로 의미 전달하기(상수는 대문자, 클래스명은 카멜케이스 등)가 있었다.
  3. 오해할 수 없는 이름들
    • 경계를 포함하는 범위 : first, last
    • 경계를 포함/배제하는 범위 : begin, end 사용
    • 불린 : is, has, can, should 사용
    • get 남발하지 않기
    • 여러 개의 이름을 후보로 놓고 고민하기
    • '다른 사람들이 다른 의미로 해석할 여지가 있는가?'가 핵심이였다. 한 번쯤 더 생각해 보면 더 좋은 변수명을 만들 수 있다.
  4. 미학
    • 문서 작업을 하더라도 한눈에 보기 쉽게 쓰인 글이 잘 읽히듯 코드도 마찬가지다.
    • 좌우로 길게 늘어진 코드는 줄 바꿈을 하고 다른 코드들도 똑같이 맞추기
    • 헬퍼 메소드를 이용하여 지저분한 코드 깔끔하게 하기
    • 코드의 위아래 열을 맞추어 읽기 쉽게 하기
    • 코드의 순서를 '가장 중요한 것'에서 '가장 덜 중요한 것' 까지 순서대로 나열하기
    • 코드를 문단으로 만들기 (핸들러, DB 사용 등 문맥이 바뀌면 한 행을 띄우는 등 글을 쓸때 문단을 나누는 것과 동일)
    • 개인의 코드 스타일 VS 전체 코드의 일관성 = 일관성이 올바른 스타일보다 더 중요
  5. 주석에 담아야 하는 대상
    • 불필요한 설명 배제
    • 나쁜 이름에 대한 변명이 아니라 좋은 이름으로 바꿀 것
    • 작업중 생각한 통찰 등을 주석에 기록
      • ex: 하위클래스로 정리해야 할 것 같다
    • 상수의 의미를 설명할 것
    • 다른 개발자가 실수할 수 있는 부분을 예상해서 주석을 달라
      • ex : 1분 후 타임아웃 된다
    • 2, 3중 반복/조건문이 달린 함수는 무엇을 위한 것인지 요약 주석을 단다
    • 주석을 다는 것에 대한 두려움을 버려라
  6. 명확하고 간결한 주석 달기
    • 간단한 입출력 예시 사용
    • 코드의 수행 동작이 아니라 코드의 의도를 적어라
    • 파라미터에도 주석을 넣어라
    • 축약된 단어를 사용하라
      • ex : ~에서 불필요한 빈칸을 제거한다 -> 공백 제거
  7. 읽기 쉽게 흐름 제어 만들기
    • 조건문에서 유동적인 값은 왼쪽, 상대적으로 고정적인 값은 오른쪽에 쓰라
    • if/else 간단한 것을 먼저 처리하라
    • 삼항 연산자의 사용은 간단하게 쓸 상황이 아니라면 피하라
    • 중첩을 피하기 위해 함수를 중간에서 반환하라
    • 2중 if 문은 나누어서 중간에 반환하라
  8. 거대한 표현 잘게 쪼개기
    • 요약 변수 사용, 조건식의 반복되는 중요 비교 값을 상수로 만들기
    • 드모르간의 법칙 사용
    • short circuit 사용을 오용하지 말 것
      • 영리하게 작성된 코드가 혼란을 초래한다
    • 복잡한 논리를 간단하게 표현하기
    • 거대한 구문은 문맥에 따라 나누기
  9. 변수와 가독성
    • 불필요한 임시 변수, 중간 결과 저장 변수, 흐름 변수(boolean) 제거하기
    • 변수의 범위 좁히기
    • 클래스를 작은 단위로 나누기
    • 전역변수 사용 피하기
    • 변수에 다른 값을 여러번 할당하는 것 피하기
  10. 상관 없는 하위 문제 추출하기
    • 비즈니스 로직과 관계 없는 문자열 빈칸 제거, url 형식, 주소 형식등을 다루는 메소드는 분리하기
    • 재사용성을 위해 일반적인 목적을 가진 코드를 많이 만들기
    • 과유불급, 지나치게 나누지는 말기
  11. 한 번에 하나씩
    • 작성된 코드가 읽기 어렵다면, 수행하는 작업을 나열하라
    • 나열된 작업중 분리될 수 있다면 별도의 함수 또는 클래스로 나눠라
    • 파편화를 최소화 할 수 있다.
  12. 생각을 코드로 만들기
    • 논리를 명확하게 설명하기
    • 해결책을 말로 묘사하기
    • 언어에서 제공하는 라이브러리를 많이 사용해 보기
  13. 코드 분량 줄이기
    • 필요가 없는 기능을 구현하려고 애쓰지 말것
    • 코드 베이스를 작게 유지할 것
    • 요구사항에 질문을 던져 요구사항을 잘게 나누어 분석하기.
    • 표준라이브러리와 친해지기
  14. 테스트와 가독성
    • 테스트 코드는 특히 더 읽기 쉬워야 한다
    • 긴 테스트 내용은 다른 메소드로 만들기
    • 읽기 편한 에러 메세지 출력 폼 만들기
    • 좋은 테스트 입력 값 선택하기
    • 지금 작성하는 코드의 테스트 코드를 나중에 작성한다는 사실을 염두해 둘것
    • 지나친 테스트는 지양
  15. 분/시간 카운터 설계 및 구현
    • 실습 예제
 
728x90
반응형

토비의 스프링 3.1 VOL.1

스프링 사용자로서 항상 읽어야봐야 한다라는 소리에 두권을 샀지만, 엄청 어렵다는 소문에 읽을 엄두를 못 내던 책이다. 한 권에 800 페이지가 넘는 굉장한 분량에 두번의 정독 시도를 헛탕쳤었다. [유튜브] "개발바닥" 채널에서 저자 이일민님의 인터뷰와, 그 분이 이제는 스프링 부트 인강을 내시면서 이 책을 다시 시도하였고. 이번에는 1독을 끝냈다.
이제 4년차에 들어서면서 읽어보니 '어느 정도 개발을 했고, 좋은 구조와 효율을 고민해본 사람이 봐야 깊은 뜻을 더 잘 이해할 수 있겠구나' 라고 느꼈다.

이 책은 객체지향적 설계, 리팩토링, 테스트주도개발의 중요성에 대해 꾸준히 강조하고 있다. 단순하게 스프링 프레임워크의 기능 / 개념에 대한 설명도 깊게 나와있지만, 이 책의 요점은 스프링이 왜 이렇게 발전했고, 어떤 패러다임을 녹여서 만든건지 엿볼 수 있도록 도와주는 책이다. 따라서 개발 철학에 더 중점을 두고 읽어야 하는 책이라고 생각 된다.

마틴 파울러와 켄트 백이 강조하던 내용이 녹아 있으며, 아래와 같은 조언을 책 전반에 걸쳐 꾸준히 강조하고 있다.

  • '고정된 작업 흐름을 갖고 있으면서 여기저기서 자주 반복되는 코드가 있다면, 중복되는 코드를 분리할 방법을 생각해보는 습관을 기르자.'
  • '비슷한 기능이 새로 필요할 때마다 앞에서 만든 코드를 복사해서 사용할 것인가? 물론 아니어야 한다. 한두 번까지는 어떻게 넘어간다고 해도, 세번 이상 반복된다면 본격적으로 코드를 개선할 시점이라고 생각해야 한다.'

인상 깊었던 문장

인상 깊었던 문장들은 다음과 같다. 다 읽어보면 떠오르는 것이 있다. 그렇다, 대부분의 레거시 프로젝트의 소스들은 아래에서 하지 말라는 대로 개발되어 있다.

  계층형 아키텍쳐
  관심, 책임, 성격, 변하는 이유와 방식이 서로 다른 것들을 분리함으로써 분리된 각 요소의 응집도는 높여주고 서로 결합도를 낮춰줬을 때의 장점과 유익이 무엇인지 살펴봤다. 성격이 다른 모듈이 강하게 결합되어 한데 모여 있으면 한 가지 이유로 변경이 일어날 때 그와 상관이 없는 요소도 함께 영향을 받게 된다. 따라서 불필요한 부분까지 변경이 일어나고 그로 인해 작업은 더뎌지고 오류가 발생할 가능성이 높아진다. 어느 부분을 수정해야할지를 파악하기도 쉽지 않다.
  따라서 인터페이스와 같은 유연한 경계를 만들어 두고 분리하거나 모아주는 작업이 필요하다.
또, 흔히 저지르는 실수 중의 하나는 프레젠테이션 계층의 오브젝트를 그대로 서비스 계층으로 전달하는 것이다.
서블릿의 HttpServletRequest나 HttpServletResponse, HttpSession 같은 타입을 서비스 계층 인터페이스 메소드의 파라미터 타입으로 사용하면 안 된다.
계층의 경계를 넘어갈 때는 반드시 특정 계층에 종속되니 않는 오브젝트 형태로 변환해줘야 한다.
스프링을 사용하면 이런 데이터 중심의 코드를 만들 수 있을 뿐만 아니라, 실제로 매우 흔하게 발견된다.
데이터와 업무 트랜잭션 중심의 개발에 익숙한 사람들이 많고 이런 아키텍쳐를 의도적으로 선호하는 개발자도 많기 때문이다.
개발자들끼리 서로 간선없이 자신에게 할당된 기능을 독립적으로 만드는 데도 편하다.
최소한의 공통 모듈 정도만 제공되는 것을 사용하고, 그 외의 기능은 단위 업무 또는 웹 화면 단위로 만들어 진다.

하지만 이런 개발 방식은 변화에 매우 취약하다.
객체지향의 장점이 별로 활용되지 못하는데다 각 계층의 코드가 긴밀하게 연결되어 있기 때문이다.
중복을 제거하기도 쉽지 않다.
업무 트랜잭션에 따라 필드 하나가 달라도 거의 비슷한 DAO 메소드를 새로 만들기도 한다.
또한 로직을 DB와 SQL에 많이 담으면 담을수록 점점 확장성이 떨어진다.
DB는 확장에 한계가 있을 뿐 아니라 확장한다 하더라도 매우 큰 비용이 든다.
잘 작성된 복잡한 SQL 하나가 수백 라인의 자바 코드가 필요한 비지니스 로직을 한번에 처리할 수도 있다.
하지만 과연 바람직한 것일까?
이런 복잡한 sql을 누구나 쉽게 이해하고 필요에 따라 유연하게 변경할 수 있을까?
또, 복잡한 sql을 처리하기 위해 제한된 자원인 DB에 큰 부담을 주는 게 과연 바람직한 일인지 생각해볼 필요가 있다.
데이터 중심 아키텍쳐의 특징은 계층 사이의 결합도가 높은 편이고 응집도는 떨어진다는 접이다.
화면을 중심으로 하는 업무 트랜잭션 단위로 코드가 모이기 때문에 처음엔 개발하기 편하지만 중복이 많아지기 쉽고 장기적으로 코드를 관리하고 발전시키기 힘들다는 단점이 있다.
스프링은 그 개발철학과 목표를 분명히 이해하고 사용해야 한다.
자바의 근본인 OOP 원리에 충실하게 개발할 수 있으며,
환경이나 규약에 의존적이지 않은 POJO를 이용한 애플리케이션 개발은
엔터프라이즈 시스템 개발의 복잡함이 주는 많은 문제를 해결할 수 있다.
POJO 방식의 개발을 돕기 위해 스프링은 IoC/DI, AOP, PSA와 같은 기능 기술을 프레임워크와 컨테이너라는 방식을 통해 제공한다.
728x90
반응형

확실히 비즈니스 모델이 SW인 회사와 그렇지 않은 회사는 같은 질문도 의도나 원하는 대답이 다르 다는 것을 느꼈다. 가고 싶은 회사로 이직하기 위해 기본기 공부와 코테 준비를 하는 것도 중요하지만, 면접 경험 역시 계속 쌓는게 좋다는 것을 느꼈다.


질문 내용

  • 당사에 와서 어떤 일을 하고 싶은지
  • 이직할 때 회사를 고르는 기준이 무엇인지
  • 왜 이직 하는지
  • 그 동안 뭘 했는지
  • 졸업하고 분야를 전향하기 전에는 뭐를 했는지
  • 초등학교때부터 개발하는 애도 있는데 무슨 경쟁력이 있다고 하는지
728x90
반응형

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

[면접 회고] 20230530 COY 면접 회고  (0) 2023.05.30
[면접 회고] 20230420 EI사 1차  (0) 2023.04.20
[면접 회고] C사  (0) 2023.02.27
2022년 회고 및 2023년 목표 설정  (0) 2023.01.03
[코테 회고] 2022 10 01  (0) 2022.10.01

역대급으로 면접을 잘 보았고, 면접이나 처우 협의 경험을 기록 해둬야 할 것 같아서 남겨둔다. 계약 연봉만 따지면 조금이나마 인상이지만, 인센이나 성과금, 현금성 복지 그리고 업무 환경으로 따지면 낮아지는 이직이 되었다.

면접관님과의 대화에서 OOP 잘 쓰는 사람들과 일 하는게 쉽지 않을 것이라는 생각이 들었고, 아키텍쳐 공부 역시 꼭 해야겠다는 생각이 들었다. 그리고 잘하는 동료와 좋은 경험을 할 수 있는 환경에서 근무를 하려면 아무래도 다음 이직은 중견 이상으로 가야겠다는 결론이 났다. 면접관님이나 그분이 말씀 하시는 환경 또한 좋지만  IntelliJ 개발 환경 그리고 실 사용자의 규모에서 나오는 경험은 못 잃겠다는게 결론이였다.


면접 내용

  • 간단한 자기소개
    • 4년 차 개발 SI, SM로 2년 재직, 이후 쇼핑몰에서 이벤트/프로모션, 결제, 물류/배송 담당으로 기능개선 작업을 주로 했다.
  • 재직중인 팀 구성은 어떻게 되는지?
  • 현재 재직 중인지
  • 이직 사유
    • 이커머스 플랫폼 프로젝트 예정이었으나 엎어지고, 외주 개발로 돌리게 됨.
    • 주요 3인이 퇴사함.
    • 할 수 있는 것이 크지 않을 것으로 보여서 이직을 고려함.
    • 본가가 이사할 예정이 되어서 자취할 겸 이직할 곳을 구하게 되었다.
  • 결혼했는가?
    • ㄴㄴ
    • 근방에 여자친구가 살고, 해당 동네 근처에 친구들이 많다
  • 자취는 부모님과 합의 됐는가?
    • 그렇다
  • 그럼 결혼은 언제?
    • 3년 내?
  • 회사 내에서 다른 문제는 없었는가?
    • 지금 사용하는 기술 스택이 자바 1.7, 스프링 3.1.1, 마이바티스 초반 버젼을 사용하는데 기술적으로 성장을 원해 이직을 고려했다.
  • 지금 해당 회사에서 사용하는 기술과 비슷하다. 어떤 회사인지 알아봤느냐?
    • OOOO, OOO을 만드는 회사로 알고 지원했다.
  • 핵심 기술은 OOOO로 A, B, C, D등이 핵심 기능이다.
  • 자바는 1.8 사용. 스프링 5점, 마이바티스 10점대로 대로 버전 업 진행 중.
  • 전의 회사에서는 어떤 것을 위주로 했는가?
    • 공공기관 SI/SM, 간단한 업무 프로세스로 게시판, 체육시설/교육프로그램/공간 대실/예약시스템, 공공 API 공고, SNS 게시물 스크래핑 등
  • 두 번째 회사를 짧게 다니고 이직한 사유
    • 7개 프로젝트를 유지보수했는데, 업무가 간단하고 단조로웠다.
  • 첫 회사, SI?
    • 솔루션 기반 지리정보 시스템이지만 프로젝트마다 커스터마이징이 심해 거의 항상 새로 개발했다.
  • 스프링 부트 써봤는가?
    • ㄴㄴ
  • 스프링 부트는 쉽다, 레거시가 어렵다. MVC 썼는가?
    • ㅇㅇ
  • DB는?
    • Oracle
  • sql은 어떻게 다뤘는가?
    • ANSI JOIN으로 사용했다.
  • PL/SQL은?
    • 손댈 일이 거의 없어서 사용해보지 않았다.
  • 우리도 PL/SQL은 별로 안 쓴다, 다른 DB는 뭐 써봤나?
    • MySQL, MariaDB, Tibero, PostgreQSL
  • PostgreSQL?
    • GIS 할 때 써드파티가 많아서 사용했다.
  • MySQL을 쓴다.
  • JPA는?
    • 인강으로 공부만 해봤다
  • Stored Procedure는?
    • 안 해봤다
  • OOP는 들어봤을 텐데 추상화의 개념이 뭐냐?
    • 예제로 자주 나오는 예시인데, 자동차에 엔진이 있고 이 엔진이 작동하는 메소드를 인터페이스로 만들고 실제로 구현은 상속받아서 구현한다. A 엔진을 사용하다 B 엔진을 사용하고 싶으면 엔진 인터페이스를 상속받는 엔진 B를 만들어서 A를 B로 교체한다.
  • 그런 식의 개발을 해봤는가?
    • S3 전환을 할 때, 파일 저장하는 Util 클래스를 로컬 파일 시스템에서 S2 환경으로 전환하면서 개발 해봤다.
  • 자바 개발자들중 절차적으로 개발 하는 경우가 많고, 설계에 대한 경험이 별로 없는 사람이 많더라. 리팩토링은 좀 해봤는가?
    • 기능개선 중에 절차지향적 소스가 많았고, API 송신 후 DB에 저장하는 프로세스를 OOP로 개선한 적 있다.
    • API 송/수신, 데이터 처리, 저장하는 로직을 역할별로 클래스를 분리한 적 있다.
  • MSA는 어느 정도 아는가?
    • 회원계 서버, 상품계 서버, 결제계 서버 따로 분리해서 클라이언트 - 서버간 API 통신, 서버간 API 통신하는 구조인 것만 알고 있다.
  • 정규화 등 잘 설계된 테이블이 있다 치고, SQL을 짤 때 어떻게 짜는가? Index나 WHERE 절을 어떻게 거는지
    • 마스터 테이블의 where 절을 먼저 만들고,
    • inner join이나 left outer join, on으로 테이블을 연결
    • where 절에 join 테이블 조건 거는 방식으로 만든다.
    • 기존에 자주 사용하는 쿼리 템플릿이 있는 경우에는 그 쿼리 위에 with as 절로 대상을 먼저 만든 뒤 조회 함.
  • 트랜잭션 관리는 해본 적 있는가? commit이나 rollback 등
    • java src 상으로는 최근에 배송 송장 상태 업데이트 배치 프로그램에서 MyBatis에서 Execute Type BATCH를 사용했고,
    • 해당 옵션은 SELECT 절이 반복되면 쿼리 결과를 재사용하는 문제가 있음.
    • 그래서 메인 메소드에서 SELECT하는 메소드 따로, UPDATE하는 메소드를 따로 호출, UPDATE 메소드에서 Transactional required_new 옵션을 걸어줬다.
    • 원하는 답이 맞는지는 모르겠다.
  • 나쁘지 않은 대답이다. 형상 관리나 배포 CI/CD 는? 젠킨스 써봤는가?
    • SVN이나 GIT 사용했고, 젠킨스는 잘 아는 것은 아니고 stage, dev 환경 분리할 때 기존에 있던 설정을 복사해서 옵션 바꿔 만들어 본 경험이 있다.
  • Redis는 어떻게 사용해보았는가?
    • 이전 시스템에서는 수기 배포를 했고 한쪽 서버를 재시작하면 세션이 끊기는 문제가 있었다.
    • 세션 클러스터링용으로 레디스를 사용, 조악한 UX 문제를 해결하는 데 사용했다.
  • Jira 사용?
    • ㅇㅇ
  • AWS EC-2만 써봤냐?
    • EC-2, S3, Code Deploy, Cloud Front 써봤다.
  • FE 개발할 때 스크립트는 어떤걸 쓰는가?
    • 타입 스크립트는 사용 안 해봤고, 되도록 ES 6 이상 사용하려고 하는데, 아무래도 JAVA만 만지다 보니 부족하다.
    • async, await만 사용하는 정도
  • 가족 관계? 사랑을 많이 받았을 것 같은 느낌이다
  • 음악과 졸업?
    • 실용음악 기타로 입학, 졸업할 때는 미디/전자음악로 졸업했다.
  • 방향을 바꾼 이유는?
    • 친구랑 같이 카페에서 공부하다 호기심이 생겨서 좀 배워봤고, 친구 권유로 국비 지원 학원을 다녔다.
  • 국비를 다니고 개발자를 하기로 마음먹었느냐?
    • 40명 중에 20명은 수업을 못 따라오고, 5명 정도 반 안에서 잘하는 것으로 두곽을 냈는데 그 5명이랑 나랑 크게 차이가 없는 것으로 느껴졌다. 나쁘지 않게 하는 것 같은 생각이 들었다. 적성에도 잘 맞는 편이였다.
  • 적성이 맞는가?
    • 구체적 예시는 없지만 적성에 맞다.
  • 음악 한 것은 아깝지 않은가?
    • 딱히 그렇게 생각하지 않는다.
  • 방통대 편입해서 졸업한 것 같은데 할만했는가?
    • ㅇㅇ, 퇴근하고 공부하는 게 할만 했다.
  • 요새도 공부 하는가?
    • 주말에 모여서 각자 공부하는 스터디를 하는데, 주제를 같이 하는 건 아니고 개발자들끼리 모여서 공부하고 있다.
    • 지금은 토비의 스프링 책을 읽고, Vue.js 인강 보고 있다. 이전에는 OOP 책 읽고, 알고리즘 강의 들었다.
  • FE에 관심 있는가?
    • 없진 않다. 예전엔 react 강의도 봤었고, 재직회사에서 추후 vue를 쓸 예정이라 결제를 했다.
  • 공부 계속 해라 ㅇㅇ. 본인도 50대인데 지금도 공부하고 있다.
    • ㅇㅇ 아버님이 퇴직하기 전까지 퇴근하면 항상 공부하셔서 보고 자란 게 그거다.
  • 좋다.
  • 연봉이 굉장히 세다, 소득 증빙 가능하냐?
    • ㅇㅇ
  • 연봉이 쎈데 왜 나오냐?
    • 새로운 환경에 들어가서 자극도 받고 싶다.
  • 전 직장 연봉도 다 증빙 가능한가?
    • ㅇㅇ
  • (10초간 정적)
  • DB 설계를 할 때 논리적 다이어그램을 그리고 물리적 설계를 할 것이고 그 후 테이블간의 종속관계나 트리거등을 만드는데
    게시판 설계를 한다면 어떻게 할 것이냐?
    • {메뉴 : PK, 메뉴 명(게시판 타이틀)}
    • {게시물 : 메뉴 FK, 게시물 PK, 게시물 타이틀, 게시물 내용, 게시자, IP, 작성시간}
    • {첨부파일 : 게시물 FK, 첨부파일 PK, 원 파일명, 저장명, 저장경로, 확장자, 용량}
    • {댓글 : 게시물 FK, 댓글 PK, 게시자 명, 댓글 내용, IP, 시간}
  • IDE 뭐 써봤?
    • 지금은 IntelliJ, 이전에는 이클립스 썼다.
  • 우리는 이클립스 쓴다. 500여 개 기업에 납품하는데 고객사에서 유료 툴을 쓸 수가 없다.
  • 프로세스 다이어그램이나 시퀀스 다이어그램은 그릴 줄 아느냐?
    • 컨플루언스에서 Draw.IO 플러그인으로 그렸음. 신규 기능 개발 시 작성하는데 많이 그려보진 않았다.
  • 문서 작성은 잘하는가?
    • 많이 안 해봐서 시간이 조금 걸리는 편이다.
  • 설계할 연차는 아닌데 히스토리가 나쁘지 않은 것 같다.
  • 질문?
    • VCS, 협업툴, IDE, 기술 스펙은 이미 들었고,
    • 야근 수당이나 식대?
      • 야근은 잘 안 하지만 야근 신청서를 작성해야 한다.
    • jira를 20년 사용했다고 했는데, 몇 번째 회사인가?
      • 본인도 온 지 4개월 됬으며, 10번째쯤 되는 것 같다.
    • 조직 변화가 많은 상황인가?
      • 어디나 마찬가지로 개발자 이직이 많다 보니 엄청 뽑고 엄청 나갔다. 연구소는 안정적인 편.
    • 일하게 될 팀 구성은?
      • 웹 기반 SaaS OOO 솔루션으로 {A, B, C} 파트가 있고 파트는 아직 정해지지 않았다. 총 11명 정도 있다.
      • 아마 B나 C를 할 것 같다.
      • 클라우드 기반 MSA로 고도화 예정이다.
    • 개인장비는?
      • I7 씽크패드 노트북 1대, 모니터 1대, 연구소는 전화기가 없음.
  • 더 대화하고 싶은데 다음 면접자가 있는지 확인해 보겠다
    • (다음 면접자 대기 중이라고 함)
  • 회사 구조 설명
    • 관리/영업은 50여 명, 연구소는 20명 정도 있고, SI은 140명, SM은 20여 명
    • 수행팀은 SI, 제품팀은 운영/개발, 연구소에서는 새로운 기능 개발 중심이지만 지금은 사람이 없어서 수행팀, 제품팀 지원을 자주 한다.
    • 협업 도구는 자체 개발 한 것과 레드마인을 쓴다.
  • 개인차가 조금 있지만 기본 연봉 테이블이 있다. 면접관 마음에 드는 데 붙여줄테니 처우 협의는 알아서 해라. 또 봤으면 좋겠다.

 

728x90
반응형

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

[면접 회고] 20230420 EI사 1차  (0) 2023.04.20
[면접 회고] W사  (0) 2023.02.27
2022년 회고 및 2023년 목표 설정  (0) 2023.01.03
[코테 회고] 2022 10 01  (0) 2022.10.01
[채용 과제 회고] 2022 09 22 P사  (0) 2022.09.22

벌써 2023년이 되었다.
지난 2022년을 되돌아 작년의 목표가 얼마나 지켜졌는지 확인해보고 2023년에 대한 목표를 잡아보고자 한다.


2022년 회고

[방통대 졸업]

물론 2022년 이전 학기부터 학점이 쌓여 온 것이지만 어쨌든 3. 후반대 학점으로 졸업 했다.
졸업은 했지만, 시험을 위한 공부를 한 탓에 CS 지식이 많이 모자라다는 것을 느끼고 2023년에도 CS 공부를 부지런히 해야겠다.

[SQLD 취득]

생각보다 노력을 덜 하고 sqld를 땄다. 6주 정도 퇴근하고 3시간, 출퇴근 길에 요약 내용 복습 정도로 공부하고 붙었으니 운이 좋았던 것 같다.
사실 자격증이 있다고 실무를 잘 하는 건 아니지만, 자격증을 딴 덕분에 쿼리를 짜거나 DB 구조를 변경할 때 한 번 더 생각하게 되었다.
물론 아직은 경험치가 모자라니 더 정진해야겠다.

[JPA 학습]

인프런에서 인강을 듣긴 했지만, 완강하지 못했다. 아무래도 지금 일 하는 곳, 지금 까지 일 했던 곳은 MyBatis를 사용하다보니 JPA 공부에 절실하지 않았던 것 같다. 테크기업 이직을 생각하고 JPA를 꼭 미리 학습 하도록 해야겠다.

[알고리즘 문제풀이]

1학기 끝나고 7월부터 인강과 함께 코테공부를 했었다. 과거형이다.
10월부터 극심한 야근의 늪에 빠지면서 지금까지 게을리 해버렸다. 올해는 꼭 프로그래머스 3레벨까지는 풀어야 겠다.

[경력기술서 지속적인 업데이트]

블로그엔 올리지 않았지만 분기별로 업데이트를 잘 했다고 생각한다. 23년에도 잘 정리해서 이직 준비 해야겠다.

[다른 개발자들과의 교류]

따로 커뮤니티를 하는 것은 아니지만 동네 스터디 모임에 들어갔고, 이전 직장 동료들이나 친구들과 꾸준히 연락하면서 소식을 듣고 있다. 나랑 다른 분야의 선후배 개발자들이나 같은 분야의 다른 회사사람들을 통해 업계 소식을 조금씩 듣고 있다. 이렇게 조금이나마 간접 경험을 하고 있고, 다른 사람의 시각이나 생각을 들으면서 내 식견도 늘리려 하고 있다.


2023년 목표

목표를 너무 많이 세우지 않고 작은 목표를 집중적으로 수행하려 한다.

[Java, Spring 더 깊게 공부하기]

Spring 소스코드도 뜯어보고, 인강이나 토비의 스프링 책읽기등을 하면서 레벨업을 해야겠다고 느꼈다. 회사 과제를 수행하면서, 종종 기초지식이 부족하다는게 느껴질 때가 있었다. 회사에서 사용하는 스펙이 심각한 레거시라 생긴 문제인지, 아니면 정말 내가 뭔가를 모르고 있는 것인지는 공부 해봐야 아는 것이다.

[인강 및 프로그래밍 책 읽기]

게을리한 JPA, 알고리즘 코테 인강을 올해는 끝내고 그 이상으로 발전 해야겠다.

[이직]

회사 사정까진 모르겠고, 지금 회사에 머물 이유가 배울 수 있는 선임들 이였는데, 그 사람들이 지금 다 나갔다.
회사가 학교는 아니지만 개인의 성장에 많은 영향을 미친다고 생각하며, 그 성장에는 같이 일하는 동료들이 중요하다고 생각한다.
떠나신 그 세분을 내가 따라 갈 수 있을지는 모르겠고, 우선 적으로 회사 매출이 어떻든 개발팀의 조직이 8인 이상인 곳으로 이직하고싶다고 생각 했다.
이직의 결심은 22년에 "다른 선/후배/동료 개발자들과 생각을 교류하고/보고/배움으로써 개인이 성장할 수 있다"고 느낀게 가장 큰 것 같다.

[여행]

적어도 분기에 한번은 여행을 다녀와야겠다고 생각했다.
일 하면서 쌓인 생각이나 걱정들도 잠시 내려두고, 여행에서 마주하는 낯선 경험들이 나를 찾도록 해주는 것 같다.

[운동, 건강]

건강하지 않으면 공부도 할 수 없는 것 같다. 살로인해(?) 집중에 방해되는 것도 있고.
일단 1년 동안 10키로 빼는 게 목표로 지금 68키로다.

 
728x90
반응형

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

[면접 회고] W사  (0) 2023.02.27
[면접 회고] C사  (0) 2023.02.27
[코테 회고] 2022 10 01  (0) 2022.10.01
[채용 과제 회고] 2022 09 22 P사  (0) 2022.09.22
패션 쇼핑몰 1년 회고  (0) 2022.09.14

+ Recent posts