[회고] 2026년 상반기 - 자기 자신에게 이르는 길

 

들어가며 

예전에는 열정을 쏟을 직업이 있는 사람이 부러웠습니다.

 

상황이 어렵고 마음의 여유가 없을 때도 눈길을 끌었던 것은 돈을 많이 벌었다고 자랑하는 사람이 아니라, 자신의 일을 이야기할 때 눈빛이 달라지는 사람이었습니다. 누가 시키지 않아도 더 잘하고 싶어서 계속 배우고 고민하는 사람을 보며, 나에게도 언젠가 저렇게 마음을 쏟을 수 있는 일이 생길까 생각했습니다.

 

시간이 흘러 개발자가 됐습니다. 출근길에 자연스럽게 어제 해결하지 못한 문제를 떠올리고, 누가 시키지 않아도 더 나은 방법을 찾고 있는 나를 발견하면서 적어도 예전의 내가 바라던 것 하나는 얻은 것 같습니다.

 

그러면서 무엇이든 많이 해내는 사람보다, 내가 의미 있다고 생각하는 일을 잘하는 사람이 되고 싶다는 생각도 하게 됐습니다.

 

그런 마음이 커질수록 앞으로 어떤 개발자가 되어야 하는지에 대한 고민도 많아졌습니다. 어떤 문제에 더 깊이 시간을 써야 할지, 무엇을 잘하는 개발자가 되어야 할지, 몇 년 뒤에는 어떤 역할을 하고 있어야 할지 정답을 빨리 찾아야 좋은 커리어를 만들 수 있을 것 같았습니다.

 

그러다 이동진 평론가의 “하루하루는 성실하게, 인생 전체는 되는 대로”​라는 말을 다시 생각했습니다.

 

먼 미래의 답까지 지금 정할 수는 없지만, 오늘 내가 어떤 일을 선택하고 어떤 문제에 마음이 가는지는 돌아볼 수 있습니다. 하루하루 그런 선택을 반복하다 보면 내가 무엇을 중요하게 생각하는 사람인지, 어떤 방향으로 가고 싶은지도 조금씩 알게 되지 않을까 생각합니다.

 

지난 6개월 동안 해결했던 문제들과 그 과정에서 새롭게 알게 된 욕망을 돌아보며, 나는 어떤 개발자가 되어가고 있는지, 그리고 자기 자신에게 이르는 길을 잘 걷고 있는지 정리해보려고 합니다.

 

 

 

 

 

---

 

 

 

 

 

어떻게 더 잘할 것인가

올해 《함께 자라기 - 애자일로 가는 길》을 읽으며 많은 문장을 메모했습니다.

 

특히 기억에 남았던 것은 뛰어난 사람을 뽑는 것만큼이나 그 사람이 일하는 시스템과 문화가 중요하다는 내용이었습니다. 아무리 훌륭한 사람도 좋지 않은 시스템에서는 역량을 제대로 발휘하기 어렵고, 반대로 좋은 시스템은 사람의 능력을 더 잘 발휘할 수 있도록 돕습니다.

 

예전에는 좋은 개발자가 되는 방법을 비교적 단순하게 생각했습니다. 더 많은 기술을 알고, 더 많은 문제를 해결하고, 다른 사람이 풀기 어려운 문제까지 해결할 수 있는 사람이 되고 싶었습니다. 하지만 일을 할수록 조금 다른 종류의 문제에서 더 큰 재미를 느끼고 있다는 것을 알게 됐습니다.

 

내가 데이터를 대신 뽑아주는 것보다 사람들이 직접 데이터를 볼 수 있게 만드는 것.

내가 배포를 잘하는 것보다 누구나 안전하게 배포할 수 있게 만드는 것.

내가 장애를 빠르게 해결하는 것보다 장애가 커지기 전에 발견하고 회복할 수 있게 만드는 것.

 

