[WIL] 12-4

벌써 12월의 중반을 지나 마지막을 향해 달려가고 있다. 분명 지난 WIL 을 작성한거 지난 주.. 아니 엊그제 같은데 작성을 못한지 몇주가 지났다. 사실 12-2 주차 WIL 을 작성하고 있다가 약속시간이 되어 임시저장하고 나갔었는데.. 결국 12-4 주차 WIL의 작성은 못하고 말았다.

 

잠시나마 요약을 해본다면, 지난 12-2~3주차 동안에는 계속해서 프로젝트를 분석하고 이해하고, 정리하는 것이 주된 하루 일과였다. 주로 프로젝트를 이해하면서 발견한 문제점들을 따로 정리하고, 이에 대한 해결책을 작성하다보면 하루가 전부 다 가버리곤 했다. 이와 관련하여 진행 예정이었던 프로젝트의 리팩터링 미팅에서 이야기를 해보고자 했는데, 다들 너무 바뻐(?) 리팩터링 미팅은 이뤄지지 못했었다. 이 과정을 거치면서 현재 우리 소프트웨어 팀의 업무 프로세스의 불편함을 느끼기도 했다.

 

타운홀 미팅의 일부분 개인적으로 가장 인상적인 부분이었다.

 

이외에도 회사 송년회도 진행되었고, 사내에서 소프트웨어팀의 현재 상태를 공유하고 내년의 목표를 세우기 위한 미니 워크숍, 그리고 현재의 회사 상황 그리고 다가올 24년의 목표를 공유하는 우리 캡틴(CEO)의 타운홀 미팅이 진행되었다. 타운홀 미팅을 통해 23년의 회사의 상태를 알 수 있어서 좋았고, 궁금한 내용을 모두가 모인 자리에서 질문할 수 있어서 개인적으로 너무 좋았다. 뿐만아니라 내가 내년에 어떤 목표를 세워야하는가? 에 대하여 스스로 고민도 해볼 수 있었다. 

 

그리고 이번 12-4주차는 가장 핵심적인 한 주였다고 이야기할 수 있다. 이번 12-4주차에는 내가 앞으로 어떤 일을 할지 또 해야할지를 좀더 명확하게 스스로 정의하고, 주도적으로 업무에 참여할 수 있게 되었기 때문이다. 이 결과는 도달하기까지 개인적으로 정말 많은 고민과 선택을 거쳐도달하게 되었는데 이 과정을 통해 스스로 성장한 것 같아 기쁘다.

 

• 프로젝트 리팩터링 제안 -> 프로젝트 리뉴얼 제안
• 기록의 중요성, 공유의 중요성, 의사소통의 중요성
• 목표설정

 

---

프로젝트 리팩터링 제안 -> 프로젝트 리뉴얼 제안

 

이번주에는 지난 주에 예정되었던 리팩터링 관련된 미팅을 드디어 진행할 수 있었다. 이와 관련하여, 나는 미팅이 진행되지 못해도 개인적으로 계속해서 사내 문서를 작성하고 있었다. 미팅이 진행되지 않아 직접 대면적으로 이야기를 해보기도 했었지만 지난 주에는 이뤄지지 못했다. 아마도 다른 바쁜 일(?)에 밀려 잊혀졌던 것이 미팅이 계속 미뤄진 원인이었던 것 같다.

 

사실 공식적인 미팅이 이뤄지기 전에, 소프트웨어 팀 미니 워크숍 진행 간, 해당 내용을 간략하게 이야기를 한 적이 있었다. 내년의 프로젝트를 진행하기에 앞서, 프로젝트 상황에 대한 이야기를 하면서 간략하게 이야기가 이뤄졌었다. 해당 내용에서는 현재 진행하기로한 프로젝트 리팩터링을 리팩터링이 아닌 리뉴얼 규모로 생각해야할 것 같다고 이야기를 했었다. 왜 리팩터링이 아니라 리뉴얼로 해야하는가? 에 대한 이유 정도만 간략하게 이야기를 한 뒤, 다음 미팅에서 더 자세하게 이야기를 해보자고 하였었다.

 

이후 진행된 미팅에서는 내가 생각하는 현재 우리 프로젝트에 대한 분석을 PR 했다. 현재까지의 우리 프로젝트의 목표는 무엇이었고, 앞으로의 목표는 무엇인지, 현재 상황은 어떠한지, 내년(미래)의 목표와 관련하여, 현 상황의 한계점과 이를 개선하기 위한 개선 방법에 대하여 이야기를 했다.

 

 

