brunch

You can make anything
by writing

C.S.Lewis

by 진영최 Mar 14. 2023

주간 업무 - 2023.10w

문제에 대한 접근 방식

10w는 감정소모가 너무 큰 주였다.


일본에 곧 서비스 할 iOS 앱의 레이아웃의 높이가 기존 한국에 서비스중인 iOS 앱과 다르게

앱 최초 실행 시 간헐적으로 높이값이 줄어들어 표출되는 이슈가 발생했다.


한 팀원이 해당 이슈에 대한 접근과 해결 방안을 얘기했지만 도저히 이해가 되지않았다.

그 팀원에게 그렇게 접근한 방식에 대한 근거를 물어보니

근거가 없어도 자기가 생각한 방법대로 처리하면 되는거 아니냐는 말에


원인을 모르고 처리하는 것(어 된다?, 왜 되지?)이 개발자에게 좋은 상황인지

그리고 기존에 정상적으로 구동하는 한국 앱과 같은 소스와 같은 프로세스의 코드인데

문제가 생기는게 이상하지 않느냐,

등으로 잘 타일러봤지만


그 팀원은 끝까지 문제의 원인을 찾아가려하는 행동을 이해하지 못하길래

결국 해당 팀원을 이슈에서 손 떼게 하고 내가 처리했다.




왜 짠 맛이 부족할까?

샌드위치로 간단히 예를 들어보겠다.


기존에 한국에서 팔던 샌드위치를 일본에서 팔게된 상황.


일본에서 팔 샌드위치에 들어가는 재료와 레시피는 한국과 같은데,

시험삼아 만들어보니 짠 맛이 부족했다.


샌드위치 요리사들이 모여 의견을 나눴다.


A : 짠 맛이 덜 나니 소금을 더 넣죠.

B : 왜 짠 맛이 덜 날까요? 어떤 재료가 맛이 변해서 영향을 줬을까요? 아니면 소스 같은 것이 덜 들어갔을까요?




A와 B

처음 언급했던 팀원은 A와 같은 유형이었고 그가 제시한 답은

레이아웃의 높이를 CSS를 사용해

height를 100%로 고정시켜

애초에 줄어들지 않게 하자는 것이었다.


나는 그에게

한국과 같은 소스와 프로세스인데

왜 일본만 그 방법을 더 추가해서 해결하려하는지 이해가 안된다

무엇이 원인인지 파악하고 처리해야한다 말했다.


그는 원인으로 브라우저 엔진 때문일 것이라는 의견을 내놓았지만

나는 그럼 브라우저 엔진의 해석 속도도 같아야 하는 것 아니냐라고 물어보니

거기에 대해선 더 답을 하지 못했다.


그리고 html의 height를 그렇게 바꿔버리면

html의 자식요소에 영향이 가는 부분은 어떻게 확인하고 처리할 것이냐 했더니

영향도 확인은 해보지도 않고

'상관없지 않을까요 영향이 안갈텐데요'

라는 어이없는 대답이 돌아왔다.


심지어 그가 제안한 CSS 적용도 회사의 CSS 작성 가이드를 위배한

HTML에 인라인 스타일로 적용을 제안했다.


문제의 원인을 파악하지 않으려 하고

터무니없는 의견과 다른 파일 영향도는 생각도 않고

회사의 가이드를 위반하는 방법까지


결국 나는 터져버렸고

해당 이슈를 혼자서 맡기로 했다.




너무 쉽게 찾은 답

원인을 정확히 분석하기 위해 테스트를 여러번 시행하니


- 페이지 로드는 정상적으로 완료가 되는데 레이아웃이 정상적으로 표출이 안된다.

외에


- 앱을 비활성화(백그라운드) 후 다시 활성화(포그라운드)하면 레이아웃이 정상적으로 표출된다.

- 웹으로 볼 땐 정상적으로 표출이 된다 하지만 앱에서 실행하면 레이아웃이 정상적으로 표출되지 않는다.

같은 특이사항을 확인할 수 있었다.


특이사항으로 접점을 쉽게 찾을 순 없었고

우선 페이지 로드 시 발생하는 이슈니

개발자도구 내 네트워크 탭에서 로드 시간을 체크했다.


체크해보니 로드 시간에 가장 크게 영향을 주는 파일이 폰트 파일이었고(또 너냐)

폰트 파일을 확인해보니 8w~9w 사이에 내가 추가했던 폰트의 파일 타입이 한국과 달랐다(부끄러워라!).


한국 폰트 파일 타입은 woff로 상당히 가벼운 파일 타입이었지만

내가 일본에 추가한 폰트 파일 타입은 otf로 상당히 무거운 파일 타입이었다.

이로 인해 시간차가 발생해 CSS 적용이 느렸던 것이라 추측했다.


때문에 폰트 파일 타입을 otf에서 woff로 바꿔주었고

기존 한국앱과 동일한 속도의 로딩 조건을 맞춰주니 해당 이슈가 해결되었다.




만약 소금만 쳤다면

원인을 찾아가지 않고 단순히 앞에 보이는 부분만 처리했다면

일본 앱의 코드가 달라지는 일이 발생했을 것이다.


이슈를 해결하고 난 후 알게된 사실인데

기존 한국 앱에서도 아주 낮은 빈도로 발생했다고 한다.

(나는 검수나 테스트때 보지 못해서 인지를 못했었다.)


그렇다면 추후에 한국과 일본을 동시에 수정할 것이고

이 때는 레이아웃과 관련된 수정이 될텐데

일본 앱만 레이아웃에 관련된 코드가 달라져 있다면,


한국이나 일본 앱에서 수정을 먼저 적용한 후

남은 다른 앱에 적용 시킬때 정상적으로

수정사항이 적용이 될까?


그리고 적용이 안된다면

개발 히스토리를 뒤져가며

무엇이 문제였는지 찾아가는 시간이나 노력은

애꿎은 누군가 들이고 있을 수도 있을 것이다.




문제 앞에 정황이 있다면

원인이 확인되지 않는 어려운 이슈 케이스들도 있는데

10w에 발생한 이슈처럼

아주 훌륭한 전제(같은 소스, 같은 프로세스)가 있다면

감사하며 이슈의 원인에 접근해야한다.


이슈를 접하는 것은 개발자의 숙명이니까

숙명은 피할게 못되니 맞받아 쳐야된다는게 내 생각인데,

이를 어떻게 효율적으로 받아칠 것인가 생각해보는게

좋은 개발자로 성장하는 길 아닐까?


그러니 이슈가 발생한다면 당장 보이는 해결방안보다 원인을 잘 살펴보자.

분명 원인 제공을 하는 어떤 요소가 있고 더 좋은 답안을 줄 것이다.


아 그리고 팀원이 제시한 해결 방안은

혹시나 시도해봤는데 역시나 엉터리였다.

CSS 적용이 아예 안되더라.

작가의 이전글 주간 업무 - 2023.09w
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari