예외를 알아보기 전에

에러와 예외의 차이부터 알아보도록 하자.

에러

일단 에러(Error)는 시스템이 비정상적인 상황에 발생하게 된다.

수습할 수 없는 상황에 놓이게되어 개발자가 예측하지 못한경우이다.

예외

예외는 개발자가 구현한 로직에서 발생된 실수나 사용자의 영향이 미쳐 발생하게 되는 것이다.

그렇기에 미리 예측해서 방지할 수가 있다.

이펙티브 자바를 회독하며 스터디를 진행하면서 2장에

IllegalArgumentException이 나오게 되어 이 예외 부분을 정리하게 됐다.

Checked, Unchecked Exception

기본적으로 오류, 예외는 Object를 상속받는 Throwable클래스를 상속받아 구현이 되어있다.

이미지 출처 - https://www.programcreek.com/2009/02/diagram-for-hierarchy-of-exception-classes/

그림을보면 Exception을 포함해 아래 뿌리로 빨간색으로 표시된 예외들은 모두

Checked Exception이다.

푸른색은 전부 Unchecked Exception이다.

RuntimeException을 상속받는 클래스들이면 하나같이 Unchecked Exception이라 할 수 있겠다.

보면 알겠지만, 프로그램이 정상 작동중에 실행될 수 있는 예외라는 뜻이다.

차이점

둘의 큰 차이점은 check, uncheck 둘다 throws로 Exception을 처리하게끔 메소드에 달아주어도

명시적으로 컴파일에서부터 에러를 띄워주는것은 Checked Exception이고 throws로 던져지는 예외는 모두 반드시 처리해주어야 한다.
(상위로 던지거나 자신의 위치에서 try~catch로 처리해주거나)

RuntimeException하위 예외들도 throws에 넣어줄 수 있겠지만, 처리해주어야 할 필요는 없을 수 있다.

같이 throws에 넣어주게 되면 이러이러한 예외가 발생한다~ 정도를 나타내는 의미정도로 생각하면 되겠다.

근데 이마저도 너무 많은 예외를 throws에 같이 넣어주면 가독성을 반대로 해칠수도 있다.

예외로 의미있는 어떤 무언가를 반드시 처리해줄 수 있는 로직이라면 Checked Exception을

예외 상황이나 문제를 해결할 수 없다면 Unchecked Exception을 활용해 볼 수 있다.

Checked Exception을 던지게 되었을 때 이 예외를 처리하는 무언가의 핸들러까지 던져지게 될텐데 (무지성 throws)

이럴때 그냥 try~catch해주면서 catch부분에 해당 Checked Exception을 받아서 Unchecked Exception으로 바꾸어 던져주는 방법도 있을 것이다.

트랜잭션 처리에 관하여...

많은 글들에서 트랜잭션 처리 시

• Checked Exception은 Rollback 하지않음
• Unchecked Exception은 Rollback 한다
  라고 되어있는데

어떤 트랜잭션인지 명시도 되어있지 않고 무작정 Rollback을 한다 안한다의 여부는 조금 잘못되었다고 백기선님이 말씀하시는걸 보았다.

좀 당연시하게 Spring Framework에서 @Transactional이라고 무작정 생각하고 보면 맞다고 느꼈었는데,

Kafka의 트랜잭션, DB의 트랜잭션 등등 트랜잭션은 정말 많다.

이 문서만 잘 읽어봐도 오해라는거다.

범용적으로 사용하는 Spring Framework에서 사용되고 있는 @Transactional 어노테이션의 롤백 기준은

바로 Unchecked Exception 종류는 기본 Rollback을 진행한다. 반대로 Checked Exception 종류는 Rollback을 하지 않는다.

기본값으로 두개를 나눠서 Check, Uncheck에 대해 트랜잭션 전략을 나누고는 있지만,