《함께 자라기》에서는 조직의 일을 A, B, C 작업으로 구분합니다. A가 제품과 서비스를 직접 만드는 일이라면, B는 그것을 더 잘하기 위한 시스템과 프로세스를 만드는 일입니다. C는 한 단계 더 나아가 개선하는 방식 자체를 개선하는 일입니다.

 

이번 반기를 돌아보니 A 작업뿐 아니라 B와 C에 가까운 문제를 많이 해결하고 있었습니다.

 

 

 

 

 

---

 

 

Step Functions를 활용한 정산 자동화

문제 정의

서비스가 성장하면서 연동하는 제휴사가 늘어났지만, 제휴사마다 판매 데이터의 형태와 정산 방식이 달랐습니다. 새로운 제휴사가 추가될 때마다 별도의 처리 로직이 필요했고 일부 과정은 특정 개발자의 경험과 수작업에 의존하고 있었습니다.

처리 성능에도 문제가 있었습니다. 기존 판매내역 업데이트 과정의 N+1 문제로 특정 제휴사의 데이터를 한 번 업데이트하는 데 약 15~20분이 걸렸습니다.

 

문제 해결

먼저 반복적으로 실행되던 쿼리를 개선해 특정 제휴사의 판매내역 업데이트 시간을 5초 이내로 줄였습니다. 이후 제휴사마다 다르게 관리되던 필드와 데이터의 의미를 분석해 공통 스키마와 처리 규칙으로 정리했습니다. Step Functions와 Lambda를 활용해 판매 데이터 수집부터 가공, 예상 수익 반영까지 이어지는 과정을 하나의 워크플로우로 구성했습니다.

 

결과

특정 제휴사의 판매내역 업데이트 시간을 약 15~20분에서 5초 이내로 단축했습니다. 제휴사별로 다르게 존재하던 판매·정산 처리 방식을 공통 구조로 통합해 12개 제휴사의 판매내역 업데이트를 자동화했습니다. 이를 통해 기존 주간 단위였던 수익 반영을 일별로 전환할 수 있는 기반을 마련했습니다.

 

 

 

 

 

 

ECS 배포 환경과 CI/CD 개편

문제 정의

기존 백엔드 프로젝트는 여러 Repository로 나뉘어 있었습니다. 공통 코드와 DB Schema가 여러 곳에서 관리되면서 변경의 영향 범위를 확인하기 어려웠고, 배포 역시 스프린트 마지막에 여러 변경 사항을 모아 진행하는 경우가 많았습니다. 인프라 구성에도 수동 작업이 많았고 일부 과정은 특정 개발자의 경험에 의존하고 있었습니다.

 

문제 해결

여러 Repository를 모노레포로 통합해 공통 코드와 실행 방식, Schema 관리 규칙을 하나의 구조에서 관리하도록 변경했습니다.

Terraform을 이용해 주요 인프라를 코드화하고 ECS를 기반으로 배포 환경을 재구성했습니다. Rolling Update와 Health Check, Rollback, Deployment Circuit Breaker, Auto Scaling 등을 적용하고, 정상적인 배포뿐 아니라 새로운 애플리케이션이 실행되지 않거나 Health Check가 실패하는 상황도 직접 테스트했습니다.

 

결과

DevLake의 DORA Metric 기준 월 약 5회 수준이던 배포 횟수는 월 90회 이상으로 증가했고, 평균 PR Merge 시간을 약 4.3일에서 0.79일까지 단축했습니다. 수동으로 1~2주 정도 필요했던 인프라 구성은 Terraform을 통해 명령어 한 번에 재현할 수 있게 됐고, 인프라 구조를 개선해 연간 약 4,200만 원 수준이던 비용도 약 2,700만 원까지 줄였습니다.

 

 

 

 

 

 

 

 

 

기존 데이터를 활용한 통합 검색 구현

문제 정의

세시간전에서 제휴링크를 생성하려면 크리에이터가 각 제휴사에서 원하는 상품을 직접 찾고 URL을 가져와야 했습니다. 특히 서비스에 처음 들어온 크리에이터에게는 어떤 제휴사를 이용해야 하는지, 어디에서 상품을 찾아야 하는지부터 익혀야 했기 때문에 첫 제휴링크를 만드는 과정 자체가 진입장벽이 될 수 있었습니다.

 

