OpenProject Work Package 상세 안내서

2025-09-06, G25DR

1. 서론: OpenProject와 작업 패키지(Work Package)의 철학

1.1 OpenProject 개요: 단순한 도구를 넘어선 철학

OpenProject는 단순한 프로젝트 관리 소프트웨어를 넘어선다.1 이는 오픈소스 커뮤니티에 의해 개발되고 유지되는 강력한 플랫폼으로, 프로젝트 생명주기 전반을 지원하도록 설계되었다.3 Ruby 프로그래밍 언어로 개발되었으며, GNU General Public License v3(GPL v3)에 따라 배포되어 누구나 자유롭게 사용, 수정, 배포할 수 있다.5 OpenProject의 핵심 철학은 ’투명성(transparency)’과 ’데이터 주권(data sovereignty)’이라는 두 가지 가치에 깊이 뿌리내리고 있다.4 이는 사용자가 자신의 데이터를 완벽하게 통제하고, 소프트웨어의 작동 방식을 투명하게 들여다볼 수 있어야 한다는 믿음을 반영한다.

이 플랫폼은 두 가지 주요 에디션으로 제공된다. 하나는 핵심 기능을 모두 포함한 무료 ’커뮤니티 에디션(Community Edition)’이고, 다른 하나는 추가적인 엔터프라이즈 기능, 전문적인 기술 지원, 보안 강화 기능을 제공하는 유료 ’엔터프라이즈 에디션(Enterprise Edition)’이다.1 이러한 이원화 모델은 오픈소스의 가치를 지키면서도 기업 환경의 요구사항을 충족시키려는 전략적 선택이다.

OpenProject의 가장 큰 장점 중 하나는 그 유연성에 있다. 전통적인 폭포수(Waterfall) 방법론, 현대적인 애자일(Agile) 및 스크럼(Scrum) 프레임워크, 그리고 이 둘을 혼합한 하이브리드(Hybrid) 접근법까지, 어떠한 프로젝트 관리 방법론에도 구애받지 않고 적용할 수 있도록 설계되었다.3 이는 조직이 특정 도구의 제약에 맞춰 프로세스를 변경하는 것이 아니라, 조직 고유의 프로세스를 도구에 투영할 수 있게 함을 의미한다.

1.2 작업 패키지(Work Package)의 핵심 개념: 프로젝트의 원자(Atom)

OpenProject의 중심에는 ’작업 패키지(Work Package)’라는 핵심 개념이 자리 잡고 있다. 작업 패키지는 프로젝트 내에서 추적하고 관리해야 하는 모든 개별 항목(item)을 포괄하는 단위이다.7 이는 단순히 ’업무(Task)’나 ‘할 일(To-do)’ 목록을 의미하는 것을 넘어선다. 기능(Feature) 개발, 버그(Bug) 수정, 리스크(Risk) 관리, 사용자 스토리(User Story) 구현, 중요한 일정 지표인 마일스톤(Milestone), 프로젝트의 큰 단계를 나타내는 단계(Phase) 등 프로젝트를 구성하는 모든 요소를 작업 패키지로 표현할 수 있다.7

이러한 접근 방식은 의도된 아키텍처적 추상화의 결과물이다. 널리 사용되는 다른 도구인 Jira의 ’이슈(Issue)’가 본래 버그 추적 시스템에서 출발하여 점차 개념이 확장된 것과 달리, OpenProject의 ’작업 패키지’는 설계 초기부터 포괄적인 작업 단위를 염두에 두고 만들어졌다.9 이는 OpenProject가 특정 방법론이나 작업 유형에 얽매이지 않고자 하는 근본적인 설계 철학을 반영하는 것이다.3 이 구조적 유연성 덕분에, 사용자는 시스템이 강제하는 방식에 자신의 업무를 맞추는 것이 아니라, 조직의 독특하고 복잡한 프로세스를 시스템 안에서 자연스럽게 모델링할 수 있다.10 결과적으로 작업 패키지는 단순한 데이터 기록(record)이 아니라, 조직의 업무 흐름과 논리를 담아내는 유연한 컨테이너(container)로서 기능하게 된다.

1.3 Jira ’Issue’와의 비교: 관점의 차이

프로젝트 관리 도구 시장에서 Jira는 애자일 방법론과 이슈 트래킹 분야에서 강력한 영향력을 가진 독점 소프트웨어로 알려져 있다.9 OpenProject와 Jira는 이슈 추적, 백로그 관리, 보고서 생성 등 많은 기능적 유사점을 공유한다.9 하지만 두 도구는 근본적인 철학과 전략에서 뚜렷한 차이를 보인다.

가장 큰 차이점은 OpenProject가 오픈소스라는 점이다.9 소스 코드가 공개되어 있어 누구나 검토하고 수정할 수 있으며, 이를 통해 조직은 특정 벤더에 대한 종속성에서 벗어나 완전한 독립성과 자율성을 확보할 수 있다. 반면, Jira는 독점 소프트웨어로서 사용자는 코드에 접근할 수 없으며, 모든 업그레이드와 기능 개선은 전적으로 개발사인 Atlassian에 의존해야 한다.9

호스팅 전략 또한 중요한 차이점이다. Jira는 클라우드 버전에 집중하면서 온프레미스(On-premises) 서버 제품에 대한 지원을 점차 축소하고, 2024년 봄부터는 신규 판매를 중단했다.9 이는 사용자들이 데이터를 Atlassian이 관리하는 클라우드 인프라에 의존하도록 유도하는 전략이다. 반면, OpenProject는 클라우드 호스팅과 온프레미스 설치 옵션을 모두 동등하게 제공하여 사용자에게 선택권을 부여한다.9

이러한 호스팅 전략의 차이는 단순한 배포 옵션의 문제를 넘어, 데이터 거버넌스에 대한 철학의 차이를 명확하게 보여준다. Jira의 클라우드 중심 정책은 데이터가 AWS와 같은 특정 클라우드 벤더의 인프라에 저장되고 관리됨을 의미한다.9 반면, OpenProject의 온프레미스 옵션은 조직이 자체 서버에 시스템을 구축함으로써 데이터의 물리적 위치와 접근 통제권을 100% 소유할 수 있게 한다. 이는 곧 ’데이터 주권’의 확보를 의미하며, GDPR과 같이 엄격한 데이터 보호 규제를 준수해야 하는 유럽 지역의 기업이나, 데이터 보안이 최우선 과제인 금융, 국방, 의료 분야의 대기업에게는 단순한 선호의 문제가 아닌, 비즈니스를 위한 필수 요건이 된다.4 따라서 OpenProject의 작업 패키지는 단순한 업무 데이터가 아니라, 조직이 완벽하게 소유하고 통제할 수 있는 핵심 디지털 자산(asset)으로서의 가치를 지닌다.

2. 작업 패키지의 해부학: 구조와 속성

