IT·소프트웨어 개발사
이 문서는 개발자 10~80명 규모의 소프트웨어 회사를 떠올리며 썼습니다. SI든 자체 서비스든 게임이든, "일이 프로젝트 단위로 쪼개지고, 그 안에서 결정과 기록이 계속 쌓이는" 조직이라면 대체로 맞습니다.
이런 조직에는 공통된 고민이 하나 있습니다. 기록이 없어서 문제가 되는 게 아니라, 기록이 너무 여러 군데 흩어져 있어서 문제가 됩니다. 스펙은 위키에, 결정은 슬랙에, 일정은 지라에, 회의록은 누군가의 노션에 있습니다. 반 년 뒤에 "이거 왜 이렇게 정했더라"를 되짚으려면 세 사람에게 물어봐야 합니다.
SynapseWorks가 이 회사 유형에서 값을 내는 지점이 정확히 거기입니다. 글·일정·회의·대화가 전부 같은 게시물 기반 위에 있고, 그것들을 프로젝트 트리에 붙여 둘 수 있고, 나중에 신경망 연관 뷰로 "무엇이 무엇과 이어져 있었는지"를 되짚을 수 있습니다. 수주형(SI) 회사라면 여기에 계약서 전자서명과 프로젝트별 손익이 더해집니다.
💡 이렇게 하면 편합니다체험 회사로 직접 보세요. 체험 회사 코어소프트(결제 솔루션 개발 · SI)와 널리지테크(제조 데이터 SaaS)가 이 문서의 모습을 실제 데이터로 보여 줍니다 — 반 년 치 프로젝트 트리(회사마다 일정이 밀린 프로젝트와 예산을 앞서 쓴 프로젝트가 하나씩 있습니다), 프로젝트에 걸린 결재 품의·계약서·장애 회고, 종료된 프로젝트와 완료보고서, 다면평가 (코어소프트는 진행 중, 널리지테크는 마감), 코어소프트의 주간 리스크 요약 초안까지 들어 있습니다. 계정과 비밀번호는 체험 페이지에 있고, 둘러보는 순서는 코어소프트 · 널리지테크 문서에 적어 두었습니다.
이 회사의 하루
말로만 하면 잘 안 와닿으니, 가상의 회사 하나를 놓겠습니다. 직원 24명, 팀은 셋(플랫폼팀, 프론트팀, 기획팀), 지금 프로젝트는 두 개가 돌고 있습니다.
오전 9시 30분. 프론트팀 이지현 님이 노트북을 열고 홈 화면을 봅니다. "오늘 처리할 일 3건"이 떠 있습니다 — 출근 체크, 오늘 스프린트 리뷰 회의, 그리고 어제 올린 휴가 신청에 대한 팀장님 결재가 아직이라는 표시입니다. 게시판에는 깃발이 붙은 필독 공지 하나 — "배포 승인 절차 변경"입니다. 열어 읽고, 출근 버튼을 누릅니다.
오전 10시. 플랫폼팀에서 업무요청이 하나 옵니다 — "스테이징 결제 API 응답 로그 좀 봐 주세요, 기한: 권장 금요일". 메신저로 부탁받았다면 대화에 묻혔을 일입니다. [수락]을 누르고 나중에 [완료]를 누르면, 요청한 사람이 결과를 보고 [확인]해야 끝납니다.
오전 11시. 백엔드 쪽에서 API 응답 형식을 바꿔야 한다는 이야기가 메신저에서 나옵니다.
스무 줄쯤 오간 끝에 결론이 납니다. 팀장이 그 대화 중 결론이 담긴 메시지 옆의 고리
아이콘을 눌러 2026 상반기 플랫폼 개편 프로젝트에 근거로 연결해 둡니다. 3초 걸립니다.
오후 2시. 스프린트 리뷰. 회의 관리로 등록해 둔 회의라 회의록을 본문에 바로 씁니다. 논의 중에 "지난번 그 설계 문서"가 필요해지자, 회의록의 관련 게시물에서 검색해 붙입니다. 바뀐 흐름은 본문에 mermaid 다이어그램으로 그려 둡니다 — 저장하면 글 상세에서 그림으로 보입니다.
오후 6시. 팀장이 프로젝트 상세를 엽니다. 맨 위 지표에서 결제 모듈이 계획 대비 뒤처져
있고, 그 아래 자금 대비 일정 카드는 "예산이 앞섬"입니다 — 일이 된 것보다 돈을 더 썼다는
뜻입니다. 지연 배지와 함께 다음 날 아침 회의 안건이 정해집니다.
두 달 뒤. 새로 온 개발자가 "결제 응답 포맷이 왜 이 모양이죠?"라고 묻습니다. 프로젝트 상세의 연결된 대화를 펼치면 그날의 스무 줄이 그대로 있습니다.
이 마지막 장면 하나를 위해 앞의 3초를 쓰는 것 — 그게 이 회사 유형의 사용법입니다.
무엇을 켜고 무엇을 미룰까
| 업무 영역 | 권장 | 이유 |
|---|---|---|
| PMS | 반드시 | 이 유형의 뼈대입니다. 일의 구조를 트리로 옮깁니다 |
| 게시판 | 반드시 | 업무일지·설계 문서·의사결정 기록이 여기 쌓입니다 |
| 회의 관리 | 반드시 | 회의록을 남길 자리. 참석 응답까지 관리됩니다 |
| 메신저 | 권장 | 결정의 절반은 채팅에서 납니다. 그걸 기록으로 끌어올립니다 |
| 업무요청 | 권장 | "이것 좀 봐 주세요"처럼 프로젝트로 만들기엔 작은 부탁을 잃지 않게 합니다 |
| 일정 관리 | 권장 | 스크럼·릴리스 일정. 빈 시간 찾기가 특히 유용합니다 |
| 문서 관리 | 권장 | 아키텍처 문서·API 명세·릴리스 산출물처럼 파일이 본체인 것을 버전과 함께 둡니다 |
| 출결 관리 | 회사 정책에 따라 | 선택근로제를 쓴다면 아래 절을 꼭 보세요 |
| 전자결재 | 나중에 | 휴가·지출 결재가 필요해지는 시점에 켭니다 |
| 판매 관리 | 수주형(SI)이면 | 견적 → 청구가 프로젝트 손익으로 이어집니다. 자체 서비스만 한다면 대개 불필요 |
| 전자문서 | 수주형(SI)이면 | 구축 계약서·NDA·검수 확인서를 고객에게 서명받고 봉인합니다 |
| 인맥 관리 · 거래처 | 영업 조직이 있다면 | 고객사를 회사 카드로 두고 담당자를 잇습니다 |
| 자산 관리 | 나중에 | 노트북·모니터·테스트 단말 지급 관리가 필요해지면 |
| 자금 관리 | 대개 나중에 | 회계 담당이 따로 있는 회사라면 굳이. 다만 프로젝트 비용을 적기 시작하면 필요해집니다 |
| 설문조사 | 나중에 | 해커톤 주제 투표·기능 우선순위 투표 정도로 가볍게 씁니다 |
💡 이렇게 하면 편합니다처음 도입이라면 PMS + 게시판 + 회의 관리 + 메신저 네 개로 시작하세요. 이 조합만 자리 잡아도 "흩어진 기록" 문제의 대부분이 정리됩니다. 업무요청은 한 달쯤 지나 "메신저로 부탁한 게 자꾸 빠진다"는 말이 나올 때 켜면 설득이 쉽습니다.
💡 회사를 새로 만든다면 업종 기본 세팅에서 IT · 소프트웨어 개발사 업종을 고를 수 있습니다. 그 업종에 맞는 업무 영역·직급·직책·게시판 분류·직무 매뉴얼이 한 번에 만들어지고, 상단 메뉴는 PMS · 업무요청 · 회의 관리 · 게시판 · 일정 관리 다섯 개만 켜진 채 시작합니다(나머지는 꺼져 있을 뿐이니 필요해지면 담당자에게 켜 달라고 하세요). 그대로 쓰라는 것이 아니라 출발점입니다 — 자세한 내용은 회사 유형별 추천 설정의 「업종 기본 세팅」 절.
뼈대 만들기 — 프로젝트 트리는 조직도가 아닙니다
가장 자주 보는 실수가 이겁니다. 프로젝트 트리를 조직도처럼 만드는 것입니다.
✗ 이렇게 만들지 마세요
개발본부
├─ 플랫폼팀
├─ 프론트팀
└─ 기획팀
이렇게 만들면 트리가 1년 내내 변하지 않고, 공정율도 의미가 없어집니다. 부서는 이미 회사와 조직에 있습니다. 프로젝트 트리는 일의 구조입니다.
✓ 이렇게 만드세요
2026년 A서비스 개편 ← 최상위(관리자가 만듭니다)
├─ 요구사항 정리
├─ DB 설계
│ └─ 마이그레이션 계획
├─ 결제 모듈
│ ├─ PG 연동
│ └─ 정산 배치
└─ 프론트 개편
├─ 디자인 시스템 정리
└─ 화면 이관
최상위 프로젝트만 회사 관리자가 만듭니다. 그 아래로는 PM이 얼마든지 내려갈 수 있습니다. 그래서 관리자에게 매번 요청할 필요가 없고, 트리가 실제 일의 모양을 따라갑니다.
★ 꼭 알아 둘 것최상위를 만들 때 관리자가 [하위 강제 종결 허용] 을 켤지 정합니다. 기본은 꺼짐이고 만든 뒤에는 바꿀 수 없습니다. "스프린트 몇 개는 정리 못 한 채 릴리스를 닫는 일이 흔하다"면 켜 두고, 아니면 꺼 둔 채 두세요(아래 「끝낼 때」 절).
깊이는 어디까지가 적당할까
계층 제한은 없지만, 실무에서 3~4단이 넘어가면 관리가 안 됩니다. 기준은 이렇게 잡으세요.
- 말단 프로젝트 = 한 사람이 1~3주 안에 끝낼 수 있는 덩어리. 공정율을 손으로 입력하는 단위이므로, 너무 크면 "50%"가 아무 뜻이 없어집니다.
- 그보다 잘게 쪼개고 싶으면 프로젝트를 더 만들지 말고 게시판 글(업무일지)로 남기세요. 이슈 하나하나까지 프로젝트로 만들면 트리가 곧 못 볼 상태가 됩니다.
참여 인원과 역할
| 역할 | 할 수 있는 일 | 다면평가에서 |
|---|---|---|
| PM | 프로젝트 수정·삭제, 하위 프로젝트 생성, 멤버 관리, 공정율 입력, 연결된 글 정리, 평가 세션 개시 | 하향(→PM이 아닌 참여 인원) |
| 팀원 | 조회, 연결된 글 보기, 글·자산 연결, 지출 등록 | 동료 / 상향(→PM) |
| 검토자 | 팀원과 같고, 공정율 변경을 승인 · 반려합니다 | 동료 / 상향(→PM) |
| 이해관계자 | 팀원과 같습니다 | 동료 / 상향(→PM) |
★ 꼭 알아 둘 것권한이 다른 역할은 PM과 검토자입니다. 검토자를 두면 PM이 바꾼 공정율은 검토자가 의견과 함께 승인해야 반영됩니다 (QA 리드가 「테스트 통과」를 확인하고 승인하는 식). 이해관계자는 팀원과 할 수 있는 일이 같고, 역할 이름은 맡은 몫(고객사 담당자 등)을 알아보게 하는 표시입니다.
★ 상위 프로젝트의 참여 인원은 하위 프로젝트도 볼 수 있습니다(상속). 하지만 "참여 인원"으로 집계되지는 않습니다. 트리에서 흐리게 보이는 프로젝트가 그런 경우입니다. 다면평가 대상이 되게 하려면 그 프로젝트에 직접 배정해야 합니다.
프로젝트와 업무요청 — 어디에 담을까
업무요청을 켜면 곧 이 질문이 나옵니다. "이것도 프로젝트로 만들어야 하나?" 기준은 간단합니다.
| 프로젝트로 | 업무요청으로 |
|---|---|
| 여러 사람이 여러 날 매달린다 | 한 사람이 한 번에 끝낸다 |
| 기획하고 일정을 나누고, 끝나면 돌아본다 | 끝나면 사라진다 |
| "결제 모듈 개편", "B사 구축 2차" | "스테이징 로그 봐 주세요", "테스트 계정 하나 만들어 주세요" |
개발 조직에서 업무요청이 특히 값을 내는 자리는 팀 사이의 부탁입니다. 같은 팀 안의 일은 프로젝트와 업무일지로 충분하지만, 플랫폼팀이 프론트팀에 부탁한 일은 메신저에 묻히기 쉽습니다.
- 담당자는 한 명만 고릅니다. 여럿이면 아무도 자기 일이라고 생각하지 않습니다.
- 급하지 않은 부탁은 기한을 「여유」 로 두세요. 날짜를 억지로 적지 않아도 30일마다 "아직 필요한 일인가요?"를 물어봐 줍니다.
- 장애 신고는 종류를 「장애·오류 신고」 로 고르면 기한 기본값이 「마감 확정」이 됩니다.
- 업무요청 한 건도 게시물이라 프로젝트에 연결할 수 있습니다. 부탁이 커져서 프로젝트의 일부가 됐다면 프로젝트 상세의 [게시물 연결] 에서 업무요청 탭을 골라 붙이세요.
★ 꼭 알아 둘 것「완료」와 「확인함」은 다릅니다. 담당자가 완료를 눌러도 요청한 사람이 확인해야 끝납니다. "했는데요?" — "그건 제가 부탁한 게 아닌데요"가 끝난 뒤가 아니라 그 자리에서 드러납니다. 자세한 흐름은 업무요청.
매일 도는 흐름 — 기록을 프로젝트에 붙이는 습관
업무 등록 버튼을 쓰세요
프로젝트 상세의 [업무 등록] 을 누르면 게시판·일정·회의 작성 화면이 그 프로젝트를 물고 열립니다. 저장하는 순간 자동으로 그 프로젝트의 "연결된 게시물"에 붙습니다.
![프로젝트에서 [업무 등록]을 눌러 열린 게시판 글쓰기](/scenario-shots/s02-pms-tasknew.png)
게시판에서 따로 글을 쓴 다음 프로젝트에 연결해도 결과는 같습니다. 다만 사람은 두 번째 단계를 잊습니다. 프로젝트 쪽에서 시작하는 습관을 들이면 연결이 빠지지 않습니다.
프로젝트에 기본 카테고리를 정해 두면 분류를 매번 고르지 않아도 됩니다.
이미 있는 것은 [게시물 연결] 로 붙입니다. 게시판·일정·회의뿐 아니라 회사가 켜 둔 업무라면 결재 품의 · 전자문서 계약서 · 판매 문서 · 업무요청 · 문서 관리의 문서도 탭을 바꿔 찾을 수 있습니다. 구축 계약 품의와 서명한 계약서를 프로젝트에 걸어 두면, 반 년 뒤 "이 범위는 어디까지 하기로 했더라"를 프로젝트 안에서 바로 찾습니다.
게시판 분류는 성격별로 세 개면 충분합니다
| 분류 | 켤 것 | 왜 |
|---|---|---|
| 업무일지 | 댓글·답글·평가(CQI) | 짧게 자주 쓰는 글. 서로 코멘트를 답니다 |
| 의사결정 기록(ADR) | 보관주기·중요도, 답글 끄기, 후속 조치 필요 | 오래 남아야 하는 글. 중요도를 높게 두면 자동 폐기 대상에서 빠집니다 |
| 기술 자료·설계 문서 | 보관주기, 버전 기록 | 계속 고쳐 쓰는 글. 수정 이력에서 두 버전을 비교할 수 있습니다 |
분류를 더 잘게 나누고 싶은 유혹이 있는데, 분류가 늘면 사람들은 어디에 쓸지 고민하다 안 씁니다. 셋으로 시작해서 정말 안 맞을 때 늘리세요.
💡 이렇게 하면 편합니다설계 글에는 mermaid 다이어그램을 그대로 쓰세요. 본문에
mermaid코드 블록으로 순서도·시퀀스를 적으면 저장한 뒤 글 상세에서 그림으로 보이고, 누르면 크게 볼 수 있습니다. 그림 파일을 따로 만들어 붙이는 것보다 고치기가 훨씬 쉽습니다 — 글자라서 수정 이력에서 무엇이 바뀌었는지도 비교됩니다.
배포 절차·보안 공지는 필독으로
"운영 접근 권한 정비", "장애 등급 기준 개정" 같은 공지는 모두가 읽었는지가 중요합니다. 글 상세의 [필독으로 지정] 을 누르면 쓴 사람과 관리자에게 확인 3/5처럼 몇 명이 읽었는지, 아직 안 읽은 사람이 누구인지가 보입니다.
"확인했습니다" 댓글을 스무 개 받는 대신, 안 읽은 두 사람에게만 따로 말하면 됩니다. 자주 다시 찾는 코딩 규칙·온보딩 문서는 각자 북마크해 두면 게시판 좌측 「북마크한 글」 에 모입니다.
파일이 본체인 것은 문서 관리로
아키텍처 다이어그램 원본, API 명세 파일, 릴리스별 설치 가이드처럼 글보다 파일이 본체인 자료는 게시판보다 문서 관리가 맞습니다. 탐색기처럼 폴더가 있고, 파일을 고쳐 올리면 이전 내용이 버전으로 남습니다.
- 문서를 열고 [새 버전 올리기] 로 바꾸면 지금 파일이 지워지지 않고 버전으로 쌓입니다.
- 잘못 올렸으면 그 줄의 [이 버전으로 복원] — 복원도 새 버전으로 하나 더 쌓이므로 되돌린 것을 다시 되돌릴 수 있습니다.
- 폴더는 만든 직후 나만 보입니다. [공유] 로 부서나 회사 전체에 열어야 동료가 봅니다.
💡 이렇게 하면 편합니다폴더는 본부나 성격으로 나누세요(예: 개발 > 설계 문서 / API 명세·연동 가이드 / QA 테스트 결과). 프로젝트마다 폴더를 만들면 게시판 분류를 클라이언트마다 만든 것과 같은 일이 생깁니다 — 프로젝트와의 관계는 [게시물 연결] 로 거세요.
메신저에서 기록으로 — 두 가지 길
개발 조직에서 결정의 상당수는 채팅에서 납니다. 그걸 흘려보내지 않는 방법이 둘 있습니다.
① 대화 한 줄을 근거로 붙이기. 메시지 옆의 고리 아이콘을 누르고 프로젝트를 고릅니다. 남이 보낸 메시지도 붙일 수 있습니다 — 오히려 그게 주된 쓰임입니다("팀장님이 이렇게 결정하셨다"를 남기는 것). 유형은 참고자료 / 근거 / 결과보고 셋 중에 고릅니다.
② 대화 여러 건을 회의록·업무일지로 옮기기. 대화 화면 위쪽의 [대화 선택] 을 누르고 옮길 메시지를 고른 뒤 [회의록·업무일지로 옮기기]. 제목과 본문이 미리 채워진 작성 화면이 열리고, 저장하면 원본 대화가 자동으로 "근거"로 연결됩니다.
계획과 회고 — 간트차트와 타임라인을 나눠 쓰기
두 화면이 비슷해 보여서 자주 헷갈립니다. 쓰는 목적이 다릅니다.
| 간트차트 | 타임라인 뷰 | |
|---|---|---|
| 언제 | 계획할 때, 일정을 옮길 때 | 돌아볼 때, 회고할 때 |
| 보여 주는 것 | 프로젝트 막대와 의존 관계 화살표 | 프로젝트 막대 + 그 아래 연결된 글이 언제 있었는지 |
| 조작 | 막대를 끌어 날짜 변경(관리 권한 필요) | 점을 눌러 그 글로 이동 |
같은 프로젝트를 지나온 기록 쪽에서 보면 타임라인 뷰입니다.
간트는 이름 앞의 ▸ 로 가지를 접었다 펼 수 있고, 위쪽 [모두 접기] 로 최상위만 남길 수 있습니다. 큰 릴리스를 볼 때는 먼저 접고 필요한 가지만 펴는 편이 빠릅니다. 시작일과 종료일이 같은 항목(릴리스일·코드 프리즈)은 마름모 이정표로 그려집니다.
의존 관계는 "표시"이지 "제약"이 아닙니다
"A는 B가 끝나야 시작한다"를 등록하면 간트에 화살표가 그려지고, 순환(A→B→A) 등록이 막힙니다. 하지만 날짜를 강제로 막지는 않습니다. 선행이 안 끝나도 후행 날짜를 옮길 수 있습니다.
이건 의도한 동작입니다. 실제 개발에서는 "앞 작업이 80%쯤 됐으니 뒤를 먼저 시작한다"가 흔합니다. 시스템이 그걸 막으면 사람은 의존 관계를 아예 안 겁니다.
공정율은 말단에서만 입력합니다
- 말단(하위가 없는) 프로젝트에서만 담당자가 0~100%를 직접 입력합니다.
- 상위 프로젝트는 하위들의 기간 가중 평균으로 자동 계산됩니다. 기간이 긴 하위가 더 큰 비중을 갖습니다.
- 공정율·기간·오늘 날짜를 비교해 일정 건강도가 자동으로 붙습니다 — 정상 / 지연 (경과 대비 많이 뒤처짐) / 초과(종료일이 지났는데 100%가 아님).
공정율 바로 아래 자금 대비 일정 카드는 예산을 쓴 속도와 일이 진행된 속도를 나란히 놓고 봅니다. 프로젝트에 예산을 정해 두고 비용(외주 개발비·클라우드·장비)을 적기 시작하면 판정이 뜹니다. 예산이 없거나 공정율 입력이 절반에 못 미치면 회색 물음표로 판정을 보류합니다 — "괜찮다"가 아니라 "아직 모른다"는 뜻입니다.
★ 꼭 알아 둘 것스프린트마다 공정율을 갱신하는 자리를 정해 두세요. 아무도 안 고치면 건강도는 전부 "지연"이 되고, 그러면 아무도 안 봅니다. 스프린트 리뷰 회의 끝에 5분이면 됩니다.
이상 신호 — 흐지부지된 결정을 스스로 챙기기
ADR 분류에 "후속 조치 필요" 를 켜 두면, 결정을 적어 놓고 아무 후속도 이어지지 않은 글이 좌측 PMS 메뉴의 [이상 신호] 에 모입니다. 내 글과 내가 PM인 프로젝트의 것만 보이고, 관리자라도 남의 신호는 못 봅니다 — 감시 목록이 아니라 스스로 챙기는 자리입니다.
관리자는 관리자 메뉴 > PMS 관리 > 이상 신호 기준에서 맨 위 [개발·SI] 를 눌러 기준을 채우고 저장하면 됩니다(지금 기본값과 같은 값입니다). 거기서 주간 리스크 요약을 켜면 월요일 아침마다 프로젝트별 요약이 초안으로 만들어지고 PM이 다듬어 게시합니다 — 보고할 것이 없는 주에는 만들지 않습니다.
수주형(SI)이라면 — 계약서와 프로젝트 손익
자체 서비스만 하는 회사라면 이 절은 건너뛰셔도 됩니다. 고객사 구축 사업을 하는 회사라면 "이 건에서 얼마 남았나" 가 결국 가장 중요한 질문이 되고, 그 답은 세 업무가 이어질 때 나옵니다.
판매 관리: 견적 → 수주 → 납품 → 청구 ──┐
├→ 프로젝트 자금 관리의 수익성 카드(매출 · 원가 · 이익률)
PMS 자금: 외주 개발비 · 클라우드 · 장비 ─┘
전자문서: 구축 계약서 · NDA · 검수 확인서 → 서명 → 봉인 → 프로젝트에 연결
① 견적과 청구는 판매 관리에서. 구축 용역(M/M)·라이선스·유지보수를 품목으로 두고 견적서를 만듭니다. 수주가 확정되면 판매 문서를 수정해 아래쪽 프로젝트 칸에 그 구축 프로젝트를 고릅니다. 청구로 넘기는 순간 자금 원장에 매출이 잡힙니다.
② 계약서는 전자문서로 서명받습니다. 계약서를 고객 담당자에게 보내 로그인 없이 서명받고, 전원이 서명하면 봉인되어 아무도 고칠 수 없게 됩니다. 봉인된 계약서를 프로젝트에 연결해 두세요 — 범위 다툼이 생겼을 때 "서명한 그 문서"가 프로젝트 안에 있습니다.
★ 꼭 알아 둘 것전자문서는 전자결재와 다릅니다. 결재는 "우리 쪽에서 누가 승인했나", 전자문서는 "양쪽이 동의했나"입니다. 계약 체결 품의는 결재로, 계약서 자체는 전자문서로 — 둘을 같은 프로젝트에 함께 걸어 두면 됩니다. 자세한 것은 전자문서.
③ 고객사는 거래처 카드로. 인맥 관리에 「거래처」 성격 분류를 두면 고객사를 회사 카드로 만들고 담당자를 그 아래에 잇습니다. 판매 문서는 회사 카드를 가리키므로, 고객사 담당자가 이직해도 [거래처 변경] 한 번이면 되고 과거 거래는 옛 고객사에 그대로 남습니다. 제안 미팅에서 받은 명함은 [명함으로 채우기] 로 사진을 찍어 채우세요(사진은 회사 서버 안에서만 읽습니다).
⚠️ 주의내부 인건비는 자동으로 잡히지 않습니다. 시스템에는 급여 데이터가 없습니다. 수익성 카드의 원가는 적어 넣은 비용(외주·클라우드·장비 등)뿐이라, 인력이 원가의 대부분인 SI에서는 이익률이 실제보다 높게 보입니다. 필요하면 월 1회 인력 투입비를 사람이 계산해 지출 한 줄로 넣으세요.
출결 — 선택근로제와 재택을 그대로 담기
개발 조직은 출퇴근 시각이 자유롭고 재택이 섞이는 경우가 많습니다. 억지로 9시 출근을 찍게 만들면 기록이 거짓말이 됩니다. 그럴 필요가 없습니다.
근무 그룹의 근무제를 선택근로로 두면 지각을 판정하지 않습니다. 출퇴근 시각이
자유로운 제도이므로 "몇 시에 왔는가"로 사람을 보지 않고, 대신 주 근무시간 합계가
집계됩니다.
⚖️ 법으로 정해진 것선택적 근로시간제(근로기준법 제52조)는 취업규칙에 근거를 두고 근로자대표와 서면 합의를 해야 적용할 수 있는 제도입니다. 정산기간·의무근로시간대 같은 항목이 합의서에 들어가야 합니다. 시스템에서
선택근로를 고르는 것은 그 제도를 이미 도입한 회사가 판정 방식을 맞추는 것이지, 설정만으로 제도가 도입되는 것은 아닙니다.
재택은 근태 신청 재택·외근으로 받습니다. 승인되면 그날 하루 IP 검사가 면제되므로,
사무실 IP 제한을 켜 둔 채로도 집에서 출퇴근을 찍을 수 있습니다.
💡 이렇게 하면 편합니다사무실 IP 제한을 켤 생각이 없다면 재택 신청도 굳이 필요 없습니다. 그냥 찍으면 됩니다. 제한을 켠 회사에만 의미가 있는 조합입니다.
⚠️ 퇴근을 찍지 않고 퇴근 체크 허용 시간이 지나면, 그날 퇴근은 정상 근무 종료 시각으로 자동 등록되고 「퇴근 자동 등록」 표시가 붙습니다. 몰입해서 일하다 퇴근을 잊는 일이 잦은 조직이라 꼭 알려 두세요 — 야근을 하고 안 찍으면 초과근무가 사라집니다. 실제 시각은 근태 정정 신청으로 바로잡습니다.
스프린트 막바지에 야근이 잦다면 연장근로 신청을 미리 받아 두세요. 인정 시간이 기록으로 남고, 주 52시간 경고와 함께 보면 무리한 일정을 사전에 발견할 수 있습니다.
⚖️ 법으로 정해진 것주 52시간(법정 40 + 연장 12)은 위반 시 사업주가 처벌 대상입니다(근로기준법 제53조, 제110조). 시스템은 넘어가면 빨갛게 경고할 뿐 막지 않습니다. 막으면 사람은 안 찍고 일하게 되고, 그러면 기록이 실제보다 적게 남아 오히려 회사가 위험해집니다. (일반적인 기준을 적은 것이고 법률 자문이 아닙니다.)
일정 — 스크럼과 회의 잡기
- 데일리 스크럼처럼 매일 같은 시간이면 반복 일정으로 한 번에 만듭니다(주기·간격· 총 횟수를 정하면 그 횟수만큼 실제 일정이 각각 만들어집니다).
- 스프린트 회의 시간 잡기는 빈 시간 찾기를 쓰세요. 참석자를 필수/선택으로 나눠 두면, 필수가 겹치는 시간은 아예 후보에서 빠지고 선택은 "몇 명 겹침"으로 알려 줍니다.
- 회의록을 남길 자리는 회의 관리로 만듭니다. 일정으로 만들었다가 나중에 [회의로 만들기] 로 옮겨도 됩니다.
일정과 회의를 가르는 기준은 하나입니다 — 회의록을 남길 일인가. 그것뿐입니다.
반 년 뒤를 위한 것 — 신경망 연관 뷰
이 화면은 당장 오늘 쓰는 화면이 아닙니다. 반 년쯤 기록이 쌓인 뒤에 값이 납니다.
- 글·회의·프로젝트가 점으로, 연결이 선으로 그려집니다.
- 명시적으로 건 "관련 게시물"뿐 아니라, A를 보다가 B로 건너간 기록도 선이 됩니다.
- 자주 조회·참조되는 자료는 밝게, 뜸해진 자료는 흐리게 표현됩니다.
- 작성자·기간으로 좁히고 타임라인을 재생하면 콘텐츠가 시간순으로 나타납니다.
- ★ 처음에는 서로 연결된 것만 보입니다. 아무것과도 이어지지 않은 글은 점만 늘리고 관계를 보여 주지 않아서 기본 화면에서 뺐습니다. 좌측 [연결 없는 글도 보기] 를 켜면 함께 보입니다.
"이 이슈, 예전에 비슷한 거 본 것 같은데"가 해결되는 자리입니다. 프로젝트 상세에서 [신경망 뷰] 를 누르면 그 프로젝트 범위로 좁혀집니다. 거꾸로 말하면, [업무 등록] 과 [게시물 연결] 을 안 쓴 조직에서는 이 화면이 거의 비어 있습니다.
끝낼 때 — 완료보고서와 종료된 프로젝트
릴리스가 끝나면 프로젝트 상태를 완료로 바꿉니다. 그 순간 몇 가지가 함께 일어납니다.
- 하위가 모두 끝나야 완료할 수 있습니다. 남아 있으면 이름을 들어 알려 줍니다. 최상위를 만들 때 [하위 강제 종결 허용]을 켰다면, 확인창에서 [함께 종결] 로 하위까지 닫을 수 있고 왜 안 끝났었는지가 완료보고서에 남습니다.
- 완료한 프로젝트와 그 하위는 잠깁니다 — 수정·진행률·연결이 막히고, 연결된 글도 고칠 수 없습니다. 보기와 첨부 내려받기는 됩니다. 잘못 눌렀으면 [완료 되돌리기].
- 좌측 트리에서 빠져 종료된 프로젝트 목록으로 갑니다. 숨긴 것이 아니라 옮긴 것입니다.
- 상세 화면에 완료보고서 상자가 열립니다. 기간·공정율·예산·매출은 시스템이 채워 두고, 사람은 한 줄 정리 하나만 써도 됩니다. 저장하면 다면평가를 준비할지 한 번 묻습니다.
💡 "교훈" 칸만은 꼭 쓰세요. 개발 조직에서 같은 장애가 두 번 나는 이유는 대개 지난번 교훈이 사람 머릿속에만 있어서입니다. 다음 프로젝트가 읽을 한 줄이면 됩니다.
프로젝트가 끝나면 — 다면평가
프로젝트를 닫을 때 참여자끼리 서로를 평가할 수 있습니다. 개발 조직에서 특히 쓸모가 있는 이유는, 게시물 축의 일부를 시스템이 자동으로 집계하기 때문입니다 — 작성한 글 수, 그 글들의 평균 CQI, 댓글·참조, 일정 준수율. 사람이 기억으로 채점하지 않아도 되는 부분이 이미 채워져 있습니다.
- PM이 프로젝트 상세의 [다면평가] 에서 세션을 만들고 가중치(직원/게시물/프로젝트, 합 100%)와 마감일을 정한 뒤 개시합니다. 완료보고서를 저장할 때 뜨는 [다면평가 준비하기] 로 시작해도 됩니다 — 자동으로 시작하지는 않습니다.
- 참여자가 상대를 별점과 코멘트로 평가합니다. 관계(상향/하향/동료/자기)에 따라 항목이 자동으로 달라집니다.
- PM이 마감하면 개인별 E/P/J 점수와 최종 점수, 레이더 차트, 익명 코멘트가 나옵니다. 개인 보고서를 인쇄할 수 있습니다.
⚠️ 다면평가는 인사고과 도구가 아니라 회고 도구로 쓰는 편이 훨씬 안전합니다. 평가 결과를 급여·승진에 직접 연결하면 사람들은 곧 서로에게 후한 점수를 주기 시작하고, 그 순간부터 데이터가 무의미해집니다. 자세한 흐름은 프로젝트를 한 바퀴 돌린다를 보세요.
이 업종에서 자주 하는 실수
프로젝트를 이슈 단위로 만든다. 트리가 수백 개가 되고 아무도 안 봅니다. 말단은 1~3주 덩어리로, 그보다 잘면 게시판 글로, 남에게 부탁하는 한 번짜리 일은 업무요청으로.
연결을 안 건다. 글은 열심히 쓰는데 프로젝트에 안 붙여서, 반 년 뒤에 검색으로만 찾게 됩니다. [업무 등록] 버튼으로 시작하는 습관이 이걸 막습니다.
공정율을 안 고친다. 한 달 방치되면 건강도가 전부 "지연"이 되고, 그러면 신호로서 죽습니다. 스프린트 리뷰에 5분을 넣으세요.
분류를 열 개 만든다. 사람들은 어디에 쓸지 고민하다가 결국 안 씁니다. 셋에서 시작하세요.
메신저를 쓰면서 아무것도 안 남긴다. 이게 가장 아깝습니다. 결론이 난 메시지 하나에 고리를 거는 데 3초입니다.
설계서 파일을 게시판 글로 계속 새로 올린다. "설계서_v3_최종"이 목록에 쌓입니다. 파일이 본체인 자료는 문서 관리에 두고 [새 버전 올리기] 로 고치세요.
완료를 안 누른다. 끝난 프로젝트가 트리에 남아 진행 중 목록이 흐려지고, 완료보고서도 다면평가도 시작되지 않습니다.
첫 2주 계획
| 날 | 할 일 | 누가 |
|---|---|---|
| 1일차 | 업무 영역 켜기(PMS·게시판·회의·메신저) — 새 회사라면 업종 기본 세팅 「IT · 소프트웨어 개발사」로 출발 | 관리자 |
| 1일차 | 부서 등록, 부서장 지정, 직원 계정 발급 | 관리자 |
| 2일차 | 게시판 분류 3개 만들고 권한 부여, ADR 분류에 "후속 조치 필요" | 관리자 |
| 2일차 | 회의 분류 1개(팀 회의) 만들기 | 관리자 |
| 3일차 | 최상위 프로젝트 1~2개 생성(하위 강제 종결 허용 여부를 이때 정합니다) | 관리자 |
| 3~4일차 | PM이 하위 프로젝트를 스프린트/기능 단위로 쪼갬 | PM |
| 4일차 | 참여 인원 배정, 기본 카테고리 지정 | PM |
| 5일차 | 팀 전체에 안내 — "업무일지는 [업무 등록]으로", 메신저 앱 설치 | 팀장 |
| 2주차 | 첫 스프린트 리뷰를 회의 관리로 등록, 회의록 작성 | 전원 |
| 2주차 끝 | 공정율 첫 갱신, 타임라인 뷰로 2주 돌아보기 | PM |
💡 이렇게 하면 편합니다3주차부터 업무요청·문서 관리·출결·전자결재를 얹는 것을 권합니다. SI라면 그다음이 판매·전자문서입니다. 처음부터 다 켜면 "쓸 게 너무 많다"는 인상이 먼저 생깁니다.
함께 볼 문서
- 체험 회사로 보기: 코어소프트 · 널리지테크 · 체험 회사 전체
- 화면별 사용법: 게시판 · PMS · 회의 관리 · 메신저 · 업무요청 · 문서 관리 · 판매 관리 · 전자문서
- 관리자 설정: PMS 관리 · 게시판 관리 · 출결 관리 · 회사 유형별 추천 설정
- 프로세스: 프로젝트를 한 바퀴 돌린다 · 지식이 흐르게 한다
📌 메모이 문서는 2026-10-04 기준 기능으로 다시 확인했습니다.