어디까지나 기본값이라는거고, Check, Uncheck상관없이 언제든 내가 원하면 해당 예외를 통해 Rollback전략을 매겨줄 수 있다는 것이다.

그러니 Check와 Uncheck라고 해서 트랜잭션을 롤백한다 안한다의 이분법적 사고는 잘못된 사고라고 이해를 하게 되었다.

시작하기

내가 클라우드 요금은 견딜 수 없어서 상당히 겁이 난 상태였다.

하지만 뭔가 내가 만들어서 써보고 싶은게 최근에 생기게 됐다.

그게 바로 북마크인데, 크롬에 의존해서 북마크를 하는게 아니라, 내가 직접 만들어서 거기에 글 포스팅을 스크랩하거나,

모르는 영단어나 줄여쓰는 영어등등.. 개발 관련 단어들도 뭔가 한 곳에 두고 싶었다.

그런데 웬걸, 친구가 라즈베리파이가 한 개 남는다고 이거 써보겠냐고 물어왔다. ㅋㅋㅋㅋㅋ 나는 좋지~

아두이노는 한번 써봤는데 이건 처음이라 그래도 OS설치는 이미 되어있다고 해서 받아서 써보는데 되게 귀엽고 성능은 좋은것 같다? (아직 첫날이라 그런걸까.... 🤔)

아무튼 각설하고 이 서버를 통해서 ssl 적용도 해서 도메인 주소 붙이고 나만의 북마크를 만들어보고 싶어졌다!

이 라즈베리를 사용하는 덕에 뭔가 운영체제나 메모리, 네트워크 등등의 지식들을 같이 얻어갈 수 있는 기회라 좋을 것 같다!

이제 막 여러 것들을 설치하면서 하나씩 보는데 상당히 재밌다.

ㅋㅋㅋㅋ 월급받으면 이 라즈베리파이에 쿨러도 달아줄까 생각중이다. (종일 써야되니 무조건 달아줘야 하는게 아닐까 싶긴 하다)

이게 진짜 웃긴게 sd카드는 용량을 다시 한번 확인해봐도 16기가였다.

근데 전체 디스크 용량을 보면 5.6기가 남짓이다.

좀 구글링을 해봤는데, 라즈베리파이에서 제공되는 OS 사용시 메모리가 4기가 남짓만 사용가능하게 설정된다고 한다.

그래서 용량을 재설정하는 것을 검색해보고 적용하니까 아래같이 바뀌게 됐다!

크... 87%에서 33%로 감소하는 수준의 용량차이다. ㅋㅋㅋㅋㅋ

뭔가 지금 해결되지 않은건 와이파이 설정인데..

일단 기존에 친동생 방에 이더넷 케이블이 남는 여분이 하나 있어서 당장 쓰지 않는 케이블이라 이더넷으로 연결해서 사용중이다.

공유기로 포트 물린게 아니라 따로 회선이 등록되어 있는경우라서 공인 ip로 바로 접속해버렸다.

이거 철저하게 관리하고 공유기로 돌릴 수 있는 방법 찾으면 그렇게 바꿔야겠다.

뭐 일단 ssh접속 포트도 바꿨고, public key접속으로만 접속하게끔 허용해놓은 상태라서 일단 당분간은 안심하고 쓸수도 있겠다.

뭐 mysql은 일단 설치 잘했고...

가장 최신 LTS인 Java17을 나중에 받아야겠다. 뭔가 homebrew에서 하는 설치랑 조금 다르게 wget으로 수행해주는 것 같다.

아니면 지금 공부중인 코틀린을 써볼까?! 하는 재밌는 생각이 계속 들면서 기분이 좋아진다.

소프트웨어 장인이라는 책을 출퇴근 시간에 읽으면서 마음가짐도 되게 많이 바뀌게 되는것 같다.

인프콘도 다녀오면서 오프라인 컨퍼런스를 체험하고 다른 개발자분들의 의지에 덩달아 자극을 받아 열심히 또 달려보려고 한다!