2.1 작업 패키지 유형(Types): 업무의 정체성 정의

작업 패키지 ’유형(Type)’은 해당 작업 패키지가 프로젝트 내에서 어떤 성격과 목적을 갖는지를 정의하는 가장 근본적인 분류 체계이다.7 이는 단순한 라벨링을 넘어, 작업 패키지의 행동 양식과 표시 방법을 결정하는 핵심적인 속성이다. OpenProject는 기본적으로 Task(업무), Feature(기능), Bug(버그), Phase(단계), Milestone(마일스톤) 등 일반적인 프로젝트 관리에서 널리 사용되는 유형들을 제공한다.7

• Task(업무): 프로젝트 목표 달성을 위해 수행해야 할 구체적인 활동.

• Feature(기능): 제품이나 서비스가 사용자에게 제공해야 할 새로운 기능적 요구사항.

• Bug(버그): 소프트웨어나 제품에서 발견된 결함이나 오류.

• Phase(단계): 프로젝트를 논리적인 구간으로 나눈 것으로, 시작일과 종료일을 가지는 기간을 나타낸다. 간트 차트에서 여러 Task를 포함하는 상위 바로 표시된다.

• Milestone(마일스톤): 프로젝트의 중요한 중간 목표나 완료 시점을 나타내는 지표. 기간이 없는 특정 날짜를 가리키며, 간트 차트에서 다이아몬드 형태로 표시된다.13

시스템 관리자는 조직의 필요에 따라 이러한 기본 유형을 수정하거나, 완전히 새로운 유형을 생성할 수 있다. 이 설정은 Administration -> Work packages -> Types 메뉴에서 이루어지며, 각 유형의 이름, 간트 차트 표시 색상, 워크플로 복사 여부 등을 지정할 수 있다.13 유형 목록의 순서를 변경하여 새로운 작업 패키지를 생성할 때 기본으로 선택될 유형을 지정하는 것도 가능하다.14

2.1.1 애자일 유형 심층 분석

애자일 개발 방법론을 지원하기 위해 OpenProject는 Epic, User Story와 같은 특수한 유형을 활용한다. 이들은 단순한 분류를 넘어 애자일 프로세스의 핵심 구성 요소로 기능한다.

• Epic(에픽): 하나의 스프린트나 이터레이션 내에서 완료하기 어려운 큰 규모의 작업 단위를 의미한다. 보통 여러 개의 사용자 스토리로 분해된다.15

• User Story(사용자 스토리): 사용자 관점에서 원하는 기능이나 목표를 서술한 작은 단위의 요구사항이다. “사용자로서 [목표]를 할 수 있기를 원한다. 왜냐하면 [이유] 때문이다“와 같은 형식을 따른다.15

이러한 애자일 관련 유형들은 특히 ‘백로그(Backlogs)’ 모듈과 긴밀하게 연동된다. 관리자가 Administration -> Backlogs 설정에서 특정 유형(예: Epic, User Story, Bug)을 ’스토리 유형(Story types)’으로 지정하면, 해당 유형의 작업 패키지들은 제품 백로그에 나타나 우선순위 지정, 스토리 포인트 추정, 스프린트 계획 등의 활동에 사용된다.16

여기서 중요한 점은 작업 패키지 ’유형’이 단순한 분류 태그가 아니라, OpenProject 내 다른 모듈의 동작 방식을 결정하고 특정 워크플로를 활성화하는 ‘트리거(trigger)’ 역할을 한다는 것이다. 예를 들어, 어떤 작업 패키지의 유형을 ’Milestone’으로 설정하는 순간, 이 패키지는 간트 차트에서 일반적인 막대 바가 아닌 특정 시점을 나타내는 마름모꼴 아이콘으로 시각화된다.13 마찬가지로, 유형을 ’User Story’로 지정하면 백로그 모듈에서 스토리 포인트(Story points)를 입력하는 필드가 활성화되고, 이를 기반으로 스프린트의 번다운 차트(Burndown chart)가 자동으로 계산된다.17 따라서 관리자가 새로운 유형을 설계할 때는, 이 유형이 단순히 무엇을 의미하는지를 넘어, 간트 차트, 백로그, 애자일 보드 등 어떤 모듈과 상호작용하고, 어떤 상태 전환 규칙(워크플로)을 따르게 할 것인지를 종합적으로 고려해야 한다. 이는 OpenProject를 조직의 프로세스에 맞게 최적화하는 첫걸음이다.

2.2 핵심 속성(Attributes) 분석: 작업의 DNA

모든 작업 패키지는 그 종류와 상관없이 공통적으로 가지는 핵심적인 내장 속성(built-in attributes)들을 통해 자신의 상태와 정보를 표현한다. 이 속성들은 작업의 DNA와 같아서, 해당 작업이 누구에게 할당되었고, 언제까지 완료되어야 하며, 현재 어떤 상태에 있는지를 명확하게 정의한다.7

주요 핵심 속성은 다음과 같다:

• ID: OpenProject 인스턴스 내의 모든 프로젝트를 통틀어 부여되는 고유한 정수 값이다. 한번 생성되면 절대 변경되지 않으며, 작업 패키지를 유일하게 식별하는 키(key) 역할을 한다.7

• Subject(제목): 작업 패키지의 내용을 간결하게 설명하는 제목이다.7

• Type(유형): 앞서 설명한 작업 패키지의 정체성을 나타낸다 (예: Task, Bug).7

• Status(상태): 작업의 현재 진행 상태를 나타낸다 (예: New, In Progress, Done, Closed). 상태는 워크플로 규칙에 따라 변경될 수 있으며, 프로젝트 현황을 파악하는 가장 중요한 지표 중 하나이다.18

• Assignee(담당자) / Accountable(책임자): 해당 작업을 직접 수행하는 담당자와 최종 책임이 있는 책임자를 지정한다. 특정 사용자뿐만 아니라 사용자 그룹 또는 역할 기반의 플레이스홀더(placeholder)에게도 할당할 수 있어 유연한 자원 관리가 가능하다.19

• Priority(우선순위): 다른 작업들과의 상대적인 중요도나 긴급성을 나타낸다 (예: Low, Normal, High, Immediate).7

• Start date(시작일) / Finish date(종료일): 작업이 시작될 예정일과 완료될 예정일을 명시한다. 이 날짜들은 간트 차트의 막대 길이와 위치를 결정한다.20

• Duration(기간): 시작일과 종료일 사이의 기간을 나타낸다. 시작일과 기간을 입력하면 종료일이 자동으로 계산되는 등 상호 연동된다.20

• Estimated time (Work)(예상 시간): 해당 작업을 완료하는 데 필요할 것으로 예상되는 총 작업 시간을 시간 단위로 기록한다. 부모-자식 관계에서는 자식들의 예상 시간이 합산되어 부모의 예상 시간으로 자동 계산되기도 한다.14