현재까지 우리 프로젝트의 목표는 무엇이고, 앞으로의 목표는 무엇인가?

 

현재까지의 프로젝트의 목표는 단언컨데, MVP의 개발이라고 이야기 할 수 있다. 스타트업의 특성 상 이는 너무나도 당연하다. 이 과정에서는 너무나도 당연하게(?) 기술 부채가 발생했고, 지금의 프로젝트 상황이 되었다고 이야기 할 수 있다.  다소 건방진 말인 것 같지만.. 냉정하게 프로젝트 상태는 엉망이다. 빠른 MVP 개발을 목표로 했다고 하지만, 프로젝트를 아키텍처 특성으로 분석해보았을 때 그 어떤 특성도 보장되지 못했다고 나는 생각한다. 정말 단순하게 기능 개발만 이뤄졌다. 근데 개발된 기능마저 안정적이지 못하다. 이에대해서는 아래에서 더 이야기해보겠다..

 

앞으로의 목표는? MVP 개발 및 실제 제품의 판매 및 고객의 피드백을 통한 시스템 개선 및 사업의 확장이다. 하지만 냉정하게 지금 시스템에서 해당 내용을 반영하려면 엄청나게 많은 곳을 손을 봐야한다. 단순하게 기능 수정 혹은 추가임에도 불구하고 말이다.

 

 

현재상황은?

 

내가 생각하는 현재상황은 앞으로의 목표를 위해서라도 빠른 개선이 필요하다. 개선의 필요성은 팀 내에 인식이되어있어 사전에 리팩터링이 1차적으로 진행이 된 상황이었으나, 잘못된 방향으로 이뤄지고 있었다.

 

내 생각의 근거는 다음과 같다.

• 리팩터링의 목표가 분명하지 않다.(모듈화를 진행하는 것이 목표라고 했지만, 왜 모듈화를 해야하는지 근거가 없다.)
• 프로그래밍 패러다임을 변경(객체지향 -> 함수형)했으나, 어느한쪽의 프로그래밍 패러다임을 제대로 이해한 사람이 없다.
• 프로젝트의 개선이 아닌, 개인의 사리사욕(?)을 위해 수정이 이뤄진다.
• 개발 프로젝트에 대한 절차와 체계가 없다.

 

사실 이 부분들에 대해서 다소 건방져보일 수 있다. 하지만 놀랍게도(?) 최대한 객관적으로 작성해보았다.. 주관적으로 작성한다면... 진짜 어떤 말까지 나올지 모른다... 

 

이 문제점들 중 내가 생각하는 가장 큰 문제점은 (다 연관이 되어있지만) 리팩터링의 목표가 분명하지 않다는 것이다. 목표가 불분명하여, 지난 리팩터링의 작업 또한 잘못된 방향으로 이어진 것이 아닌가 생각한다. 계속해서 묻고, 생각하고, 의사소통의 과정을 거치면서 든 생각은 그저 개인의 욕심으로 선택된 결과라는 생각이 들었다.

 

내가 생각하기에는, 이전까지 문제점들은 분명했고(모두가 인지하고 있었고, 내부에서 소리가 계속해서 지금까지도 나오고 있다.) 이에 대한 문제 해결을 고민했어야 한다고 생각한다. 그리고 계속해서 나오고있는 소리는, 프로젝트를 수정하기가 어렵다는 것이다.

 

그렇다면 왜 프로젝트가 수정하기 어려운 것일까? 여렇 이유들이 존재하지만, 과거 코드를 모두 확인해본 결과 가장 큰 원인은 함수와 클래스가 너무 많은 책임을 갖고 있기 때문이었다. 그런데 내가 보기에는 이것 때문에 모듈화를 해야한다. 는 아니라고 생각한다. 클래스와 모듈이 너무 많은 책임을 갖고 있었지만, 관련된 기능들만 갖고 있었기 때문에 모듈화를 통해 이 문제를 해결한다는 것은 아니라고 생각이 들었기 때문이다.

 

