벌써 2022년 연말이다. 올해는 꼭 연말 회고를 써야지 써야지 하면서 마음만 먹고 계속 미루다가 2022년이 하루도 채 안 남은 이제서야 부랴부랴 자판을 두드리는 나 자신을 반성해본다.

2022년은 여러모로 내게 큰 의미가 있는 한 해였다. 기나긴 대학 생활을 뒤로하고 취업을 하게 되었으며, 취업해서 풀스택 개발자로서의 커리어를 찬찬히 다져갔다. 주어진 환경에서 최선을 다해 회사업무를 쳐내다보니 신입 개발자 치고는 기술 스택 측면에서 꽤 다양한 것을 경험해 보았다고 생각한다.

그간 걸어왔던 한 해를 일종의 달리기 과정처럼 정리해보고자 한다. 달리기에 임하기전 준비과정부터, 코스에 첫 발걸음을 내딛는 것, 그리고 속도를 높이기 전의 잰걸음에서 보폭을 넓힌 달리기. 여기에 막판 스퍼트까지 더해 종료지점까지 다다른 후의 숨고르기와 기록 체크, 다음 기록 수립의 시간들을 22년도에 내가 걸어왔던 개발 업력들을 회고하며 대입하고 정리해 보려한다.

🧎🏻‍♂️ 준비하기. IoT 회사로의 취업

21년도 10월, 한창 구로디지털단지 넷마블 사옥 내 글로벌창업사관학교에 입교한 한 스타트업에서 인턴 프론트앤드 개발자로 일을 하고 있을 때 대학 인트라넷 취업 공고에 한 회사의 소개글이 올라왔다. 학교 동문께서 대표로 있는 IoT조명 회사에서 신입 개발자를 공개채용하고 있다는 것이었다. 당시 집을 먼저 구했던 나는 회사가 집과 매우 가까운 거리에 있고, 사용하고 있는 기술 스택도 꽤 매력이 있다고 판단이 되어 부랴부랴 코딩테스트 및 면접을 준비했고 다음 년도 1월에 입사를 하는 것으로 최종합격 하였다.

회사에 대한 첫인상은 꽤 좋았다. 잡코리아와 여러 포털, 인터넷 기사를 통해 접한 회사의 모습은 나쁘지 않았고, 무엇보다 회사 주요 서비스에서 채택하고 있는 기술들이 내가 다뤄보고 싶었던 기술이었다.

• 프론트엔드: React(TS), React-bootstrap, storybook

• 백엔드: NestJS & Jest(Testing), Go, C

• DB: RDBMS(MySQL)

• 인프라: Docker, Kubernetes, AWS clouds solutions, terraform, jenkins, etc.

• 협업 툴: Github, Jira, slack, Jandi, Figma, etc.

스타트업에서 인턴으로 일하면서 React, Pure Javascript, Liquid(For Shopify) 등의 프론트엔드와 밀접한 언어 및 프레임워크, wordpress 같은 웹퍼블리셔 툴을 다루는 것에 업무가 국한되어 아쉬움이 다소 남았는데 위 기술들은 개발 도메인을 넓히고 싶었던 나를 만족시키기에 아주 충분했다. 궁극적으로 풀스택 개발자로 거듭나고 싶은 나는 이러한 기술들을 신입 레벨에서부터 경험할 수 있다는 메리트와 집과 가깝고 처우가 좋은 점 등을 감안하여 이곳에서 첫 스타트를 시작해보자 생각하게 되었다.

🧑🏻‍🦯 첫걸음. 회사 조직과 서비스의 이해

1월 3일 월요일. 첫 출근을 했을 때의 감회가 새록새록하다. 분명 21년도 하반기 인턴하면서 '회사'라는 곳이 익숙해졌다고 생각했는데, 회사라고 해도 다른 '환경'이다 보니 적응이 필요했다.

먼저 회사의 조직도가 이전 스타트업과는 달랐다. 신생 IT 스타트업은 아니다보니 사원,대리와 같은 직급이 존재했고, 비개발 부서 직원들이 대다수였다. 내가 소속된 부서는 기업내 연구소로, 조직 체계는 연구원-주임연구원-선임연구원-책임연구원-수석연구원 구조였다. IT 회사라면, 엔트리-주니어-테크리드-시니어 같은 체계일 줄 알았는데 아니었던 것이다. 또 입사한 회사가 Internet Of Things, 즉 사물인터넷 회사였기 때문에 IoT 관련 기술과 지식 이해가 필요했다.