• Remaining time(잔여 시간): 남은 예상 작업 시간을 기록한다.20

• % Complete(진척도): 작업의 완료율을 백분율로 표시한다. 이 값은 ’상태’에 따라 자동으로 설정되게 하거나(예: ‘In Progress’ 상태는 50%), ‘예상 시간’ 대비 ’소요 시간’을 기반으로 수동 또는 자동으로 계산되도록 설정할 수 있다.14

이러한 속성들은 OpenProject API를 통해 외부 시스템과 연동할 때 더욱 명확한 기술적 사양을 갖는다. 예를 들어, API 문서에 따르면 ID는 Integer 타입이며 읽기 전용(READ-ONLY)이고, Subject는 String 타입으로 1에서 255자 사이의 길이를 가져야 하는 제약 조건이 있다.20 이처럼 각 속성은 명확한 데이터 타입과 규칙을 가지며, 이는 시스템의 데이터 정합성을 유지하는 기반이 된다.

2.3 정보 구조화 전략: 사용자 정의 필드와 카테고리

기본으로 제공되는 핵심 속성만으로는 모든 조직의 고유한 데이터 관리 요구사항을 충족시키기 어렵다. 이를 해결하기 위해 OpenProject는 ’사용자 정의 필드(Custom Fields)’와 ’카테고리(Categories)’라는 강력한 확장 기능을 제공한다.

2.3.1 사용자 정의 필드(Custom Fields)

사용자 정의 필드는 조직이 필요로 하는 어떠한 추가 정보라도 작업 패키지에 담을 수 있게 해주는 기능이다.21 예를 들어, ‘고객사명’, ‘영향받는 시스템’, ‘비용 코드’ 등 조직의 비즈니스 프로세스에 필수적인 정보를 위한 새로운 필드를 직접 만들 수 있다.

사용자 정의 필드는 Administration -> Custom fields 메뉴에서 생성하며, 매우 다양한 형식을 지원한다 21:

• Text, Integer, Float: 문자열, 정수, 실수 값을 입력받는다.

• List: 미리 정의된 목록에서 하나 또는 여러 개의 값을 선택하게 한다 (Multi-select).

• Date, Boolean: 날짜 선택기 또는 참/거짓(True/False) 체크박스를 제공한다.

• User, Version: 시스템에 등록된 사용자나 버전을 선택하게 한다.

• Hierarchy (Enterprise 기능): 다단계 계층 구조를 가진 목록을 만들 수 있다 (예: 대륙 > 국가 > 도시).

중요한 점은, 사용자 정의 필드를 생성했다고 해서 즉시 모든 작업 패키지에서 사용할 수 있는 것은 아니라는 점이다. 두 단계의 활성화 과정이 필요하다. 첫째, 생성된 필드를 특정 작업 패키지 유형의 입력 양식에 추가해야 한다 (Administration -> Work packages -> Types -> Form configuration).13 둘째, 해당 필드를 사용할 각 프로젝트의 설정에서 개별적으로 활성화해야 한다 (Project settings -> Work packages -> Custom fields).21 이 2단계 구조는 시스템 전반의 필드를 중앙에서 관리하면서도, 각 프로젝트의 특성에 맞게 필요한 필드만 선택적으로 사용할 수 있게 하는 유연성을 제공한다.

2.3.2 카테고리(Categories)

카테고리는 하나의 프로젝트 내에서 작업 패키지들을 추가적으로 분류하고 그룹화하기 위한 간편한 방법을 제공한다.23 사용자 정의 필드처럼 시스템 전역적으로 관리되는 것이 아니라, 각 프로젝트별로 독립적으로 설정된다 (Project settings -> Work packages -> Categories). 예를 들어, 개발 프로젝트에서는 ‘Frontend’, ‘Backend’, ’Database’와 같은 카테고리를, 마케팅 프로젝트에서는 ‘온라인 광고’, ‘콘텐츠 제작’, ’이벤트’와 같은 카테고리를 만들어 사용할 수 있다. 카테고리는 작업 패키지 테이블 뷰에서 필터링하거나 그룹화하는 기준으로 활용될 때 그 가치가 극대화된다. 또한, 특정 카테고리가 선택되었을 때 자동으로 특정 담당자가 지정되도록 설정할 수도 있어, 반복적인 할당 작업을 줄여준다.23

이러한 사용자 정의 필드와 카테고리는 단순히 정적인 데이터를 저장하는 필드를 넘어, 동적인 리포팅과 자동화의 핵심 기반이 된다. 예를 들어, ’고객사’라는 List 형식의 사용자 정의 필드를 생성하면, 이는 단순히 어떤 고객사와 관련된 작업인지를 기록하는 데 그치지 않는다. 작업 패키지 테이블 뷰에서 ’고객사별’로 작업을 그룹화하여 각 고객사별로 진행 중인 작업의 수와 총 예상 시간을 요약한 실시간 보고서를 즉석에서 만들어낼 수 있다.24 더 나아가, Enterprise 기능인 ’사용자 정의 액션(Custom Actions)’과 연계하면, “A 고객사의 Bug 유형 작업이 생성될 경우, 담당자를 ’고객 지원팀’으로 자동 할당하고 우선순위를 ’High’로 즉시 설정하라“와 같은 정교한 자동화 규칙을 구현할 수 있다.25 이처럼 잘 설계된 메타데이터(사용자 정의 필드와 카테고리)는 수동적인 데이터 관리를 예측 가능하고 자동화된 비즈니스 프로세스로 전환하는 강력한 열쇠가 된다.

3. 작업 패키지 생명주기 관리 (CRUD & Workflow)

3.1 생성(Create) 및 복제(Duplicate): 효율적인 작업 착수

OpenProject에서 작업 패키지를 생성하는 방법은 사용자의 상황과 목적에 따라 다양하게 제공되어 작업 착수의 효율성을 높인다.

• 테이블 뷰에서의 인라인(In-line) 생성: 작업 패키지 목록 하단의 + Create new work package 링크를 클릭하면, 마치 Excel 스프레드시트처럼 목록의 마지막 줄에 새로운 행이 추가된다. 여기서 바로 제목, 유형, 상태 등 주요 속성을 입력하고 Enter 키를 누르면 즉시 작업 패키지가 생성된다. 여러 개의 작업을 빠르게 목록화해야 할 때 매우 유용하다.26

• 분할 화면(Split Screen) 뷰에서의 상세 생성: 화면 우측 상단의 + Create 버튼을 클릭하고 생성할 유형을 선택하면, 왼쪽에는 기존 작업 목록이, 오른쪽에는 상세 정보 입력 양식이 있는 분할 화면이 나타난다. 이 방식은 제목, 설명, 담당자, 마감일 등 모든 속성을 처음부터 상세하게 입력하며 작업을 생성할 때 적합하다.8