스터디도 JVM 관련 스터디와 이펙티브 자바 회독을 하려고 이 스터디도 들어가게 되서 총 2개 스터디를 들어가게 됐다.

이것도 같이 병행하면서 열심히 해야겠다. (북마크 만드려면 JavaScript도 공부해야되는데...?)ㅋㅋㅋㅋ

아무튼 요근래 못했던 삽질 ATDD과정 끝나면서 이런 값진 행동들을 하면서 많이 에러 맞아볼 수 있는 또 하나의 기회가 오지 않았나 싶다.

마무리

공부할게 정말 많고 시간이 없어서 내 자신을 하나의 프로세스로 두고 여러 스레드를 할당해서 병렬로 지식습득을 하고 싶다 😇

요즘에 계속 TDD를 하려는 습관을 가지다 보니까 전에 단위 테스트를 작성했던 나보다 훨씬 예외 케이스나 엣지 케이스들을 더 잘 찾아내는것 같다.

확실히 반복적으로 짧게 테스트를 가져가면서 피드백 받으니 이렇게 되는건가 싶다.

이 포스팅은 반효경 운영체제 강의 를 듣고 정리하는 글이다.

fork, exec실습 코드는 깃허브에 있다.

프로세스 생성

부모 프로세스는 1개만 존재하고, 자식 프로세스들을 생성한다.
copy on write (cow) 기법

주소 공간
자식은 부모의 공간을 복사한다.
자식은 그 공간에 새로운 프로그램을 올린다.

유닉스에서는 fork 시스템 콜 을 통해 부모 프로세스와 똑같이 복사한다.

수행

• 부모 자식이 공존하며 수행되는 모델
• 자식이 종료될 때까지 기다렸다가 수행되는 모델

프로세스 종료
프로세스가 마지막 명령을 수행한 후 운영체제에게 이를 알린다. (exit)

• 자식이 부모에게 output data를 보낸다.
• 프로세스의 각종 자원들이 운영체제에게 반납됨

부모 프로세스가 자식의 수행을 종료시킨다. (abort)

• 자식 프로세스가 할당 자원의 한계치를 넘어설때
• 자식에게 할당된 태스크가 더 이상 필요하지 않음
• 부모가 종료하는 경우
  • 운영체제는 부모 프로세스가 종료하는 경우 자식이 더 이상 수행되도록 두지않음
  • 단계적인 종료

자식을 전부 죽이고서 부모가 죽게되는 구조

wait()
프로세스가 wait() 시스템 콜을 호출하게 되면,

• 커널은 child가 종료될 때까지 프로세스 A를 sleep 시킴 (block 상태)
• 자식 프로세스가 종료되면 커널은 프로세스 A를 깨운다 (ready 상태)

exit()
프로세스의 종료
exit()을 만나는 순간 바로 종료가 되게 된다.
자바로 하게되면 System.exit(0);

자발적 종료
마지막 작업 수행 후 exit() 시스템 콜을 통해 수행
프로그램에 명시적으로 넣어주지 않아도 main 함수가 return되는 위치에 컴파일러가 삽입해준다.

비 자발적 종료

1. 부모 프로세스가 자식 프로세스를 강제 종료시킴
   • 자식 프로세스가 한계치를 넘어서는 자원 요청
   • 자식에게 할당된 작업이 더 이상 필요하지 않음
2. 키보드로 kill, break를 수행한 경우
3. 부모가 종료하는 경우
4. 부모 프로세스가 종료하기 전에 자식들이 먼저 종료

프로세스간 협력

독립적 프로세스

프로세스는 각자의 주소 공간(코드, 스택, 데이터)을 가지고 수행되므로,
원칙적으로 하나의 프로세스는 다른 프로세스의 수행에 영향을 미치지 못한다.

협력 프로세스

프로세스 협력 메커니즘을 통해 하나의 프로세스가 다른 프로세스에 영향을 미칠 수 있다.

