Jira Software 8.6 ~ 8.8 릴리스 노트

Jira Software 8.6 ~ 8.8 릴리스 노트:

• 8.6 Release Notes: https://confluence.atlassian.com/jirasoftware/jira-software-8-6-x-release-notes-978220007.html
• 8.7 Release Notes: https://confluence.atlassian.com/jirasoftware/jira-software-8-7-x-release-notes-990550432.html
• 8.8 Release Notes: https://confluence.atlassian.com/jirasoftware/jira-software-8-8-x-release-notes-994314852.html

이번 포스트는 Jira Software 8.6 ~ 8.8 버전 릴리스들을 모아서 보겠습니다.
(사실 8.6 릴리스에 추가된 기능이 많고 8.7, 8.8 릴리스에는 크게 소개할만한 내용은 없습니다.)

Jira 8.6

2019년 12월에 릴리스한 버전입니다.

하이라이트 (Highlights)

• Jira copies over changes files on upgrade
• New JVM code cache check
• Replying to JIRA notifications in Outlook made way better
• Users and roles made better
• PostgreSQL 10 comes to Jira
• Several older platforms get deprecated
• Prefix and suffix search
• Accessible dropdown menus
• Configurable scheme parameters in Jira REST API for projects creation
• Burnup charts in Jira Software
• Self-protect and sleep easy with rate limiting
• New information in the audit log
• Cluster monitoring

8.6 릴리스는 앞선 8.5 엔터프라이즈 릴리스 후에 나온 버전이라 업데이트된 기능들이 많습니다.
시스템 관리자가 알아야 하는 내용보다 태스크 관리 및 프로젝트 관리 측면의 기능 내용을 중점으로 살펴보겠습니다.

Replying to JIRA notifications in Outlook made way better

많은 사용자들의 요청에 의해 추가된 기능입니다.
Outlook에서 Jira 이슈 알림 메일에 댓글을 남길 수 있도록 하는 기능을 세팅할 수 있게 되었네요.
설명 상으로는 2개의 기능을 deprecate 했다고 하네요.

• Add a comment from the non-quoted email body
• Create a new issue or add a comment to an existing issue

설정과 관련한 내용은 이 링크에서 확인할 수 있습니다.
참고차 설정 링크에는 기능을 어떻게 설정할 수 있는 방법보다는 개론과 같은 내용이 있습니다.
(Jira 어드민이 대충 이런 느낌으로 사용하면 될 것이다의 느낌이에요.)

Users and roles made better

기존에는 하나하나 role 그룹에 유저들을 추가해줘야 했다면 이제는 체크박스를 이용해서 더 간편하게 수정할 수 있도록 변경되었습니다.
다만 그전에는 롤에 따라서 어떤 유저가 있는지 한분에 볼 수 있었는데 지금은 roles 메뉴를 눌러서 볼 수 있도록 변경되었습니다.
(지금 상태가 조금 더 잘 정리되어 보이는 것 같긴 합니다. ㅎㅎ)

Prefix and suffix search

지난 8.0 릴리스에는 Prefix 검색에 대해서 지원을 시작했는데 이번 8.6부터 suffix 검색도 추가되었다고 합니다. 👏

검색 기능이 조금씩 개선되는 것 같아 좋네요! :)

Accessible dropdown menus

드롭다운 메뉴에 대해서 스크롤이 추가되었다는 내용입니다.
기존에는 메인화면을 내려야 했다면 드롭메뉴 자체에 스크롤이 생겨서 편하게 메뉴를 볼 수 있게 되었네요.

Burnup charts in Jira Software

번업(Burnup) 차트 기능이 Jira Server에도 추가되었습니다.
앞으로 애자일 보드 -> 리포트에서 새로운 번업 차트를 볼 수 있게 되었네요.

More granular sprint permissions

하이라이트에는 없는 내용이지만 언급이 필요해 보여서 넣었습니다.
스프린트 관리 권한에 대해 몇 가지가 분리되어 추가되었습니다. 이에 따라 스프린트 관리를 사용자 권한에 맞게 부여할 수 있게 되었습니다.
기존에 있던 Manage Sprint 권한은 있으나 Start/Complete sprints, Edit sprints 두 가지 권한이 추가되었네요.
앞으로는 스프린트를 시작, 완료하는 사용자와 삭제도 할 수 있는 사용자 등으로 나눠서 관리할 수 있겠습니다.

