IT·소프트웨어 개발사

이 문서는 개발자 10~80명 규모의 소프트웨어 회사를 떠올리며 썼습니다. SI든 자체 서비스든 게임이든, "일이 프로젝트 단위로 쪼개지고, 그 안에서 결정과 기록이 계속 쌓이는" 조직이라면 대체로 맞습니다.

이런 조직에는 공통된 고민이 하나 있습니다. 기록이 없어서 문제가 되는 게 아니라, 기록이 너무 여러 군데 흩어져 있어서 문제가 됩니다. 스펙은 위키에, 결정은 슬랙에, 일정은 지라에, 회의록은 누군가의 노션에 있습니다. 반 년 뒤에 "이거 왜 이렇게 정했더라"를 되짚으려면 세 사람에게 물어봐야 합니다.

SynapseWorks가 이 회사 유형에서 값을 내는 지점이 정확히 거기입니다. 글·일정·회의·대화가 전부 같은 게시물 기반 위에 있고, 그것들을 프로젝트 트리에 붙여 둘 수 있고, 나중에 신경망 연관 뷰로 "무엇이 무엇과 이어져 있었는지"를 되짚을 수 있습니다.

---

이 회사의 하루

말로만 하면 잘 안 와닿으니, 가상의 회사 하나를 놓겠습니다. 직원 24명, 팀은 셋(플랫폼팀, 프론트팀, 기획팀), 지금 프로젝트는 두 개가 돌고 있습니다.

오전 9시 30분. 프론트팀 이지현 님이 노트북을 열고 홈 화면을 봅니다. "오늘 처리할 일 3건"이 떠 있습니다 — 출근 체크, 오늘 스프린트 리뷰 회의, 그리고 어제 올린 휴가 신청에 대한 팀장님 결재가 아직이라는 표시입니다. 출근 버튼을 누르고 회의 시간을 확인합니다.

오전 11시. 백엔드 쪽에서 API 응답 형식을 바꿔야 한다는 이야기가 메신저에서 나옵니다. 스무 줄쯤 오간 끝에 결론이 납니다. 팀장이 그 대화 중 결론이 담긴 메시지 옆의 고리 아이콘을 눌러 2026 상반기 플랫폼 개편 프로젝트에 근거로 연결해 둡니다. 3초 걸립니다.

오후 2시. 스프린트 리뷰. 회의 관리로 등록해 둔 회의라 회의록을 본문에 바로 씁니다. 논의 중에 "지난번 그 설계 문서"가 필요해지자, 회의록의 관련 게시물에서 검색해 붙입니다.

오후 6시. 팀장이 프로젝트 상세에서 하위 프로젝트들의 공정율을 확인합니다. 결제 모듈 이 65%인데 일정은 80%가 지났습니다 — 화면에 지연 배지가 떠 있습니다.

두 달 뒤. 새로 온 개발자가 "결제 응답 포맷이 왜 이 모양이죠?"라고 묻습니다. 프로젝트 상세의 연결된 대화를 펼치면 그날의 스무 줄이 그대로 있습니다.

이 마지막 장면 하나를 위해 앞의 3초를 쓰는 것 — 그게 이 회사 유형의 사용법입니다.

---

무엇을 켜고 무엇을 미룰까

업무 영역	권장	이유
PMS	반드시	이 유형의 뼈대입니다. 일의 구조를 트리로 옮깁니다
게시판	반드시	업무일지·설계 문서·의사결정 기록이 여기 쌓입니다
회의 관리	반드시	회의록을 남길 자리. 참석 응답까지 관리됩니다
메신저	권장	결정의 절반은 채팅에서 납니다. 그걸 기록으로 끌어올립니다
일정 관리	권장	스크럼·릴리스 일정. 빈 시간 찾기가 특히 유용합니다
출결 관리	회사 정책에 따라	선택근로제를 쓴다면 아래 절을 꼭 보세요
전자결재	나중에	휴가·지출 결재가 필요해지는 시점에 켭니다
자산 관리	나중에	노트북·모니터 지급 관리가 필요해지면
자금 관리	대개 불필요	회계 담당이 따로 있는 회사라면 굳이
인맥 관리	대개 불필요	영업 조직이 있다면 그때

💡 이렇게 하면 편합니다

처음 도입이라면 PMS + 게시판 + 회의 관리 + 메신저 네 개로 시작하세요. 이 조합만 자리 잡아도 "흩어진 기록" 문제의 대부분이 정리됩니다.

---

뼈대 만들기 — 프로젝트 트리는 조직도가 아닙니다

가장 자주 보는 실수가 이겁니다. 프로젝트 트리를 조직도처럼 만드는 것입니다.