이는 서버와 IoT 장비간 통신 규약인 MQTT 같은 프로토콜이 해당되었는데, 이외에도 Wifi, BlueTooth, Zigbee, Mesh 등 프로토콜도 연관되면서 컴퓨터 네트워크 개념의 중요성을 여실히 느낄 수 있었다. OSI 7계층 전반적인 개념들이 두루 해당되었다.

클라이언트 단에서 서버 백엔드로 요청-응답 할 때 사용되는 Application Layer의 HTTP와 HTTPS 뿐만 아니라, MQTT 프로토콜도 여기에 해당되었고 handshaking 이 이루어지는 transport layer의 TCP, IoT 장비의 펌웨어가 깊게 다루는 Ethernet, Wifi, BLE, Zigbee 등이 해당되는 1, 2 레이어(Physical layer, Data-link layer)까지 학부에서 배웠던 각 계층별 프로토콜에 해당하는 기술을 실무에서 생생하게 느낄 수 있었다.

1. 회사의 서비스 모델 파악

회사의 주력 사업은 B2B 모델과 B2C 모델 둘다 있다. 회사에서 개발, 생산하는 IoT 조명은 일반 소비자 대상 조명과 공장 및 사업체 대상 조명이 따로 있어 이에 맞게 서비스가 구현이 된 듯 했다.

회사의 스마트 조명 시스템 구축에는 기본적으로 허브라고 하여, 조명의 master 역할을 하는 클러스터가 필요하고, 여기에 여러 type의 조명들이 node가 되어 붙게 되는 구조로 되어있다.

이 허브에 wifi, zigbee, mesh 등의 firmware가 내장되면서 중개 브로커를 거쳐 서버와 MQTT 송수신을 담당하게 되고, 조명 밝기 제어 등의 명령들을 개별 조명에 전하면서 말그대로 중추(hub) 역할을 하는 것이다.

'GRiD'와 'Home Recipe'. 이들이 각각 기업 대상 서비스와 소비자 대상 서비스이고 home recipe의 경우 서버리스로, Android/iOS 네이티브 환경에서 각각 동작하는 모바일 어플리케이션 형태로 구현되었다. GRiD는 AWS 클라우드에서 FE, BE 앱이 통합 관리되는 거대한 서비스였으며, 입사 후 약 2주간의 스터디 및 온보딩 프로세스 이후 이 서비스 개발에 투입되어 본격적으로 서비스를 이해해 나갔다.

2. 서비스 아키텍처 및 응용 기술 파악

사내 깃허브에서 GRiD 프로젝트를 처음 pull 받았을 때 처음 보는 SW 아키텍처 구조와 소스의 체계성과 방대함에 맨 먼저 압도되었다. Monolithic Repository로써 FrontEnd와 Backend, CI/CD script, 인프라 관련 세팅 파일까지 하나로 통합 관리 및 구축이 되었으며, TypeScript라는 핵심 언어로 대부분이 작성되어 있었다.

앞서 언급한 기술스택들이 대부분 여기에 적용이 되어있던 것이다. 무엇보다 서비스의 일관된 아키텍처로 채택한 'DDD'가 신기하게 다가왔고, 이에 대한 학습이 시급했다.

Domain Driven Design 은 MVC처럼 소프트웨어 개발의 구조, 아키텍처 디자인 방법론 중 하나로 다양한 기업에서 위 구조를 많이 채택하고 있었다. 여기에 presentation, application, domain, infrastructure에 이르는 4 layered architecture와 어우러져 서비스의 모든 기능들이 개별 'Domain Event'로 관리되어 ubiquotous language로 작성, 공유되었다.

처음 이 DDD를 접했을 때, 그리고 이 DDD를 제대로 이해하지 못하고 소스코드를 살펴보았을 때 너무 어렵게 느껴져 '과연 실무에 내가 잘 적응할 수 있을까? 이게 기업이 몇 년 동안 구축한 결과물일텐데 다 습득할 수 있을까' 생각을 많이 했다. 그러면서도 도전정신이 생겨서 이해가 안되면 될 때까지 갖가지 노력은 다 해본 것 같다.