그 외의 데이터 센터 내용은 스킵합니다.
(관리자 기능이기도 하고 크게 소개할 내용은 없어 보여서 스킵합니다.)

Jira 8.7

2020년 2월에 릴리스한 버전입니다.

하이라이트 (Highlights)

• Anonymizing users for GDPR compliance
• PostgreSQL 11 support
• OpenID Connect comes to Jira

GDPR 관련 내용, DB 시스템, OpenID(데이터 센터) 등에 대한 릴리스로 일반 유저를 위한 기능 업데이트는 없네요.
8.6 버전에 많이 업데이트하고 나서 안정화하는 버전이었는지 기능 추가는 없었네요.
다음 8.8 버전으로 넘어가겠습니다~

Jira 8.8

2020년 3월에 릴리스한 버전입니다.

하이라이트 (Highlights)

• Revamped Audit log
• Dates for future sprints
• Jira loves accessibility
• Access Data Center features on Server infrastructure

Revamped Audit log

데이터 센터 버전과 몇 가지 기능이 다를 수는 있겠지만 서비스 로그에 대해서 추가적으로 볼 수 있도록 기능이 개선되었습니다.

• 어떤 로그를 어느 기간 동안 보관할 것 인지를 설정할 수 있습니다. (you can decide which events are logged and how long you want to keep them)
• 로그들에 대해 더 자세히 알 수 있습니다. (you can filter the events, expand each for further details, and export the audit log if necessary)
• 카테고리로 정리된 로그를 통해 로그 확인이 개선되었습니다. (by getting an audit log that’s clear and categorized, you don’t need to spend time browsing through piles of events.)
• 나머지는 데이터 센터 내용이라서 스킵합니다.
  • 인스턴스와 관련한 로그를 확인할 수 있다는 내용과 3rd 파티 툴 연동 등에 대한 내용이 포함되어있습니다.

위 개선 사항들은 Administration> System > Audit log 에서 확인하실 수 있습니다.

Dates for future sprints

미래 스프린트를 위해 날짜 입력을 할 수 있도록 업데이트되었네요.
기존에는 스프린트에 날짜를 입력하도록 Required(필수 입력) 설정되어있었는데 미래 스프린트 계획을 위해 추가된 기능으로 보입니다.

Jira loves accessibility

https://confluence.atlassian.com/jirasoftwareserver/accessibility-998878998.html
개인 설정을 통해서 상태(Status)의 색/무늬를 변경할 수 있도록 할 수 있게 되었네요.
관련한 자세한 내용은 위 링크에서 보실 수 있습니다.

마무리

8.6 ~ 8.8 버전을 모두 살펴보았습니다.
8.6 버전에는 추가/수정된 기능들이 많았네요. 8.7, 8.8 버전은 안정화 업데이트 같은 느낌을 받았습니다.
한 달마다 버전 업데이트를 하고 있는데 버그 내용도 하나하나 보고 싶지만 이번 포스트에서는 스킵하고 다음 버전에서는 코멘트할 내용이 있을지 보겠습니다.

감사합니다. :)

Jira Software 8.5 릴리스 노트

Jira Software 8.5.x 릴리스 노트: https://confluence.atlassian.com/jirasoftware/jira-software-8-5-x-release-notes-975014654.html

2019년 10월에 릴리스된 Jira Software 8.5 기능에 대해 살펴보는 포스트입니다.
위 릴리스 노트에서 자세한 내용을 보실 수 있으며, 이 포스트는 주관적인 생각을 담고 있습니다.

하이라이트 (Highlights)

• Distribute the Jira Server mobile app to managed devices
• New JVM check available
• Hungry for new features?
• API change log
• Enterprise releases, performance-wise
• Resolved issues

이번 8.5 릴리스는 하이라이트 리스트를 보면 새로운 피쳐는 없습니다.
이번 릴리스에서 중요한 것은 엔터프라이즈 버전이라는 것입니다.

Distribute the Jira Server mobile app to managed devices

jira server에서 모바일 기기에 따라 제한할 수 있도록 하는 기능이 추가되었네요.
관련 내용은 Mobile Device Management(MDM) 문서를 참고해주세요.

Enterprise release

릴리스 노트에 대해서 소개하려고 했는데 특별히 소개할 내용이 없네요.
앞서 말씀드렸듯이 엔터프라이즈 버전 릴리스라서 특별히 소개드릴 피쳐가 추가되지 않았습니다.
8.5 버전이 엔터프라이즈 버전이라는 의미는 중요한 보안, 안정성, 데이터 무결성 및 성능 문제를 해결하기 위해 8.5의 수명이 다할 때까지 버그 수정 릴리스를 제공한다는 의미입니다.

