업무 도구가 다른 시스템에 붙어야 했던 이유를 다룹니다. 시리즈의 다른 글 보기
안녕하세요. 오픈소프트랩 개발팀입니다.
지난 편에서 애자일 방법론을 걷어낸 이야기를 했습니다. 개인의 진척을 가시화했더니 사람들이 도구를 피했고, 그래서 방법론을 버리고 업무 관리 도구로 방향을 바꿨습니다.
이번 편은 그다음입니다. 방법론을 걷어냈는데도 기록이 안 쌓이던 시기의 이야기입니다.
이제 쓰기 편하게만 만들면 될 줄 알았습니다
방법론을 걷어내니 할 일이 명확해 보였습니다.
개인 지표를 없앴으니 등록을 피할 이유가 사라졌고, 남은 건 쓰기 편하게 만드는 것이라고 봤습니다. 화면을 정돈하고, 입력 단계를 줄이고, 필요한 것만 남겼습니다.
기능은 분명히 나아졌습니다. 그런데 기록은 여전히 성기게 들어왔습니다.
일은 다른 곳에서 벌어지고 있었습니다
현장을 들여다보고 나서야 알았습니다.
요청은 메일로 옵니다. 급한 건 메신저로 옵니다. 회의에서 정해진 건 회의록에 있고, 담당자가 누구인지는 인사 시스템에 있습니다. 업무 시스템은 그 일이 다 끝난 뒤에 결과를 옮겨 적는 곳이었습니다.
옮겨 적는 일은 아무도 좋아하지 않습니다. 이미 끝난 일을 한 번 더 입력하는 거니까요. 그래서 중요한 것만 적거나, 나중에 몰아서 적거나, 안 적습니다.
기록이 안 쌓이는 이유가 도구가 불편해서가 아니었습니다. 도구가 일이 벌어지는 자리에 없었기 때문입니다.
붙이기 시작했습니다
그래서 방향을 바꿨습니다. 사람을 도구로 데려오는 대신 도구를 일이 벌어지는 자리로 보내기로 했습니다.
붙인 것들입니다.
| 붙인 곳 | 이유 |
|---|---|
| 메일 | 요청이 들어오는 자리 |
| 메신저 | 급한 일이 오가는 자리 |
| 인사 시스템 | 담당자와 조직이 정의된 자리 |
| 디렉터리 서비스 | 계정과 권한이 정의된 자리 |
| 형상관리 도구 | 개발 산출물이 쌓이는 자리 |
메일로 온 요청이 시스템에 자동으로 들어오고, 처리 상황이 메신저로 나가고, 조직이 바뀌면 담당자 목록이 따라 바뀌게 했습니다.
이렇게 하고 나서야 기록이 쌓이기 시작했습니다. 사람이 옮겨 적지 않아도 되니까요.
붙일 곳마다 방식이 달랐습니다
여기서 예상 못 한 일이 생겼습니다. 연동 쪽 코드가 계속 늘어났습니다.
고객마다 쓰는 메신저가 다르고, 인사 시스템이 다르고, 조직 구조를 표현하는 방식이 다릅니다. 어떤 곳은 디렉터리 서비스를 쓰고 어떤 곳은 자체 계정 체계를 씁니다. 붙일 때마다 그 조직의 방식을 새로 배워야 했습니다.
처음에는 고객마다 연동 코드를 따로 짰습니다. 그러다 새 고객의 인사 시스템을 붙이면서, 앞서 다른 곳에 쓴 코드를 열어 놓고 이름만 바꾸고 있다는 걸 알았습니다. 붙는 시스템은 달랐지만 하는 일은 담당자 목록을 가져오는 것 하나였습니다.
그래서 바깥과 붙는 부분을 따로 떼어냈습니다. 업무 로직은 "담당자 목록을 가져온다"까지만 알고, 그게 어느 시스템에서 어떻게 오는지는 연동 쪽이 책임지게 했습니다.
나중에 AI 서비스마다 커넥터를 따로 둔 것도(관련 글) 같은 구조입니다. 그때는 몰랐는데, 이미 한 번 해본 일이었습니다.
얻은 것과 포기한 것
얻은 것 — 기록이 쌓이기 시작했습니다. 그리고 도입할 때 "기존 시스템을 바꿔야 하나요"라는 질문에 아니라고 답할 수 있게 됐습니다. 이게 공공·금융 사업에서 특히 컸습니다. 그쪽은 이미 쓰는 시스템을 바꾸는 걸 가장 꺼립니다.
포기한 것 — 도입 기간이 길어졌습니다. 제품만 설치하면 끝나는 게 아니라 붙일 시스템을 하나씩 확인해야 합니다. 그리고 연동한 시스템이 바뀌면 저희도 따라 바뀌어야 합니다. 저희가 통제할 수 없는 변경에 계속 노출됩니다.
이건 감수할 수밖에 없었습니다. 붙지 않으면 애초에 쓰이지 않으니까요. 쓰이지 않는 제품의 유지보수 비용이 0이라는 건 위안이 되지 않습니다.
어디까지 붙일 것인가
지금도 정리가 안 된 부분입니다.
연동을 늘리면 제품이 자리를 잡습니다. 그런데 늘릴수록 저희가 책임지는 표면이 넓어집니다. 상대 시스템이 응답을 늦게 주면 저희 화면이 느려지고, 상대가 형식을 바꾸면 저희가 깨집니다. 장애가 나면 어느 쪽 문제인지부터 가려야 합니다.
지금은 없어도 업무가 돌아가게 만드는 걸 기준으로 삼고 있습니다. 연동이 끊겨도 시스템은 계속 동작하고, 자동으로 들어오던 게 수동 입력으로 떨어질 뿐입니다. 편의가 줄지 업무가 멈추지는 않게요.
다만 이 기준은 붙일지 말지를 정해주지 못합니다. 어떤 연동은 없으면 제품을 쓸 이유 자체가 사라지고, 그런 건 "없어도 돌아가게" 만들 수가 없습니다. 지금은 건건이 판단하고 있고, 판단 기준을 세우려면 사례가 더 쌓여야 할 것 같습니다.
다음 편에서는 제품이 늘어나면서 뼈대를 어떻게 나눴는지 다룹니다.
오픈소프트랩 개발팀이 작성합니다. 보안 운영 포탈과 생성형 AI 사용 통제를 만들고 있습니다.