인수인계를 어느 정도 받은 후에 자잘한 유지보수 개발 투입과 스터디를 병행하면서 모르는 개념들은 노션으로 하나씩 정리해나갔다. 이해가 어느 정도 된 개념은 복습을 거듭, 따로 응용도 해보며 기록한 내용에 살을 더해갔다.

그 결과, 아래 사진과 같이 나만의 wiki docs 틀이 만들어졌고, 사내에서 DDD란 무엇인가를 주제로 자체 세미나도 진행해볼 수 있었다.

🚶🏻 잰걸음. 새 프로젝트 시작 및 성과

서비스에 대한 이해가 어느 정도 되었을, 그러나 아직 모르는 세계가 여전히 많구나 느낄 무렵 무더운 여름과 함께 새로운 프로젝트가 찾아왔다.

'스마트 조명 주파수 추종 기능'이라고 해서 주파수 변화에 맞게 자동으로 조명의 밝기, 전력 소모를 조절하는 기능을 개발하는 것이었고, 약 3~4개월의 개발기간이 주어졌다.

이름도 생소한 이 기능을 이해하기 위해 MQTT와 MQTT broker, Zigbee와 주파수 등의 개념을 백그라운드로 다시한번 정립하고 넘어가야했다. 그 다음 기획과 설계과정에 능동적으로 참여하여 기획&개발을 동시에 진행해야 했는데, 여기서도 많은 인사이트를 얻었다.

PRD(Product Requirement Document)를 작성하면서 기능 개발을 위해 어떤 개념과 설계가 선행되어야 하고, 펌웨어 개발자와 협업이 어떤 식으로 이루어져야 하며, 결과물과 UI는 어떻게 되는지를 주체적으로 그려나갔다. 개발자는 나와 다른 동기 개발자 이렇게 신입 둘로 이루어졌으나 동기 개발자의 군문제 등 개인적인 사정으로 나는 프론트엔드와 DB 설계 및 백엔드 API(CUD- Create, Update, Delete) 등 대부분의 초기 개발을 담당하게 되었다.

먼저 인턴 때 다루어보았던 React를 다시한번 리마인드 하는 스터디 시간을 가진 뒤 곧바로 web application에서 해당하는 기능을 붙여가기 시작했다. 연결해야 하는 API 중 Read 하는 부분은 임의의 JSON 데이터로 채웠고 update와 delete는 react hook을 활용한 상태로 클라이언트 단에서 동적으로 보이게끔 처리하고 넘어갔다.

어느 정도 UI가 완성된 이후, 그리고 틈틈히 회의와 PRD 작성을 거쳐 DB 설계를 시작했다.

당시, 서버에서 부하가 매우 큰 버그로 인해 데이터베이스에서 정보를 가져올 때 서버에 문제 생기는 이슈가 고질적으로 있었고, 취급하는 데이터의 속성이 매번 다를 수 있었으며, AWS cloud 컨퍼런스에서 들었던 분산 데이터베이스와 데이터베이스 다양화를 이제는 적용해보아야겠다 생각이 들어 MongoDB를 도입을 검토했다.

또 위 버그 발생, 그리고 백엔드 서버의 지속적인 restart로 인해 데이터의 손실이 발생하고 이는 구현해야 할 피처에서 치명적이라고 생각하였기에, kafka와 같은 event queue이자 message queue의 도입 역시 검토하였다.

그리하여 대략적인 기술 스터디 이후 mongoDB와 kafka를 도입하게 되었고, 이를 위해 docker와 kubenetes 역시 좀 더 파고들어 mongoDB와 kafka broker, zookeeper, kafka-ui 와 같은 Service를 사용하고 있는 EKS cluster에 추가하기에 이르렀다.

이는 자연스레 MSA(Micro Service Architecture) 로 향후 서비스를 확장해 나가는 데에 크게 영향을 미치게 되었다.

다시 개발이야기로 돌아가서, typeORM이라는 Database ORM 모듈에서 제공해주는 migration 기법으로 기존에 사용하는 MySQL에도 데이터베이스를 추가하고 MQTT topic 처리 로직 뿐만 아니라 Create, Update, Delete 등에 관한 모든 요구되는 기능들을 기존 DDD 흐름에 맞게 domain event로 브레인스토밍하여 구현해나갔다.