마무리

8.4 릴리스 소개 글에서는 8.5가 기대된다고 했는데 새로운 기능이 없는 릴리스였습니다.
다음 8.6, 8.7에는 무엇이 추가되었는지 다음 포스트에서 정리해보겠습니다~

Jira 이슈 링크(issue link) 삭제하기

관련 포스트: Bulk remove change Jira issue links
위 포스트에서는 이슈에 걸려있는 모든 링크를 삭제하는 것을 공유드렸었습니다.
이번 포스트에서는 이슈에 걸려있는 링크 중에 특정 타입의 링크를 삭제하는 방법을 공유해보겠습니다.

이슈 - 이슈 링크

Jira에서 이슈와 이슈를 연결해주는 이슈 링크,
전의 포스트에서는 링크를 그냥 다 삭제하는 포스트였기에 자세히 다루지는 않았지만 이번 포스트에서는 링크 타입에 대해 알아야 정확하게 삭제할 수 있기에 조금 더 자세히 설명해보고자 합니다.

위와 같이 이슈 링크 속성에는 Name, Outward Description, Inward Description 항목이 있습니다.

한국어 버전으로는 이슈 링크 속성 이름이 명확한지 모르겠지만 다음과 같네요. 이름(Name), 가르키는 입장 설명(Outward Desc), 받는 입장 설명(Inward Desc)

Jira 시스템에 기본적으로 있는 이슈 링크 타입은 4개로 Blocks, Cloners, Duplicate, Relates 이렇게 구성되어 있습니다.
각각 링크 타입 항목들을 보면 이슈와 이슈를 연결했을 때 각 이슈에 보이는 링크의 이름이 다르게 보일 수 있도록 설정할 수 있습니다.

이슈 링크를 설정하고 어떻게 보이는지 아래의 문서 링크를 참고하시면 좋을 것 같습니다.
(EN) Jira Docs: linking issues

“이슈 - 이슈 링크”의 관계를 정리해보자면, 아래와 같이 볼 수 있겠습니다.

• 이슈는 목적지
• 이슈 링크는 출발지와 도착지 정보를 가지고 있는 화살표

이슈 링크 타입 확인해보자

개념적인 설명은 이만 마치고 스크립트를 통해 이슈에 있는 이슈 링크들을 한번 확인해보겠습니다.
우선 테스트를 위해 이슈에 설정한 이슈 링크들은 아래와 같습니다.

링크된 항목들을 정리해보면 다음과 같습니다. 괄호 내용은 이슈 링크 이름입니다.

• PUB-16 (blocks) PUB-1
• PUB-16 (blocks) PUB-2
• PUB-16 (blocks) PUB-3
• PUB-16 (clones) PUB-5570
• PUB-16 (duplicates) PUB-17
• PUB-16 (is blocked by) PUB-4

PUB-16 이슈에 연결된 이슈 링크들을 확인하기 위한 스크립트 입니다.
스크립트를 ScriptRunner에 Script console에서 실행된 내용을 볼 수 있습니다.

스크립트 코드

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

import com.atlassian.jira.component.ComponentAccessor
import com.atlassian.jira.issue.IssueManager
import com.atlassian.jira.jql.parser.JqlQueryParser
import com.atlassian.jira.bc.issue.search.SearchService
import com.atlassian.jira.web.bean.PagerFilter
import com.atlassian.query.Query

def searchService = ComponentAccessor.getComponent(SearchService)
def jqlQueryParser = ComponentAccessor.getComponent(JqlQueryParser)
def user = ComponentAccessor.getJiraAuthenticationContext().getLoggedInUser()
def results = searchService.search(user, jqlQueryParser.parseQuery("key=PUB-16"), PagerFilter.getUnlimitedFilter())
def issueManager = ComponentAccessor.getIssueManager()
def issueLinkManager = ComponentAccessor.getIssueLinkManager()

results.getResults().each
{
  def issue = issueManager.getIssueObject(it.id)
  log.warn("Get InwardLinks")
  def linkInwardList = issueLinkManager.getInwardLinks(issue.getId())
  linkInwardList.each {
    log.warn("${it.getIssueLinkType().getName()}, ${it.getSourceObject().getKey()}")
  }
  log.warn("Get OutwardLinks")
  def linkOutwardList = issueLinkManager.getOutwardLinks(issue.getId())
  linkOutwardList.each {
    log.warn("${it.getIssueLinkType().getName()}, ${it.getDestinationObject().getKey()}")
  }
}