하지만 "모듈화를 한다." 라는 목표가 세워진 것에 대하여, 아마도 관련된 기능들 내에서 또 기능들을 추출하여 사용하고 한 것 같다. 그리고 코드의 응집도를 높이고 해당 코드를 재사용하고자 한게 아닐까? 생각을 해본다.(해당 목표를 세운 사람에게 물어봤지만 그 이유를 듣지 못했다.)

 

모듈화의 단편적인 기능은 코드 응집도를 높이고 코드의 재사용성을 높이는 것이다. 그러나 모듈화를 고민할 때에는 코드 결합도를 반드시 고려해야한다. 재사용성이 높아진다는 것은 해당 코드(모듈)을 다른 코드에서 참조를 한다는 것이며 이는 코드의 의존성이 발생한다는 것을 의미한다. 그리고 이것은 코드의 유지보수성을 낮추게 될 것이다.

 

근데 모듈화는 왜 진행하는걸까? 코드 응집도를 높이고 코드 재사용성을 증진시키면 어떤 특성이 증진되는걸까? 내가 생각하는 첫번째 문제점은 바로 이것이다. 나는 모듈화가 목표가 될 수 없다 생각한다. 이는 잘못된 목표 설정이다.(궁극적 목표 달성을 위한 세부 목표라면 모를까..) 모듈화를 한다는 것은 궁극적으로 유지보수성 을 높이기 위해 진행하는 것이다.

 

따라서 내가 생각하는 목표는 다음과 같이 설정되어야 한다. 코드의 유지보수성을 증진시키기는 것이 리팩터링의 목표이다. 그리고 이를 위해 모듈화를 진행할 계획이다. 모듈화를 진행함에 따라 코드의 응집도를 증진시키고 코드의 재사용성을 증진시킬 수 있다. 하지만 코드의결합도 및 의존성이 발생할 수 있으므로 이를 고려한 모듈화를 진행해야한다. 

 

 

내년(미래)의 목표와 관련하여, 현 상황의 한계점과 이를 개선하기 위한 개선 방법

 

내년의 목표는 분명하다. 시스템을 고도화하고, 궁극적인 목표인 클라우드 랩을 구현하는 것이다. 고도화 과정에서는 사업의 신규 비즈니스 아이템을 구현해야한다. 그리고 이를 위해서는 오프라인 뿐만아니라 온라인에서도 프로그램을 구동하고 신규 기능(사업 아이템)을 사용할 수 있어야 한다.

 

이를 달성하기 위해, 우리는 이구동성으로 특정 라이브러리를 개발해야한다고 이야기한다. 하지만 이 라이브러리를 어떻게 개발할지는 전혀 모른다. 그저 MSA 로만 이야기할 뿐.. 이는 잘못됬다. 우리의 캡틴(CEO)는 이렇게 이야기해도 되지만, 소프트웨어 팀 사람이라면 이렇게 이야기해선 안된다...

 

지금 내가 본 우리 사람들은 계층화, 추상화의 이해가 다소 부족한 것 같다.(내가 이해가 깊다는 것이 절대아니다.) 이 생각의 이유는 해당 요소에 대한 고려가 전혀 되어 있지 않기 때문이다. 이로인해 특정 기능을 설계할 때, 불필요한 부분에 대한 고려와 고민을 동반하고 있다. 그저 단순하게 역할과 책임에 따라 계층을 나누고 해당 계층만 고민하면 되는 문제를 해당 기능을 위해 전체를 고민하고 있다. 내 말의 의도는 전체를 고려해야 하는 요소가 아님에도 불구하고 전체를 고민하면서 결정을 못한다는 의미다.

 

그리고 이것은 고스란히 프로젝트에 반영되어있다. 계층은 명확하게 나눠져있지 않고, 알 수 없는 호출관계가 이뤄져있다. 하나의 유스케이스를 이해하는데 8개 이상의 파일을 참조하고 있다.. 참조도 참조지만, 해당 파일이 있는 패키지들이 왜 이렇게 나눠진 것인지 이해가 되지 않는다.. 이와관련하여 내가 부족한 것도 맞지만, 일단 가장 먼저 계층을 올바르게 나누는 것이 먼저라는 생각이 들었다.

 

계층을 나누는 것이 선행되지 않는다면, 프로젝트를 이해하기 위해서는 엄청나게 많이 시간이 소요될 것이고,  작은 기능을 추가 혹은 유지보수하는데 있어서 필요이상으로 큰 고민을 하게 될 것이다. 그리고 나는 이것이 명백한 소중한 자원의 낭비라고 생각한다.

 