• 전역(Global) 생성을 통한 빠른 접근: 페이지 상단 헤더의 + 아이콘을 클릭하면 현재 어떤 페이지에 있든지 상관없이 즉시 새로운 작업 패키지 생성 양식으로 이동할 수 있다. 이는 다른 모듈을 보다가 갑자기 새로운 작업을 등록해야 할 때 컨텍스트 전환 없이 빠르게 작업을 생성할 수 있게 해준다.8

• 컨텍스트 기반 생성: 간트 차트나 애자일 보드와 같은 특정 뷰 내에서도 직접 작업 패키지를 생성할 수 있다. 예를 들어, 간트 차트에서는 새로운 Task를 추가하여 타임라인에 바로 배치할 수 있고 27, 애자일 보드에서는 특정 상태(열)에 새로운 카드(작업 패키지)를 즉시 추가할 수 있다.28

복제(Duplicate) 기능은 반복적인 작업을 효율적으로 관리하기 위한 핵심 도구이다. 특정 작업 패키지를 복제하면, 원본의 제목, 설명, 유형, 우선순위 등 대부분의 속성 값이 그대로 복사된 새로운 생성 양식이 나타난다.29 사용자는 일부 정보만 수정하여 새로운 작업을 신속하게 생성할 수 있다. 이는 정기적으로 발생하는 유사한 버그 리포트, 테스트 케이스 생성, 표준화된 업무 요청 등에 매우 효과적이다.

3.2 조회(Read) 및 편집(Update): 정보 접근과 변경

생성된 작업 패키지의 정보를 조회하고 최신 상태로 유지하는 것은 프로젝트 관리의 기본이다. OpenProject는 이를 위해 직관적인 인터페이스와 강력한 편집 기능을 제공한다.

작업 패키지 정보는 주로 세 가지 뷰 모드를 통해 조회할 수 있다 30:

• 테이블 뷰(Table View): 모든 작업 패키지를 목록 형식으로 보여주며, 여러 작업의 상태를 한눈에 비교하고 분석하는 데 용이하다.

• 분할 화면 뷰(Split Screen View): 테이블 뷰에서 특정 작업 패키지를 클릭하면, 화면 오른쪽에 해당 작업의 상세 정보가 나타난다. 목록과 상세 내용을 동시에 보면서 작업 간의 컨텍스트를 빠르게 전환할 수 있다.

• 전체 화면 뷰(Full Screen View): 특정 작업 패키지를 더블 클릭하면, 해당 작업의 모든 상세 정보가 화면 전체에 표시된다. 설명, 댓글, 활동 기록 등 하나의 작업에 집중하여 검토하거나 편집할 때 유용하다.

작업 패키지의 속성을 편집하는 것은 매우 직관적이다. 상세 뷰(분할 또는 전체 화면)에서 수정하고자 하는 필드(예: 설명, 담당자, 마감일)를 클릭하면 바로 편집 모드로 전환되며, 변경 사항을 입력하고 저장하면 된다.8

**일괄 편집(Bulk Edit)**은 OpenProject의 생산성을 극대화하는 강력한 기능이다. 테이블 뷰에서 Ctrl 키를 누른 채 여러 작업 패키지를 선택한 후, 마우스 오른쪽 버튼을 클릭하여 컨텍스트 메뉴를 열면 선택된 모든 작업에 대해 상태, 담당자, 우선순위, 버전 등을 한 번에 변경할 수 있다.32 이 기능은 단순한 편의성을 넘어, 프로젝트 관리자가 변화에 신속하게 대응하는 핵심 전략 도구로 작용한다. 예를 들어, 프로젝트 계획이 변경되어 특정 마일스톤에 포함된 모든 작업의 마감일을 일주일씩 연기해야 하거나, 특정 팀원이 휴가를 가게 되어 그의 모든 미결 작업을 다른 팀원에게 재할당해야 하는 상황을 생각해보자. 수십, 수백 개의 작업 패키지를 하나씩 수정하는 것은 엄청난 시간을 소모할 뿐만 아니라 인적 오류를 유발할 가능성이 높다. 일괄 편집 기능을 사용하면, “X 스프린트에 할당된 모든 ‘Bug’ 유형 작업의 담당자를 Y에서 Z로 변경“과 같은 복잡하고 중요한 변경 작업을 단 몇 번의 클릭만으로 정확하고 신속하게 수행할 수 있다. 이는 프로젝트의 변화 대응 속도(agility)를 극적으로 향상시키고, 관리자가 반복적인 수작업에서 벗어나 더 전략적인 의사결정에 집중할 수 있도록 돕는다. 또한, 대규모 업데이트 시 관련자들에게 과도한 알림 이메일이 발송되는 것을 방지하기 위해, 일괄 편집 시 알림 전송을 비활성화하는 옵션도 제공된다.32

3.3 워크플로(Workflow) 설계: 프로세스의 규칙화

워크플로는 작업 패키지가 생성부터 완료까지 거치게 되는 생명주기를 정의하는 규칙의 집합이다. OpenProject에서 워크플로는 ’역할(Role)’과 ’유형(Type)’의 조합에 따라 허용되는 ‘상태(Status)’ 간의 전환을 제어하는 방식으로 구현된다.19 이는 조직의 고유한 업무 프로세스를 시스템에 내재화하여 일관성을 유지하고 오류를 방지하는 핵심적인 거버넌스 기능이다.

워크플로 설계는 Administration -> Work packages -> Workflow 메뉴에서 이루어진다. 설정 과정은 다음과 같다 33:

1. 컨텍스트 선택: 워크플로를 정의할 ’역할(예: Developer, Project Manager, QA)’과 ’작업 패키지 유형(예: Bug, Feature)’을 드롭다운 메뉴에서 선택한다.

2. 전환 규칙 설정: 화면에 상태 전환 매트릭스(matrix)가 표시된다. 행(row)은 현재 상태를, 열(column)은 전환될 수 있는 새로운 상태를 나타낸다. 특정 역할과 유형에 대해 허용할 상태 전환을 체크박스로 선택한다. 예를 들어, ‘Developer’ 역할이 ‘Bug’ 유형의 상태를 ’New’에서 ’In Progress’로 변경하는 것은 허용하지만, ’New’에서 ’Closed’로 바로 변경하는 것은 허용하지 않도록 설정할 수 있다.

3. 조건부 규칙 추가: 작업의 ’작성자(Author)’이거나 ’담당자(Assignee)’인 경우에만 특별히 허용되는 전환 규칙을 추가로 설정할 수 있다. 예를 들어, 일반 사용자는 댓글만 달 수 있지만, 담당자는 상태를 변경할 수 있도록 권한을 세분화할 수 있다.33

새로운 상태 값(예: ‘For Review’, ‘On Hold’)이 필요하다면 Administration -> Work packages -> Status 메뉴에서 먼저 생성해야 한다.18