스크립트 실행 결과

1
2
3
4
5
6
7
8

...: Get InwardLinks
...: Blocks, PUB-4
...: Duplicate, PUB-17
...: Get OutwardLinks
...: Blocks, PUB-1
...: Blocks, PUB-2
...: Blocks, PUB-3
...: Clones, PUB-5570

이슈 링크 타입에 따라 이슈 링크를 삭제해보자

이슈 링크 타입을 확인했으니 이슈 링크 타입에 따라 삭제할 수 있게 되었습니다.
사실 위 링크 확인 스크립트 코드에서 타입과 inward/outward 만 확인해서 이슈 링크 삭제 함수만 사용하면 우리가 원하는 링크 삭제가 가능합니다.

이슈 링크 타입 확인 & 삭제

이슈 링크 타입을 확인하는 것 자체는 어렵지 않습니다.
issueLinkObj.getIssueLinkType().getName()로 이름을 확인하면 되니까요.
다만 Inward, Outward 링크 타입을 확인해야하는데, 삭제할 때에 아래 옵션을 선택할 수 있도록 함수를 만들어야겠네요.

• Inward 링크만
• Outward 링크만
• 모든 링크

삭제 함수도 간단합니다. 참고: Jira API Docs: IssueLinkManager.removeIssueLink()
아래 함수를 위에서 확인한 이슈 링크를 파라미터로 호출하면 링크 삭제가 가능합니다.

1
2
3

// issueLink - the issue link to remove
// remoteUser - needed for creation of change items
void removeIssueLink(IssueLink issueLink, ApplicationUser remoteUser)

스크립트 코드

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

import com.atlassian.jira.component.ComponentAccessor
import com.atlassian.jira.issue.IssueManager
import com.atlassian.jira.jql.parser.JqlQueryParser
import com.atlassian.jira.bc.issue.search.SearchService
import com.atlassian.jira.web.bean.PagerFilter
import com.atlassian.query.Query
import com.atlassian.jira.issue.MutableIssue

def searchService = ComponentAccessor.getComponent(SearchService)
def jqlQueryParser = ComponentAccessor.getComponent(JqlQueryParser)
def issueManager = ComponentAccessor.getIssueManager()
def issueLinkManager = ComponentAccessor.getIssueLinkManager()

def user = ComponentAccessor.getJiraAuthenticationContext().getLoggedInUser()
// NOTE: jql options
def results = searchService.search(user, jqlQueryParser.parseQuery("key=PUBGTEST-3"), PagerFilter.getUnlimitedFilter())

// NOTE: remove link options
def removeLinkType = "Blocks"
def removeLinkIO = "all" // all, inward, outward

def removeInwardLinks = {MutableIssue issue ->
  def linkInwardList = issueLinkManager.getInwardLinks(issue.getId())
  linkInwardList.each {
    def link = it
    if (link.getIssueLinkType().getName() == removeLinkType) {
      log.warn("removed links: ${link.getIssueLinkType().getName()}, ${link.getSourceObject().getKey()}")
      issueLinkManager.removeIssueLink(link, user)
    }
  }
}
def removeOutwardLinks = {MutableIssue issue ->
  def linkInwardList = issueLinkManager.getOutwardLinks(issue.getId())
  linkInwardList.each {
    def link = it
    if (link.getIssueLinkType().getName() == removeLinkType) {
      log.warn("removed links: ${it.getIssueLinkType().getName()}, ${it.getDestinationObject().getKey()}")
      issueLinkManager.removeIssueLink(link, user)
    }
  }
}

results.getResults().each {
  def issue = issueManager.getIssueObject(it.id)
  if (removeLinkIO == "all" || removeLinkIO == "inward") {
    log.warn("Get & Remove InwardLinks")
    removeInwardLinks(issue)
  }

  if (removeLinkIO == "all" || removeLinkIO == "outward") {
    log.warn("Get & Remove OutwardLinks")
    removeOutwardLinks(issue)
  }
}

스크립트 결과

현재 스크립트 상으로는 all(inward, outward), blocks 타입의 링크만 삭제하도록 구성되어 있어 실행시 blocks 타입의 링크가 모두 삭제됩니다.