그렇다면 계층화를 명확하게 함으로써 이를 해결할 수 있는가? 라는 물음에는 맞으면서도 아니다. 아니다라는 생각은 신규 기능 추가 및 유지보수를 하는데 있어서 계층화를 명확하게 나누는 것이 좋은 해결책이 될 수 있지만, 이보다 더 좋은 해결책이 존재한다 생각한다는 의미이다.

 

내가 생각하는 현제의 한계점을 극복하기 위한 가장 좋은 방법은 바로 테스트를 작성하는 것이다.  테스트를 작성하는 것이 가장 가성비 좋은 방법이라 생각한다. 기존의 문제점은 기능 수정 혹은 추가를 하는데 있어서 너무 큰 문제를 고민해야하며, 해당 작업 간 발생하는 사이드 이펙트를 전혀 예측할 수 없다는 것이다.

 

처음에는 계층을 나눠 책임을 분리하여, 해당 작업에 대하여 관련된 계층만 확인한다는 의도를 가지고 이 문제를 해결하고자 하였으나, 이를 통해서도 근본적으로 사이드 이펙트에 대한 문제해결은 불가능하다. 그러나 분명히 계층을 분명하게 나눔으로써 현재의 문제를 분명하게 개선할 수 있음은 분명하다. 

 

하지만 결국 근본적인 문제를 해결하면서 가장 효율적인 해결책은 테스트를 작성하는 것이다. 테스트를 작성함으로써 사이드 이펙트를 예측할 수 있고, 신규 기능의 정상 작동을 검증할 수 있다. 뿐만아니라 미래의 CI CD 를 고려해볼 때 테스트의 작성은 반드시 필요하기 때문에 테스트를 작성하는 것이 현재의 문제를 해결하는 것 + 미래를 위한 준비로서 최적의 해결책이라는 생각이 들었다.

 

 

---

프로젝트 리뉴얼 제안

 

나는 이렇게 다양한(?) 분석과 해결책을 정리하면서 도달한 생각은 이건 리팩터링 보다는 리뉴얼이 좋겠다는 판단이 들었다. 그리고 시기또한 지금이 최적의 시기가 아닐까? 하는 생각이 함께들면서 리팩터링보다는 리뉴얼을 제안하는 쪽으로 맘이 더 기울게 되었다.

 

하지만 리뉴얼을 제안하는데 까지는 내 스스로 넘어야할 산들이 있었다. 따지고보면 내가 하는 모든 작업들이 너 잘못됬어! 라고 이야기가 전달되기 쉽다.(내 의도는 맞는것같지만 아니다...) 프로(?)라면 이는 감정적으로 받아들이는 것이아니라 필요한 것으로 받아들여져야한다고 생각하지만 이렇게 받아들여지는 것이 결코 쉬운일은 아니라는 것을 나는 안다.

 

뿐만아니라 현재 내 상태는 인턴이다. 그리고 프로젝트 리팩터링 관련된 것은 이미 진행된 사항이며, 현재 추가적인 프로젝트의 일부분으로 되어있는 것이라는 것이다. 내가 생각하기에는 분명 계획이 있을 텐데.. 감히 내가 말해도 되는건가? 하는 생각이 크게 들었다. 그렇다고해서 가만히 이 상황을 지켜보는 것만큼 고통스러운 것도 없었다. 이 고민이 점점 더 깊어질 때, 우연한 기회에 co-founder 분과의 대화를 통해 지혜(?)를 얻고서 내 생각의 최선의 방법으로 프로젝트 리뉴얼을 제안하게 되었다.

 

co-founder 분(이하 대장)의 출장을 보조하러 가는 우연한 기회를 통해 해당 고민을 이야기해볼 수 있었다. 물론 우리 회사라는 말이 아닌, 친구의 고민이라고 이야기하며 운을 띄웠지만, 대장은 눈치를 챈것 같다. 당시 이야기에서 핵심은 문제를 언급할 수 없는 상황에서 어떻게 하면 이 문제를 해결할 수 있을까? 이었는데, 대장은 내게 "해당 프로젝트를 좀 더 주도적으로(맡아서) 해보고싶다." 이야기해보는 것을 추천해주었다. 그리고 해당 조언은 다른 생각으로 이어졌다. "내가 이 고민을 왜하게 된 것인가? 나는 프로젝트를 주도적으로 하고싶은 것인가? 아니면 남의 잘못을 이야기하고 싶은 것인가?" 

