지금이 재밌는 이유는

이 글은 두 편 중 두 번째입니다. 첫 번째 글 일을 줄이려고 도입했는데, 일이 더 생겼다에서는 SaaS를 만들고 제안하면서 저희가 계속 마주해 온 문제를 적었습니다. 이번에는 그 문제를 요즘 어떻게 보고 있는지 이야기합니다.

요즘 저희 팀은 오래 풀지 못했던 막힘을 다시 들여다보는 일이 즐겁습니다. 시스템마다 승인 상태가 달라지고, 조직이 바뀌면 권한 설정을 다시 손봐야 하고, 중간에 한 곳이 실패하면 사람이 나서서 수습하는 일은 저희에게 낯선 문제가 아닙니다. 그런데 지금은 이 문제를 바라보는 느낌이 예전과 다릅니다.

가능했지만, 선택하기 어려웠던 일

고객사에 맞는 연동이나 예외 처리를 만들려면 먼저 그 회사의 환경을 이해해야 합니다. 기존 시스템이 어떻게 돌아가는지, 예외가 어디에서 생기는지, 누가 어떤 기준으로 승인하는지를 파악하고, 그에 맞춰 만들고, 시험하고, 고쳐야 합니다. 이 과정에 드는 시간이 크면 고객사마다 다른 예외를 따로 만드는 일은 정당화하기 어렵습니다. 모두에게 맞아야 하는 공용 제품에는 넣을 수 없고, 고객별로 따로 만들기에는 비용이 맞지 않으니, 그 차이는 결국 사람이 메우는 일로 남았습니다.

기술적으로 불가능했던 것은 아닙니다. 예전에도 가능했습니다. 바뀐 것은 시간과 비용입니다. 저희 팀은 AI와 개발 도구를 활용하면서 분석·구현·검증을 반복하는 데 드는 시간과 비용이 눈에 띄게 줄었습니다. 그래서 고객사마다 다른 예외도 이제는 선택지에 올릴 수 있게 되었습니다.

예전에 멈췄던 지점을 다시 봅니다

연동을 다루다 보면 상대 시스템에 쓸 만한 연동 방법이 없어 멈추는 지점이 있습니다. 이럴 때 화면 제어로 사람이 하던 조작을 자동화하거나, 시스템이 주고받는 통신(패킷)을 분석해 동작을 이해하는 방법을 쓸 수 있습니다. 환경을 파악하고 시험하는 비용이 맞지 않아 접어 두었던 쪽입니다. 그 지점을 다시 열어 볼 수 있게 된 것이 요즘 가장 신납니다.

이런 방법도 고객이 허용한 시스템과 계정, 보안 요구사항과 이용 조건 안에서 검토합니다.

또 이것은 여러 선택지 중 하나일 뿐입니다. 공식으로 제공되는 연동이 있으면 그쪽이 낫고, 절차나 설정을 바꾸는 것만으로 풀리는 일이라면 그렇게 하는 편이 맞습니다. 모든 곳에 AI를 쓰자는 이야기도 아닙니다. AI는 필요한 곳에 쓰는 수단입니다. 도구가 빨라질수록 어디에 무엇을 쓸지 고르는 판단과, 그 판단에 쓰이는 현장 경험이 더 중요해집니다.

빨리 만들수록 더 꼼꼼히 확인할 것

빠르게 만들 수 있게 되면 한 번 작동하는 것과 계속 믿고 쓸 수 있는 것의 차이가 더 중요해집니다. 그래서 만든 뒤에 이런 것들을 확인하려 합니다.

• 상대 시스템의 화면이나 응답이 바뀌었을 때 그 사실을 바로 알아챌 수 있는지
• 실패했을 때 조용히 묻히지 않고 담당자에게 보이는지
• 같은 요청을 다시 보내도 같은 건이 두 번 처리되지 않는지
• 누가 어떤 권한으로 무엇을 했는지 남고, 문제가 생기면 누가 책임지고 판단하는지

비용이 사라진 것도 아닙니다. 만든 것은 계속 관리해야 하고, 새로 만든 도구가 또 하나의 유지보수 일거리가 된다면 첫 번째 글에서 말씀드린 문제를 되풀이하는 셈입니다. 그래서 기준은 하나입니다. 이 작업이 고객의 실제 업무를 줄였는가. 저희는 이 문제를 아직 풀고 있는 중이고, 그 과정에서 확인한 것을 하나씩 쌓아 가고 있습니다.

lapal lab이 말하는 Beyond advice. We build.는 조언을 가볍게 본다는 뜻이 아닙니다. 조언에서 멈추지 않고 만들고 확인하는 데까지 가겠다는 뜻입니다. 고객께 “이건 한번 만들어서 확인해봅시다.”라고 제안할 수 있게 된 것, 지금이 재밌는 이유는 거기에 있습니다.

앞선 글: 일을 줄이려고 도입했는데, 일이 더 생겼다