반면 내부에는 크리에이터들이 지금까지 생성한 많은 제휴링크와 클릭·판매 데이터가 쌓여 있었습니다. 그래서 크리에이터가 각 제휴사 사이트를 직접 탐색하기 전에, 서비스 안에서 원하는 상품을 검색하고 바로 제휴링크를 생성할 수 있도록 만들면 첫 제휴링크 생성까지의 과정을 줄일 수 있지 않을까​라는 문제에서 통합 검색을 시작했습니다.

 

처음에는 각 제휴사의 상품 검색 API를 활용하려 했지만 제휴사마다 API 정책이 달랐고, 실제 서비스에서 모두 사용할 수 있다는 보장이 없었습니다. 결국 외부 API에 의존하기보다 이미 축적된 제휴링크 데이터를 검색 가능한 자산으로 만드는 방향으로 문제를 다시 정의했습니다. 또한 검색에는 명확한 정답이 없었습니다. 정확히 키워드가 일치하는 결과와 의미적으로 유사한 결과 중 무엇을 먼저 보여줄지, 클릭이나 판매 데이터는 어느 정도 반영할지도 함께 판단해야 했습니다.

 

 

 

 

문제 해결

먼저 제휴사마다 서로 다른 형태로 저장된 URL을 실제 상품 URL로 정제하고, 중복되거나 검색 가치가 낮은 데이터를 제거했습니다.

이후 Keyword Search와 Semantic Search를 함께 사용하는 Hybrid Search를 설계했습니다.

 

두 검색 방식의 점수 체계가 달랐기 때문에 Score를 직접 합산하는 대신 각 검색 결과의 순위를 결합하는 RRF 방식을 적용했습니다.

검색 결과를 한 번 구현하고 끝내지 않기 위해 사용자가 어떤 검색어를 입력했는지 기록하는 Search Log와 결과를 평가할 수 있는 Feedback API도 함께 구성했습니다.

 

 

결과

기존에 축적되어 있던 주요 제휴사의 제휴링크를 검색 가능한 데이터로 가공하고, 크리에이터가 서비스 안에서 상품을 검색한 뒤 바로 제휴링크를 생성할 수 있는 통합 검색 기능을 구축했습니다. 기능 오픈 후 약 3주 동안 4,900명의 크리에이터가 약 3.3만 회 검색 기능을 사용했고, 검색 기능을 이용한 크리에이터 가운데 71%가 실제 제휴링크 생성까지 완료했습니다.

 

통합 검색의 가장 중요한 목표였던 신규 크리에이터의 첫 제휴링크 생성에도 변화가 나타났습니다. 기능 오픈 이후 신규 크리에이터의 가입 후 7일 이내 제휴링크 생성 비율이 40%를 넘어섰고, 특히 광고를 통해 유입된 신규 크리에이터의 제휴링크 생성 전환도 이전보다 크게 개선됐습니다.

 

검색 결과를 평가하기 위해 수집한 피드백에서도 다음 개선 방향을 확인할 수 있었습니다. 65건의 피드백을 분석했을 때 Ranking 자체에 대한 문제보다 ‘원하는 상품이 검색 결과에 존재하지 않는다’는 의견이 가장 많이 나타났습니다. 이를 통해 검색 알고리즘만 고도화하는 것보다 검색 가능한 제휴처와 상품 데이터를 확대하는 것이 다음 단계에서 더 중요한 문제라는 것도 확인할 수 있었습니다.

 

결과적으로 통합 검색은 단순히 검색 API를 추가한 작업이 아니라, 신규 크리에이터가 서비스의 핵심 행동인 첫 제휴링크 생성까지 더 빠르게 도달할 수 있도록 진입장벽을 낮추고, 실제 사용 데이터를 통해 다음 개선점을 찾을 수 있는 기반을 만든 작업​이었습니다.

 

 

 

 

 

 

 

 