나는 프로젝트를 주도적으로 하고싶고, 회사의 목표 그리고 내 목표를 달성하고 싶다. 효율적으로. 그래서 나는 리뉴얼을 진행하기에 앞서, 미팅에서 프로젝트를 좀 더 주도적으로 이끌어보고 싶다고 이야기했다.

 

그리고 주도적으로 진행하면서, 현재의 더 큰 문제를 인지할 수 있었다. 우리는 생각만한 껍데기에 불과했다. 기존의 리팩터링 계획은 정말 제목만 존재했고, 아무런 계획도 일정도 없었다. 왜 내가 문제라고 생각한 부분이 문제였는지를 이해할 수 있었다.

 

---

기록의 중요성, 공유의 중요성, 의사소통의 중요성

 

현재의 문제를 명확(?)하게 파악한 뒤에는 정말 솔직하게 엄청나게 막막했다. 분명 나는 A, B, C 계획을 들고 있었는데,  이 A, B, C 는 현 상황에 큰 도움이 되지 않았다. 갑자기 내가 생각해야 할 부분이 엄청나게 커져버렸고, 나는 순간 패닉이 잠깐 왔었다. 하지만 패닉할 시간도 없다. 다시 정신 바짝 차리고 하나하나 정리해보았다.

• 지금 (반드시) 필요한 것은 무엇인가?
• 지금 해결해야할 문제는 무엇인가? 해당 문제는 왜 발생했는가?
• 문제 해결을 위해 필요한 것들은 무엇인가?

 

기록의 중요성

내가 생각한 지금 문제의 가장 큰 문제점은 기록이 제대로 되지 않는다는 것 이다. 분명 기록은하는데, 제대로 기록이 이뤄지지 않는다. 적고서 보지않고(보는지도모르겠다.) 봐도 작성한 사람만 알 수 있다. 문서의 가치가 없다 는 것이 문제였다. 이로인해 문서 작성의 가치는 인정받지 못하고 있었고, 작성된 그리고 작성되는 문서는 객관적으로 의미없는 행위 수준이었다.

 

하지만 문서를 작성한다고 해서 이 문제가 해결되는 것은 아니다. 잠재적으로 이렇게 작성한 문서가 똑같이 읽히지 않는다면 잘 작성된 문서조차 가치를 잃을 것이다. 하지만 대화를 통해 알게된 팀의 문화 및 분위기는 문서의 중요성을 느끼고 있었고 문서화의 필요성을 크게 느끼고 있었다.(아이러니하다..)

 

그래서 나는 가장 먼저 문서의 템플릿을 먼저 작성했다. 기본적으로 ADR 을 참고하여, 작성했다. 의사 결정을 기록하는데 있어서 가장 객관적인 문서가 될 수 있을 것이라고 생각했기 때문이다.  그리고 다른 작업인 Github 을 적극적으로 활용하기 위한 Issue 및 PR 템플릿 또한 작성했다. 

 

 

공유의 중요성

우리는 공동 작업과 관련하여 공유해야하는 내용은 언급을 통해 공유하고 있다.

 

공유는 현재 내가 가장 부족한 능력이라 생각하는 부분이다. 우리 회사는 현재 문서는 노션을 통해 작성하고, 사내 메신저의 경우, MS Teams 를 사용하고 있다. 그리고 함께 일하는 부분과 관련하여 알아야하는 부분은 언급과 태그를 통해 공유를 진행한다. 그리고 이번 리뉴얼 프로젝트 또한 언급과 태그를 통해 해당 내용을 서로 공유하였다.

 

나는 태그와 언급이 많이 익숙하지가 않다.(핑계1) 관련된 작업을 모아두는 것을 정해둔다면 관련 부분을 지속적으로 Listen 하는 것은 담당자의 책임이고 역할이라고 생각했다.(핑계2) 그래서 결과적으로 나는 공유를 잘 하지 못하는 사람이 되어 있었고, 작업한 내용을 공유해달라고 할 때, 솔직하게 이해를 하지 못했었다. 

 

결론적으로, 이번 프로젝트를 경험하면서, 내가 공유 능력이 부족함을 스스로 많이 인지할 수 있었다. (지금을 포함한) 앞으로는 공유를 해주지 말라해도 적극적으로 공유할 것이다! 일단해! 필요한지 없는지는 상대방이 판단하도록 하자!

 

 