활용

위 스크립트를 활용시에는 NOTE: 라고 표시된 내용에 링크 삭제가 필요한 이슈, 링크 타입을 알맞게 변경을 한 뒤에 사용하시면 됩니다.
이슈 링크 삭제 시에 주의해서 사용해주세요!

마무리

이번 내용은 약간 길어졌는데요. 포스트를 작성하면서 이슈와 이슈 링크의 관계, 이슈 링크의 속성 등에 대해서 공부할 수 있어서 좋았고 이 글을 보시는 다른분들도 스크립트를 이용하여 원하는 이슈 링크를 삭제할 수 있었으면 좋겠습니다.
감사합니다. 😀

Jira 이슈에 연결되어있는 이슈 링크 한번에 삭제하기

참고: https://community.atlassian.com/t5/Jira-questions/Bulk-remove-change-issue-links-in-Jira/qaq-p/659381

문제 인식

최근 특정 Jira 이슈에 연결된 이슈들을 삭제해야하는 일이 있었습니다.
(한 작업 이슈에 확인한 버그를 모두 링크를 달고 링크된 버그 이슈들을 보다가 링크 타입이 잘못된 것도 있는 등의 이슈가 있어 수정이 필요했습니다.)
Bulk로 링크들을 삭제하는 기능이 있는지 찾아보았는데 없더군요. 그래서 스크립트러너로 가능한지 찾아보았습니다.

다행히, 당연하게도 이미 같은 고민을 했던 사람들이 있었고 아틀라시안 커뮤니티 채널에 해결방법이 있었습니다.
기본 Jira 기능에는 없지만 스크립트러너를 사용해서 가능하다는 것이었죠.

제가 현재 사용하고 있는 Jira 버전은 8.5여서 위 링크의 8.x 코드를 보면서 설명해보고자 합니다.
(위 링크에 7.13 버전에서 사용할 수 있는 코드도 있으니 참고해서 쓰시면 됩니다.)

문제 해결 방법 (ScriptRunner)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

import com.atlassian.jira.component.ComponentAccessor
import com.atlassian.jira.issue.IssueManager
import com.atlassian.jira.jql.parser.JqlQueryParser
import com.atlassian.jira.bc.issue.search.SearchService
import com.atlassian.jira.web.bean.PagerFilter
import com.atlassian.query.Query

def searchService = ComponentAccessor.getComponent(SearchService)
def jqlQueryParser = ComponentAccessor.getComponent(JqlQueryParser)
def user = ComponentAccessor.getJiraAuthenticationContext().getLoggedInUser()
def results = searchService.search(user, jqlQueryParser.parseQuery("Your JQL Filter"), PagerFilter.getUnlimitedFilter())
def issueManager = ComponentAccessor.getIssueManager()

results.getResults().each
{
  def issue = issueManager.getIssueObject(it.id)
  log.warn(issue.key)
  // get all linked issues
  log.warn(ComponentAccessor.issueLinkManager.getLinkCollection(issue, user).getAllIssues())
  ComponentAccessor.issueLinkManager.removeIssueLinks(issue, user)
}

로그 관련한 코드는 설명 중 불필요하여 삭제했습니다. 실제 코드 동작하는데에 영향이 없습니다.
사실 코드 상으로는 크게 어려운 부분이 없습니다.

스크립트 Flow

1. 검색, JQL 파서, 사용자, 이슈 컨트롤러를 정의한다. (검색 및 설정 준비 과정)
2. JQL을 통해 이슈들을 가져온다.
3. 각 이슈들의 모든 링크를 삭제한다.

issueLinkManager, removeIssueLinks

issueLinkManager 인터페이스 설명은 jira/docs/api/8.5.1/…/IssueLinkManager 이 문서에서 볼 수 있습니다.
이 매니저에는 여러가지 함수들이 있습니다. 이슈 링크의 생성, 삭제, 조회, 변경 등이 가능합니다.

removeIssueLinks() 함수도 위 issueLinkManager에서 볼 수 있는데요.

1
2
3
4
5
6

int removeIssueLinks(Issue issue, ApplicationUser remoteUser)
// Parameters:
// issue - the Issue
// remoteUser - the remote user
// Returns:
// The total number of issuelinks deleted.

모든 링크를 삭제하고자하는 이슈와 삭제할 때 필요한 사용자를 받아 함수가 동작합니다.