✗ 이렇게 만들지 마세요
개발본부
 ├─ 플랫폼팀
 ├─ 프론트팀
 └─ 기획팀

이렇게 만들면 트리가 1년 내내 변하지 않고, 공정율도 의미가 없어집니다. 부서는 이미 회사와 조직에 있습니다. 프로젝트 트리는 일의 구조입니다.

✓ 이렇게 만드세요
2026년 A서비스 개편                 ← 최상위(관리자가 만듭니다)
 ├─ 요구사항 정리
 ├─ DB 설계
 │   └─ 마이그레이션 계획
 ├─ 결제 모듈
 │   ├─ PG 연동
 │   └─ 정산 배치
 └─ 프론트 개편
     ├─ 디자인 시스템 정리
     └─ 화면 이관

최상위 프로젝트만 회사 관리자가 만듭니다. 그 아래로는 PM이 얼마든지 내려갈 수 있습니다. 그래서 관리자에게 매번 요청할 필요가 없고, 트리가 실제 일의 모양을 따라갑니다.

깊이는 어디까지가 적당할까

계층 제한은 없지만, 실무에서 3~4단이 넘어가면 관리가 안 됩니다. 기준은 이렇게 잡으세요.

• 말단 프로젝트 = 한 사람이 1~3주 안에 끝낼 수 있는 덩어리. 공정율을 손으로 입력하는 단위이므로, 너무 크면 "50%"가 아무 뜻이 없어집니다.
• 그보다 잘게 쪼개고 싶으면 프로젝트를 더 만들지 말고 게시판 글(업무일지)로 남기세요. 이슈 하나하나까지 프로젝트로 만들면 트리가 곧 못 볼 상태가 됩니다.

참여 인원과 역할

역할	할 수 있는 일	다면평가에서
PM	프로젝트 수정·삭제, 멤버 관리, 게시물 연결, 평가 세션 개시	하향(→팀원)
팀원	조회, 연결된 글 보기, 공정율 입력	동료 / 상향(→PM)
검토자	조회	동료
이해관계자	조회	동료

★ 꼭 알아 둘 것

상위 프로젝트의 참여 인원은 하위 프로젝트도 볼 수 있습니다(상속). 하지만 "참여 인원"으로 집계되지는 않습니다. 트리에서 흐리게 보이는 프로젝트가 그런 경우입니다. 다면평가 대상이 되게 하려면 그 프로젝트에 직접 배정해야 합니다.

---

매일 도는 흐름 — 기록을 프로젝트에 붙이는 습관

업무 등록 버튼을 쓰세요

프로젝트 상세의 [업무 등록] 을 누르면 게시판·일정·회의 작성 화면이 그 프로젝트를 물고 열립니다. 저장하는 순간 자동으로 그 프로젝트의 "연결된 게시물"에 붙습니다.

게시판에서 따로 글을 쓴 다음 프로젝트에 연결해도 결과는 같습니다. 다만 사람은 두 번째 단계를 잊습니다. 프로젝트 쪽에서 시작하는 습관을 들이면 연결이 빠지지 않습니다.

프로젝트에 기본 카테고리를 정해 두면 분류를 매번 고르지 않아도 됩니다.

게시판 분류는 성격별로 세 개면 충분합니다

분류	켤 것	왜
업무일지	댓글·답글·평가(CQI)	짧게 자주 쓰는 글. 서로 코멘트를 답니다
의사결정 기록(ADR)	보관주기·중요도, 답글 끄기	오래 남아야 하는 글. 중요도를 높게 두면 자동 폐기 대상에서 빠집니다
기술 자료·설계 문서	보관주기, 버전 기록	계속 고쳐 쓰는 글. 수정 이력에서 두 버전을 비교할 수 있습니다

분류를 더 잘게 나누고 싶은 유혹이 있는데, 분류가 늘면 사람들은 어디에 쓸지 고민하다 안 씁니다. 셋으로 시작해서 정말 안 맞을 때 늘리세요.

메신저에서 기록으로 — 두 가지 길

개발 조직에서 결정의 상당수는 채팅에서 납니다. 그걸 흘려보내지 않는 방법이 둘 있습니다.

① 대화 한 줄을 근거로 붙이기. 메시지 옆의 고리 아이콘을 누르고 프로젝트를 고릅니다. 남이 보낸 메시지도 붙일 수 있습니다 — 오히려 그게 주된 쓰임입니다("팀장님이 이렇게 결정하셨다"를 남기는 것). 유형은 참고자료 / 근거 / 결과보고 셋 중에 고릅니다.