구현해야 하는 기능 중에는 mongoDB에 기록하는 실시간 데이터를 csv 파일로 생성, 다운로드 해야 하는 기능도 있는데 이를 위해 AWS S3 연결 및 사용과 데이터 파싱, 실시간 데이터 retention등을 공부해볼 수 있었다.

후에 합류하여 나머지 API Read 부분과 Infrastructure 관리(yaml 작성 및 통합)를 담당한 개발자 동료와 함께 3~4달에 걸쳐 회사에서 요구하는 기능들 개발을 기간 내 완수할 수 있었고, 전력거래소 주관 실증 검증까지 잘 완료하여 회사가 주력으로 삼고자 하는 독보적인 기술을 성공적으로 안착하게 되었다. 이는 네이버 기사에도 실리게 되면서 신입으로 처음 맡은 역할을 잘 감당해 냈구나 하는 자부심을 갖게 해주었다.

🏃🏻 달리기. 서비스 성능 개선 및 고도화

'GFDR 또는 FastDR'이라고 하는 스마트조명 주파수추종 기능 개발을 마친 뒤 곧바로 주어진 업무는 위에 언급했던 고질적인 버그 및 부하 문제를 해결하는 것이었다.

문제가 되었던 기능은 '에너지 모니터링'이라는, 우리 조명을 사용하는 기업체에 연결된 각각의 조명들이 갖는 전력량 데이터를 불특정 시간에 계속 기록해 나간 데이터를 CSV 파일로 다운 받을 수 있게 하는 기능이다. 이 기능을 위해 전임자가 데이터베이스의 몇몇 테이블에 불필요한 컬럼들을 추가하고, 정규화 하지 않은 레코드들을 하나의 테이블에 쌓음으로 단시간에 엄청 많은 쓰기와 읽기 작업이 발생하여 서버와 데이터베이스가 이를 감당하지 못해 뻗어버리는 것이었다. 게다가 조명 추가, 제어 등의 핵심 기능 까지 하나의 백엔드 서버에서 담당하는 구조였기에 다른 기능에서 부하가 발생하면 위 기능까지 사용 못하는 등 영향을 받는 아주 치명적인 문제를 야기했다. 이로써 회사가 당장 타겟으로 삼는 가용 조명 및 통신 부하 까지 절대 커버가 불가능한, 비유하자면 100% 성능 중 최소 80%는 안정적으로 처리해야 하는데 기능 제한을 통해 60%만으로 설정한 그런 상황이었고 회사의 향후 계약건 처리량 확보를 위한 대규모 서버 확장을 앞두고 개선이 시급하여 서둘러 투입이 되었다.

이번에는 PRD 작성 없이 기획 및 설계와 개발이 동시에 진행이 되었고, 맨먼저 한계치 테스트를 진행하였다. 그리고나서 문제가 되는 로직을 분석했다. 정보 전달을 위해 backend에서 axios post로 불필요하게 사용되면서 HTTP 프로토콜 위에서 동작하는 것이 부적절하다고 생각하여 전달 부분에 kafka producer-consumer 구조를 넣어야 겠다 생각하였고, 기존 하나의 테이블에 모든 request가 다 몰리는 것을 나누기 위해 request의 주체가 되는 허브의 ID별 테이블 관리가 더 적절하겠다고 판단했다.

그에 따라 대용량 데이터 처리에 적합하고 자유로운 확장과 collection-document 구조를 갖는 NoSQL 기반 MongoDB로 해당 데이터 기록 기능을 이관하고, Hub ID 별 table을 따로 두고 여기에서 document를 기록하게 되었다.

또 서버에서 전력 사용 데이터를 받는 즉시 이전 데이터를 가져와서 전력량 계산을 하고 다시 기록하는 불필요한 로직이 CSV 데이터를 다운 받을 때에만 필요하다는 것을 인식하고 서버에서 매번 하는 것이 아닌, 특정 시간에 특정 기간만큼의 전력량 계산을 한번에 하고 이를 기록하는 식으로 해야겠다고 설계를 하였다.

이를 위해 조명 등록 이후 시점부터 모든 데이터를 하나의 csv 파일로 기록하지 않고 하루치의 데이터를 기록하는 것으로 기획을 수정하였으며 이 데이터 기록만을 담당하는 Cronjob을 만들어서 서버로부터 기능을 분리하였다. 그리고나서 csv 파일은 스트림 파이프를 통해 기록과 동시에 S3에 파일을 저장하게 하고, 클라이언트에서 다운로드 요청시에는 미리 생성한 파일의 s3 경로를 내려줌으로써 다운로드 시간 역시 획기적으로 줄이게 하였다.