프로세스 협력 메커니즘 (IPC: Inter Process Communicaiton)

1. 메세지를 전달하는 방법
   message passing : 커널을 통하여 메세지를 전달
   프로세스에게 직접 전달하는 방법, mailbox를 통한 전달방법
2. 주소 공간을 공유하는 방법
   shared memory : 서로 다른 프로세스 간에 일부 주소 공간을 공유하게 하는 shared memory 메커니즘이 존재 (이 부분도 커널에게 공유하겠다는 시스템 콜을 이용해야한다)

program은 CPU를 사용하는 단계 (CPU burst) -> I/O를 수행하는 단계 (IO burst)를 계속 반복하며 실행된다.
(물론 CPU만 사용하는 프로그램도 존재할 수 있음)

여러종류의 job(=process)가 섞여있어 CPU스케줄링이 필요하다.
Interactive job에게 적절한 응답 제공하기 위함
CPU와 입출력 장치등의 시스템 자원들을 골고루 효율적으로 사용하기 위함

CPU 스케줄러
ready 상태의 프로세스 중 이번에 CPU를 줄 프로세스를 고름

Dispatcher
CPU의 제어권을 CPU 스케줄러에 의해 선택된 프로세스에게 넘김
이 과정을 context switching(문맥 교환)이라 한다.

동기식, 비동기식 입출력

프로세스가 입출력이 진행되는 동안에 CPU 점유는 중요하지 않음

입출력 명령을 계속 대기하면 동기,
해놓고서 다른 작업을 수행하면 비동기

구현 1

I/O가 끝날때 까지 계속 대기해 CPU를 낭비시킴
매시점 하나의 입출력만 일어남

구현 2

입출력이 완료될 때까지 해당 프로그램에서 CPU를 빼앗음
다른 프로그램에서 CPU를 가지고 연산 수행
입출력 작업이 완료되면 해당 프로세스에 CPU할당

스레드

프로세스 내부의 CPU 수행단위가 여러개 있는것이 스레드

프로세스마다 code, data, stack 이 주어짐

CPU수행과 관련된정보는 스레드가 별도로 가지고있고,
나머지는 공유한다.

스레드의 구성

program counter
register set
stack

스레드의 장점

1. 다중스레드 구성된 작업구조에서는 하나의 스레드가 blocked 상태인 경우에도
   동일한 작업 내의 다른 스레드가 실행되어 빠른 처리가 가능하다.
   1, 2, 3 을 보여줄때
   먼저 완료된거 바로 보여주게 되면 사용자에게 좀더 원활한 서비스를 제공가능

2. 자원 공유 - 같은 일을 하는 프로그램을 멀티 프로세스를 구성하기 보다는 cpu 수행단위만 여러개로 주게되면 자원을 효율적으로 사용이 가능하다.

3. 같은 작업을 다중 스레드를 사용하여 동시처리가 좋아지고 성능 최적화를 할 수 있다.
   (병렬 처리)

4. 여러개의 프로세스에서 각각의 스레드가 서로 다른 CPU에서 병렬적으로 작업 수행이 가능하다.

커널 스레드
커널의 지원을 받는 스레드
운영체제 커널이 여러 스레드로 구성되어 있는것을 알고있음

유저 스레드
라이브러리를 통해 지원, 프로세스안에 여러 스레드가 있다는것을 운영체제는 모름
구현사항에 제약은 있을 수 있음

프로세스

프로세스는 파일 형태로 존재하는(ex - xxx.exe 등) 프로그램이 실행되어 메모리에 올라가 있는 상태를 뜻한다.

잡(Job)이라는 용어와도 혼용해서 부른다.

프로세스를 이해하려면 프로세스 문맥(Context)도 알아야 한다.

프로세스 문맥(Context)

문맥은 해당 프로세스의 주소공간, 레지스터의 값, 시스템 콜 등등을 통해