이러한 워크플로 기능은 조직의 프로세스를 시스템에 강제함으로써 업무 품질을 통제하고, 잠재적인 병목 지점을 식별하는 강력한 거버넌스 도구로 기능한다. 예를 들어, 소프트웨어 개발 프로세스에서 ‘Bug’ 유형에 대해 다음과 같은 워크플로를 설계할 수 있다. ‘Developer’ 역할은 상태를 ‘New’ → ‘In Progress’ → ’Resolved’로만 전환할 수 있다. ‘QA’ 역할만이 ‘Resolved’ 상태의 버그를 검증하고 ‘Tested’ → ’Closed’로 전환하거나, 문제가 재발견되면 ‘Reopened’ 상태로 되돌릴 수 있다. 이러한 워크플로는 개발자가 충분한 테스트를 거치지 않고 임의로 버그를 종결시키는 것을 시스템적으로 방지한다. 이는 단순히 상태 변경을 관리하는 것을 넘어, 각 업무 단계의 담당자와 책임을 명확히 정의하고, 사전에 합의된 프로세스를 모든 구성원이 일관되게 따르도록 강제하여 최종 산출물의 품질을 보장하는 역할을 수행한다.

3.4 워크플로 자동화: 사용자 정의 액션(Custom Actions) (Enterprise 기능)

워크플로가 프로세스의 ’규칙’을 정의한다면, ’사용자 정의 액션(Custom Actions)’은 그 규칙의 실행을 ’자동화’하는 기능이다. 이는 Enterprise 에디션에서 제공되는 고급 기능으로, “단 한 번의 클릭으로 미리 정의된 여러 작업 패키지 속성을 동시에 변경하는 지능형 워크플로 자동화 버튼“이라고 할 수 있다.10

사용자 정의 액션은 Administration -> Work packages -> Custom actions 메뉴에서 설정하며, 두 가지 주요 요소로 구성된다 25:

• 조건(Conditions): 이 자동화 버튼이 어떤 상황에서 작업 패키지 화면에 나타날지를 정의한다. 예를 들어, “상태가 ’New’이고, 유형이 ’Feature’이며, 현재 사용자의 역할이 ’Project Manager’일 때“만 특정 버튼이 보이도록 설정할 수 있다.

• 동작(Actions): 사용자가 해당 버튼을 클릭했을 때 어떤 속성들이 어떻게 변경될지를 정의한다. 상태 변경뿐만 아니라 담당자, 우선순위, 마감일, 사용자 정의 필드 값 등 거의 모든 속성을 동시에 업데이트할 수 있다.

이 기능의 강력함은 실제 활용 사례를 통해 명확히 드러난다. 예를 들어, ‘신규 기능 아이디어 승인’ 프로세스를 자동화하는 시나리오를 생각해보자.10

1. 초기 상태: 아이디어가 ‘New’ 상태로 등록된다.

2. 승인 버튼: 프로젝트 관리자에게만 ’아이디어 승인(Approve Idea)’이라는 사용자 정의 액션 버튼이 보인다.

3. 자동화된 동작: 관리자가 이 버튼을 클릭하면, 시스템은 다음과 같은 동작을 한 번에 수행한다.

• 상태를 ’New’에서 ’Approved’로 변경한다.

• 담당자를 아이디어 제안자에서 ’개발팀 리더’로 변경한다.

• 우선순위를 ’Normal’로 설정한다.

• 시작일을 오늘 날짜로, 마감일을 2주 후로 자동 설정한다.

• 관련자들에게 변경 사항에 대한 알림을 보낸다.

이처럼 사용자 정의 액션은 기존의 워크플로를 ’수동적 규칙’에서 ’능동적 자동화’의 차원으로 격상시킨다. 일반적인 워크플로에서는 사용자가 상태를 ’Approved’로 변경한 뒤, 담당자를 찾아 할당하고, 우선순위를 설정하는 등 여러 단계를 수동으로 거쳐야 한다. 이 과정은 번거로울 뿐만 아니라, 일부 단계를 누락하는 인적 오류(human error)를 유발할 수 있다. 사용자 정의 액션은 이 모든 과정을 하나의 원자적 트랜잭션(atomic transaction)으로 묶어버린다. 이를 통해 조직은 프로세스의 표준화를 완벽하게 강제할 수 있으며, 담당자의 인지 부하를 크게 줄여주고, 데이터의 정합성과 일관성을 보장하여 전체적인 업무 처리 속도와 품질을 극대화할 수 있다.

4. 작업 패키지 관계망 구성: 계층과 의존성

4.1 수직적 관계: 계층 구조(Hierarchies)와 WBS

OpenProject는 작업 패키지 간의 부모-자식(parent-child) 관계 설정을 통해 수직적인 계층 구조를 구성할 수 있는 강력한 기능을 제공한다.34 이 기능은 복잡한 프로젝트나 대규모 작업을 관리 가능한 작은 단위로 체계적으로 분해하는 작업 분할 구조(Work Breakdown Structure, WBS)를 구현하는 데 필수적이다.

자식 작업 패키지를 추가하는 방법은 여러 가지가 있다 34:

• ‘Relations’ 탭 활용: 부모가 될 작업 패키지의 상세 뷰에서 ‘Relations’ 탭으로 이동한 후, + Relation 버튼을 클릭하여 ‘Create new child’(새로운 자식 생성) 또는 ‘Add existing child’(기존 작업 패키지를 자식으로 추가)를 선택한다.

• 테이블 뷰에서의 컨텍스트 메뉴 활용: 테이블 뷰에서 자식이 될 작업 패키지를 선택하고 마우스 오른쪽 버튼을 클릭한 후, ‘Indent hierarchy’(계층 들여쓰기)를 선택하면 바로 위에 있는 작업 패키지의 자식으로 편입된다.

일단 계층 구조가 설정되면, 이는 단순한 시각적 그룹화를 넘어서는 중요한 기능적 의미를 갖게 된다. 부모 작업 패키지의 주요 속성들, 특히 진척도(% Complete), 예상 시간(Work), 잔여 시간(Remaining work) 등은 더 이상 독립적인 값이 아니라, 그 아래에 있는 모든 자식 작업 패키지들의 값을 집계하여 자동으로 계산되는 종속적인 값이 된다.14