② 대화 여러 건을 회의록·업무일지로 옮기기. 대화 화면 위쪽의 [대화 선택] 을 누르고 옮길 메시지를 고른 뒤 [회의록·업무일지로 옮기기]. 제목과 본문이 미리 채워진 작성 화면이 열리고, 저장하면 원본 대화가 자동으로 "근거"로 연결됩니다.

---

계획과 회고 — 간트차트와 타임라인을 나눠 쓰기

두 화면이 비슷해 보여서 자주 헷갈립니다. 쓰는 목적이 다릅니다.

	간트차트	타임라인 뷰
언제	계획할 때, 일정을 옮길 때	돌아볼 때, 회고할 때
보여 주는 것	프로젝트 막대와 의존 관계 화살표	프로젝트 막대 + 그 아래 연결된 글이 언제 있었는지
조작	막대를 끌어 날짜 변경(관리 권한 필요)	점을 눌러 그 글로 이동

같은 프로젝트를 지나온 기록 쪽에서 보면 타임라인 뷰입니다.

의존 관계는 "표시"이지 "제약"이 아닙니다

"A는 B가 끝나야 시작한다"를 등록하면 간트에 화살표가 그려지고, 순환(A→B→A) 등록이 막힙니다. 하지만 날짜를 강제로 막지는 않습니다. 선행이 안 끝나도 후행 날짜를 옮길 수 있습니다.

이건 의도한 동작입니다. 실제 개발에서는 "앞 작업이 80%쯤 됐으니 뒤를 먼저 시작한다"가 흔합니다. 시스템이 그걸 막으면 사람은 의존 관계를 아예 안 겁니다.

공정율은 말단에서만 입력합니다

• 말단(하위가 없는) 프로젝트에서만 담당자가 0~100%를 직접 입력합니다.
• 상위 프로젝트는 하위들의 기간 가중 평균으로 자동 계산됩니다. 기간이 긴 하위가 더 큰 비중을 갖습니다.
• 공정율·기간·오늘 날짜를 비교해 일정 건강도가 자동으로 붙습니다 — 정상 / 지연 (경과 대비 많이 뒤처짐) / 초과(종료일이 지났는데 100%가 아님).

---

출결 — 선택근로제와 재택을 그대로 담기

개발 조직은 출퇴근 시각이 자유롭고 재택이 섞이는 경우가 많습니다. 억지로 9시 출근을 찍게 만들면 기록이 거짓말이 됩니다. 그럴 필요가 없습니다.

근무 그룹의 근무제를 선택근로로 두면 지각을 판정하지 않습니다. 출퇴근 시각이 자유로운 제도이므로 "몇 시에 왔는가"로 사람을 보지 않고, 대신 주 근무시간 합계가 집계됩니다.

⚖️ 법으로 정해진 것

선택적 근로시간제(근로기준법 제52조)는 취업규칙에 근거를 두고 근로자대표와 서면 합의를 해야 적용할 수 있는 제도입니다. 정산기간·의무근로시간대 같은 항목이 합의서에 들어가야 합니다. 시스템에서 선택근로를 고르는 것은 그 제도를 이미 도입한 회사가 판정 방식을 맞추는 것이지, 설정만으로 제도가 도입되는 것은 아닙니다.

재택은 근태 신청 재택·외근으로 받습니다. 승인되면 그날 하루 IP 검사가 면제되므로, 사무실 IP 제한을 켜 둔 채로도 집에서 출퇴근을 찍을 수 있습니다.

💡 이렇게 하면 편합니다

사무실 IP 제한을 켤 생각이 없다면 재택 신청도 굳이 필요 없습니다. 그냥 찍으면 됩니다. 제한을 켠 회사에만 의미가 있는 조합입니다.

스프린트 막바지에 야근이 잦다면 연장근로 신청을 미리 받아 두세요. 인정 시간이 기록으로 남고, 주 52시간 경고와 함께 보면 무리한 일정을 사전에 발견할 수 있습니다.

⚖️ 법으로 정해진 것

주 52시간(법정 40 + 연장 12)은 위반 시 사업주가 처벌 대상입니다(근로기준법 제53조, 제110조). 시스템은 넘어가면 빨갛게 경고할 뿐 막지 않습니다. 막으면 사람은 안 찍고 일하게 되고, 그러면 기록이 실제보다 적게 남아 오히려 회사가 위험해집니다.

---

일정 — 스크럼과 회의 잡기

• 데일리 스크럼처럼 매일 같은 시간이면 반복 일정으로 한 번에 만듭니다(주기·간격· 총 횟수를 정하면 그 횟수만큼 실제 일정이 각각 만들어집니다).
• 스프린트 회의 시간 잡기는 빈 시간 찾기를 쓰세요. 참석자를 필수/선택으로 나눠 두면, 필수가 겹치는 시간은 아예 후보에서 빠지고 선택은 "몇 명 겹침"으로 알려 줍니다.
• 회의록을 남길 자리는 회의 관리로 만듭니다. 일정으로 만들었다가 나중에 [회의로 만들기] 로 옮겨도 됩니다.