커널에서 수행한 작업의 상태, 커널이 관리하고 있는 정보들을 담고있다.

프로그램이 프로세스가 되면, 운영체제는 프로세스를 관리하기 위한 자료구조를 유지한다.

이 두개가 바로 PCB, 커널스택이다.

프로세스의 상태에는 실행, 준비, 봉쇄가 있다.

• 실행
  • 프로세스가 CPU를 보유, 기계어 명령을 실행하고 있는 상태
  • CPU는 하나뿐이므로, 여러 프로세스가 실행된다 하더라도 실행 상태에 있는 프로세스는 매 시점에 하나뿐
• 준비
  • CPU를 할당 받지 못한 상태
• 봉쇄
  • CPU를 할당받더라도 바로 명령을 실행할 수 없는 프로세스의 상태
  • 프로세스가 요청한 입출력 작업이 진행중인 경우 이에 해당함

프로세스의 상태를 구분하는 이유는 컴퓨터의 자원을 효율적으로 관리하기 위함

크게는 3가지이고

시작과 완료 상태가 존재한다.

프로세스가 시작되어 프로세스를 위한 자료구조는 생성됐는데 메모리를 획득하지 못한 경우를 시작상태,

프로세스와 관련된 자료구조를 완전히 정리하지 못한상태가 완료상태이다.

운영체제에게 입출력을 요구하건 다른 작업을 요구하면 모두 큐에 줄을 서게되고,

자기 차례가 되면 그때서야 데이터들을 받게되고, 그 때 인터럽트가 발생해서 입출력 완료 사실을 알림

프로세스 제어 블록 (Process Control Block; PCB)

PCB는 운영체제가 시스템 내의 프로세스들을 관리하기 위하여 프로세스마다 유지하는 정보들을 저장하는

커널 내의 자료구조이다. 구성 요소는 아래와 같다.

• 프로세스의 상태
• 프로그램 카운터 값
• CPU 레지스터 값
• CPU 스케줄링 정보 (메모리 할당을 위해 필요한 정보)
• 메모리 관리 정보 (메모리 할당을 위해 필요한 정보)
• 자원 사용 정보
• 입출력 상태 정보

문맥교환 (Context Switching)

하나의 프로세스로부터 다른 프로세스로 CPU 제어권이 이동하는 것을 컨텍스트 스위칭이라 한다.

교환이 될 때 원래 CPU를 가지고 있던 프로세스는 프로세스의 문맥들을 PCB블록에 저장하고,

제어권을 받은 CPU는 자기 자신의 저장된 문맥을 PCB로부터 읽어온다. (이 과정이 성능을 느리게 할듯?)

인터럽트에서 설명을 정리했을 수 있는데,

프로세스 중간에 입출력을 해야된다거나 등등으로 운영체제를 사용해야 하는 경우에 시스템 콜을 하게 될텐데

이 때의 프로세스는 컨텍스트 스위칭이 아니라 그냥 해당 프로세스가 실행중인 것이다.

그래서 이러한 과정에선 컨텍스트 스위칭이라고 하지 않는다.

CPU를 점유하는 프로세스가 다른 사용자의 프로세스로 변경되어야만이 컨텍스트 스위칭이라 할 수 있다.

CPU 할당 시간을 아주 작게 설정하면 너무 많이 컨텍스트 스위칭이 일어나서 오버헤드가 커지며

성능이 저하될 것이다.

반대로 너무 시간을 길게 잡게되면 시분할 시스템의 의미가 퇴색될 수 있다.

이전에 TDD, Clean Code with Java 12기를 이수하면서,

테스트 코드에대한 중요성 그리고 단위 테스트는 어떻게 해야겠다! 라고 깨달음을 얻었었다.

그렇게 하면서 업무에도 테스트코드를 적용하려고 하는데