RDS에서 Aurora로 DB 이관

문제 정의

CRM 자동 발송 시스템을 준비하면서 특정 시간대에 많은 사용자가 동시에 서비스에 접속해도 안정적으로 트래픽을 처리할 수 있는 환경이 필요했습니다. 기존 시스템의 한계를 확인하기 위해 2026년 2월, 5분 동안 n명의 가상 사용자가 스튜디오 대시보드에 접근하는 상황으로 부하 테스트를 진행했습니다. 그 결과 API 호출의 약 31.5%가 실패했고 평균 응답 시간은 22초까지 증가했습니다.

 

기존 RDS에 Read Replica를 추가하는 방법도 검토했습니다. 하지만 트래픽이 증가할 때마다 Replica를 직접 생성하고 애플리케이션에 Host를 추가해야 했으며, 트래픽이 줄면 다시 제거해야 했습니다. 생성할 수 있는 Replica 수에도 한계가 있었습니다.

 

DB Instance를 Scale-up하는 방법 역시 근본적인 해결책은 아니라고 판단했습니다. Instance 사양을 변경하면 MySQL이 유지하고 있던 런타임 상태를 그대로 유지하기 어려워 DB 프로세스 재시작이 필요할 수 있고, 운영 서비스에 영향을 줄 가능성이 있었습니다.

 

그래서 단순히 현재 DB의 사양을 높이기보다, 서비스가 성장하면 읽기 부하도 함께 확장할 수 있는 데이터베이스 구조를 만드는 것을 목표로 RDS MySQL을 Aurora MySQL로 이관하기로 했습니다. Aurora에서는 Reader Auto Scaling과 Reader Endpoint를 활용해 읽기 부하를 분산할 수 있고, 클러스터 단위로 DB를 관리할 수 있다는 점도 주요한 선택 이유였습니다.

 

 

 

 

문제 해결

운영 DB를 변경하는 작업이기 때문에 가장 중요하게 생각한 것은 새로운 DB를 만드는 방법보다 데이터를 잃지 않고 전환하는 방법과 문제가 생겼을 때 되돌아갈 방법이었습니다.

 

먼저 실제 운영 환경에서 처음 시도하는 작업을 최대한 줄이기 위해 개발 DB에서 전체 과정을 여러 번 리허설했습니다. 이 과정에서 MySQL 버전 호환성 문제도 발견했습니다. 기존 버전에서는 Aurora Read Replica를 바로 만들 수 없어 여러 버전과 Snapshot 기반 이관을 테스트했고, 최종적으로 호환되는 MySQL 버전을 확인한 뒤 Blue/Green Deployment를 이용해 운영 DB의 버전까지 업그레이드했습니다. 개발 환경에서는 DB 버전 업그레이드와 Aurora Replica 생성, Promote까지 실제 소요 시간도 미리 측정했습니다.

비용도 함께 검토했습니다. 최근 한 달간의 CPU, Connection, Read/Write I/O 등을 분석한 결과 지속적인 Storage I/O보다는 순간적인 CPU·메모리·쿼리 동시성이 병목일 가능성이 높다고 판단했습니다. Aurora Standard와 I/O-Optimized도 비교해 현재 트래픽에서는 Standard가 더 경제적이라는 결론을 내렸습니다.

 

 

 

 

그다음에는 애플리케이션과 DB 전환을 분리하기 위해 RDS Proxy를 먼저 적용했습니다. 애플리케이션이 기존 RDS에 직접 연결된 상태에서 DB까지 동시에 변경하면 장애 발생 시 원인을 구분하기 어렵기 때문입니다. 우선 서버가 Proxy를 통해 기존 RDS에 접근하도록 변경한 뒤, 개발 환경에서 Proxy의 Target을 RDS와 Aurora 사이에서 전환하며 정상적으로 연결되는지 검증했습니다.

 

 

