[일반] si/sm에선 병목지점이 눈에보여도

[익명(172.224)]

임의로 건들면 안되는 거겠지..?

고민이다 진짜..

이런거 하나하나가 다 비용인데 이걸 사측에서는 당연히 비즈니스로 보고 싶어하고..

개인적인 입장으로는 토픽 처리하다가 남는 시간에 이런거 개선해주고 싶은데.. 잠재적으로는 이익창출을 저해하는 거 같아서

그냥 내용을 잘 말아서 영업한테 주고 제안하라고 해야하나.. 하..

[백갤러 1(14.52)]

우선 제가 글쓴분의 입장이라면 마지막에 말씀하신대로 병목지점들 개선으로 인한 편의성 증대 등을 어필하여 제안하고 비즈니스 건으로 연결 시키려고 노력할 것 같아요. 큰틀에선 코드 오너쉽과 개인의 성향, 조직의 목표등으로 인해 발생하게 된다고 생각하는데요, 우선 글쓴분은 코드에 대한 완벽한 통제권이 없는 상황 + 코드에 대해 통제하고자 하는 욕심 + 코드의 통제 기준이 성능이 아님 등으로 인해서 발생하고 있는거죠. 하지만 이런 경우는 서비스 회사에서도 유사하게 발생될 수 있는데요. 여러 팀원과 같이 코드를 관리하는 경우에는 여러 팀원들이 인지하기 편한 구조로 짜는게 전체적인 관점에서 좋은 코드라고 할 수 있는데 이건 종종 혹은 자주 성능면에서 안좋을 수 있죠.

[백갤러 1(14.52)]

하지만 이 안좋다의 기준도 결국 그렇게 인지하는 사람의 기준이라서, 그 사람이 C로 짜다가 자바 등 비교적 느린 언어에서 하면 결국 욕심은 단순히 패턴 정도가 아닌 언어를 바꾸기를 희망할 수도 있는데, 언어 수준의 변경은 조직별로 다르겠지만 선호하지 않는 곳들이 더 많습니다. 뿐만 아니라 언어가 아닌 특정 패턴, 사용하는 인프라, 솔루션 등에서도 불만이 나타날 수 있고요. 그러면 이제 결국 또 불만이 생길 수 있는 구조가 반복되는데 그러한 불만을 해결하는 방법은 제 생각에는 크게 두가지 정도 있는 것 같습니다. 본인이 원하는 수준의 오너쉽을 가질 수 있는 조직으로 전향하시거나, 불만 자체를 어느정도 내려 놓는 것이죠.

[백갤러 1(14.52)]

저도 이 문제에 대해서 아직 어려움을 겪고있는 사람인데 저는 두가지 방식을 어느정도 혼용했습니다. 우선 저는 어느정도 오너쉽을 가질 수 있는 서비스 회사에서 일을 하게 되었고, 제가 관리할 수 있는 영역을 어느정도 제한을 해두면서 그 안에서 최적화를 해보거나 비즈니스의 관점을 기준삼아서 개선할 수 있도록 유도하고 있습니다. 하지만 이 상황에서도 물론 저는 언어 레벨도 썩 마음에 안들고 코드 패턴들도 마음에 들지 않는데, 제 불만을 잠재우기 위해서 코드의 기준점을 나라는 개발자가 아닌 시스템에 대한 적정기술로 조금 변경해보니 저를 속일 수 있게 되더라구요.

[백갤러 1(14.52)]

예를 들자면 제가 마음에 안드는 코드 -> 시스템 관점에서 개발자 개인이 마음에 안든다고 쉽게 바꿀수 있으면 그건 안전성이 보장되는 시스템이 맞는건가? 성능이 마음에 안드는 코드 -> 해당 코드의 성능이 시스템 혹은 이용자에게 유의미하게 나쁜가? 시스템이 개선되었을 때의 효과를 측정할 수 있는가? 이해관계자들이 변화에 동의하는가? 등등으로 말이죠. 이제 이러한 기준에서도 올바르지 못하면 그때부터는 과감하게 추진하려고 하고 있습니다. 더이상은 못참는다 느낌이죠 ㅋㅋㅋ... 물론 이건 그냥 저라는 개인이 쓰고있는 방안이고, 개발자분들의 성향에 따라서 많이 다를 것 같아요. 글쓴분은 어떻게 생각하실지도 궁금하네요.

[백갤러 2(172.224)]

@백갤러1(14.52) 글에서 많이 공감 가는 부분들이 많네요 우선 첫 번째로 저도 같은 이유로 서비스 회사로의 전향을 고려하고 있고 두 번째로 해당 부분이 사용자들이 불편함을 느끼지만 응당 누려야 할 지원으로 생각합니다. 즉 돈 안내고 원래 잘못 만든거 아니냐? 고쳐줘야하는거 아니냐? 는 느낌이라 개인적으로는 상관은 없는데 회사에선 돈 안주는데 왜 해주냐 이런 느낌이구요:)

[백갤러 2(172.224)]

@백갤러1(14.52) 큰 틀을 깨진 않는 간단한 쿼리 튜닝이나 코드 수둔에서 해결되면 그냥 적당히 해주고 있고, 더 큰 수준으로 넘어가면 저도 어쩔 수 없기에 그냥 개선방안만 따로 기록해두고 마네요

[백갤러 1(14.52)]

@백갤러2(172.224) 말씀하신 두번째가 결국 조직구성 혹은 조직 성향과 개인의 성향이 충돌하는 지점일것같은데요. si/sm 혹은 서비스 회사라도 큰 회사여서 분업이 철저하게 되어있는곳 들에서는 개발자는 고객이 진짜 고객이 아니라 기획자가 고객인 포지션들이 많더라구요.

[백갤러 1(14.52)]

@백갤러2(172.224) 따라서 실제 사용자의 불편에 대한 인지, 책임, 관리는 개발자가 신경쓸게 아니면서 심하면 신경쓰면 월권이 되는 상황마저 발생하구요. 따라서 개발자가 결국 기획에 대한 책임, 권한을 함께 지면서 실제로 고객에게 대응할 수 있는 그러한 조직을 찾으시는게 역시 좋지 않을까 싶습니다. 성공하시길 바랄께요.

[익명(175.119)]

팀원들은 저런거 고쳐도 되냐고 물어보면 고치게해줌?

[백갤러 3(172.224)]

내 사이트는 나 혼자 맡음 팀원이 없다

[딘퐁(gunwoo7193)]

잘못되면 님이 책임질거임? - dc App

[백갤러 3(172.224)]

내가 책임지지 누가 짐? 애초에 잘못될 일도 없음