의사소통의 중요성

 

미팅을 진행하면서 계속해서 중요하다 느껴지는 부분이 바로 의사소통이다. 의사소통이 중요하다는 것은 누구나 다 알고 있는 사실이지만, 계속된 미팅을 진행하면서 정말 의사소통의 중요성을 몸소 느끼는 요즘이다. 상대방의 의도와 생각을 이해하는 유일한 방법은 소통뿐이다. 추측과 예측은 올바른 방법이 아님을 다시한번 마음 속에 되새기며, 소통은 정말 중요하다.

 

협업을 진행하면서, 이런 순간들이 많았다. "와 이거 이야기 안했으면 큰일날뻔했네.", "지난번에 말한 것의 의도가 이거라고 했던 것 같은데, 완전히 다르네" 등 아차, 아찔한 순간들이 많았다. 그리고 동시에 "진짜 이야기하길 잘했다." 를 많이 느꼈다. 

 

말을 하지 않으면 알수 없다. 내 마음도, 상대방의 마음도 말이다. 이건 업무적인 부분 뿐만아니라 인간관계에서도 중요한 부분이라는 생각이다. 이야기 하는 것에 대하여 부담이 없는 내 성격이 정말 다행이라고 생각이다. 지금처럼 앞으로도 이렇게 의사소통을 적극적으로 해야겠다.

 

---

목표설정

 

나는 이번 리뉴얼을 진행하면서 가장 많은 질문을 한 것은, "어떤 것을 목표로 하는 것인가?(목표는 무엇인가?)" 이다. 이 질문은 소프트웨어 팀 뿐만아니라 비즈니스팀의 팀원들에게도 물어보았다.

 

비즈니스 팀에서는 고객의 요구사항 및 피드백을 수용하고 충족되지 못한 현재 미충족된 부분(Unmeet needs)을 만족시는 것이었고, 이를 소프트웨어를 통해 이뤄내는 것이 핵심인듯 하였다. 

 

소프트웨어 팀에서는 비즈니스 요구사항을 반영하며, 궁극적으로 소프트웨어를 통해 미충족된 부분을 만족시켜주는 것이었다. 그리고 지금, 궁극적인 목표를 달성하기 위해 프로젝트의 현재 한계점을 극복해 내는 것이 목표인듯하다.

 

현재 프로젝트의 한계점은 분명하다. 현 상황에서는 작은 기능의 수정 및 신규 기능의 추가가 너무나도 어렵고, 시스템의 안정성, 테스트 가능성 등 너무나도 많은 문제가 존재한다..  그리고 나는 지금 상황이 소프트웨어의 특성(유지보수성, 확장성, 안정성 등)들이 너무나도 낮은 상태이라고 판단했다.

 

지금 현재 상황에서는 절대 회사의 목표를 달성해낼 수 없다.(시간이 무한하다면 가능하다.) 이와 관련하여 나는 프로젝트의 유지보수성, 확장성 을 가장 우선적으로 보장하는 것을 목표로 설정했다. 유지보수성 및 확장성 만을 증진시킨다는 것은 불가능하지만, 나는 유지보수성과 확장성을 가장 핵심적으로 지금 프로젝트의 리뉴얼을 진행해보고자 한다. 그리고 리뉴얼 이후로는 다양한 비즈니스 요구사항을 개발하고, 이를 안정적으로 서비스할 것이다.

 

---

정리

 

지난 한주는 정말 많은 일이 있었다. 정신차려보니 금요일이었고, 눈떠보니 주말이었다. 한주를 회고해보니 너무나도 많은 이슈들이 있었고, 이를 정리하는 것도 힘들었다. 그저 있던 일들에 대하서만 정리하는 건데 이리 힘들 일인가 싶지만, 이런 정리들들 통해 좀더 내 자신을 다듬어 가는 듯하다.

 

이번 한주는 내가 해야할 것, 하고싶은 것을 이전보다 분명하게 구분할 수 있었다. 이 과정을 통해 다가올 24년이 너무나도 기대가 된다. 지금 이 상황을 잘 극복하고 만들어냈을 때, 얼마나 많은 (개인 그리고 회사의) 목표를 달성해낼 수 있을까? 설렌다!