실제 데이터 이관에서는 Aurora Read Replica를 기존 RDS와 동기화한 뒤 Aurora를 Writer로 승격했습니다. 여기서 가장 중요했던 것은 승격하는 순간부터 최종 애플리케이션 전환까지 기존 RDS에서 발생하는 데이터 변경을 어떻게 누락 없이 Aurora에 전달할 것인가였습니다. 이를 위해 AWS DMS의 CDC를 사용했습니다. Aurora의 Native Replication을 중단한 뒤 SHOW REPLICA STATUS를 통해 Aurora가 실제로 마지막까지 적용한 Binlog File과 Position을 확인했습니다. 그리고 바로 그 지점을 DMS CDC의 시작점으로 사용했습니다.

 

시작점을 앞에 잡으면 이미 Aurora에 존재하는 변경 사항이 중복 적용될 수 있고, 반대로 뒤에 잡으면 그 사이의 데이터가 누락될 수 있기 때문에 정확한 경계 지점을 확인하는 것이 중요했습니다. DMS를 적용한다고 모든 데이터가 자동으로 안전하게 옮겨지는 것도 아니었습니다. 사전 평가 과정에서 Generated Column, LOB, Primary Key, CASCADE Constraint 등 실제 Schema 특성에 따라 데이터 정합성 문제가 발생할 수 있는 항목을 확인했습니다. Generated Column은 DMS가 직접 복제하지 않고 Target Aurora가 다시 계산하도록 Mapping에서 제외하는 등 테이블 특성에 맞게 이관 방법을 조정했습니다. 또한 CDC Task가 성공했다고 해서 곧바로 이관이 성공했다고 판단하지 않고, Source와 Target의 데이터 상태와 CDC 시작 위치, Endpoint 연결, Replication 상태 등을 확인한 뒤 최종 전환을 진행했습니다.

 

 

 

 

결과

운영 DB는 Writer와 Reader를 분리하고 Auto Scaling을 적용해 트래픽 증가에 따라 읽기 부하를 확장할 수 있는 구조로 변경했습니다.

이관 이후에는 Slow Query를 Slack으로 전달하고 CPU와 Connection에 대한 CloudWatch Alarm을 추가해 DB 상태를 지속적으로 확인할 수 있는 환경을 구축했습니다. Aurora 관리자 계정 역시 Secrets Manager를 통해 관리하도록 변경했습니다. 마지막으로 기존 RDS의 분석용 데이터를 BigQuery로 이관하는 작업도 Aurora Cluster 기준으로 변경해 DB를 사용하는 주변 시스템까지 함께 정리했습니다.

 

비용 측면에서도 현재 트래픽을 기준으로 Aurora Standard가 I/O-Optimized보다 유리하다는 것을 확인하고 실제 사용량에 맞는 구성을 선택했습니다. 단순히 성능을 높이기 위해 더 비싼 인프라를 도입하기보다 성능, 확장성, 운영 안정성, 비용을 함께 고려해 DB 구조를 변경한 작업​이었습니다.

 

 

 

 

 

 

 

---

 

 

 

 

 

 

 

이번 반기에 반복해서 해결한 문제

회고를 위해 이번 반기에 했던 일들을 다시 펼쳐보니, 처음에는 전혀 다른 프로젝트라고 생각했던 작업들 사이에 공통점이 있었습니다.

 

정산에서는 사람이 반복하던 일을 자동화했고, 배포에서는 실수를 예방하는 데 그치지 않고 실패해도 빠르게 회복할 수 있는 환경을 만들었습니다. 검색에서는 기능을 한 번 만들고 끝내기보다 사용자 피드백을 바탕으로 검색 품질을 계속 개선할 수 있도록 했고, DB에서는 트래픽이 늘어날 때마다 사람이 직접 대응하지 않아도 시스템이 함께 확장될 수 있도록 했습니다.

 

이렇게 돌아보니 《함께 자라기》에서 읽었던 A, B, C 작업도 조금 더 와닿았습니다.

 