이 자동 집계 메커니즘은 상향식(Bottom-up) 비용 및 진척도 관리를 자동화하는 핵심적인 역할을 한다. 프로젝트 관리자는 프로젝트의 가장 세분화된 최하위 레벨의 작업(자식 패키지)에 대해서만 예상 시간을 입력하면 된다. 그러면 OpenProject는 이 값들을 자동으로 합산하여 상위 단계(부모 패키지) 및 프로젝트 전체의 총 예상 시간을 실시간으로 계산해준다.14 프로젝트가 진행됨에 따라, 각 팀원이 자신의 담당 작업(자식 패키지)의 진척도를 업데이트하면, 부모 작업 패키지의 진척도 역시 각 자식 작업의 예상 시간을 가중치로 한 평균값으로 자동 업데이트된다. 이는 관리자가 개별 작업의 세세한 진행 상황을 일일이 추적하는 마이크로매니징의 부담에서 벗어나, 프로젝트 전체의 현황과 리스크를 거시적인 관점에서 정확하고 시의적절하게 파악할 수 있도록 돕는 매우 강력한 기능이다.

4.2 수평적 관계: 의존성(Relations) 관리

프로젝트 내의 작업들은 단순히 상하 관계만으로 이루어지지 않는다. 어떤 작업은 다른 작업이 끝나야만 시작할 수 있거나, 특정 작업의 완료가 다른 작업의 상태에 영향을 미치는 등 복잡한 수평적 관계를 맺고 있다. OpenProject는 이러한 기능적, 시간적 의존성을 모델링하기 위해 다양한 ‘관계(Relations)’ 유형을 제공한다.34

관계 설정은 작업 패키지의 ‘Relations’ 탭에서 이루어지며, 사용자는 상황에 맞는 최적의 관계 유형을 선택해야 한다. 각 관계 유형은 고유한 의미와 시스템적 효과를 가지므로, 그 차이를 명확히 이해하는 것이 중요하다.

이처럼 다양한 관계 유형을 적절히 활용하면 프로젝트의 복잡한 내부 의존성 네트워크를 명확하게 시각화하고 관리할 수 있다. 특히 ‘선행/후행’ 관계와 ‘차단’ 관계는 비슷해 보이지만 그 효과가 근본적으로 다르다는 점을 이해하는 것이 중요하다. ‘선행/후행’ 관계는 작업의 ’일정(schedule)’에 직접적인 영향을 미치며 간트 차트에서 자동으로 일정을 조정하는 역할을 한다.35 반면, ‘차단’ 관계는 작업의 ‘상태(status)’ 변경을 제한하여, 정의된 프로세스 순서를 강제하는 역할을 한다.34 이러한 미묘하지만 중요한 차이를 이해하고 올바른 관계를 설정하는 것은 프로젝트의 리스크를 사전에 식별하고, 병목 현상을 방지하며, 전체적인 작업 흐름을 원활하게 유지하는 데 결정적인 역할을 한다.

5. 작업 패키지 시각화 및 분석

OpenProject는 동일한 작업 패키지 데이터를 다양한 관점에서 조망할 수 있도록 여러 가지 시각화 뷰(View)를 제공한다. 각 뷰는 고유한 목적과 장점을 가지며, 프로젝트 관리자와 팀원은 상황에 따라 최적의 뷰를 선택하여 데이터를 분석하고 의사결정을 내릴 수 있다.

5.1 테이블 뷰(Table View): 데이터 기반 분석의 중심

테이블 뷰는 모든 작업 패키지를 행(row)으로, 각 속성을 열(column)으로 표시하는 가장 기본적이면서도 강력한 데이터 분석 도구이다.30 단순한 목록 표시 기능을 넘어, 사용자가 원하는 형태로 데이터를 가공하고 분석할 수 있는 다채로운 설정 기능을 제공한다.24

• 열(Columns) 구성: 열 설정 메뉴를 통해 보고서에 필요한 속성(기본 및 사용자 정의 필드 포함)만 선택하여 표시하고, 드래그 앤 드롭으로 순서를 자유롭게 변경할 수 있다.

• 필터(Filters): 하나 이상의 조건을 조합하여 원하는 데이터만 정확하게 추출할 수 있다. 예를 들어, “담당자가 ’나’이고, 상태가 ‘Open’ 또는 ’In Progress’이며, 마감일이 ’이번 주’인 모든 ‘Bug’ 유형 작업“과 같은 복잡한 쿼리를 GUI를 통해 손쉽게 생성할 수 있다.

• 그룹화(Group by): 특정 속성을 기준으로 작업들을 그룹화하여 표시할 수 있다. ’담당자’를 기준으로 그룹화하면 각 팀원이 어떤 작업을 얼마나 맡고 있는지 명확하게 파악할 수 있고, ’상태’를 기준으로 그룹화하면 프로젝트의 전체적인 병목 현황을 한눈에 볼 수 있다.

• 정렬(Sort): 우선순위, 마감일 등 여러 속성을 기준으로 다중 정렬을 적용하여 데이터를 원하는 순서로 나열할 수 있다.

• 합계 표시(Display sums): Work(예상 시간), Remaining work(잔여 시간), % Complete(진척도)와 같은 숫자 형식의 속성에 대해 그룹별 소계 및 전체 총계를 자동으로 계산하여 표시해준다.

이러한 기능들을 조합하면, 테이블 뷰는 단순한 데이터 목록이 아니라, 사용자가 직접 만드는 ’커스텀 리포팅 엔진’으로 변모한다. 관리자는 별도의 비즈니스 인텔리전스(BI) 도구나 복잡한 엑셀 작업 없이도 “팀원별 주간 미처리 작업의 총 예상 시간”, “우선순위별 버그 분포 현황 및 해결률”, “고객사별 프로젝트 진행률” 등 다양한 관점의 심층적인 보고서를 즉석에서 생성할 수 있다. 이렇게 정교하게 구성된 뷰는 개인화된 ’저장된 뷰(Saved View)’로 저장하여 언제든지 다시 불러오거나, ’공개 뷰(Public View)’로 설정하여 다른 팀원들과 공유할 수 있다.24 이는 데이터에 기반한 신속하고 정확한 의사결정을 조직 문화로 정착시키는 데 핵심적인 역할을 한다.

5.2 간트 차트(Gantt Chart): 시간축 기반의 프로젝트 계획

간트 차트는 프로젝트의 모든 작업 패키지를 수평적인 타임라인 위에 막대 형태로 시각화하여, 프로젝트 전체의 일정과 작업 간의 선후 관계를 조망하는 데 최적화된 뷰이다.27

간트 차트의 주요 기능은 다음과 같다:

• 직관적인 일정 조정: 타임라인 위의 막대 바를 마우스로 드래그 앤 드롭하여 작업의 시작일과 종료일을 손쉽게 변경할 수 있다. 막대의 양 끝을 조절하여 기간을 늘리거나 줄이는 것도 가능하다.27

• 의존성 시각화 및 자동 조정: 작업 간의 ‘선행/후행(Precedes/Follows)’ 관계가 화살표 선으로 명확하게 표시된다. 여기서 핵심은, 선행 작업의 일정이 변경(예: 지연)되면, 그에 의존하는 모든 후행 작업들의 일정이 자동으로 연쇄 조정된다는 점이다.27