결과적으로 하나의 백엔드에서 모든 기능을 감당하는 monolithic 구조에서 기능별 여러 서버와 cronjob들로 세분화 되는 Micro Service Architecture로 확장되었으며 리소스 사용 최적화가 원활히 이루어져 restart 발생하나 없이 목표하는 허브 별 조명 감당 성능까지 처리하는 안정된 서비스를 구축할 수 있었다.

이 기능을 구현하기 위해 Frontend와 backend, 그리고 Infrastructure까지 더욱 방대하고 깊은 지식을 찾아보고 얻게 되었으며, 이전 프로젝트에서 도입한 kafka와 mongoDB를 유연하게 더 확장하고 분산, 관리하면서 서비스에 대한 이해도도 훨씬 높아지고 개발 역량도 한층 높아졌다.

🏃🏻🏃🏻 스퍼트. 핵심 기능 전담 개발

서비스 분산 및 최적화가 어느 정도 마무리 되었을 때는 한창 쌀쌀한 겨울이었다. 그리고 미처 쉴틈 없이 다음 업무가 주어졌는데 이는 12월 한달이라는 시간 동안 Zigbee 센서 연결을 위한 mqtt communication 부터 프론트엔드 & 백엔드 CRUD API 설계, 데이터 실시간 polling 등을 전부 개발하는 것이었다.

먼저 프론트엔드 개발에서는 일반 사업체 대상 웹과 관리자 웹 두 개의 React Application에서 서로 다른 backend 의 REST API를 연결을 위한 state store 및 repository 작성, 관련 모달 및 스타일 작업 진행을 마쳤다.

백엔드 서버에서는 관리자와 사용자 각각에서 스마트 센서를 등록, 정보 업데이트, 센서리스트와 센서 상세 정보 ViewModel 정의, 삭제 기능을 작성하였고 이와 별개로 허브와 센서 관련 송수신할 MQTT communicator 로직도 작성했다.

데이터베이스 설계도 동시에 진행되었는데, 허브로 부터 JSON format의 데이터를 받아서 DB에 저장했던 이전 방식과 다르게 이번에는 byte 정보를 받아서 data를 적절히 parsing, DB에 기록하는 것으로 바뀌어서 여기에 맞게 대응하는 것이 쉽지 않았다.

이를 위해 들어온 number에 대한 byte 배열을 공백을 포함한 string으로 DB에 data라는 attribute로 저장을 한 뒤, GET 요청에 의해 ViewModel를 만들어 뿌려줄 때 parsing logic을 거쳐 데이터를 가공, 정의해주는 것으로 하여 로직을 설계하였다. DB는 최종적으로 정규화를 거쳐 2개가 만들어졌다.

짧은 시간 내에 PRD 작성부터 데이터베이스 테이블 설계 및 정규화, FE, BE 개발, MQTT topic 개발 및 테스트 등 모든 과정을 밤낮없이 진행해왔던 것 같다. 정말 막판 스퍼트처럼 말이다....

🧘🏻⏱ 숨고르기 & 목표기록 세우기

2022 지나온 개발 업력들을 이렇게 나열해놓고 보니 길면 길고 짧다면 짧은 1년이라는 시간 동안 참 많이 뭔가를 해왔구나 생각이 든다. 기술적으로 정말 많이 성장해왔고, 컨퍼런스 참가 및 협업, 서비스 기술 스택 온전히 파고 들기 등을 통해 다양한 인사이트를 끊임없이 받아왔던 것 같다.

이쯤되면 되묻지 않을 수 없겠다.

나는 이 모든 과정을 통해 과연 무엇을 이루었나?

먼저 내가 처음 목표했던, 다양한 기술스택 접하고 이해하기는 어느정도 달성한 것 같다. 원래는 프론트엔드, 백엔드만이었지만 DBA 부재로 인한 DB 설계 참여와 infrastructure까지 해봄으로써 진정한 풀스택의 첫 start를 끊었지 않았을까 싶다. 또 입사 후 AWS 컨퍼런스, hashicorp workshop, NHN conference 등 외부 컨퍼런스 기회도 가지게 되면서 개발 컨퍼런스가 주는 인사이트가 크다는 것, 개발 세계는 되게 넓구나 하는 것을 생생하게 느낄 수 있었다.