흔히 Spring framework에서 사용하는 Controller, Service Layer 들의 테스트들을 내가 작성할 때에는 전부 Mock을 이용해서

테스트를 진행을 해주었다.

이렇게 해주는게 맞을까? 🤔 라는 의문을 계속 가지면서 그리고 최근에 뭔가 조금 해이해진 경향을 바로 잡고자

이 강의를 신청하게 되었다.

각 주차마다의 미션들을 좀 가져와봤다. 궁금하면 한번 놀러와주세요!

1주차 - 인수 테스트

https://github.com/lsj8367/atdd-subway-map

2주차 - 인수 테스트와 TDD

https://github.com/lsj8367/atdd-subway-path

3주차 - 인수 테스트와 인증

https://github.com/lsj8367/atdd-subway-favorite

4주차 - 인수 테스트와 리팩토링

https://github.com/lsj8367/atdd-subway-fare

이렇게 4주까지 피드백 받으면서 인수 테스트를 작성했더니 시나리오 흐름대로 뭔가 이해할 수 있게 테스트를 구성하는게 가능해진것 같다.

또 한번 사석에서 리뷰를 받아보니까 어떤 부분을 내가 놓치고 있었고, 어떤 부분에서 조금 더 나은 선택을 할 수 있는지 많은 고민을

할 수 있어서 굉장히 좋았다.

RestAssured를 사용해서 인수테스트를 진행했는데, MockMvc와의 다른점과 좋았던 점 등등을 다른 포스팅에서 다시 쓰도록 하겠다.

(여기는 회고글이기 때문)

한 프로젝트를 돌아가게 작성만 해놓고 다른 프로젝트를 또 시작하는 SI 형식의 개발이 아니기 때문에,

내가 짠 코드에 대해서 유지보수를 잘하게끔 도와주고, 더 나아가서는 코드를 다른사람이 볼 때에도 이해하기 쉽게끔 테스트를 구성하는게 습관이 되어가고있다.

이와 동시에 비즈니스 코드를 작성하는것보다 무조건 테스트 클래스부터 만드는 내 자신을 볼 때 좀 뿌듯한 감정도 있다. ㅋㅋㅋㅋ

다만 이 과정중에 아쉬웠던 것은, 조금 더 여유있을 때 해볼걸 하는 생각도 있지만 끝나고 보니 열심히 하는 다른 분들이 있어서

같이 자극받고 하지 않았나 싶다!!

이제는 다시 업무를 위한 공부를 하면서, 틈틈이 하려고했던 운영체제, 네트워크, 알고리즘을 쭉 해야겠다.

아무튼 좋았고 되게 값진 경험이었다!

블로그를 기존 벨로그에서 티스토리로 옮기게 되었다.

그래서 거기서 포스팅 했던 글들을 전부 지금 이 티스토리로 옮기고

드디어!! 진짜 날짜에 맞는 첫글을 써본다.

이직

우선, 전 직장에서 6개월을 하고 그만 둬버렸다. 뭔가 시도해보고 도입해보려고 했던건 많이 도입을 해보았던 것 같다.

내 입장에서는 그래도 같은 업무를 보는 개발자분들이 좀 더 많았으면 좋겠다고 생각했고,

여러 의견을 들어보고 싶었던게 가장 컸던 것 같다. 그래서 이직을 하게 됐다!!

물론 근속기간이 짧고 그렇게 이르게 이직을 했다는 것 자체가 문제라고 본다면 문제일 수 있다고 생각하지만,

뚜렷한 기준을 가지고 충분히 설명할 수 있을거라고 생각했었다.

B2C 서비스를 하던 기존 회사였지만, 그래도 아직 시장이 되게 작았었고,

그것으로 인해 여러 트래픽 경험을 못해봤던게 조금 아쉬움이 많이 남았는데..

B2B 핀테크 서비스로 옮기면서 전 회사가 작았던 탓인지 지금 이곳이 트래픽이 훨씬 많다!!!