• 계층 구조(WBS) 표시: 부모-자식 관계가 들여쓰기 형태로 시각화되어, 프로젝트의 전체적인 구조를 파악하기 용이하다.35

• 기준선(Baseline) 비교 (Enterprise 기능): 프로젝트 계획 수립 시점의 초기 계획(기준선)을 스냅샷으로 저장한 후, 실제 진행 상황을 나타내는 현재의 간트 차트와 겹쳐서 표시할 수 있다. 이를 통해 계획 대비 실적의 차이(지연 또는 단축)를 시각적으로 명확하게 확인할 수 있다.9

OpenProject의 간트 차트는 단순히 완성된 계획을 보여주는 정적인 그림이 아니다. 이는 프로젝트 계획을 수립하고, 다양한 시나리오를 시뮬레이션하며, 변화에 대응하여 계획을 동적으로 조정하는 ’상호작용적인 계획 도구’이다. 예를 들어, 프로젝트 관리자는 간트 차트 상에서 특정 핵심 작업의 기간을 임의로 며칠 늘려보는 것만으로도, 그 작업에 의존성을 가진 모든 후속 작업들의 일정이 연쇄적으로 어떻게 밀리는지, 그리고 최종 프로젝트 완료일에 어떤 영향을 미치는지 즉시 시각적으로 확인할 수 있다. 이러한 시뮬레이션 기능은 잠재적인 병목 현상이나 리스크를 사전에 식별하고, “특정 작업에 리소스를 추가 투입하여 기간을 단축했을 때의 효과“나 “작업 순서를 변경했을 때의 전체 일정 변화” 등 여러 대안의 결과를 비교 분석하여 최적의 프로젝트 계획을 수립하는 데 결정적인 도움을 준다.

5.3 애자일 보드(Agile Boards): 워크플로 중심의 협업

애자일 보드는 칸반(Kanban) 또는 스크럼(Scrum)과 같은 애자일 방법론을 적용하여 팀의 작업 흐름을 시각적으로 관리하기 위한 도구이다.15 보드는 일반적으로 ‘To Do’, ‘In Progress’, ’Done’과 같이 작업의 상태를 나타내는 여러 개의 수직적인 리스트(열)와, 각 리스트 안에 위치하는 개별 작업 패키지를 나타내는 카드(card)로 구성된다.

OpenProject는 두 가지 종류의 애자일 보드를 제공한다:

• Basic Board (Community Edition): 사용자가 원하는 이름으로 자유롭게 리스트를 생성하고, 카드를 리스트 간에 자유롭게 이동시킬 수 있다. 이 보드의 가장 큰 특징은 카드를 다른 리스트로 옮겨도 해당 작업 패키지의 속성(예: 상태)이 자동으로 변경되지 않는다는 점이다. 이는 아이디어 수집, 브레인스토밍 결과 정리 등 정형화된 워크플로가 필요 없는 자유로운 형태의 목록 관리에 적합하다.28

• Action Board (Enterprise Edition): 이 보드의 각 리스트는 작업 패키지의 특정 속성 값과 직접적으로 매핑된다. 예를 들어, ’Status Action Board’의 ‘New’, ‘In Progress’, ‘Done’ 리스트는 각각 작업 패키지의 ‘New’, ‘In Progress’, ‘Done’ 상태에 해당한다. 사용자가 카드를 ‘In Progress’ 리스트에서 ‘Done’ 리스트로 드래그 앤 드롭하면, 시스템은 이 행위를 해당 작업 패키지의 상태를 ’Done’으로 변경하는 명령으로 인식하고 속성을 자동으로 업데이트한다. 이는 팀의 작업 흐름을 표준화하고 상태 업데이트를 자동화하는 데 필수적인 기능이다.28 Action Board는 상태(Status) 외에도 담당자(Assignee), 버전(Version), 상위 작업(Parent) 등 다양한 속성을 기준으로 생성할 수 있다.

Action Board는 팀의 작업 흐름을 실시간으로 시각화하고, 사전에 정의된 프로세스 규칙을 강제하며, 상태 업데이트와 같은 반복적인 작업을 자동화하는 ‘살아있는 워크플로’ 그 자체이다. 개발자가 ‘In Progress’ 리스트에 있는 카드를 ‘For Review’ 리스트로 옮기는 행위는 단순히 보드 위의 시각적 위치를 바꾸는 것이 아니다. 시스템의 관점에서 이는 ’해당 작업 패키지의 상태를 In Progress에서 For Review로 변경’하는 명확한 트랜잭션이다. 이와 연동하여, 담당자를 자동으로 QA 리더에게 재할당하고, 관련자들에게 리뷰 요청 알림을 보내는 등의 후속 조치를 자동화할 수 있다. 이는 팀원들이 복잡한 상태 변경 절차나 규칙을 일일이 기억할 필요 없이, 보드 위에서 카드를 옮기는 직관적인 행위만으로도 조직이 정의한 프로세스를 정확하게 따르도록 유도한다. 이를 통해 병목 현상을 쉽게 식별하고, 작업의 흐름을 최적화하며, 팀 전체의 협업 효율성을 극대화할 수 있다.

6. 결론: OpenProject 작업 패키지의 전략적 활용

이 안내서에서 살펴본 바와 같이, OpenProject의 작업 패키지는 단순한 ‘할 일’ 항목을 넘어, 프로젝트의 모든 구성 요소를 담아내는 유연하고 강력한 핵심 개념이다. 작업 패키지는 고유한 **유형(Type)**과 다채로운 **속성(Attribute)**을 통해 자신의 정체성을 정의하고, **워크플로(Workflow)**와 **사용자 정의 액션(Custom Actions)**을 통해 예측 가능한 생명주기를 따르며, **계층(Hierarchy)**과 **관계(Relation)**를 통해 프로젝트 내에서 복잡한 관계망을 형성한다. 그리고 이 모든 정보는 테이블 뷰, 간트 차트, 애자일 보드 등 다양한 시각화 도구를 통해 사용자의 목적에 맞게 분석되고 활용된다.

이러한 기능들은 독립적으로 존재하는 것이 아니라, 서로 유기적으로 긴밀하게 연결되어 시너지를 창출한다. 예를 들어, 관리자가 정의한 ’작업 패키지 유형’은 특정 ‘워크플로’ 규칙을 활성화하는 트리거가 된다. 작업 간에 설정된 ’선행/후행 관계’는 ’간트 차트’의 일정을 자동으로 조정하는 기반이 되며, ’애자일 보드’에서의 카드 이동은 ’워크플로’에 정의된 상태 변경을 자동으로 실행시킨다. 그리고 이 모든 활동의 결과는 최종적으로 ’테이블 뷰’에서 정량적인 데이터로 집계되고 분석될 수 있다.