스크립트 결과

맨 처음 이미지를 보여드렸던 이슈의 키를 JQL로 입력하고 실행해보겠습니다.
“key=PUBGTEST-112”로 입력하고 스크립트 콘솔에서 테스트 해보았습니다.

Logs:

1
2

2020-02-23 02:16:42,545 WARN [runner.AbstractScriptRunner]: PUBGTEST-112
2020-02-23 02:16:42,545 WARN [runner.AbstractScriptRunner]: [PUBGTEST-75, PUBGTEST-111, PUBGTEST-225]

Timing: Elapsed: 4949 ms / CPU time: 531 ms
동작하는데 생각보다 시간이 많이 걸리긴 하네요.
(약 5초 정도 걸리는 것으로 보이는데 링크 삭제가 오래걸리는 것인지 다른 것이 오래걸리는 것인지는 봐야겠습니다.)

실행 결과로는 이슈의 히스토리에 아래와 같이 남았습니다.

링크가 걸려있는 이슈의 모든 이슈 링크들이 삭제되었습니다! 👍

문제 해결!

제가 했던 하나의 이슈만 링크를 삭제할 수도 있고 JQL로 검색된 모든 이슈들의 모든 링크를 삭제할 수 있습니다.
다만 여기서 제가 원했던 것은 모든 링크의 삭제가 아니라 특정 타입의 링크들만 삭제하고 싶었던 것이어서
다음 포스트에서는 특정 링크 타입의 링크를 삭제하는 내용으로 한번 더 다뤄봐야겠습니다.

다음 포스트에서 만나요! :)

Tech PM(Project Manager)이란 무엇일까?

지금까지 약 2년 동안 개발 PM으로 일해왔는데, 내가 상상하고 생각했던 개발 PM이 지금 하는 일과 같은가? 하는 내안의 질문이 있었다.

개발자(엔지니어)로 앱 개발하다가 개발 PM으로 전직하고나서 전직 전에 내가 생각했던 일을 하고 있는지, 내가 잘알고 있었던 것인지 되짚어보고 싶어졌다.

내가 생각했던 Tech PM부터 한번 알아보고, 내가 왔던 길과 가야할 길을 정리해보고자 한다.

Tech PM 구글에 찾아보면…

구글에 Tech PM이라고 검색해보면 그렇게 많은 내용은 나오지 않는다. 아래 링크를 보면 대략적인 기술 PM의 역할을 볼 수 있지만.. 내가 알고 있는 개발 PM의 일반적인 내용을 담고 있어서 “기술 PM이 그래서 뭐가 다른 것이지?” 하는 의문이 있었다.

https://www.wrike.com/project-management-guide/faq/what-is-technical-project-management/

링크에 있는 내용을 정리해보면 3줄 정도로 요약해볼 수 있다.

• IT 프로젝트에서 기술 지식 기반으로 프로젝트를 관리할 수 있음.
• 기본적인 프로젝트 매니저가 하는 일을 함.
• 큰 그림도 볼 줄 알아야하며 전반적인 기술 지식도 있어야 함.

결론, 소프트웨어 개발 PM으로 일하는 데에 어려움이 없을 정도로 지식이 있는 PM이면 된다.
(너무 일반적인 내용이라서 자세하게 안본 탓도 있는 것 같지만, 뭔가 딱 이거야! 하는 내용이 없었다.)
이 정도 내용으로는 내가 생각하는 기술 PM이 설명되지 않은 것 같아 더 찾아보기로 했다.

Technical PM 업무 소개서(Job Description) 보기

다른 회사의 기술 PM 업무 소개서를 보면 알 수 있지 않을까?로 시작된 조사!

https://www.indeed.com/m/jobs?q=Technical+Project+Manager

• 몇 가지 JD를 보면서 각 회사마다 원하는 바가 많이 다르다는 것을 알 수 있었다.
• Oracle, IBM 등 IT 솔루션을 판매하는 회사의 경우 내부 기술 PM이라기보다 기술 영업 PM의 느낌이 강하다.
  • 기술을 이해하며 해당 솔루션을 영업하는 업무
  • 기술적인 부분에 대해 고객과 커뮤니케이션하는 TAM(Technical Account Manager)
• IT 회사가 아니지만 기술 PM이 필요한 경우에는 내가 지금하고 있는 개발 PM과 다를 것이 없는 듯 하다.
  • 일반적인 IT 서비스 개발 PM (일반적이라는 말이 모호하긴하지만 더 좋은 표현은 못찾겠다.)

