ASH84

Software Engineer/Developer, co-founder of Payhere. Ex-Banksalad. Intereseted in iteroperability, bootstrap company, writting.

스타트업과 완결성

created:2024-01-20
updated:2024-01-20
edit

완결성

요즘 완결성이라는 단어에 꽂혔다. 영어로는 completeness. 내 개인적인 성향은 약간 작은API를 만들더라도 로그나 옵저빌리티 등 서비스 운영에 대한 완결성을 가져가려고 하는게 내가 선호하는 작업 성향이다.(이건 꽤 오랫동안 스스로를 지켜봐왔고 내린 결론이다.)

어쨋든 스타트업에서 일을 하다보면 A를 하다가 B를 뛰어가야하고, C에서는 헤엄도 쳐야한다. 그러다보면 이전 작업에 대한 완결성이 떨어지게 되고 MVP, 스타트업, 데이터 의사결정 같은 여러 스타트업스러운 단어들로 스스로를 변호한채 완결성의 내부레벨을 낮추게 되는것 같다. 그런것들은 조금씩 마음의 짐으로 남기도 하고, 개인적으로 봤을때 완결성의 내부레벨이 낮아지고, 더 나아가서는 그런것들이 조직에 퍼지게 된다.

어려운 부분은 이런 완결성의 애기를 조직에서 하면 생존이라는 단어 앞에 무너진다. 그건맞다. 생존없이는 아무것도 할 수 없으니까. 그리고 대부분의 무형의 가치는 유형의 가치에 비해서 측정할 수 없다는 이유로 낮게 취급된다.

하지만 무형의 가치는 유형의 가치에 영향을 줄 수 있다고 생각한다. 예를 들어 지금 완결성을 낮추고 다른 작업에 들어갔을때 그 이전 작업이 3개월 1년후에 어떤 임팩트로 다가올지는 모른다. 하나의 제품/서비스가 망가질 수도 있고, 고객이 실망할 수도 있다. 혹은 내부 리소스를 더 써야할 수도있고, 그로 인해서 내부 구성원이 지쳐 퇴사를 할 수도 있다.

그렇다고 개인에게 이 완결성을 강요할 수 있는가? 시간적 희생을 통해서 완결성을 가져가라고 하라고 하는게 맞는가? 엔지니어니까?가스라이팅이라고 생각한다. 물론 엔지니어라는 자부심과 직업정신도 중요하지만 기약없는 희생을 받아들일 사람이 누가있을까.

어려운 문제인것 같다. 그렇지만 한가지 확실한 방향은 엔지니어라면 완결성을 지향해야하고 제대로 된 테크기반의 회사라면 그런 완결성을 만들어낸 엔지니어에게 보상과 칭찬이 뒤따라야 한다는 것이다. 특히 시간적 희생을 할 수 밖에 없는 스타트업에서 더 그래야 한다고 생각한다.


#   #개발자  #스타트업  #essay  #startup  #completeness  #완결성