무엇보다 이직한지 1달이 조금 넘은 지금은 CTO님이 계셔서 탄탄하게 흘러가고 있다는 것이 좋게 느껴진다.

다들 고민을 위해서 뭐든지 뛰어들고 공유해보고 얘기하는 것을 좋아하시는 것 같다고 내 주관적으로 생각한다.

아키텍처 리뷰

지금 당장 내가 담당하고 있는 일은 공통 메세지 서버를 개발을 진행중이다.

서비스가 점점 커지며 MSA 아키텍처로 전환하면서 지금의 회사는 Kafka를 도입했다. (이 포스팅에 대해선 추후에 다시 다루도록 하겠다. 😁)

이렇게 분리하면서 나온게 지금 내가 개발하고 있는 공통 메세지 서버이다.

간단하게 설명하자면 여러 메세지들을 푸시, 메일, 슬랙 등등으로 공지나 알람들을 보내주게 되는 서버이다.

처음 써보는 Kafka지만 그래도 다들 많이들 도와주셔서 잘 구축한거라고 생각한다.

작성 시점 기준으로 어제 아키텍처 리뷰를 받았는데, 면접 때 질문 받은것보다 이상으로 더 많이 깊게 물어봐주시고 알려주시고 한 덕분에

얻어가는게 많은것 같다. ㅋㅋㅋㅋ (아직 한참 모자라다고 많이 느낀다)

코드리뷰도 적극적으로 한 PR에 코드 수정이 아니더라도 생각할 수 있게끔 주시는 코멘트도 많아서

답변까지 포함해서 첫 PR기준으로 4~50개가 달렸었다. 각기 다른 시각으로 봐주는게 내 입장에서는 정말 좋다고 느꼈다.

개인적으로는 이직 후에 1달이 지난 지금이지만, 각 서비스에 대한 도메인 지식은 지금이 훨씬 습득이 빠른것 같다.

VOC도 처리하면서 온보딩 받아가며 하다보니 잘 잡혀가는 것 같다.

그래도 계속 내가 성장하는데 발목을 잡는건 CS였다. 뭔가 잘 개발하는것 같다가도 궁금증이 생기는 건 무조건 CS였다.

그래서 내가 생각했던 방법은...

모각코를 해서 다양한 사람들의 의견도 들어보고 내 공부도 틀어지는 것 같을때 질문해서 방향성 잡아 좀 깊게 하고 싶었다.

그래서 최근에 내가 거주하는 지역에서 오프라인 모각코를 모집했다.

내가 뭔가 주도해서 소통하고 싶고 다른 분들의 생각도 들으면서 공유하고 싶었던게 크다.

스터디 구인 글

이렇게 모집하면서 나를 포함한 8명이 내일이면 처음 모각코를 시작한다.

지속적으로 잘 운영이 된다면 인원도 늘려서 소규모로 자기가 배웠던것이나 최근 이슈를 해결했던 것을 발표하는 시간도 가져보고 싶은

생각이 있다. (커지면 해당 노션도 이렇게 운영되고 있다 라고 보여주려고 공유할 생각이다!)

계속 생각하는 것이지만 커머스, 금융 도메인에서 뭔가 돈이 관련된 서비스들을 주로 다루어보고 싶었다.

누군가가 보면 피곤하다고 생각이 들 수 있는데, 예민한 정보이고 깐깐하게 검증을 수행해주어야 하기 때문에

더 탄탄하게 많은 경우의 수를 가지면서 다룰 수 있을거라고 생각해서 이쪽으로 관심을 가지게 되었던 것 같다.

이제는 지금 회사에서 꾸준히 잘 성장하다보면 언젠가는 내가 원하는 회사에 갈 수 있지 않을까 생각한다.

다음 회고에서는 지금보다 더 성장하는 내가 되었으면 하고 계속 반복적인 연습이 답인것 같다. 🔥🔥🔥🔥