2023년이 끝나갈 시기이다. 올해를 슬슬 마무리하면서 올해동안 무엇을 학습했으며, 앞으로 내가 나아가야할 "학습" 방향성에 대해 회고해보고자 한다. 학습 회고 외의 다른 내용들은 온전히 생략하고, 따로 회고를 진행해볼까한다.
평생 학습기반을 가꾸기 위해 노력한 글쓰기
나는 지금까지 그 어떠한 교육기관의 도움없이 독학으로 나만의 개발 철학, 공부법을 만드는데 묵묵히 많은 시간을 투자했다. 웹 프로그래밍을 처음 시작한지는 약 1년 반이 넘어가는 중이며, 자바 프로그래밍을 공부한지는 1년 조금 넘은듯하다.
하루도 빠짐없이 카페, 도서관에 가서 글쓰기, 사이드 프로젝트에 그 누구보다 열심히 몰입했던 것 한 해였다.
책임감 있는 블로깅 : 설명하기의 학습효과와 능동적인 공부법 로 올해의 첫 글쓰기를 시작했다. 난 메타인지를 실천하기 위한 최고의 학습법으로 블로깅만큼 최고인 것이 없다고 굳게 믿는다. 처음에는 서투른 글쓰기였지만, 정말 많은 시간을 학습법을 가꾸는데 투자하니 어느새 글쓰기 속도와 학습 내용에 대한 이해도, 기억률이 꽤나 향상되었다. 이 학습법을 정립하는데 까지 동아리 선배 로 부터 도움을 받고 기반을 다질 수 있었다.
남을 위해 공유하는 습관을 길들인 글쓰기가 곧 나를 위한 것이다. 위에서 다룬 공부법을 더 발전시켜서, [회고] 글쓰기가 정말 나에게 도움이될까? 에서 개선된 공부법에 대해 새롭게 다루었다. 배움을 글쓰기로 인출하는 것이다.
하나의 지식을 습득하는 과정은 매우 고통스러워야 한다. 가만히 책과 인강을 듣는것으로 안일하게 학습을 끝내선 안된다. 또한 인간은 망각의 동물이다. 이 공부법의 기원은 미국 버즈니아 NTL 연구소의 논문 결과에 기반하여 발전시킨 것이다.
다만 내 블로그도 앞으로 어떻게 관리하고 다듬어야 할지에 대한 회고 내용이 가득한데, 자세한 내용은 별도로 다루도록 한다. 이런 방법으로 많은 글들을 쌓아왔는데, 그 중 인상깊게 기억이 남는 토픽 몇가지에 대해서만 즐겁게 회고해보고자 한다.
동시성 이슈 제어
가장 먼저 떠오르는 것은, 동시성 문제에 대해 많은 학습과 고민이 있었다. 사이드 프로젝트에서도 동시성 문제가 발생할 가능성이 충분히 존재했었고, 이와 관련한 다양한 동시성 제어 기법에 대해 익힐 필요가 있었다. 프로젝트에 적용하는 기법 외에도 다양한 락 메커니즘에 대해서도 학습했었다.
Redis
가장 먼저 떠오르는 내용은 [Redis] 분산락(Distribution Lock) 을 구현해 다중화 서버에서 발생하는 동시성 문제 제어하기 에서 다룬 내용이다. 이떄 Redis 를 단순히 캐싱의 용도를 넘어서 동시성 제어에도 활용할 수 있고, 위와 같이 Kafka 처럼 (당연히 둘은 많이 다르긴 하지만) 메시지브로커 로도 활용 가능하다는 것에서 정말 신기했었다. Publisher 와 Subscriber 서버를 배치하여 높은 확장성, 고가용성을 갖는 구조를 만들 수 있다는 점을 알게되었다. 이러한 Redis 의 Pub/Sub 관련 내용은 [Redis] 분산 시스템에서 Pub/Sub 메시지브로커를 활용한 다중 로컬캐시 동기화 에서 다루었다.
이때 막연하게 CS 의 중요성도 깨달았다. 항상 수업으로만 듣던 전공 수업 내용들이 어떻게 적용되고, 왜 중요하다는 것인지 의문이 가득했었다. 동시성 이슈를 제어하기 위한 기법들이 나에게 처음으로 CS 의 필요성을 깨닫게 해준 토픽이었다.
다양한 락 메커니즘 ( 분산 락, DB 락, 낙관적 락, ... )
Redis 의 분산락 외에도, 이 토픽을 내 머릿속에 온전히 채화하기위해 많은 부가 지식들이 필요했고, 다양한 동시성 기법들에 대해 공부할 필요가 있었다. 때문에 JPA 단에서 제공해주는 낙관적 락(Optimisstic Lock), 비관적 락(Pessimistic Lock) 을 처음 접했는데, 단순히 스프링부트 프레임워크의 근본.핵심적인 지식을 넘어서 프레임워크가 정말 다양한 케이스를 고려해서 잘 만들어졌다는 것을 체감했다. @Version, @Lock 같은 어노테이션을 통해서 제어가 가능하다니.. 이걸 만든 사람들은 정말 천재라는 것을 느꼈다. 난 아직 우물 안 게구리이다. 아직 배워나갈 내용들이 산더미라는 것을 체감했다.
MySQL 의 네임드 락(Named Lock) 에 대해서도 공부해보면서, 분산락과 일반적인 DB 락 기법의 차이점에 대해서도 정리했었다. 이 과정에서 JPA 의 NativeQuery 의 존재를 처음 알게 되기도 했다.
다만 아쉬운점은, 아직 100% 체화시키지 못했다는 것을 느꼈다. 사이드 프로젝트를 진행하는 과정에서 락 기법에 대해 잘못 이해를 하면서 팀원들과의 소통에서 어려움을 겪은 일화가 있다... 나만의 지식으로 더욱이 습득할 필요가 있다.
위와 같은 지식들을 이해하기 위해, 원초적인 근본 지식인 트랜잭션의 격리수준과 전파, ACID 에 대해서도 공부하면서 DB 에 대해서도 실무적인 관점에서 필요에 의해 이론 지식을 공부하게 되었다. 사실 이번 1학기 수업때 학교 DB 수업을 들으면서 ACID, 트랜잭션, 인덱스, 정규화, ... 등을 배웠다. 그때만 해도 왜 이런걸 내가 왜 배워야하나라는 무식한 생각을 했었는데, 이렇게 공부했던 CS 지식들이 실제 개발에서 활용할 줄은 몰랐다.
자바의 동시성 제어 키워드 들도 학습했다. synchornized, atomic 변수, volatile 등 여러 키워들에 대해 꼼꼼히 차이점, 활용 상황을 정리해봤다. 이들을 왜 잘 활용하지 않는지, 특히나 왜 분산 환경에서 사용하기에 부적합한지도 알 수 있었다. 추후 학교 OS 수업을 들을때 CAS 알고리즘 을 접했을때 너무나도 반갑기도 했다. CAS 알고리즘이 내부적으로 이렇게 구현되는구나..! 유레카! 라는 느낌이었다.
이러한 에피소드로 점차 하나씩 시야가 넓어지는듯한 느낌을 받았다. 또한 이런 경험을 통해 맹목적으로, 수동적으로 지식을 이유없이 주입하는 습관에서 한층 벗어날 수 있게 되었다.
날 힘들게했던 하이리스크 프로젝트
올해 사이드 프로젝트를 진행하는 과정에서 많은 트러블슈팅을 만났다. 아주 간단한 CRUD 구현만 가능했던 내가 특정 도메인 개발을 맏게 되었고, 개발을 위해 필사적으로 방대한 지식들을 습득해야했다. 무엇보다 모놀리틱 아키텍처 에만 익숙했던 내가 헥사고날 아키텍처 환경에서 개발을 진행하니, 이떄만 떠올리면 정말정말 프로젝트에 적응하는게 많이 힘들어했었다. 부족한 나였던만큼, 허겁지겁 던져지는 키워드들을 밤을 새우며 미친듯이 공부하고, 개발에 몰입했던 기억이 남는다.
MSA.. 헥사고날 아키텍처.. 멀티모듈.. 애자일 .. 그게 다 뭔데 😭
뿐만 아니라 프로젝트가 멀티모듈 구조를 취하고 있었다. MSA 로 확장하기 쉽도록 이것저것 체계를 갖추고 있었다. MSA 는 Monolithic 아키텍처와 달리 다중 모듈간의 순환 참조 구조, 의존관계, 패턴, 설계가 한 눈에 파악하기 정말 정말 힘들다. 어댑터와 포트는 어떻게 적용하고, 모듈간의 참조를 어떻게 설계하고 파악해야할지... 지금 다시 떠올려봐도 정말 막막했다. 이 많은 아키텍처 관련 지식을 습득하고, 담당한 도메인 및 요구사항에 대한 이해를 빠삭하게 이해하고.. 애자일 프로세스에 대해 이해하고... 머리가 지끈지끈 했다. 요구사항, 기능 명세서를 어떻게 구체화시키고, Tech Spec, 스크럼을 어떻게 구체화하여 팀원들에게 공유해야 할지, 또 어떻게 설득시킬지 많은 생각을 해야했다. 난 경험이 매우 적은 상태인 초보였기에, 무엇을 모르는치 조차도 모르는 바보였다. 많이 우왕자왕했던 시기였다.. 😓
높은 난이도의 도메인 개발, 극단적인 상황 가정
프로젝트에 유저도 좀 있는 편이었다. 사실 그래서 부담이 정말정말 컸다. 비즈니스 로직을 조금이라도 잘못 설계했다만 모든 책임은 나에게 돌아올 수 밖에 없기에, 정책을 꼼꼼히 체크하고 명세서를 작성해야했다. 그래서 스트래스를 많이 받지 않았나 싶다. 사이드 프로젝트 치곤 규모가 매우 컸기 때문에.. 🤔 자그마한 스타트업 규모로 생각하면 좋을듯하다.
프로젝트 자체가 맨 처음에 합류한 후 겉보기엔 단순해 보였지만, 요구사항 및 정책이 정말 복잡하고, 얽히고 꼬인게 많았다. 또한 사소한 것 하나까지 극단적으로 최악의 상황을 가정해야 하는게 많았다. 가령 서비스는 대한민국 내에서만 유저가 있는게 아니였다. 중국, 미국, 홍콩, 프랑스, 터키, ... 등 많은 국적의 사람들이 있었고, 타국에서 서비스를 이용할 떄 고려해야 할 비즈니스 정책들이, 고려해야 할 요소들이 너무 많았다. 단순 정책을 넘어서도 인프라는 어떻게 구축해야할지, 순간 특정 리전에서 트래픽이 몰길 경우 어떻게 대처해야할 것인지, 다중 디바이스로 다른 리전에서 로그인을 시도할 경우 어떻게 로직을 설계한 것인지 등 꽤나 큰 하이리스크였다.
몰론 내가 많이 경험을 가진 사람이었다면 얘기가 정반대였을 것이다.
또한 클린 아키텍처 의 등장배경부터 도입 이유, 아키텍처의 세부 구성요소 (UseCase, Adpater, Port, Entity 등) 의 낯선 개념을 내것으로 만드는데까지 많이 고생했다. 이 과정에서 객체지향, 디자인패턴의 중요성을 다시 깨닫게 되었다. 진짜 아무것도 몰랐을 땐 SOLID 가 스프링 Bean 컨테이너를 개발할 때만 도입되는 개념이라고만 알고 있었는데, 이는 큰 오산이었다. 클린 아키텍처를 비롯한 수많은 이론들이 결국 객체지향으로 귀결된다.
가장 못하는 사람이 되라
이 힘든 과정을 포기하고 벗어날까도 엄청 고민했었다. 하지만 묵묵히 버텨낸 결과, 아직 남에게 설명할 수 있을 정도는 절대 아니지만 병아리 정도는 된듯하다. 너무 못한다는 부족함을 느낀탓에, 하루에 순수 프로그래밍 시간으로 14시간 이상을 투자했었다. 밥먹는 시간도 최대한 줄여갔다. 원래 혼자 식사를 할때 유튜브를 보면서 여유 생활을 즐기는데, 이때는 이런 생활도 없이 밥을 먹으면서 도메인 개발 및 기술적 이슈에 대한 고민이 머릿속에 가득했다. 다행히도 이런 극단적인 연습괴 성장하고 싶은 절실한 마음을 통해 많이 성장할 수 있었다.
사실 올해에 학술 동아리 운영진도 병행했었는데, 나조차도 바쁘고 힘든 심정에 부원들을 챙겨줄 마음이 없었다. 나름 도와주려고, 시간을 투자해야겠다고 생각은 조금 했지만 채력이 많이 빠져서 잘 못 챙겨준거 준 것 같다. 동아리 세션떈 Django 를 기반으로 진행했기에, 열심히 공부해서 도움을 줘야겠다! 라고 생각해도 ... 흠 세션은 매주 2일밖에 없겠지만 이것조차 내겐 너무 큰 부담이었다. 당시 새벽 34시경쯤이 되서야 겨우 잠자리에 들고 78시쯤에 기상하기를 반복했다. 동아리 부원들에겐 더 신경을 써주지 못해 조금은 아쉬운 마음이 있다.
이와 관련한 나의 극복 에피소드와 비슷하게, 자바지기 박재성님이 많은 사람들에게 응원의 메시지로 전달하는 포스트를 최근에 봤다. 가장 못하는 사람이 되라 : 박재성님 씀 글을 보면, 박재성님은 가장 빠르게 효과적으로 성장하기 위한 방법은 역량이 뛰어난 개발자들과 함께 하는것이라고 말한다. 이 글을 보자마자 크게 공감할 수 있었다.
어제보다 나아진 나만을 바라보자
가장 못하는 사람이 되는 환경에 처했을때, 빠르게 효과적으로 성장할 수 있다. 나는 이 말을 경험을 통해서 이미 굳게 믿는다. 하지만 이 점에서 주의해야 할 점은, 타인과 나를 비교하는 것은 당연하고 자존감이 떨어질 수 밖에 없다는것이다. 어느 그룹에 속해있던, 어떤 사람들을 만나던 어제와 오늘의 나만의 비교하자. 꾸준한 페이스로 나를 바라보며 발전하는 것에 집중하자. 타인과 나를 계속 비교한다면, 언젠간 분명 크게 번아웃이 찾아올 것이다.
고가용성을 위한 MySQL InnoDB 아키텍처
데이터베이스 Replication 을 통한 쿼리 성능 개선
한편 MySQL 의 아키텍처 구조에 대해서도 꽤나 깊게 학습했었다. 데이터베이스 클러스터링(Clustering) 과 샤딩(Sharding) 을 학습했으며, 파티셔닝(Partitioning) 을 학습하며 어떻게 데이터베이스의 고가용성을 높일 수 있을지에 대해 학습한 적이 있다. 아직 프로젝트에는 적용해보지 못했지만, 현 프로젝트 구조상 언젠간 반드시 적용될 키워드들이다.
무엇보다 데이터베이스 레플리케이션 을 적용하는 과정이 가장 험난하면서도 즐거웠다. Master 서버는 Read Only 로, Slave 서버는 Write Only 로 배치하는 방식이었는데, 스프링부트의 Multi DataSource 라우팅 환경을 구축하는 과정이 많이 어려웠다.
또한 레플레케이션을 이해하고 구축하려면 Master-Slave 토폴로지 구성 방식 에 대해 선수 지식으로 빠삭하게 이해해야했다. 바이너리 로그 기반 복제 방식이 눈에 보이지 않는 추상화 개념이여서 이해하기 힘들었다. 하지만 여러번 정리한 내용을 읽어보고 글쓰기로 인출하니, 다행히도 지식을 내 것으로 만들고 라우팅 환경을 구축할 수 있었다.
인덱스(Index)
인덱스 공부하는 과정도 너무 재밌었다. 내가 진짜 "찐" 실력 개발자가 된 것 같았다. 아무래도 인덱스가 DB 쿼리 성능의 최적화 와 가장 밀접하고 중요한 키워드여서 그런듯 하다. "쿼리 성능을 35초에서 0.06초 개선했다" 와 같은 표현을 보면 너무 멋지다. (간지가 철철 흐르는 개발자가 된것같다!)
처음 인덱스를 접했을떄는 너무 어려워서 이해가 가지 않았다. 하지만 끝까지 지적 호기심을 해결하고자 하는 굳은 마음으로 끝내 내 지식으로 만들었다. 구글링을 통해 최대한 여러 인사이트를 참고하고, 도저히 이해가 가지 않는 부분들은 동아리 선배에게도 카톡으로 계속 질문하며 궁금증을 해결했었다.
[MySQL 8.0] MySQL 에서 B+ Tree 인덱스 스캔을 통한 성능 최적화 방식 (Index Scan) 에서도 다루었듯이, 인덱스에 대해 나름대로 깊이 학습했던 경험이 있다. 커버링 인덱스, 인덱스 레인지 스캔, ... 등등에 대한 특정 상황에 적합한 인덱스 스캔 방식을 실행계획(Execution Plan) 을 통해 직접 확인했었다. 이 과정에서 옵티마이저(Optimizer) 에 대해서도 공부하면 좋겠다는 생각이 들었는데, 향후 이 키워드를 깊게 다루어볼 예정이다.
이렇게 인덱스의 스캔 방식을 공부하니, 자연스레 등장한 키워드가 바로 클러스터링 인덱스, 논 클러스터링 인덱스 였다. 이 글쓰기를 통해 데이터베이스의 PK 로 어떤 타입을 지정하는 것이 좋은지에 대해 나름의 기준을 만들 수 있었다. 비슷한 맥락으로 카디널리티(Cardinality) 에 대해서도 학습하면서, 보편적으로 알려진 인덱스의 적용 기준을 정리해볼 수 있었다.
Blue/Green 무중단 배포 아키텍처 수동 구축
무중단 배포 아키텍처에 대해서도 너무너무 재밌게 공부했었다. 무중단 배포 아키텍처의 다양한 배포전략 (Rolling, Blue&Green, Canary 배포에 대해) 에서 이론적으로만 다루었던 내용을 플러그인에 의존하지 않고 직접 수동으로 구축했었다. 블루 서버와 그린 서버를 배치해두고, 재배포가 발생할때 마다 리버스 프록시의 포인터를 매번 바꾸는 방식이다. 이 과정에서 10초에 1번의 주기로 헬스채킹의 과정도 일어난다.
다운타임(Downtime) 을 완벽하게 제거할 수 있을까? : Nginx Graceful Shutdown
지금껏 어려운 이론들을 깊게 공부했었지만, 이만큼 집요허게 파고들었던 큰 주제는 절대 없었던 것 같다. 무중단 배포를 구축하는 과정에서, 의문이 들었던 점은 주어진 환경에서 "과연 다운타임을 0.000초로 완벽히 만들 수 있을까?" 였다. 이에 대해 결론내렸던 것은, "다운타임은 완벽히 제거할 수 없다" 는 것이다. 더 자세히 결론 내렸던 내용을 요약하면 아래와 같다.
- Nginx Graceful Shutdown 은 표현히 모호하다. 우아한 종료라는 표현은 충분히 오해할 소지가 있다.
- 무중단 배포에 "가까워지기" 위해선, 워커 프로세스나 기타 옵션에 대한 튜닝을 통해 가능할 것이다.
위와 같은 결론을 증명해내기 위해서 온갖 몸부림이 있었다. 진짜 머리가 너무 아팠다. 다행히도 포기하지 않는 굳은 각오를 통해서 증명 가능했었던 것 같다. 처음에는 막연하게 SpringBoot Graceful Shutdown 를 적용하면 "당연히도" 다운타임이 제거될 줄 알았지만, 기대와 달리 다운타임의 제거는 불가능했다는 점에서 의구심을 품고 다운타임을 제거하기 위한 시행착오가 많았다. 여러 개선 과정을 통해, 다운타임을 약 0.02초로 대폭 감소시키는데 성공했다. 또한 TCP 커넥션 처리 문제로 인해 발생한다는 것을 증명해냈었다.
N+1 문제, BatchUpdate 통한 쿼리 성능
이 외에도 사이드 프로젝트를 진행하면서 JPA 의 N+1 문제를 직접 마주쳤다. 이를 해결하도록 JdbcTemplate 의 벌크연산을 통해 쿼리 성능을 개선했던 경험도 정말 재밌었다. 이 과정에서 근본적인 기초 지식인 영속성 컨텍스트, 지연로딩과 즉시로딩의 중요성을 몸소 꺠달았다. 또한 아직 ORM 이 해결하지 못하는 SQL Mapper 의 필요성에 대해 다시금 되짚어볼 수 있었다.
옛날에 인강을 들으면서 이들이 왜 중요하다는건지 도무지 이해가지가 않았었는데, 역시 직접 트러블슈팅을 만나서 이론을 보충하니 왜 중요하다는지 알 수 있었다. 이 과정에서 야생형 학습법 이 나에게 얼마나 잘맞는 방식인지를 알 수 있었다.
지금까지의 학습 및 프로젝트 관심사를 살펴보면 난 확실히 최적화, 자동화에 관심이 많다. 성능을 개선하고, 자동화를 통해 불편함을 감소시키는 것이 정말 즐거운 키워드다.
감사하게도, 나에게 컨텍을 주신 여러 회사들
이렇게 다년간 꾸준히 블로그를 운영한 결과, 나에게 메일로 좋은 컨텍을 주신 회사들이 몇 있었다. 이렇게나 대단한 회사나 그룹에서 나에게 교육과 컨설팅을 받고자 연락을 주시다니, 독학으로 개발을 시작한지 (컨텍 메일을 받았던 당시 기준) 1년도 안된 학부생인 나로썬 당황스럽기도 했지만, 잊지 못할 소중한 경험이었다.
성장이 지체되어 있다고 생각이 들때, 내 장점을 찾고 자신감을 되찾을 수 있는 가장 정량적인, 객관적인 지표라고 생각한다.
앞으로 어떻게 학습할 것인가?
지금껏 내가 원하는 공부만을 학습하는 것에 집중해왔으며, 특히 올해의 경우 나만의 프로그래밍 공부법을 만드는데 집중했다. 앞으로 나는 어떤 방향성과 목표를 가지고 학습해 나가야할까? 이에대한 상세한 방안, 계획, 생각등은 지금은 생략한다. 지금에선 대략적인 방향성만 잡아두는것을 목표로 둔다.
추후 깊은 회고에 따라 생각이 변할 수 있기에, 현 내용이 그대로 실천되지 않아도 괜찮다.
고수준이 아닌, 저수준을 깊이있게 학습해야 할때
지금껏 고수준을 지양하고 다짐해왔지만, 근본적이고 핵심적인 기술에 막힐떄가 많았다. 이를 알면서도 항상 등한시했다. 이젠 깊이있는 학습이 정말 절실히 필요할 떄이다. 근본부터 시작하여, 깊이있는 학습을 이어가보자. 어떤 학습 경로던 좋다. 아직도 매우 중요한 근본 지식들에서 구멍이 난 것들이 많다.
그렇지만 사실 고수준에 대해서 학습하고 싶은 리스트와 욕심은 많고도 많다. 막연하게 적어보자면 MSA, Circuit Breaker 패턴, DDD, 클린 아키텍처, 헥사고날 아키텍처, Apache Kafka, K8S, Redis, Elastic Search, Kibana, LogStash Github Actions, Grafana, Prometheus, ... 등이 있다. (사실상 이들 중에서 이미 학습한 것들이 대부분이긴 하지만, 아직 깊게 파고들며 학습 한것이라고는 못 느낀다.) 너무너무나도 공부하고 싶지만... 욕심을 잠시 접어둘때다. 좁은 범위 내에서 깊이있는 학습을 통해, T자형 인재가 되는데 집중해보자. 지금 내 상황에선 T자형 인재가 되기에 최고의 적기라고 생각한다.
블로그
이에 관한 자세한 내용은 별도로 다루겠다.
글쓰기, 프로젝트의 비율
이 또한 추후 자세히 다루겠다.
책을 최대한 많이 읽기
위 생각 및 계획들보다 훨씬, 이번 회고중에서 가장 중요하다고 생각하는 것이다. 막막하고, 무언가 풀리는것이 없고, 현실적인 조언을 구하고 싶다면 책을 통해 해답을 찾아보자. 책만큼 빠르게 답을 찾을 수 있는 수단은 결코 없을것이다.
이 또한 자세히 회고하겠다.
나 자신에게 더 솔직해지자
내 감정에 대해 더 진솔해질 필요가 있다. 이에대한 내용은 따로 회고를 쓰도록 한다 🙂
마치며
앞으로도 내 장점이 무엇인지를 다시 되짚어보며, 항상 감사하고도 소중했던 것들을 기록해보자. 아직 자세한 회고 및 계획 내용중 정말 소수에 내용에 대해서만 다루었다.
타이탄들이 말하듯, 나는 공격적인 성향의 작은 타이탄이 되고 싶다. 매 순간순간 작은 하나라도 감사하며 행복한 삶을 살아보고 싶다. 나만의 주체적이며 매력적인 길을 걸어보고 싶다. 또한 안테암불로의 길을 걸어봐야겠다. 모두가 인정받지 못하고 분노할 때, 나만큼은 안테암불로의 길을 갈 것이다. 미래의 큰 자산이 되는 호의와 신용의 잔고를 쌓아두어야 겠다. 🙂
2024년엔 내가 정말 멋지게 성장해있기를 바란다.