따라서 OpenProject의 작업 패키지 기능을 성공적으로 도입하고 활용하기 위해서는 조직의 프로젝트 관리 성숙도에 따른 단계적인 접근이 필요하다.

• 1단계 (도입기): 기본 추적 및 가시성 확보

• 기본으로 제공되는 작업 패키지 유형(Task, Bug 등)과 핵심 속성을 활용하여 모든 업무를 중앙에서 추적하는 것부터 시작한다. 테이블 뷰를 통해 단순한 작업 목록을 관리하며, 프로젝트의 모든 활동을 가시화하는 데 집중한다.

• 2단계 (성장기): 프로세스 구조화 및 계획 수립

• 조직의 용어에 맞는 ’사용자 정의 필드’와 ’카테고리’를 도입하여 데이터를 체계적으로 구조화한다. 간트 차트를 활용하여 프로젝트의 전체 일정을 계획하고 의존성을 관리하며, Basic Board나 간단한 Status Action Board를 통해 팀의 작업 흐름을 시각화하기 시작한다.

• 3단계 (성숙기): 워크플로 자동화 및 최적화

• 조직의 표준 업무 프로세스를 ’워크플로’로 정교하게 설계하여 시스템에 내재화한다. 반복적이고 오류 발생 가능성이 높은 작업들은 ’사용자 정의 액션’을 통해 자동화하여 인적 오류를 최소화하고 효율을 극대화한다. 데이터 주권, 투명성과 같은 OpenProject의 핵심 철학을 조직의 IT 거버넌스 전략에 통합하여 장기적인 가치를 창출한다.

결론적으로, OpenProject의 작업 패키지 시스템은 단순한 ’프로젝트 관리 도구’의 기능을 넘어선다. 이는 조직의 고유한 프로세스를 담아내는 유연한 프레임워크이자, 모든 프로젝트 데이터를 중앙에서 통제하고, 다양한 분석 관점을 제공하여 데이터 기반의 합리적인 의사결정을 지원하는 강력한 **‘프로젝트 관리 운영체제(Project Management Operating System)’**의 핵심 커널(kernel)이라 할 수 있다. 이 커널을 얼마나 깊이 이해하고 전략적으로 활용하는가에 따라 조직의 프로젝트 수행 능력과 경쟁력은 근본적으로 달라질 것이다.

7. 참고 자료

1. OpenProject - 오픈 소스 프로젝트 관리 소프트웨어. 강력함. 사용하기 쉬움. 무료. - Reddit, https://www.reddit.com/r/opensource/comments/7smowz/openproject_open_source_project_management/?tl=ko
2. OpenProject 소개 by 기윤 맹 on Prezi, https://prezi.com/p/7gqezommxdb3/openproject/
3. About OpenProject - Open Source Project Management Software, https://www.openproject.org/about-us/
4. OpenProject - Open Source Project Management Software, https://www.openproject.org/
5. en.wikipedia.org, https://en.wikipedia.org/wiki/OpenProject
6. Jira vs OpenProject | Which Project Management Software Wins In 2025? - SelectHub, https://www.selecthub.com/project-management-software/jira-vs-openproject/
7. Work packages - OpenProject, https://www.openproject.org/docs/user-guide/work-packages/
8. Introduction to Work Packages - OpenProject, https://www.openproject.org/docs/getting-started/work-packages-introduction/
9. The open source alternative to Jira - OpenProject, https://www.openproject.org/blog/open-source-jira-alternative/
10. Customize and automate your workflows - OpenProject, https://www.openproject.org/blog/customize-workflows/
11. Compare Jira Software vs OpenProject in September 2025 - SoftwareSuggest, https://www.softwaresuggest.com/compare/jira-vs-openproject
12. Compare Jira vs. OpenProject in 2025 - Software - Slashdot, https://slashdot.org/software/comparison/JIRA-vs-OpenProject/
13. Manage work package types - OpenProject, https://www.openproject.org/docs/system-admin-guide/manage-work-packages/work-package-types/
14. Frequently asked questions (FAQ) for work packages - OpenProject, https://www.openproject.org/docs/user-guide/work-packages/work-packages-faq/
15. Project management terminology - OpenProject, https://www.openproject.org/blog/project-management-terminology/
16. Backlogs configuration - OpenProject, https://www.openproject.org/docs/system-admin-guide/backlogs/
17. Working with Backlogs - OpenProject, https://www.openproject.org/docs/user-guide/backlogs-scrum/work-with-backlogs/
18. Manage work package status - OpenProject, https://www.openproject.org/docs/system-admin-guide/manage-work-packages/work-package-status/
19. Project Collaboration Software Features - OpenProject, https://www.openproject.org/collaboration-software-features/
20. API: Work Packages - OpenProject, https://www.openproject.org/docs/api/endpoints/work-packages/
21. Manage custom fields - OpenProject, https://www.openproject.org/docs/system-admin-guide/custom-fields/
22. Workflows and Customization - OpenProject, https://www.openproject.org/collaboration-software-features/workflows-customization/
23. Work packages - OpenProject, https://www.openproject.org/docs/user-guide/projects/project-settings/work-packages/
24. Work package table configuration - OpenProject, https://www.openproject.org/docs/user-guide/work-packages/work-package-table-configuration/
25. Automated workflows with custom actions (Enterprise add-on) - OpenProject, https://www.openproject.org/docs/system-admin-guide/manage-work-packages/custom-actions/
26. Create Work packages - OpenProject, https://www.openproject.org/docs/user-guide/work-packages/create-work-package/
27. Gantt charts - OpenProject, https://www.openproject.org/docs/user-guide/gantt-chart/
28. Boards for Agile Project Management - OpenProject, https://www.openproject.org/docs/user-guide/agile-boards/
29. Duplicate, move to another project or delete a work package - OpenProject, https://www.openproject.org/docs/user-guide/work-packages/duplicate-move-delete/
30. Work packages views - OpenProject, https://www.openproject.org/docs/user-guide/work-packages/work-package-views/
31. OpenProject - Work Package Views - Rod Hill’s Service Desk, https://hesk.rodhill.net/knowledgebase.php?article=7
32. Edit work packages - OpenProject, https://www.openproject.org/docs/user-guide/work-packages/edit-work-package/
33. Manage work package workflows - OpenProject, https://www.openproject.org/docs/system-admin-guide/manage-work-packages/work-package-workflows/
34. Work package relations and hierarchies - OpenProject, https://www.openproject.org/docs/user-guide/work-packages/work-package-relations-hierarchies/
35. OpenProject Work Package Relations and Hierarchies - YouTube, https://www.youtube.com/watch?v=pTKQkAxFKXM
36. Introduction to Gantt charts - OpenProject, https://www.openproject.org/docs/getting-started/gantt-chart-introduction/
37. How to create, configure and manage your projects with OpenProject, https://www.openproject.org/blog/create-configure-manage-projects-openproject/