2021년 1분기가 벌써! 끝나고 2분기가 시작한다. 뭔가 번아웃때문에 한달반정도를 날려먹어서 그런지 이뤄놓은게 별로 없는 것 같지만, 그래도 ATDD과정을 무사히 수료해서 조금이나마 마음의 위안이 된다.
Dunning-Kruger Effect
알만한 사람들은 모두 아는 더닝 크루거 효과.
지금 내 상황과도 같다. 공부를 할수록 시야가 넓어지니 그만큼 내가 무지한부분이 보이면서 더 자신감이 사라지는 상태가 계속되고 있다. 오히려 입사초 반년정도가 제일 자신만만했던 것 같다.
나는 회사에서 차장님도 잘 모르는 JPA도 할 줄알고 이런저런 최신트렌드도 공부하고있다는 자신감에 차있었는데, 스터디를 계속하면서 1년정도가 지나니 오히려 자신감은 꾸준히 줄어들고 지금은 거의 하향치 찍은 기분.
그리고 공부한 내용들에 대해서 잊는것들도 많이 생기니 더욱더 자신감이 떨어지다가 요즘 최고점인것 같다.
여기서 더 하면 다시 확신이 생길지 어떨지는 해봐야 할 것 같다.
대학생때도 저학년때는 그랬던 것 같다. 시험직전까지 공부를 아예 안할때는 이책 이책 이렇게 공부하면 되겠다~ 하면서 걱정이 없다가, 오히려 공부를 하면 할수록 내가 X되었다는 것을 자각하며 학점 조져지는 악몽을 실현하곤 했다.
남이 아닌 나 자신과의 경쟁
이어지는 내용인데, 나는 취업을 상당히 늦게한 편이다.
대학원을 마치고 약 2년반을 게임(와우)만 잠도안자면서 하면서 시간만 죽였었는데, 여기에는 내 낮은 자존감이 크게 역할을 했다. 대학교를 지방대 컴공을 다녔는데, 어떻게하다보니 같이 어울리는 동기, 후배, 선배 모두가 다 과에서 수석, 차석을 하거나 고등학생때부터 코딩을 해왔던 친구 취미가 게임이아니라 개발인 친구까지 하나같이 개발을 정말 잘하는 친구들이였다.
1~2학년때는 사실 놀기바빴고, 군대 복학 후 3~4학년이되어 마음을 다잡고 친구 추천으로 랩실에 들어갔고, 대학원까지 가게되었는데 같이 붙어있는 모두가 너무 실력들이 좋고 공부를 쉬지 않다보니 계속 비교를 하게 되고, 이제와서 공부를 하려고해도 놀았던 업보들 때문에 학점은 암기하는식으로 혹은 친구들의 도움으로 어느정도 나왔지만, 개발실력자체는 비전공자와 크게 다를바가 없었다.
나중에는 다들 잘나가는데 나만 주저앉아있는 악몽을 자주 꾸며 불면증도왔었고 그럴수록 게임에 매달리거나 운동을하거나 다른 방향으로 회피를 했었다.
근데 지금와서 잘 생각해보면, 분명 그때의 나는 적어도 그냥 학부생 수준의 실력은 되었다. 대학원때도 조교로 실습 수업에 들어가 자바실습에서 질문사항도 대부분 답할 수 있었고, 그럭저럭 1인분 언저리는 했던 것 같다.
하지만, 이미 머릿속 기준선이 최소 내 동기들 수준은 되야한다. 라는 생각에 빠지다보니 이걸론 부족하다며 대학교를 떠나 본가로 돌아와서 어느정도 준비를 해서 취업을 하자는 생각은 2년 반동안 지속되었던 것 같다.
그러다보니 친구들과의 연락도 끊어가고, 지인들도 부끄러워서 안만나고 와이프도 한창 슬럼프때라 만나도 서로 우울하기만하고, 장학금이나 연구지원비용등으로 모아놨던 돈들도 떨어져가면서 인생 최악의 시기를 보냈던 것 같다.
지난주 수요일 NextStep의 네트워킹데이에서 개발자의 고민이나 질문들을 공유하며 같이 얘기 나누다 나왔던 이슈가 남들과 비교하며 우울해지는 이런저런 상황들에 대한 얘기였는데, 나 역시 이 부분때문에 너무 힘들었고 지금도 완전히 해결된건 아니라 공감이 많이 갔다. 그리고 거기서 나온 말 중 남과 비교하지말고 지금까지의 나 자신과 비교해야한다는건데, 공감이 가는부분이 있고 안가는 부분도 있었다.
나를 타인과 비교하면서 자존감을 깎아먹는 것은 위의 나온 내 사연처럼 인생을 늪으로 빠트리게하는 원인이 되고, 나는 분명 오늘도 공부를 하며 어제의 나보다 발전을 했다는 점을 알아야 한다. 하지만, 오늘 내가 영어단어 하나만 외워도 어제의 나보다는 발전 한 것은 맞기에, 내 발전 속도에 대한 생각은 꾸준히 고려해야한다고 생각한다.
나는 100걸음을 갈 수 있는 사람인데 이런저런 핑계로 10걸음만 내딛으며 그래도 어제보단 10걸음 발전했잖아? 라며 자기 위안하는 것은 좋지 않다. 그렇기에 뭐라 정답을 정의할 수 없고 계속 고뇌하며 나 자신만의 가치관을 성립해야 할 것 같다.
나는 그걸 이 블로그를 통해서 조금씩이나마 만들어 나가고 있다.
확신이 떨어질 때는 블로그에 내가 작성한 글을 보면서 노력한 것을 눈으로 확인하면서 다시 걸어갈 힘을 얻는다.
ATDD
이제 4주차 3번째 미션까지 모두 완료하여 정식 과정은 모두 수료했고, 이제 번외편 도전과제만남아 오늘부터 천천히 해볼 예정이다. 4단계 에서는 지금껏 듣기만하고 시도조차 해본적 없는 문서화에 대해 학습해봤는데 Spring Rest Docs를 사용해봤다. 사용방법에 대해 익숙치 않고 회사에서 이런 문서에 대해 엄격하게 요구하는편이 아닌지라 사실 쓸 일이 없었는데, 이렇게 써보고 나니 API 정의서를 만들 때 정말 편하겠다는 생각이 들었고, 다음 프로젝트부터 사용을 해봐야겠다.
다만, ATDD로 인수테스트에서 사용했었기에 문서화기능을 RestAssured에서만 사용해봤는데, 이 사용법에대해서는 따로 더 공부를 해봐야 할 것 같다.
•
RestDocs 예시
지하철 경로 미션을 테스트코드에서 문서화를 추가해 만든 페이지인데, 가독성도 높고 API의 Request/Response도 한눈에 알아 볼 수 있게 나와서 좋았다.
그밖에 이번 4주차 과정을 진행하며 얻은 인사이트를 정리하면,
1.
원시값 포장에 대한 리마인드
: TDD 과정때도 들었던 피드백 중 하나로 원시값을 포장해 일급객체로 만드는 것인데, 실무에서도 그렇고 사실 미션진행때를 제외하면 잘 안쓰다가 다시 리마인드해서 재사용을해 비용적인 부분에 대해 Cost로 원시값을 포장함으로써 요금에 대한 유효성 검증 책임을 객체에 부과함으로써, SRP 원칙을 좀 더 지킬수 있었다.
2.
DIP에 대한 실습 학습
:과금 정책에 대해서 PaymentPolicy라는 인터페이스를 필두로 거리기반(DistancePaymentPolicy), 나이 기반(AgePaymentPolicy), 지하철 노선 기반(AddedCostLinePaymentPolicy)같은 구현체들을 다형성을 적용하여 이를 구성영역을 만들어 Handler를 통해 의존관계를 주입해주며 DIP원칙도 지키고 이런 다양한 원칙들의 관계를 고려해 책임사슬 패턴을 적용해 지하철 경로 요금에 대한 요금정책을 확장성을 가진 유연한 구조로 만들 수 있었다.
@Configuration
public class PaymentPolicyConfig {
@Bean
public PaymentPolicyHandler paymentPolicyHandlerV1() {
PaymentPolicyHandler handler = new PaymentPolicyHandlerV1();
handler.link(distancePaymentPolicy())
.link(addedCostPaymentPolicy())
.link(agePaymentPolicy());
return handler;
}
@Bean
public PaymentPolicy distancePaymentPolicy() {
return new DistancePaymentPolicy();
}
@Bean
public PaymentPolicy addedCostPaymentPolicy() {
return new AddedCostPaymentPolicy();
}
@Bean
public PaymentPolicy agePaymentPolicy() {
return new AgePaymentPolicy();
}
}
Java
복사
PaymentPolicyHandler에 요금정책들을 등록시켜서 스프링 빈으로 등록한다.
3.
고립테스트(BlackBox Test)
인수테스트를 진행하면서도 사실 명확하게 인수테스트와 단위테스트에 대한 차이점의 대한 감을 잡지 못하고 그냥 서술형으로 API 요청해서 테스트한다, 메서드 단위 테스트한다 정도로만 이해하고 있다가 이번 4주차에서 좀 더 이해를 할 수 있었다. 기존의 코드에서는 요금정책 도메인 테스트에서 텍스트 픽스쳐를 준비하는 부모 테스트 객체를 만들때 각종 서비스와 레파지토리를 이용했다.
@BeforeEach
void setup() {
lineRepository = new MemoryLineRepository();
stationRepository = new MemoryStationRepository();
stationService = new StationService(stationRepository);
lineService = new LineService(lineRepository, stationService);
graphService = new GraphService(lineService);
교대역 = stationService.saveStation(new StationRequest("교대역"));
강남역 = stationService.saveStation(new StationRequest("강남역"));
양재역 = stationService.saveStation(new StationRequest("양재역"));
남부터미널역 = stationService.saveStation(new StationRequest("남부터미널역"));
이호선 = lineService.saveLine(new LineRequest("2호선", "green", 교대역.getId(), 강남역.getId(), 70, 70, 0));
신분당선 = lineService.saveLine(new LineRequest("신분당선", "green", 강남역.getId(), 양재역.getId(), 7, 5, 900));
삼호선 = lineService.saveLine(new LineRequest("3호선", "green", 교대역.getId(), 남부터미널역.getId(), 16, 17, 500));
lineService.addSection(삼호선.getId(), new SectionRequest(남부터미널역.getId(), 양재역.getId(), 43, 30));
}
Java
복사
PathTest - 경로탐색 테스트용 테스트 픽스처
하지만 위와같은 코드는 도메인 테스트는 고립테스트임에도 불구하고 각종 레파지토리와 서비스에 의존성을 가진다는 점에서 전혀고립되지 않는다는것을 알 수 있다. 그렇기에 해당 내용을 변경해 고립된 내용으로 바꿔줬다.
public class IsolatePathTest {
protected Station 교대역;
protected Station 강남역;
protected Station 양재역;
protected Station 남부터미널역;
protected Line 이호선;
protected Line 신분당선;
protected Line 삼호선;
protected PathResult 강남역_양재역_경로;
protected PathResult 양재역_교대역_경로;
protected PathResult 교대역_남부터미널역_경로;
protected PathResult 교대역_강남역_경로;
protected PathResult 남부터미널역_강남역_경로;
@BeforeEach
void setup() {
교대역 = new Station("교대역");
ReflectionTestUtils.setField(교대역, "id", 1L);
강남역 = new Station("강남역");
ReflectionTestUtils.setField(강남역, "id", 2L);
양재역 = new Station("양재역");
ReflectionTestUtils.setField(양재역, "id", 3L);
남부터미널역 = new Station("남부터미널역");
ReflectionTestUtils.setField(남부터미널역, "id", 4L);
이호선 = new Line("2호선", "green", 0L);
ReflectionTestUtils.setField(이호선, "id", 1L);
신분당선 = new Line("신분당선", "green", 900L);
ReflectionTestUtils.setField(신분당선, "id", 2L);
삼호선 = new Line("3호선", "green", 500L);
ReflectionTestUtils.setField(삼호선, "id", 3L);
이호선.addSection(교대역, 강남역, 60, 70);
신분당선.addSection(강남역,양재역,7,5);
삼호선.addSection(교대역,남부터미널역,16,17);
삼호선.addSection(남부터미널역,양재역,43,30);
강남역_양재역_경로 = new PathResult(createStations(강남역, 양재역),
createSections(new Section(신분당선, 강남역, 양재역, 7, 5)));
양재역_교대역_경로 = new PathResult(createStations(양재역, 남부터미널역, 교대역),
createSections(new Section(삼호선, 남부터미널역, 양재역, 43,40),
new Section(삼호선, 교대역, 남부터미널역, 16, 16)));
교대역_남부터미널역_경로 = new PathResult(createStations(교대역, 남부터미널역),
createSections(new Section(삼호선, 교대역, 남부터미널역, 16, 16)));
교대역_강남역_경로 = new PathResult(createStations(교대역, 강남역),
createSections(new Section(이호선, 교대역, 강남역, 60, 70)));
남부터미널역_강남역_경로 = new PathResult(createStations(남부터미널역, 양재역, 강남역),
createSections(new Section(삼호선, 남부터미널역, 양재역, 43, 30),
new Section(신분당선, 양재역, 강남역, 7, 5)));
}
private Stations createStations(Station... stations) {
return new Stations(Arrays.asList(stations));
}
private Sections createSections(Section... sections) {
return new Sections(Arrays.asList(sections));
}
}
Java
복사
IsolatePathTest - 모든 테스트 픽스처가 고립(Isolate)되어 있다.
4.
BDD 테스트 숙달
: BDD테스트를 4주차까지 진행하며 많이 익숙해질 수 있는 기회였다. 매번 학습을 하면서도 충분한 반복타이핑을 하지 않으면 금새 까먹게되는데, 이번에는 테스트를 작성하며 조금이나마 체득할 수 있었다.
아래 코드는 거리기반 요금정책에 대한 BDD테스트이다.
@DisplayName("DistancePaymentPolicy 클래스")
public class DistancePaymentPolicyTest extends IsolatePathTest {
private final PaymentPolicy paymentPolicy = new DistancePaymentPolicy();
@DisplayName("cost 메서드는")
@Nested
class Describe_cost{
@Nested
@DisplayName("경로의 총 거리가 10km 이내일 경우")
class Context_with_distance_under_10 {
@DisplayName("기본요금이 부과된다.")
@Test
void it_is_default_cost() {
//when
CostRequest costRequest = paymentPolicy.cost(CostRequest.of(강남역_양재역_경로));
//then
Cost cost = costRequest.getCost();
assertThat(cost.getCost()).isEqualTo(PaymentPolicy.DEFAULT_COST);
}
}
@Nested
@DisplayName("경로의 총 거리가 10km 초과 50km 이하일 경우")
class Context_with_distance_between_10_and_50 {
@DisplayName("5키로당 100원의 요금이 부과된다.")
@Test
void it_is_additional_cost_100_by_5km() {
//when
CostRequest costRequest = paymentPolicy.cost(CostRequest.of(교대역_남부터미널역_경로));
//then
Cost cost = costRequest.getCost();
assertThat(cost.getCost()).isEqualTo(1450);
}
}
@Nested
@DisplayName("경로의 총 거리가 50km 초과일 경우")
class Context_with_distance_exceed_50 {
@DisplayName("8키로당 100원씩 요금이 부과된다.")
@Test
void it_is_additional_cost_100_by_8km() {
//when
CostRequest costRequest = paymentPolicy.cost(CostRequest.of(양재역_교대역_경로));
//then 59km 1250 + 800 + 200
Cost cost = costRequest.getCost();
assertThat(cost.getCost()).isEqualTo(2250);
}
}
}
}
Java
복사
이런 테스트 코드는 아래와 같은 결과를 보여주는데 테스트하려는 클래스와 메서드 그리고 조건과 결과에 대해서 한눈에 알아보기 쉽게 작성되어 있어서 개발자 뿐아니라 기획자나 사용자 입장에서도 이해하기 쉽다.
5.
스프링 시큐리티에 대한 학습
: 스프링 시큐리티를 인프런을 통해 내부코드까지 어느정도 학습하고 DB를 통하거나, ajax통신을 이용한 시큐리티 세팅까지 다 실습을 했음에도 불구하고 아는것보다 모르는게 더 많은 스프링 시큐리티 였으나 이번 과정에서 강사분이 제공해준 네이티브로 구현한 스프링 특정 영역들 코드를 보모 커스터마이징하면서 나도 스프링 시큐리티에 대해 조금 더 체득할 수 있는 기회였다.
4주차에서는 비회원도 해당 API에 접근할 수 있어야하는데, 파라미터에 @AuthenticationPrincipal 어노테이션이 있어서 이를 AuthenticationPrincipalArgumentResolver부분에서 처리 해주는 코드가있는데 이를 이용해 비회원 객체(Null Object) 를 제공하는 인터페이스와 구현체를 만듬으로써 비회원용 로그인 정보를 보낼 수 있도록 했다.
스프링 핵심원리
ATDD과정으로 많은시간을 쓰지는 못했지만 꾸준히 조금씩 진행하는 인프런 강의
사놓은게 많아서 빨리빨리 봐야하는데... 이번주에 들었던 스프링 강의 내용은 크게 두 챕터 스프링 컨테이너와 스프링빈, 그리고 싱글톤 컨테이너 챕터였는데,
스프링 컨테이너와 스프링 빈
여러 테스트코드를 작성하면서 스프링 컨테이너에 스프링빈을 어떻게 등록하고 조회하는지, 그리고 조회할때 여러 케이스별로 어떻게 동작하는지에 대한 학습이다. 스프링에서 구성정보에 대해서 예전에는 XML을 통해 설정하다가 스프링부트가 나오고나서는 Java를 통해서 설정 정보들을 등록하는데 이게 어떻게 가능한 것인지에 대해서도 학습한다.
이런 내용들을 학습하면서 느끼는점은 추상화와 다형성의 범용성이 정말 넓다는 것이다. 설정정보가 JSON으로 오던 XML으로 오던 Java로 오던 해당 코드를 읽고 파싱해주는 Reader만 있고 결과물의 대한 타입만 맞춰준다면 모두 허용이 가능하다는 점은 인터페이스의 다형성의 강점이다.
싱글톤 컨테이너
이전시간에 학습했던 내용들중 스프링 빈을 등록하는 부분이 있었다.
좀 생각을 해본다면 여기서 이 빈들을 등록하는 부분이 많다면 빈들이 여러개 생성되지 않을까? 그럼 어떻게 해야하나? 라는 생각과 이를 해결하기위해 스프링에서 싱클톤 패턴이 사용된다는 것을 학습하고, 이 싱글톤이 가지는 단점에 대해서도 얘기한다. 또한 여기서 한걸음 더 나아가 스프링에서 이러한 단점들을 어떻게 해결하고 장점만을 취하는지에 대해서도 얘기하는데, 되새김질 할 수록 선배 개발자들의 천재성을 엿볼 수 있다.
밀려있는 강의와 밀려있는 책
이건 인프런 강의만이고 사실, 패스트캠퍼스의 스위프트 강의도 절반정도 남았고, 책도 정말 많이 남았다.
플러터도 봐야하고 클린코드도 남은 챕터봐야하고, 클린아키텍처랑, TDD도 봐야하고 이펙티브 자바도 봐야하고.. 후...
뭔가 내가 뒤쳐지고있고 부족한게 많다는게 느껴질때마다 조급함에 책을 사고 강의를 사며 지식쇼핑을 한다.
그럼 잠깐이지만 이 지식이 내 손에 들어온 것 같다는 느낌이드는데, 사실 1도 들어오지 않고 내가 다 읽고 듣고 학습까지 해야 절반이나마 내 지식이 되는 것인데, 머리로는 알면서도 이렇게 사고 있다.
1월부터 3월이 끝나가는 지금까지 쓴 강의및 학습비용이 거의 100만원을 넘은 것 같다.
가장 큰 비용을 투자한 ATDD는 그래도 무사히 마쳤지만, 책과 강의는 100% 다듣고 수료증까지 받고 블로그에 정리도하고 깃에다가도 해당내욕 학습해서 올리기까지 해야 들었다고 할 수 있는데 그런의미에서 들었다고 할 수 있는 강의가 몇 없는 것 같다. 작년에 했던 올해 목표중 하나가 강의 1000편이상 보기였는데
작년에비교해서 몇 편 보지도 못했다... 이래서 신년계획 지킬 수 있을지 모르겠다.
당분간은 구입보다는 있는걸 소화하는 쪽으로 방향을 잡고 진행해야 겠다.
ETC
이번주까지해서 3월은 한달 내내 금요일은 재택근무 & 연차를 이용해 집에있었다.
물론 집에서 공부를하던 일을하던해서 딱히 놀거나 한 것은아니지만, 짬짬히 청소도하고, 요리도 해서 먹고 프리한 옷차림으로 집에서 쉬었더니 삶의 퀄리티자체가 많이 올라간것 같았다.
고등학생때는 토요일도 학교에갔고 일요일에도 학교옆에있는 도서관에가서 사실상 주7일제였는데, 어떻게 살아남았는지 모르겠다.
아는 동생은 NHN에 최종합격했다고하고, 다른 동생도 물론 내년 연봉동결을 대가로 +500에 기존 연협내용이 합쳐져서 중소기업치고는 상당한 연봉을 받게되었다.
이젠 내차롄데 내생각에 연협이 어느정도 성공적으로 한다고 쳐도 만족스럽긴 힘들 것 같은데, 이직에 대한 생각은 긍정적인 부분과 부정적인 부분이 공존한다.
현재 직장의 장점
◦
격주로 금요일 재택근무
: 더 좋은 곳도 있을 수 있지만 중소기업에서 안정적으로 재택을 할 수 있다는게 상당히 만족스럽다.
◦
꼰대없는 회사
:다른 기업의 얘기를들으면 나오는 인간과의 불협화음이 딱히 없다. 이사님들은 다 개발자출신이 현역이고 다른 동료들도 개인주의도 있고, 따로 얽힐일이 별로 없어서 그런지 서로 의견충돌이나 쿠사리나 정치질 아무것도 없다.(회사가 작아서 그런걸수도.) 그러다보니 사람에 대한스트레스가 고객사를 제외하면 없다시피 하다.
◦
교통
: 현재 신혼집에서 회사까지 걷는 시간을 다 포함해도 왕복 1시간 반이 안걸린다. 지하철 한번에 간다는 점과 현재 신혼집이 전세가 끝나려면 대략 2년인데, 2년내로 이직을 먼곳으로가버리면 출퇴근의 고통이...
◦
프로젝트 기술 선택을 어느정도 자율적으로 할 수 있다.
: 중소기업의 장점이다 단점이다. 프로젝트를 시작할 때 제대로 된 아키텍처나 사수가 없기 때문에 프로젝트에 들어가는 기술이나, 라이브러리, 언어등 어느정도 다 내마음대로 한다. 그렇기에 학습한 내용에 대해서 적용할 때 눈치 볼일도 크게 없다.
◦
연차의 자유로움
:반차/연차 소모에 있어서 그냥 전날에 제출해도 정말 왠만해선 다 OK다 다른 회사도 그런진 모르겠지만 만족하는 부분
◦
철야하면 쉬게 해준다.
: 일이 너무 많아서 밤샘근무를 하거나 단기로 1~2일정도 파견을가서 무리하게 일을하면, 회사에서 모른척하지않고 쉬고싶을때 그냥 쉬라고 한다. 당연한걸수도있지만, 지금가지 들어온 다른 분들 얘기로는 이런 당연한게 안지켜지는 경우가 너무 많은것 같아 장점이 된다.
◦
칼퇴근 노터치
: 일이 없는데, 굳이 안남고 걍 퇴근해도 별 말 없다. 눈치주는 것도 없다. 동생 회사는 그냥 먼저가면 싫어하는 경우가있어서 이런것도 장점이라면 장점이다.
현재 직장의 단점
◦
사수가 없다.
:입사할때는 있었던 선임들이 다 이직을 해버려서 사실상 내 위로는 이사님들밖에 없다. 그래서 주니어인데도 너무 방치되서 일을 하고있다. 보통 일을 할 때 이사님과 같이하면서 이사님에게 질문하면서 진행하지만, 이사님의 입장은 너무 코어 개발쪽이기에 그외적으로는 답답할때도 종종있다.
공부나 코드리뷰관련해서는 사실 답답했던부분도 있지만, 이 부분은 요즘 교육시스템이 잘되어있어 걍 돈내고 유료스터디나 강의 들으면서 피드백 받으면되는 부분이라 이건 상관없지만, 코드 외적인 회사 업무적으로 문서작업이나 체계에 대해 제대로 못배우는게 단점이다.
◦
연봉
: 평범한 SI중소기업치고는 그냥 평균이라 할 수 있다. 인상율도 작년에 23%였고 올해도 최소 10%는 넘을 것 같다. 하지만, 비교군이 좀 큰 회사를 기준으로 보다보니 절대적으로 초봉이 낮았기 때문인지, 신입사원들보다도 훨씬 낮은 연봉인지라, 게다가 이제 와이프가 지방에서 올라오면서 외벌이를 하게 된다면 부담이 되는 연봉이다.
◦
작은회사에서 주니어기간을 다 보내면 이직이 힘들다
: 요즘 자주듣는 얘기인데 4~5년차까지는 주니어로 중고신입으로 큰 곳을 노릴수도있고 이직이 비교적 쉽지만 그 이상부터는 경력직을 노려야하고 갈수록 요구수준도 높아진다고 하니, 고민이 된다.
회사가 차라리 블랙이거나 엄청 좋거나 하면 고민이 없을텐데 장점과 단점이 너무 명확하고, 놓칠수 없는 영역도 서로 있다보니 고민이 될 수밖에 없다. 동생이나 동료들은 2~3년차에서 이직을하며 연봉과 처우를 높히고 있다보니 사실 그냥 공부하면서 일하던 내입장에서는 심정이 복잡해진다.
