호랑이 담배피던 시절의 전자정부 프레임워크을 통해 배운 교훈은 프레임웍을 만들려면 잘 유지되야 한다는 것이다. 그래서 프레임워크라는 물건을 만드는 건 매우 어렵다. 전자정부 프레임워크는 당시의 Spring Framework 초기 버전에 공공 프로젝트 진행을 위해 필요한 몇가지 요소를 더한 것이다. 스프링이 시장의 주류로 자리잡는 시기였기에 일관된 형태로 사용하도록 가이드가 어려웠다. 더해서 스프링 프레임워크는 쭉쭉 발전하는데, 전자정부 프레임워크는 스프링의 …
AI는 맥락을 기반으로 스토리를 풀어낸다. 적절한 맥락을 줬을 때 AI가 기가막힌 응답을 만들어내는 걸 보고 있다. 거꾸로 짚어보면 좋은 혹은 쓸만한 결과를 만들기 위해서는 맥락이 중요하다는 반증이다. 하지만 기대하는 결과가 커지면 커질수록 부합하는 맥락은 어느 수준일까? Prompt Engineering이 주류를 이룬다. 좋은 Prompt를 이야기하면서 그 Prompt가 내가 겪고 있는 문제를 한번에 해결해주길 원한다. 사람이 그렇다. 하지만 …
30:70 혹은 20:80은 IT 업계에서 제품/서비스는 만들기보다 운영이 더 어렵다는 것을 의미하는 대표적인 비교 수치다. 제품/서비스의 전체 생애주기에서 만드는 비용보다 쓰이는 과정에서 닦고 조이는 비용이 3배 혹은 4배 이상 들어간다는 것이 업계 정설이다. 특히 생명주기가 긴 제품, 혹은 사용자가 많은 제품일수록 이 비용의 크기는 커진다. SaaS/PaaS 시대를 거치면서 구성 요소의 일부를 서비스로 대체하면서 운영 노력 …
AI를 잘 쓸려면 알아야 하고, 아는 가장 첫번째 방법은 써보는 것이다. 쓰다보면 유용함을 알게 되고, 유용하면 더 쓰게 마련이다. 특히 아는 사람이 더한다고 엔지니어들은 이제 AI없이는 일할 수 없는 세상이 됐다. 세상이 이렇게 변하다보니 개인이나 회사나 모두 토큰비를 걱정할 수 밖에는 없다. 최근 성능 좋은 AI 공급사들이 쓴만큼 청구하는 방식으로 전환하기에, 더욱 더 고민될 수 …
오토에버에서도 라이브옵스(LiveOps)를 시작할려고 한다. 조직은 이미 봄에 만들었고, 뭘 하기도 전이긴 하지만 이야기 할 사람들과 역할을 가지고 이야기를 해야하기 때문에 작지만 팀을 만들었다. 팀 리드를 세우고 여러 관계자들과 이야기를 하면서 역할의 타당성과 기대 역할에 대한 의견을 모았다. 있어야 할 조직이라는 생각이 들었고, 제대로 일 할 제대로 된 팀을 만들기 위해서 본격적으로 채용을 시작한다. 왜 LiveOps인가? …
어느새 쏘카에서의 시간이 만 1년이 됐다. 제대로 일할 수 있는 기술 조직을 만들어보겠다는 생각으로 “본사”로 이직을 했던 것이 얼마 안된 것 같은데 벌써 시간이 이만큼 지나갔다. 개인적으로도 큰 변화의 시기였고, 쏘카의 기술 조직도 그만큼의 변화의 시간을 함께 관통하고 있다. 일하는 방법부터 시작해서 조직개편, 그리고 새로운 아키텍처 를 적용하는 여정까지 하루하루가 다이나믹하게 지나갔다. 그럼에도 1년이 지난 …
3월에 모 부트캠프 참가자들을 대상으로 “S/W 아키텍처(Architecture)“에 대한 특강을 진행했다. 강의 이후에 이런 저런 질문들이 있었다. 질문들이 과정에 참가한 분들만 궁금해하는 사항들이 아닐 것 같아서, 정리해서 기록으로 남겨볼려고 한다. 원하시는 인재상, 어떤 개발자를 원하시는지 궁금합니다. 이야기를 개발을 리드하는 입장에서, 특히 쏘카의 개발 방향 관점에서 이야기했기 때문에 자연스럽게 이 질문에 가장 관심이 많았던 것 같다. 사실 …
어플리케이션 수준부터 시스템 수준의 아키텍쳐에 대한 이런 저런 이야기를 계속 해왔다. 사실 이런 이야기들은 이론이다. 이론과 현실은 다른다. 다르다는 것을 인정하고, 현실에 맞춰 이론을 적용하는 것이 선수들이 해야할 일이다. 현실을 규정하는 것들 가운데 가장 큰 몫은 환경일 것이다. 그리고 그 환경 가운데 또한 가장 큰 몫은 바로 조직 모델이지 않을까 싶다. 다른 글에서 Monolithic과 Microservice …
시스템을 개발하는 방식에는 여러가지가 있을 수 있다. 가장 크게는 남이 개발해주는게 있고, 내가 개발하는게 있겠다. 우리나라에서 소위 SI(혹은 외주)라고 부르는 방식이 남이 개발해주는 방식이다. 이런 개발을 “프로젝트” 방식이라고 한다. 대체로 요구 사항과 기간을 개발사에게 전달한다. 물론 돈과 함께. 개발사는 최대한 맞춰 개발하고 그 결과를 전달한다. 물론 필요하면 설치와 운영에 필요한 사항까지 잘 마무리해야지. 그리고 남은 …
팀에서 개발한 서비스들 가운데 대용량 트래픽을 처리하는 경우, Mongo DB를 Main Repository로 사용하고 있다. 국내에서 제공되는 모든 트래픽을 모두 처리하기 때문에 MySQL같은 RDB로는 이를 처리할 수 없고, NoSQL 몇 개를 평가한 다음에 결국 주력으로 Mongo DB를 사용했다…. 하지만 Mongo를 전담하는 인원을 둘 수 없는 지경이라… 전문적으로 시간 투자를 해서 관리하고 튜닝할 수 있으면 좋겠지만 환경상 …