우리는 효율적으로 일을 하기 위해 반복적인 작업을 그룹화하여 처리한다. 웹 개발에서 사용하는 디자인 시스템 같은 걸 예로 들을 수 있겠다. 반복 작업들로 이루어진 그룹들을 또 전체로 묶어 시스템이라 명칭 하는데 이런 시스템은 일상의 어느곳에서든 적용할 수 있다.
이번 글을 통해서 나는 내가 갖고 있는 여러 가지 개발 습관을 분류하고 그룹화하여 앞으로 만날 여러 종류의 프로젝트들을 효율적으로 작업할 수 있길 바란다.
📝 기획 시스템
내 작업의 목적을 짧게 정의하면 "사용자에게 제공"이라고 생각한다. 정해진 시간 내에 특정 서비스를 유저에게 사용하기 편리하고 보기 깔끔하게 만들어 전달해야 한다.
그러기 위해선 기획 단계에서 서비스에 맞춰 내가 사용할 기술 스택을 고민만 하는 것뿐만 아닌, 더 나아가 어떤 라이브러리를 먼저 사용할지 나열하고 미리 필수 기능 테스트를 진행하는 과정을 추가하는 게 좋아 보인다. 악보의 정원 프로젝트 진행 중 음원을 조회하는 기능을 만들 때 기술 문제 때문에 작업이 지체된 적이 있었는데 이때 기획 단계에서 얘기했던 Spotify나 다른 음원 조회 api를 리스트업만 하는 것이 아닌 실행 가능성까지 파악하는 것이 미흡했었다.
그럼, 기획 작업을 어떻게 시스템화할 수 있을까? 아래에 타임라인별로 정리해보자.
시작전
-
프로젝트 목표 설정:
- 프로젝트 목표와 목적 설정
- 핵심 성공 지표 정의
- 주요 대상 사용자 그룹 식별
- 사용자 요구사항 및 기대치 문서화
-
기술 스택 선택, 스코프 정의:
- 프로젝트 범위 정의
- 기능 명세서 작성
- 사용할 기술 스택 및 도구 결정
-
시간 계획:
- 자원 할당 계획 수립
- 프로젝트 일정 세분화 및 마일스톤 정의 (미리 이슈또는 PR을 만들어서 작업하면 작업간 혼동을 최소화 할 수 있을 거 같다)
-
요구사항 정의:
- 상세한 요구사항 문서 작성
- UI/UX 디자인과 데이터 모델링 작업 수행 (개인작업일 경우 아래에 작성한 디자인 시스템 사용)
-
품질 관리 및 테스트 계획:
- 테스트 계획 작성 (기술 스택과 요구사항 문서를 통해 사용해야하는 라이브러리, API 테스트)
- 테스트 케이스 및 품질 기준 정의
-
프로젝트 관리 및 커뮤니케이션 계획 (팀단위 프로젝트):
- 프로젝트 관리 방법론 선택
- 회의 일정 및 이슈 추적 방법 정의
-
위험 관리:
- 프로젝트 위험 식별
- 위험 관리 계획 수립
-
관리 및 감독체계 (팀단위 프로젝트):
- 팀원 역할과 책임 정의
- 의사 결정 프로세스 및 업무 흐름 설계
진행중
-
프로젝트 문서화:
- 프로젝트 관련 모든 문서 정리 및 유지
-
변경 관리:
- 변경 요청 및 승인 프로세스 관리
-
프로젝트 피드백 및 개선:
- 팀원또는 이해관계자들로부터의 피드백 수용 및 개선사항 적용
마무리
- 완료 및 평가:
- 프로젝트 완료 평가
- 성과 지표를 통한 목표 달성 여부 확인
위에 작성한 타임라인은 아무래도 노션 템플릿을 하나 만들어 놓는게 좋겠다.
🎨 디자인 시스템 정리
프로젝트를 끝내고 돌이켜보면 가장 많이 떠오르는 게 좀 더 섬세한 디자인 시스템에 대한 욕심이다.
미적 감각이 떨어진다는 이유로 팀으로 작업 할 때는 피그마를 되도록 멀리했고, 혼자 작업할 때는 다른 레퍼런스를 카피하곤 했다. 앞으로 진행하고 싶은 사이드 프로젝트가 많은데 이걸 언제까지 외면할 수는 없다고 생각한다. 따라서 나의 디자인 시스템을 정리하고, 팀단위 프로젝트가 진행되고 얻은 인사이트로 조금씩 업데이트 해나가는 노력이 필요하다.
최초로 시도했던 노력은 악보의 정원 프로젝트를 진행할 때 했던 구체적인 Figma 작업과 storybook을 사용한 UI 테스트였다. 공들여 만들었기에 react component로 수월하게 만들어 낼 수 있었지만, Figma의 component 기능을 100% 활용하지 않고 생김새를 구현하는 데에 급급했던게 아쉽다고 생각한다. 시간을 조금 더 들여서 variant/property 같은 기능을 사용해 관리의 용이함을 얻었다면 팀원들과의 소통에도 도움되고 아토믹 디자인 패턴에 맞게 설계할 수 있었을 거 같다.
프로젝트 디자인의 일관성을 유지하고, 효율적인 개발 및 디자인 경험을 만들기 위해 Figma를 이해하고 데스크탑, 모바일에서 통용되는 여러 약속에 대한 지식 습득이 필요할 거 같다.
🧑💻 개발 시스템 정리
서비스를 개발할 때 어떻게 하면 더 효율적이고 유기적인 움직임을 가져갈 수 있을까?
개발하면서 마주치는 어려움 중 하나는 이미 작성된 코드를 수정해야할때 일겁니다.
그 코드가 단순한 코드여서 사이드 이펙트를 고려하며 수정하여도, 가끔은 완전히 그 영역을 커버하지 못 할 때가 있죠. 따라서 대다수의 개발자들은 코드수정에 꽤 예민한 편입니다 특히 동료가 내가 쓴 코드를 읽고 수정할 때..
또 영원히 수정이 필요없는 코드는 없죠, 끊임없이 리펙토링하고 새로운 기능을 추가하며 서비스를 계속 발전시키는게 저희의 임무입니다.
결국 효율적으로 개발하기 위해 우리는 가독성이 좋고 장기적인 유지보수에 용이한 코드를 작성해야 하는데 이를 위해서 코드를 작성하기 전 팀적으로 약속 을 만들곤 합니다.
가장 큰 뼈대인 소프트웨어 아키텍처부터 살펴보죠.
아키텍처는 소프트웨어의 기본적인 구성 요소, 그들 사이의 관계, 시스템의 동작 방식, 성능, 확장성 및 유지보수 가능성과 같은 다양한 측면을 다룹니다. 아키텍처는 소프트웨어 시스템의 기반을 제공하며 전체 개발 프로세스를 안내하고 조직의 비즈니스 요구 사항을 충족시키기 위한 청사진 역할을 합니다.
아키텍처에 관한 중요한 개념과 원칙은 다음과 같습니다
1. 모듈화: 시스템을 작은 모듈 또는 컴포넌트로 나누어야 합니다. 각 모듈은 특정 기능 또는 역할을 담당하며 독립적으로 테스트, 개발, 유지보수할 수 있어야 합니다.
2. 관심사 분리: 시스템의 다른 부분들 간의 의존성을 최소화하고 각 부분이 자체적으로 특정 관심사에 집중하도록 설계해야 합니다. 예를 들어, 데이터 액세스와 사용자 인터페이스 로직을 분리하거나, 비즈니스 로직과 프레젠테이션 로직을 분리할 수 있습니다.
3. 단일 책임 원칙 (Single Responsibility Principle): 모듈이나 클래스는 단 하나의 책임을 가져야 합니다. 이것은 코드의 읽기 쉽고 이해하기 쉬운 구조를 유지하고 변경 사항에 대한 영향을 최소화하는 데 도움이 됩니다.
4. 계층화: 소프트웨어 시스템을 여러 개의 레이어 또는 계층으로 나누어 구성합니다. 일반적으로는 데이터 계층, 비즈니스 로직 계층 및 프레젠테이션 계층으로 나누어 구성합니다.
5. 확장성: 아키텍처는 시스템이 더 많은 요구 사항을 수용하고 더 큰 규모로 확장할 수 있는 방식으로 설계되어야 합니다. 이는 시스템의 성능을 향상시키고 사용자 수나 데이터 양이 증가할 때 대처하기 쉽도록 하는 중요한 고려 사항입니다.
6. 보안: 아키텍처는 시스템의 보안을 고려해야 합니다. 데이터의 안전성과 개인 정보 보호를 위한 적절한 보안 메커니즘을 구현해야 합니다.
7. 유지보수 용이성: 아키텍처는 시스템의 장기적인 유지보수를 고려해야 합니다. 변경이 필요한 경우 최소한의 노력으로 수정하고 확장할 수 있어야 합니다.
그 다음은 디자인 패턴입니다.
큰틀에서 아키텍쳐 패턴을 정했다면, 개발단계에서 어떻게 실제 코드 구조를 짤지를 정하는 게 디자인 패턴입니다.
