개발자 레이첼에게 무엇이든 물어보세요 E.007
저는 평소에 개발, 프로덕트, 여성 3가지 키워드로 대화를 자주해요. 대화를 통해서 많은 깨달음도 얻고 지인들의 이야기를 공유하면서 또 깨달음을 얻고 그랬어요. 문득, 누구에게 고민을 털어놓거나 질문해야할지 모르는 사람들도 많지 않을까? 다른 분들에게도 이야기를 들으면 또 몰랐던 깨달음을 얻게 되지 않을까? 라는 생각을 했어요. 화려하고 거창하지는 않지만 어떤 고민이든 어떤 질문이든 편하게 남겨주시면 진지하게 고민하고 좋은 형태로 답을 드릴게요. 제 이야기가 답이 아닐 수 있지만 답을 찾아가는 과정도 의미있을 것 같아요. 공유는 환영입니다!
수많은 고민과 질문이 저에게 도착했습니다. 뉴스레터 형태로 고민에 대한 저의 생각을 공유하고 있고요. 그렇게 공유한 저의 생각을 이곳에도 기록으로 남겨둘까 합니다.
✏️ 오늘의 질문: 개발/공부
프로젝트 막바지에 제가 만든 결과가 마음에 들지 않을 때 어떻게 대처해야 할까요? 시간만 허락한다면 데이터 설계부터 다시 하고 싶습니다. 조언 부탁드려요.
⭐️ 레이첼의 생각
정도의 차이는 있겠지만 또 고민의 종류가 다를 수 있겠지만 10년 가까이 개발자로 일하고 있는 저도, 20년 가까이 개발자로 일하고 있는 저의 동료도 여전히 품고 있는 생각이 아닐까 합니다. 오늘은 ‘최고의 결정으로 결과가 100% 만족스러운 순간은 없다. 항상 최선의 결정을 할 뿐이다.’ 를 기본 생각으로 풀어볼까 합니다. 실제로 제가 그렇기 때문이죠.
두 가지 관점에서 저의 단상을 이야기해볼까요. 프로젝트 결과가 마음에 들지 않는다 그리고 시간이 허락한다면.
프로젝트 결과가 마음에 들지 않는다.
개인 프로젝트가 아니라면 참여하는 멤버 모두가 자원이 충분하다고 만족할 수 있는 프로젝트 환경은 찾기 힘들 거라 생각합니다. 여기서 자원이라 함은 시간, 참여하는 멤버의 수 등이 포함되겠죠. 시간이 충분했던 프로젝트가 있었나요? 혹은 사람이 충분했던 프로젝트가 있었나요? 아쉽게도 저는 아직 그러한 프로젝트를 만나보지 못했습니다.
이러한 환경에서 서비스의 성장에 기여해야 하는 10년 가까운 시간을 지내오며, 저는 항상 두 가지 키워드를 품고 프로젝트에 임하는 것 같습니다. ‘유연함’과 최고의 선택이 아닌 ‘최선의 선택’ 입니다.
2년 반 전으로 돌아가 보겠습니다. 당시의 저는 현재 회사(글을 처음 작성했을 당시에는 현재 회사였지만, 지금은 전 회사)에 입사했고 새로운 서비스를 처음부터 구축해야 하는 상황이었습니다. 도메인이 복잡한 서비스였으나, 사용자에게 제공해야 하는 최소한의 기능을 정의하고, 서비스 오픈 일정을 예측하여 회사 구성원 모두가 열심히 달려가는 시기였죠. (구체적으로 언급할 수는 없지만) A 데이터 모델과 B 데이터 모델을 하나의 데이터 모델로 구성했었습니다. 서비스의 3개월, 6개월, 1년 예측 가능한 성장을 고려했을 때 기능 확장에 데이터 구조가 유연하게 대처할 수 있는지 그리고 데이터베이스의 성능을 함께 고려한 최선의 선택이었죠. 서비스가 런칭한지 2년이 지난 지금, 저희는 A와 B 데이터 모델을 분리하는 프로젝트를 진행하고 있습니다. 그래서 2년 반 전의 그 결정을 후회하는가? 저는 그렇지 않습니다. 다시 2년 반 전으로 돌아간다 해도 서비스의 2년 후 성장 방향을 예측하는 것은 불가능에 가깝다고 생각하며, 앞서 언급한 것처럼 예측 가능한 서비스의 성장 범위 내에서 유연한 데이터 구조와 데이터베이스 성능을 고려한 적절한 선택이었다고 판단하기 때문이죠. 지금은 지난 2년의 경험과 또 다른 앞으로의 변화를 고려해서 현재의 최선의 선택에 집중하면 됩니다.
또 다른 이야기입니다. 저 역시 내가 작성한 코드에 대한 의구심을 항상 품으며 키보드에 손을 얹고는 합니다. 좋은 피드백을 줄 수 있는 훌륭한 개발자가 함께한다면 참 다행이고, 내 프로젝트의 상황과 딱 맞는 멋진 오픈소스가 존재하면 금상첨화이겠지만 환경을 탓하고 불안함을 유지한 채 계속 코드를 만들어낼 수는 없겠죠. 이번에도 최고의 선택은 아니지만 최선의 선택을 언급할 수 있을 것 같습니다. 장치를 심어두고는 합니다. 단위 테스트 코드, 통합 테스트 환경, 테스트 주도 개발, 코드 리뷰 문화 등 다양한 장치를 통해 내 코드에 불신만이 존재하지 않도록 하죠. 물론 이 장치들이 얼마나 좋은 품질을 보장할 수 있는가는 또 다른 고민일 것 같습니다. 어쨌든, 코드를 더 개선할 수 있을 것 같지만 시간이 부족한 상황에서 테스트 코드가 잘 동작하는 것을 확인한다면 적어도 기능하지 않는 코드를 만들어내지는 않았구나 라고 근심을 덜 수 있고, 예측 가능한 사용자 요청을 만들어낸 후 작성한 코드가 포함된 기능의 성능을 판단할 수 있었다면 이 또한 한 줌의 근심을 덜 수 있는 방법이겠죠.
근심을 덜기 위한 방법에 대한 단상이 된 듯하나, 우리는 항상 넉넉한 환경이 아닌 곳에서 바쁘게 일해오니까요. 그 어려운 ‘적절한’ 수준의 ‘최선의 방법’을 고민하는 태도가 문제를 해결하는 사람의 올바름이 아닐까 생각합니다.
시간이 허락한다면
아마 질문 주신 분의 의도는 아닐 거라 생각하지만, ‘시간이 허락한다면’ 이라는 환경이 지금까지 얼마나 주어졌는가 생각해봅니다. 우리는 개발자로 일하면서 개발 그 자체가 목적이 되는 순간은 거의 없습니다. 회사 서비스 혹은 제품을 위해 우리는 수단으로써의 개발을 하는 것이죠. 서비스가 성장할수록 요구사항은 많아질 테고, 그 속도를 따라 필요한 사람이 채용되기는 쉽지 않겠죠.
하고자 하는 말은, 우리는 개발‘만’을 하는 사람이 아닙니다. 개발을 도구 삼아 서비스 혹은 제품을 성장시키는 사람이죠. 개발 영역에만 머물러있는 시야를 넓혀야 합니다. 일의 우선순위도, 일에 대한 어떠한 선택도 그래서 결국 서비스의 성장과 개선에 어떤 영향을 미칠지 함께 고려되어야 하죠. 기술적인 무언가도 이것이 지금 이 순간에 서비스의 그것을 위해 반드시 필요한 결정인가 라는 고민과 함께 포기해야 하는 순간도 가능하다는 말이죠.
개발이라는 영역 밖을 보지 못했던 저의 한 시절이 생각나서 짧게 이야기를 풀어보았습니다.
마무리 하며 (´▽｀)
2021년 3월 28일에 작성
책의 기획이 흥미롭고, 내용 또한 많은 순간 감탄할 수밖에 없는 김겨울 작가님의 ‘책의 말들’ 중 한 구절을 공유합니다.
『사람 만나는 걸 싫어하지 않는다. 새로운 사람을 알게 되는 것도, 친구들과 만나는 것도 좋아하지만 제한된 시간 속에서 내가 부여한 우선순위의 목록이 조금 다른 것뿐이다. 물론 언젠가 이게 다 부질없는 일로 밝혀질지도 모른다. 소중한 사람들과 자주 만났어야 한다고 땅을 치고 후회할지도 모른다. 하지만 그때 오히려 고독의 시간을 가지지 않았던 것을 후회할지도 모른다. 어차피 사람은 자신이 가지지 못한 것을 후회하는 법이니까.』
어떤 날은 코드의 품질이 아쉽고 또 어떤 날은 사용자에게 전달된 기능 자체가 아쉽고 그런 날들을 반복하고 있습니다. 작가님의 말처럼, 어떤 선택을 하든 결국 선택하지 않은 것은 아쉬움으로 남을 테고, 아쉬움이 공존하지 않는 순간이 있을까요!