기능을 직접 만드는 A 작업에만 머무르기보다, 제품과 서비스를 더 안정적으로 만들고 운영하기 위한 B 작업에 많은 시간을 쓰고 있었습니다. 여기에 검색의 사용자 피드백이나 배포·DB의 모니터링처럼 결과를 확인하고 다음 개선으로 이어갈 수 있는 흐름을 만들면서 조금씩 C 작업도 고민하기 시작했습니다. 결국 내가 반복해서 하고 있던 일은 사람의 노력과 숙련에 의존하던 문제를 시스템으로 해결하는 것이었습니다. 그리고 이 사실을 발견하면서 도입부에서 고민했던 질문도 조금 달라졌습니다.

 

‘앞으로 어떤 직함을 가져야 할까’보다 먼저, 나는 어떤 방식으로 문제를 해결할 때 가장 보람을 느끼는 사람인가를 생각하게 됐습니다. 그 답이 조금씩 선명해지면서 앞으로 어떤 개발자가 되고 싶은지도 보이기 시작했습니다.

 

 

 

 

 

 

---

 

 

 

 

 

더하기보다 곱하기

 

커리어를 고민하던 중 Individual Contributor라는 개념을 알게 됐습니다. 처음에는 팀워크를 중요하게 생각하는 나와 Individual이라는 단어가 잘 어울리지 않는다고 생각했습니다. 하지만 IC에 대해 찾아보면서 생각이 조금 달라졌습니다.

 

예를 들어 Google의 Principal Engineer 역할에서는 직접 사람을 관리하지 않는 Individual Contributor에게도 여러 팀의 기술적인 방향을 제시하고, 엔지니어를 가이드하거나 코칭하는 역할을 기대하고 있었습니다. 이를 보면서 개발자의 영향력이 꼭 자신이 직접 처리하는 일의 양이나 관리하는 사람의 수로만 커지는 것은 아니라는 점이 인상 깊었습니다. 돌아보면 이번 반기에 내가 반복해서 해왔던 일 역시 이런 방향과 닮아 있었습니다. 직접 열 가지 일을 처리하는 것보다 내가 만든 시스템 하나 때문에 여러 사람이 하지 않아도 되는 일이 생겼을 때 더 큰 보람을 느꼈습니다.

 

《함께 자라기》에서는 시간을 더 투입해 많은 일을 처리하는 것을 더하기에, 집단의 지능을 높이는 것을 곱하기에 비유합니다.

예전에는 문제 하나를 더 해결하고, 기술 하나를 더 알고, 더 많은 일을 해내는 더하기를 잘하는 개발자가 되고 싶었습니다. 하지만 지금은 곱하기가 되는 개발자가 되고 싶습니다.

 

내가 만든 결과만 좋아지는 것이 아니라 함께 일하는 사람들이 만들어내는 결과도 조금 더 좋아지게 만드는 사람.

내가 모든 문제를 직접 해결하지 않아도 팀이 이전보다 더 잘 움직일 수 있는 무언가를 남기는 사람.

 

지금은 그런 IC의 방향에 마음이 갑니다.

 

그리고 커리어를 고민하면서 내가 어떤 방식으로 인정받고 싶은지도 조금씩 알게 됐습니다.

 

‘저 사람은 일을 많이 한다’는 말보다,

‘저 사람이 있으면 우리가 일을 더 잘할 수 있다’는 말을 듣는 개발자가 되고 싶습니다.

 

 

 

 

 

 

---

 

 

 

 

 

 

 

자기 자신에게 이르는 길

 

커리어에 대한 고민은 결국 나는 무엇 때문에 이 일을 계속하고 싶은가라는 질문으로 이어졌습니다.

최근 빅터 프랭클의 ‘의미에의 의지’에 대한 이야기를 접하며 이 질문을 오래 생각했습니다.

 

 

 

 

 

 

 

기술도, 회사도, 직함도 계속 달라질 것입니다. 지금 어렵게 배우고 있는 기술이 언젠가는 당연한 것이 될 수도 있고, 지금 내가 잘하는 일을 AI가 훨씬 쉽게 해결하는 날도 올 것입니다. 그렇다면 그런 것들이 바뀌어도 남는 이유 하나쯤은 필요하다고 생각했습니다. 지금의 답은 비교적 단순합니다.

 