일정과 회의를 가르는 기준은 하나입니다 — 회의록을 남길 일인가. 그것뿐입니다.

---

반 년 뒤를 위한 것 — 신경망 연관 뷰

이 화면은 당장 오늘 쓰는 화면이 아닙니다. 반 년쯤 기록이 쌓인 뒤에 값이 납니다.

• 글·회의·프로젝트가 점으로, 연결이 선으로 그려집니다.
• 명시적으로 건 "관련 게시물"뿐 아니라, A를 보다가 B로 건너간 기록도 선이 됩니다.
• 자주 조회·참조되는 자료는 밝게, 뜸해진 자료는 흐리게 표현됩니다.
• 작성자·기간으로 좁히고 타임라인을 재생하면 콘텐츠가 시간순으로 나타납니다.

"이 이슈, 예전에 비슷한 거 본 것 같은데"가 해결되는 자리입니다. 프로젝트 상세에서 [신경망 뷰] 를 누르면 그 프로젝트 범위로 좁혀집니다.

---

프로젝트가 끝나면 — 다면평가

프로젝트를 닫을 때 참여자끼리 서로를 평가할 수 있습니다. 개발 조직에서 특히 쓸모가 있는 이유는, 게시물 축의 일부를 시스템이 자동으로 집계하기 때문입니다 — 작성한 글 수, 그 글들의 평균 CQI, 댓글·참조, 일정 준수율. 사람이 기억으로 채점하지 않아도 되는 부분이 이미 채워져 있습니다.

1. PM이 프로젝트 상세의 [다면평가] 에서 세션을 만들고 가중치(직원/게시물/프로젝트, 합 100%)와 마감일을 정한 뒤 개시합니다.
2. 참여자가 상대를 별점과 코멘트로 평가합니다. 관계(상향/하향/동료/자기)에 따라 항목이 자동으로 달라집니다.
3. PM이 마감하면 개인별 E/P/J 점수와 최종 점수, 레이더 차트, 익명 코멘트가 나옵니다. 개인 보고서를 인쇄할 수 있습니다.

---

이 업종에서 자주 하는 실수

프로젝트를 이슈 단위로 만든다. 트리가 수백 개가 되고 아무도 안 봅니다. 말단은 1~3주 덩어리로, 그보다 잘면 게시판 글로.

연결을 안 건다. 글은 열심히 쓰는데 프로젝트에 안 붙여서, 반 년 뒤에 검색으로만 찾게 됩니다. [업무 등록] 버튼으로 시작하는 습관이 이걸 막습니다.

공정율을 안 고친다. 한 달 방치되면 건강도가 전부 "지연"이 되고, 그러면 신호로서 죽습니다. 스프린트 리뷰에 5분을 넣으세요.

분류를 열 개 만든다. 사람들은 어디에 쓸지 고민하다가 결국 안 씁니다. 셋에서 시작하세요.

메신저를 쓰면서 아무것도 안 남긴다. 이게 가장 아깝습니다. 결론이 난 메시지 하나에 고리를 거는 데 3초입니다.

---

첫 2주 계획

날	할 일	누가
1일차	업무 영역 켜기(PMS·게시판·회의·메신저)	관리자
1일차	부서 등록, 부서장 지정, 직원 계정 발급	관리자
2일차	게시판 분류 3개 만들고 권한 부여	관리자
2일차	회의 분류 1개(팀 회의) 만들기	관리자
3일차	최상위 프로젝트 1~2개 생성	관리자
3~4일차	PM이 하위 프로젝트를 스프린트/기능 단위로 쪼갬	PM
4일차	참여 인원 배정, 기본 카테고리 지정	PM
5일차	팀 전체에 안내 — "업무일지는 [업무 등록]으로"	팀장
2주차	첫 스프린트 리뷰를 회의 관리로 등록, 회의록 작성	전원
2주차 끝	공정율 첫 갱신, 타임라인 뷰로 2주 돌아보기	PM

💡 이렇게 하면 편합니다

3주차부터 출결·전자결재를 얹는 것을 권합니다. 처음부터 다 켜면 "쓸 게 너무 많다"는 인상이 먼저 생깁니다.

---

함께 볼 문서

• 화면별 사용법: 게시판 · PMS · 회의 관리 · 메신저
• 관리자 설정: PMS 관리 · 게시판 관리 · 출결 관리
• 프로세스: 프로젝트를 한 바퀴 돌린다 · 지식이 흐르게 한다