티스토리 뷰

하네스는 만드는 게 아니라 뽑아내는 쪽이 맞았다

정리하면서 제일 크게 바뀐 생각은 이거다.

하네스는 먼저 설계하는 게 아니라, 실제로 만들어본 뒤에 추출하는 게 맞다.

처음부터 7개 하네스, 공통 엔진, 자동화 시스템을 만들면 뭔가 대단한 걸 하는 것 같지만, 사실은 아직 써보지도 않은 도구를 만드는 일이 될 수 있다.

진짜 필요한 도구는 삽질을 해봐야 나온다.

데이터를 입력하다가 짜증나는 순간, 모바일에서 화면이 깨지는 순간, 지도 API 연결에서 막히는 순간, 상세페이지가 너무 비슷해서 지루해지는 순간. 그런 순간들이 쌓여야 다음 프로젝트에 필요한 진짜 템플릿이 나온다.

그래서 결론이 조금 바뀌었다.

엔진을 먼저 만들지 말고, 하나를 끝까지 만들면서 반복되는 것을 기록하기로 했다.

 

그래도 얇은 기록 장치는 필요하다

그렇다고 아무것도 기록하지 말자는 건 아니다. 무거운 엔진은 나중에 만들더라도, 얇은 기록 장치는 지금부터 필요하다.

예를 들면 이런 것들이다.

오늘 막힌 것. 왜 이 결정을 했는지, 데이터 컬럼은 왜 이렇게 정했는지, 완료 기준은 뭔지, 모바일에서 확인해야 할 것은 뭔지.

배포 전에 꼭 봐야 할 체크리스트는 뭔지등등

이 정도는 엔진이라기보다 작업일지에 가깝다. 하지만 이런 기록이 있어야 다음 프로젝트로 경험이 넘어간다.

그냥 만들고 끝내면 다음에도 또 처음부터 헷갈린다.

 

결론은 작게 끝까지 가는 것

오늘 정리한 결론은 생각보다 단순하다.

플랫폼을 여러 개 만들고 싶으면, 먼저 하나를 끝까지 만들어야 한다.

엔진을 만들고 싶으면, 먼저 엔진 없이 하나를 완주해야 한다.

자동화를 하고 싶으면, 먼저 수동으로 해보면서 어디가 아픈지 알아야 한다.

리고 그 과정에서 반복되는 것만 따로 기록한다.

그게 다음 GStack의 재료가 된다.

오늘은 뭔가 대단한 기능을 만든 날은 아니다.

하지만 방향이 많이 정리됐다.

많이 만드는 것보다 하나를 끝내는 것.

공통 엔진을 상상하는 것보다 실제 삽질을 기록하는 것.

수익을 급하게 붙이는 것보다 정보 신뢰를 먼저 만드는 것.

이 기준을 잡은 것만으로도 꽤 큰 진전이라고 본다.

댓글