내가 가진 능력이 누군가에게 도움이 됐으면 좋겠습니다.

내가 만든 시스템 덕분에 누군가 반복적인 일을 덜 하고, 조금 덜 불안하게 일할 수 있었으면 좋겠습니다. 팀이 어려운 문제를 만났을 때 지금까지 쌓아온 기술과 경험으로 도움이 될 수 있었으면 좋겠습니다.

 

돌이켜보면 도입부에서 이야기했던 ‘내가 의미 있다고 생각하는 일을 잘하고 싶다’​는 마음도 결국 여기에 가까웠던 것 같습니다.

많은 일을 하는 것보다 내가 중요하다고 생각하는 문제를 잘 해결하고, 그 결과가 나뿐 아니라 함께 일하는 사람에게도 도움이 되는 것. 지금은 그런 일에 더 많은 시간과 마음을 쓰고 싶습니다. 하지만 일만 잘하는 사람이 되고 싶은 것은 아닙니다.

 

아침에는 해결하고 싶은 문제가 있어서 집을 나서고, 하루를 마치고 나면 사랑하는 사람에게 돌아가는 삶도 중요합니다. 좋아하는 일에 충분히 몰두하면서도, 하루의 끝에는 사랑하는 사람과 함께할 수 있는 삶. 내가 바라는 삶도 어쩌면 그런 모습에 가까운 것 같습니다.

 

예전에는 열정을 쏟을 일이 있는 사람을 부러워했습니다. 지금은 적어도 내가 어떤 일에 마음이 가는지, 어떤 방식으로 일하고 싶은지는 예전보다 조금 더 알게 됐습니다. 그래서 ‘자기 자신에게 이르는 길’이라는 말을 조금 다르게 이해하게 됐습니다.

 

처음부터 내가 누구인지 정확히 알고 정해진 답을 향해 걷는 것이 아니라, 내가 반복해서 내리는 선택들을 돌아보며 무엇을 중요하게 생각하는 사람인지 조금씩 알아가는 과정. 어쩌면 지금 그 길 위에 있는지도 모르겠습니다.

 

 

 

 

 

---

 

 

 

 

 

 

 

 

마치며

예전에는 좋은 커리어를 만들기 위해 몇 년 뒤의 모습을 미리 정하고 그 답을 향해 가야 한다고 생각했습니다. 하지만 이번 반기를 돌아보면서 조금 다른 방법으로도 나아갈 수 있겠다는 생각이 들었습니다.

 

내가 어떤 문제에 계속 마음이 가는지 살펴보고, 그 문제를 더 잘 해결하기 위해 오늘 할 수 있는 일을 하는 것.

사람의 노력에 의존하는 문제가 있다면 시스템으로 해결할 방법을 고민하고, 내가 만든 결과가 나뿐 아니라 함께 일하는 사람에게도 도움이 되도록 만드는 것.

 

이런 마음 가짐을 품고 하루를 계속 쌓아가고 싶습니다.

 

 

 

 

 

 

 

그리고, 이제는 사랑하는 사람과 함께 더 나은 하루를 쌓을 수 있도록 함께 걸으려 합니다. 

 

부디 이 글이 누군가에게 도움이, 혹은 위로가 되는 바람으로 글을 마칩니다.

 

긴 글 읽어주셔서 감사합니다.

 

 

 

 

 

 

 

 

 

 

참고 링크

데미안, 헤르만 헤세, 자기 자신에게 가는 길은?

모든 사람의 삶은 제각기 자신에게로 이르는 길이다.  

삶은 자기 자신에게로 이르는 길, 헤르만 헤세 <데미안>

구글 시니어 개발자가 성장을 위해 선택한 길 | 요즘IT

아무도 알려주지 않는 리더십, 어떻게 배워야 할까? - 오픈패스 블로그 | OPENPATH BLOG