🖍 LESSER 프로젝트 개요
학생, 소규모/개인 개발자를 위한 애자일 프로젝트 관리 툴
개발 경험이 많지 않은 학생, 신입 개발자들에게 쉽게 제품의 백로그를 생성하고 관리하도록 도와주는 프로젝트 관리 툴입니다.
프로젝트 관리를 위해 사용해본 Jira는 유용한 프로그램이었지만, 높은 학습곡선으로 인해 처음 사용하기에는 굉장히 어려웠던 경험이 있습니다. 특히, Jira의 높은 학습 곡선의 원인은 처음 개발을 접하는 사람들에게 너무 높은 자유도와 많은 기능으로 판단했습니다.
예를 들어, Jira는 “이슈 유형” 설정에서 자유롭게 이슈의 단계와 종류, 그리고 이슈의 기능을 설정할 수 있습니다. 하지만 처음 프로젝트를 만들고 관리하는 개발자나 학생의 경우, 프로젝트 관리방법 / 이슈에 대한 지식 / 지라의 복잡한 사용 방법이라는 큰 학습 곡선에 가로막혀 Jira의 좋은 기능들을 잘 활용하지 못할 수 있습니다.
Jira에는 굉장히 높은 자유도로 프로젝트를 관리하기 편하지만, 너무 높은 자유도로 인해 프로젝트 관리를 어떻게 하는지 모르는 경우 오히려 사용하기 어려울 수 있다.
저희는 이 문제를 해소하기 위해, 더 적은 자유도와 더 적은 기능으로 추려 개발자들에게 프로젝트 관리를 위한 핵심 기능만을 제공하는 서비스를 개발하고자 했습니다. 특히, 처음 프로젝트를 개발하는 개발자 및 학생들이 자연스럽게 애자일한 프로젝트 관리를 할 수 있도록 이끄는 서비스를 완성하고자 고민했습니다.
🎯 LESSER 프로젝트 수행 간 목표
코드를 설계하는 과정 하나 하나를 직접 고민하고 선택하여, 주체적으로 개발하자
LESSER 이전에도 몇몇 프로젝트를 수행해 본 경험이 있었습니다. 예전 프로젝트를 개발하고 회고할 때마다, 가장 아쉬웠던 점은 “그냥 되는대로 개발했던 경험”입니다.
당시에는 근본적으로 코드를 “왜 이렇게 구현해야할까”, 근본적인 부분까지 생각하지 않았었습니다. 예를 들어, 개발을 할 때 TypeScript를 사용한 이유는 다른 사람들도 다 Typescript를 사용하기 때문이었습니다. 프로젝트의 코드 구조를 이렇게 만들었던 이유는 그저 만들었더니 동작했기 때문이었습니다. 주변과 상황에만 맞추어 수동적인 태도로 개발을 수행하다 보니, 더 빠르게 코드를 동작하기 위해서 해야 할 고민이나, 다른 사람들이 내 코드를 쉽게 사용할 수 있도록 하는 방식은 고민하지 못했습니다.
나의 주체적인 의도로 TypeScript를 학습하지 않았기 때문에, 이전에 수행한 프로젝트에서 TypeScript의 이해가 낮은 모습을 확인할 수 있었다.
이러한 수동적인 개발은 넘어서기 위해, 개발 중 마주하는 선택의 순간마다 “왜”라는 질문을 스스로에게 던지고 답을 찾아보았습니다. 사용자의 경험을 향상 시키기 위해서, 즉 더 좋은 프로젝트를 만들기 위해 어떻게 해야할까? 내가 만든 코드를 다른 개발자들이 쉽게 이해하고 유지 보수하기 위해선 어떻게 해야할까? 이런 기준을 바탕으로 직접 선택하고 설계하는 주체적인 코드를 만드는 것을 LESSER 개발 간 가장 큰 목표로 삼았습니다.
👨🏫 LESSER 프로젝트에서 6번의 스프린트에서 배운 점
1. 선택에 대한 적절한 근거를 고민하는 연습을 하다.
의도와 효율에 대해 의식하며 개발을 수행하다보면, 수 많은 선택의 기로에 마주하였습니다. 혼자 혹은 다른 개발자들과 함께 선택지를 마주하고 고민하며, 점차 어떤 것을 고르는 것이 우리에게 더 효율적일지 고민하고 적절한 기준을 세우는 법을 익힐 수 있었습니다.
예를 들어, 웹소켓 통신을 위해 Socket.io를 사용하여 코드를 작성하는 중 어떠한 구조로 React 코드를 설계해야 가장 좋을지 팀원과 함께 고민하게 되었습니다. 여러 방향을 설계하고 논의하며, “데이터 관리 효율성”, “유지 보수 및 가독성”의 기준을 세우고 이를 중점으로 고민하여 설계 방향성을 정할 수 있었습니다.
이외에도 기술의 동작을 구현하기 위한 라이브러리의 선택 과정에서도 우리가 사용가능한 시간, 비용과 같은 리소스 그리고 최적화와 같은 이유를 근거로 선택하려 노력했고, 덕분에 Socket.io / yjs와 같은 여러 라이브러리를 적절한 근거와 함께 선정할 수 있었습니다.
개발에 있어 여러 선택지를 찾아보고 올바른 기준을 세워 고민하는 습관을 기른다면, 사용자의 경험을 향상시킬 수 있는 좋은 프로젝트, 유지 보수하기에 좋은 프로젝트로 이끄는 좋은 방향이 될 것이라 생각합니다.
2. 새로운 기술을 배움에 있어, 나만의 체계적인 방법을 세우다
어떤 기술을 선택하기 위해서, 그리고 주어진 시간 안에 선택한 기술을 배우고 활용하는 과정 속에서 점차 더 효율적으로 기술을 배우고 활용하는 방법을 체계화 할 수 있었습니다.
- 학습을 시작하기 전, 배경 지식을 쌓다.
- 복잡하고 방대한 양의 기술 관련 코드를 읽고, “아! 이 코드는 이렇게 동작하는 것이구나!”를 파악하는 것은 지금의 개발 경험, 지식으로는 아직 어려운 일이었습니다.
- 그렇기 때문에, 이 라이브러리 혹은 기술은 어떤 목적으로 만들어졌는지 이해하고 어떠한 원리로 동작하는 지에 대한 지식을 쌓고 이를 기반으로 이해의 물꼬를 틀고자 했습니다.
- 이 배경지식을 쌓기 위해 오픈소스의 공식 문서 혹은 깃허브 리드미를 꼼꼼하게 읽으며 어떻게 활용되고 사용되는지, 어떤 것을 위해 탄생했는지를 이해하고자 했습니다.
- 현재 기술을 사용하기 위한 목표를 정하다.
- 특정 기술 혹은 라이브러리들은 오랜 시간 관리되고, 확장되고, 발전해온 코드이기 때문에, 단 시간내에 이를 전체 다 읽는 것은 불가능한 일이었습니다. 그래서 내가 왜 이 기술을 사용하고, 활용하고자 하는지 적절한 목표를 세우고 따라가기로 결정했습니다.
- 예를 들어 yjs 라이브러리의 경우, 많은 데이터 타입 중
text타입의 데이터를 관리하는데 집중하여 기술을 익히고 학습하는 목표를 정했습니다.
- 가장 먼저, 테스트 코드와 예제 코드를 읽어보다.
- 본격적으로 기술을 활용하기 전, 배경을 쌓고 어떤 코드들을 활용할 수 있는지의 일환으로써 테스트 코드와 예제 코드를 읽었습니다. 이들은 오픈 소스를 만든 사람들이 공인한 올바른 코드의 사용 방법이기 때문에, 라이브러리를 오류없이 활용할 수 있는 가장 좋은 방법으로 이해하고 테스트 코드를 읽었습니다.
- 이렇게 테스트 코드를 참고한 경험은 내가 활용할 수 있는 기능들이 무엇이 있는지 더 명확하게 파악할 수 있었습니다. 예를 들어 yjs 라이브러리를 활용할 때, applyUpdate를 적용하기 전 yjs 객체의 정보를 저장할 방법을 고민했었는데, 공식 문서에 설명이 잘 되어 있지 않은 snapshot 기능을 테스트코드를 통해 찾고 이해하여 사용해본 경험이 있습니다.
3. 개발 일지를 작성하고 관리하다.
개발 중 고민이 되는 내용을 글로 작성하고 작업이 완료 된 이후 개발일지로 관리한 경험 덕분에, 문서화의 중요성을 체득할 수 있었습니다.
머리 속의 추상적인 이미지를 구체화하다
- 평상시에 수행했던 개발은 머릿속에 있는 추상적인 논리 과정을 코드로 구현하는 과정이었습니다. 추상적인 형태를 논리 구조로 만들었기 때문에, 에러가 발생할 수 있는 모든 엣지 케이스를 처리하지 못하는 구조가 만들어지기 쉬웠습니다.
- 또한, 구조를 분석하여 효율적인 코드를 설계하지 않은 탓에 불필요하게 복잡한 구조를 만드는 경우가 너무나도 많았습니다. 이전에 개발했던 흔적들을 되돌아보면, “왜 이렇게 불필요하게 복잡하게 만들었을까?”라는 생각이 드는 이유의 가장 큰 원인이라 판단이 됩니다.
- 이번 LESSER를 개발함에 있어, 복잡한 구조 혹은 사용자의 동작을 꼼꼼하게 살펴야 하는 경우 개발 일지를 활용하여 개발을 수행했습니다. PublicRouter/PrivateRouter를 개발하는 과정 간 개발 일지로, 사용자의 예상 시나리오를 세우고 이를 기반으로 코드를 설계함으로써 더 깔끔한 코드의 동작을 만들 수 있다고 생각했습니다.
문서화하며 개발 과정을 회고하다
- 개발 일지를 작성하는 과정은, 논리 과정의 구체화하는 것 이외에도 실제 문서로 정리하며 코드를 회고하는 과정이 되어주었습니다. 실제 코드 작성 과정을 정리하면서, 코드의 부족한 부분 혹은 더 개선할 점을 깨닫고 추가적인 커밋을 작성할 수 있었습니다.
🤔 LESSER를 수행하면서 아쉬운 점들
1. 기술에 대한 트래킹이 부족하다.
한번 사용한 기술들에 대한 트래킹이 되어가고 있지 않습니다. 해당 기술을 적용하기만 하는 것이 다가 아니라, 그 기술을 현재 제대로 사용하고 있는지도 굉장히 중요한 문제라고 생각합니다. 예를 들어, MSW를 최초 적용할 때에는 잘 사용했지만, 현재에는 MSW가 적절하게 관리되고 있지 않는 점이 아쉬웠습니다.
어떻게 개선할 수 있을까?
프로젝트의 회고 방식으로 KPT를 적용하여 전체적인 프로젝트 수행 방식에 대해 점검하고 개선방안을 적용하고 있습니다. 프로젝트의 KPT 회고 방식을 기술 회고에도 동일하게 시도하여, 기술의 활용 여부를 트래킹할 수 있을 것입니다. 예를 들어, 계속해서 적용해야 하는 기술(MSW, Test Code, Error Handling)과 이번 스프린트에 일시적으로 적용한 기술들을 KPT 방식으로 점검하고 개선할 수 있는 방안을 만들고자 합니다.
회고에서 발견한 문제점인 MSW 기술을 트래킹하기 위해, 어제 MSW 기술을 사용방식 개선 및 트랙킹 방식 회의를 FE 팀원화 함께 진행했다.
2. 너무 개발 중심적인 시간 배분이 아쉽다.
LESSER를 개발하면서 대부분의 시간을 기능 개발에 대한 시간에 투자하였습니다. 새로운 기술을 배우고 이를 적용하는 것에 대부분의 시간을 사용했습니다. 하지만, 개발만큼이나 사용자들에게 기능을 최적화한 형태로 제공하고, 나의 코드를 더욱 읽고 관리하기 좋은 형태로 다른 개발자들에게 제공하는 것도 중요함을 깨닫게 되었습니다.
그렇기 때문에 너무 개발에만 시간을 투자한 탓에 테스트 코드를 통한 점검이나 코드 리팩토링을 통한 최적화/유지 보수성 개선과 같은 점들이 제대로 투자하지 않은 지난 스프린트들이 굉장히 아쉽게 느껴집니다.
어떻게 개선할 수 있을까?
스프린트 중 1일 ~ 2일을 지난 코드를 점검하고 개선하는 과정으로 할애하고자 합니다.
(단, 스프린트 중 발행된 태스크 티켓을 잘 해결했을 경우에 한함)
- 단계를 수행하기에 앞서 본인이 적용한 기술들을 “일시적 적용 기술” / “지속적으로 트래킹할 기술”로 분류한다. “지속적으로 트래킹할 기술”로 분류되었을 경우, 해당 기술을 적절하게 사용하는 것에 대한 기준과 기술에 대한 적용 방법을 정리한다.
- 이번 스프린트에 적용한 기술이 적절하게 적용되어 있는지 점검한다.
- 지속적으로 트래킹하는 기술들이 이번 스프린트의 태스크에 잘 적용이 되어 있는지 점검한다.
- 해당 점검 사항에 문제점이 발견되었다면, 문제의 원인을 분석한다.
- 문제의 원인을 개선하기 위한 방안을 만들고 기존의 적용 방법을 개선한다.
📝 회고 마무리
LESSER 프로젝트에서 팀원들의 도움 덕분에 제가 하고 싶은 여러 일들에 도전해볼 수 있는 좋은 기회입니다.
웹소켓 통신, CRDT를 사용한 동시 편집 등을 만들며 제가 평소 해보고 싶었던 여러 기능들을 개발하며 큰 뿌듯함과 도전하고 있다는 충실함을 느낄 수 있엇습니다.
팀원 모두가 팀의 시스템을 살펴보고 더욱 발전하고자 노력하는 환경 속에서 저도 스스로를 살펴보고, 있습니다. 특히 매 스프린트마다 수행하는 KPT 회고를 통해 우리의 애자일 방식을 어떻게 더 개선할 수 있을지 고민하고 실제로 이것이 적용되는 과정을 보며 큰 뿌듯함을 느끼고 있습니다.
KPT 방식을 통해 프로젝트 수행 간 문제를 파악하고, 개선하려 노력하고 있다.
실제로, 스프린트 회의 방식과 회고 방식을 개선한 덕분에 스프린트를 점검하는 시간을 2시간에서 30분으로 줄여 더욱 효율적인 회의를 수행할 수 있었습니다.
운이 좋게도 이런 좋은 환경과 좋은 팀원들 속에서 개발하며 공부할 수 있는 만큼, 이 기회를 놓치지 않고 팀원들과 더 높은 곳을 향해 성장해나가고자 더욱 노력해보겠습니다.