TAM(Technical Account Manager)은 또 뭐지?

그러던 중 TAM과 관련한 내용도 계속해서 나오길래, 한번 찾아보게 되었다.
https://www.buzzvil.com/ko/2018/12/26/buzzvil-people-jen-yoon-technical-account-manager/

• 버즈빌에서 TAM 업무를 하고 있는 분의 인터뷰 글.
• 연동 문서 관리 / 내외부 이슈 해결 / 프로세스 세팅 및 개선 업무를 하고 있다고 한다.

https://cloud.google.com/tam/?hl=ko

• 구글 클라우드에서 TAM 팀은 약간 컨설턴트 느낌이다.
• 다른 TAM도 마찬가지이긴 한데 구글은 B2B 관련 일이 많아 그런 것 같다.

https://aws.amazon.com/ko/careers/support/employee3/

• AWS의 TAM 업무 소개 페이지.
• TAM이 하는 업무에 대해 소개하고 지원 버튼이 밑에 있다.

Technical Program Manager도 있네?

https://www.amazon.jobs/en/jobs/990061/technical-program-manager

찾다보니 내가 하고자했던 것이 기술 프로그램 매니저였을까 하는 물음표가 생겼다.

처음에 내가 하고싶었던 일이 프로젝트 매니저였는지 프로그램 매니저였는지 모호한 상태이고, 회사마다 PM의 정의가 다르기 때문에 이 용어를 분리해서 이야기하는게 큰 의미는 없을 수 있다.
(참고 링크: “프로덕트, 프로그램, 프로젝트 매니저? 뭐가 다른가요?” )

다만 내가 원했던 일은 엔지니어 경험을 활용해서 개발팀의 전체적인 프로세스가 잘 진행될 수 있도록 돕고 싶었고, 일이 효율적으로 진행될 수 있도록하고 싶었다.

위 참고 링크에서는 프로그램 매니저, 프로젝트 매니저를 이렇게 설명한다.

• 프로그램 매니저는 제품을 어떻게 에 모든 열정을 쏟는 역할
  • 어떻게 제품을 만들지, How에 집중하는 역할로 이해했다.
• 프로젝트 매니저는 제품을 언제 에 관심이 있는 역할
  • 제품을 언제까지 만들 수 있을지, 언제 내보낼 수 있을지 When에 집중하는 역할로 이해했다.

정리해보면 전직 전에는 “어떻게 개발을 잘할 수 있을까” 같은 고민을 하면서 일하겠지? 했지만, 지금하고 있는 일은 언제 출시할 수 있을지 관리하는 프로젝트 매니저일을 하고 있는 것 같다.
(물론 전체 조직의 개발 생산성에 관심이 많아 생산성을 올릴 수 있는 도구들도 도입해보고 개발해보는 등 프로그램 매니저일도 약간은 하고 있다는 생각도 든다.)

Tech PM, 프로젝트 매니저든 프로그램 매니저든

맨처음으로 돌아가서.. 내가 하고싶어하는 Tech PM의 정의는 무엇일까 정리해보자.
이 글을 쓰기 전에 페이스북에 “여러분들이 생각하는 Tech PM(Technical Project Manager)는 어떤 모습인가요?” 질문을 올렸었는데, 회사 동료분의 말이 와닿아서 같이 정리해본다.

PM도 포함해서 사람들이 모호하게 정의한다고 생각해요. 프로그래머에게 바라는게 무엇인가요? 하는 느낌같은…? 상황, 경험과 역량에 따라 천차만별이 아닐까요?

회사마다 PM을 정의하는게 다르고 팀마다 다르고 경험과 역량에 따라 다 달라진다는 것을 한번 더 확인받은 기분이었다.

정리하다보니 더 심플해지는 것 같지만, “어떤 역량과 경험을 가지고 일하는지에 따라 PM 역할은 달라질 수 있다. Tech PM이라는 역할에 갇히지말고 역량을 키우자” 정도로 내 생각을 마무리해본다.

위에 있는 정리된 내용으로 기본적인 Tech PM 정의는 된 것 같지만, 아직 한국에서는 PM의 명칭, 역할이 명확하게 구분되어 있지 않아 딱 이거다하는 정의는 어려운 것 같다.

이정도로 생각을 마무리해본다.
다음 글에서 더 성장한 생각의 글을 쓸 수 있기를!