두번째로 어떻게 공부해야 하는지와 어떻게 개발해야 하는지를 배운 것이다.
위에 직접적으로 알려줄 사수가 없다보니 하나부터 열까지 스스로 찾아보고 직접 응용을 해봐야 했다. 그렇다보니 단시간 내에 어떤 정보를 효율적으로 찾아내야하는지, 구글링을 어떻게 효과적으로 할 수 있을 지와 공식문서의 깊이있는 이해의 중요성을 확실히 체감할 수 있었다.

또 무작정 코드를 짜는 데에 급급하지 않고, 신중하게 설계를 하고 이 설계에 필요한 백그라운드 사전지식을 충분히 습득, 이해하고 필요에 따라 다른 개발자들과 토론, 미팅으로 협업하는 것의 중요성도 알 수 있었다. 주니어 개발자라는 타이틀에 나 자신을 한계 짓지 않고 체계적이고 실력 있는 개발자가 되기 위해 고민하고 노력했던 것 같다.

마지막으로 성장과 합당한 성과이다.
프론트엔드 개발 하나만에도 급급하던 내가, 연말이 되어 막판 스퍼트를 달릴 때 짧은 기간 내에 프론트엔드와 백엔드, 그리고 인프라 까지 도메인을 넘나 들며 혼자서든 개발을 해낼 때, 그리고 그것이 실제로 좋은 결과물이 되어 모두를 만족시켰을 때 '아 내가 성장했구나'를 크게 느낀 것 같다.

작년 한해 깃허브 contribution 수가 600 여개 남짓이었다면, 2022년 한 해에는 약 1200개로 두배 가량 많은 기여를 했고, 프로젝트 투입 후 1년 만에 최다 contributor로 기록을 할 수 있었다.

단순히 양적으로 커밋과 PR 수를 늘렸다고 할 수 있겠지만, 내가 몸 담는 소프트웨어팀이 지향하는 agile development에 맞게 잘 따라왔다고 생각한다.

2023년도에는 그래서 뭘 할거야?

1. 개발 관련 서적 2권 이상 읽기

작년 2022년에는 개발 관련한 서적을 한권도 제대로 끝내지 못한 것 같다. clean code나 DDD 관련 책, 심지어는 그냥 기본적인 언어/프레임워크 자습서도 있을텐데 일이 바쁘다는 핑계로 다소 소홀했다.

2023년에는 최소 클린코드 책 하나는 읽고, 이후에는 React 관련 서적이나 NestJS 관련 자습서라도 하나 읽고 기록해야겠다.

2. 2022년에 배운 내용 활용하여 풀스택 앱하나 완성하기

사이드 프로젝트로 하나 하는 것은 늘 생각만 하고 제대로 실천하지 못했던 것 같다. 주니어급 개발자들이 기본적으로 많이 개발하는 편지 전달 앱, 심리테스트 앱이나 고유 블로그 하나 정도라도 남겨보자. 조금씩 조금씩 진행하다보면 다뤘던 내용 복기 겸 체화도 되고 깃허브 1일 1커밋 운동도 자연스레 달성하고 있지 않을까? 2023년에는 2023 total contribution을 목표로 달려가도 좋겠다.

3. 사내 세미나 2개 이상 열기 & 외부 컨퍼런스 2회 참석

컨퍼런스와 세미나 역시 개발자가 성장하는데에 있어 크게 도움을 줄 수 있다고 생각한다. 개발만 잘한다고 되는 것이 아닌, 어떤 것을 개발했고, 개발을 위해 요구되는 지식을 내가 얼마나 이해하고 있는지를 다른 사람들과 공유하는 것도 바람직한 자세라고 생각한다.

---

우선 위 세가지만 잘해도 이번 2023년은 2년차 개발자로서의 발걸음은 꽤 묵직할 것이다. 개발 외적으로 바디프로필 찍기, 배드민턴 배우기, 공인 영어 성적 갱신하기 등 목표도 있는데 이번 2023년에는 120% 중에 100퍼센트를 다한다 생각하고 임해보자. 그렇게 해서 다음 2023년 회고를 기록할 때 흐뭇하게 써내려가는 나자신이 되길 나지막히 바라본다.