All-round programmer

개발자 안티패턴3 - 정답을 단정 짓지 말라

Unikys — Sun, 21 May 2023 17:55:29 +0900

요즘 협업을 하면서, 팀을 리드하면서 디자인 리뷰를 하면서 많이 생각하게 되곤 합니다. 내가 생각하고 있는 것이 맞는 정답일까, 이 사람이 만들어놓은 디자인은 맞는 정답일까? 그런데 프로젝트를 여러 번 하다 보니 내리게 된 결론은 다음과 같습니다.

시스템 디자인에 정답은 없습니다.

요즘 다시 고용 시장이 조금 회복되면서 다시 인터뷰도 많이 하고 있습니다. 저는 자주 시스템 디자인 세션을 맡곤 하는데, 한 시간의 인터뷰 세션 안에서 자기소개하고 인터뷰이 소개하고 기본적인 질문들을 하다 보면 15분 정도 쉽게 지나가고 마지막 5분은 질답 시간으로 남겨두려면 결국 남는 건 40분 밖에 되지 않습니다. 40분 안에 물어보는 시스템 요구사항에 대한 최적의 디자인을 만들기란 당연히 턱 없이 부족합니다. 인터뷰어로서 살펴보는 건 "장단점을 알고 있느냐" 다른 말로, "Trade off"를 이해하고 있느냐를 위주로 봅니다.

모든 디자인이나 접근 방법에는 Trade off가 있습니다.

이것은 디자인 리뷰를 할 때나 디자인을 공유할 때 언제나 강조하는 부분입니다. 심지어 두 변수를 더하는 간단한 연산 구문조차도 trade off와 장단점이 있습니다.

int add(int x, int y) {
  return x + y;
}

이러한 단순히 두 수를 더하는데 코드에 대해서도 다른 대안을 여러 가지로 제시할 수도 있고, 그 여러 대안들에 대해서도 여러 장단점들을 나열할 수도 있습니다. 연산에 사용되는 메모리를 고려해 int를 그대로 쓰느냐, 범위를 고려해서 int를 long으로 바꿀 거냐, 소수점이 혹시 필요할지 모르니 float / double로 바꿀 거냐, 화폐 단위 계산을 고려해 BigDecimal을 쓸 거냐, 여러 값들을 한 번에 더할 수 있게 별도의 클래스로 Wrap 해서 더하기 연산자를 객체에 넣느냐 등등, 각 접근 방법은 장점이 있고 단점이 있습니다. 명확한 것은 "장점만 있는 방법은 없다"입니다. 이것을 이해하고 다른 개발자들과 소통하는 것은 중요합니다.

장점만 있는 접근 방법은 없습니다.

이제 개발자 안티패턴이라는 주제로 돌아와서 하지 말아야 할 행동은 무엇이 있을까요? 제가 가장 많이 접하는 문제 되는 개발자 유형은 "정답을 정해놓고 닫힌 귀로 소통하는 개발자"입니다. 앞선 글에서도 썼었던, 고집을 버려야 하고 겸손해야 한다는 것과 유사합니다만, 제가 이것을 본 개발자들을 주로 리뷰를 해주는 고급 개발자들에게서 입니다. 디자인 리뷰를 하면 끝까지 자기의 디자인을 고집하는 것을 보고 있으면 소통이 안 되는 개발자라는 것이 느껴지고, 그 개발자와 같이 협업하는 것을 꺼리게 됩니다.

물론 리뷰를 받는 입장에서도 비슷하게 적용됩니다. 고급 개발자들이 그렇게 말하는 데에는 이유가 있을 것입니다. 이것을 이해하고 왜 그렇게 이야기하는지 판단하는 것이 중요합니다. 저는 리뷰하는 입장이 많이 되다 보니 조금만 구조를 개선하면 더 오랫동안 시스템의 확장성 이슈가 없어질 수 있는 제안을 많이 하곤 합니다. 그런데 항상 정답이 없다는 것을 명심하고 리뷰받는 개발자의 의견을 존중하려고 노력합니다. 보통은 제가 제안하는 방법은 확장성은 좋아지지만 복잡도가 올라가는 경우가 많거나, 유지보수가 편해지지만 코드의 커플링이 강해지는 방법들을 던져주곤 합니다. 결과적으로 결정을 각 개발자들에게 맡기지만 고급 개발자로서의 역할은 언제나 조금은 다른 관점에서 새로운 접근 방법을 제시해 보는 것이라 생각합니다. 저희 팀 개발자들을 때로는 수용하고 때로는 자기 주관대로 가는데 어느 방향을 선택하든 단기적으로 프로젝트에 영향이 없다면 그대로 진행합니다. 보통은 장점만 있는 접근 방법이 없기 때문에 중요한 것은 개발자들이 그 장단점을 이해하고 있다면 그것으로 된 것입니다.

처음부터 확장성이 있는 방법을 선택하느냐 복잡도가 적은 선택을 하느냐는 항상 고민되는 부분입니다. 저는 개발일정을 조금은 미루더라도 확장성이 있는 방법을 우선으로 고려합니다. 하지만 상황에 따라서 유연하게 처리를 할 수 있는 것이 중요합니다. 이러한 유연함은 개발자에게 아주 중요하다고 생각합니다. 특히 프로젝트 오너나 비즈니스와 이야기할 때 무조건 반대 또는 무조건 요구사항 수락을 하는 것이 아니라 한 가지 정답만을 향해 가는 것이 아니라 여러 방법들을 고민하고 먼저 제시하는 것이 중요하다고 생각합니다. 따라서 개발자로서 가장 중요한 것은 어떠한 접근 방법에 대한 결정을 내렸을 때 항상 생각해야 하는 것은 아래와 같습니다.

어떠한 접근 방법들과 대안들이 있는가?
각 접근 방법들의 장단점이 무엇인가?
현재 상황에 가장 적합한 접근 방법은 무엇인지 또는 선호되는가?

특정한 문제에 대하여 한 가지 정답만을 바라고 생각하지 말고 이러한 식으로 고민을 한번 더 하면 좋고, 고급 개발자라면 다른 개발자들이 어떠한 문제를 해결할 때 이렇게 생각할 수 있도록 도와주는 것이 중요합니다.

개발에 있어서 정답은 없습니다. 왜냐하면 요구사항은 항상 언젠가는 바뀌기 때문입니다.

다음 편: "개발자 안티패턴4 - 남의 문제를 지적하지 말라"

개발자 안티패턴2 - "급하니까 나중에 고칠께요."

Unikys — Thu, 21 Oct 2021 01:40:07 +0900

코드리뷰를 하다보면 정말 좋지 않은 코드를 많이 보곤 하죠. 이럴 때 '이것 제대로 고쳐주세요', 라고 이야기하면 가끔씩 들려오는 이야기가

"급하니까 나중에 고칠께요."

"일단 배포하고 수정할께요."

비슷한 부류로 이러한 케이스도 있죠.

"일단 배포하고 테스트 쓸께요."

이러한 상황이 많다면 근본적으로 다시 어떻게 일을 하고 있는지 검토가 필요할 겁니다. 아니면 혹시 주위에 이러한 개발자가 보인다면, 이러한 개발자는 온 몸에 시한폭탄을 두르고 다니는 개발자이기 때문에 좋은 길로 잘 인도해주거나 좀 거리를 두는 것이 좋을 것입니다. 그러면 이러한 개발자를 어떠한식으로 올바르게 성장 시킬 수 있을까요?

먼저 어떠한 개발자들이 이러한 이야기를 많이하는지 대충 살펴보면:

(1) 정말 급한 요청을 처리하는 개발자: 오케이 인정, 이번은 봐주지만 매주 그러면 안 됨

(2) 마지막에 엄청 큰 코드리뷰를 올리는 개발자: 수능 공부를 하루전날 밤세워서 할 사람이지만, 개선 가능성 큼

(3) 게으른 개발자: 역시 개선의 여지는 있음. 개인적으로는 고집 쎈 것보다는 나음

(4) 고집 쎈 개발자: 말을 해도 못 알아들으니 그냥 같이 일하기 싫음

그러면 "급하니까 나중에 고칠께요"라는 말을 하지 않도록 어떻게 개선할 수 있을까요?

(1)번 케이스는 흔하게 발생하는 것 같지만, 그렇게 코드리뷰나 테스트 코드를 쓰지 못할정도로 급한 케이스는 한달에 한번도 많은 것이라고 생각합니다. 만약 한 달에 비슷한 케이스가 많이 일어난다면, 기본적인 코드 퀄리티와 개발 프로세스를 검토할 필요가 있습니다. 일단 지금 부터 나가는 코드에 대해서라도 테스트를 조금 더 쓰는 것에 신경 쓴다면 충분히 개선 될 수 있습니다.

(2)번이 제일 많이 발생하는 케이스인데, 개발 방법을 바꿔줘야할 필요가 있습니다. 하나의 큰 코드 리뷰보다는 하위 호환성을 고려한 짧은 코드리뷰로 여러 개 만들어내는 것을 연습하면 충분히 개선 가능합니다. 아직 경력이 많지 않거나 좋은 개발 환경에서 일해보지 못한 개발자분들에게서 많이 볼 수 있습니다. 하나의 코드리뷰나 커밋에 테스트나 환경설정 변경 이외 순수 로직 변경 코드가 파일 10개가 넘어가면 작게 나눌 수 있도록 고민해보면 좋습니다. 연습이 좀 필요할 수 있지만 작은 코드 개발 루틴이 습관이 되고 익혀두면 코드리뷰로 개선되는 코드퀄리티가 월등하게 올라가게 되고, 하위호환성 고려를 잘해두면 롤백할 때에도 리스크가 적습니다. 특히 하나의 큰 코드리뷰 자체는 이미 "되돌아갈 수 없는 강"을 건너가버린 것입니다. 되돌아갈 수 있게 디자인 논의/미팅 많이 하시고 코드리뷰도 프로토타입이든

만약 세번 이상 비슷한 리뷰 커멘트가 달린다면 (3) 또는 (4)번에 해당하는 확률이 높으니 다시 한번 어떠한 커멘트가 달렸고 왜 그것이 고쳐지지 않았는지 되돌아 볼 필요가 있습니다. 참고로 비슷한 코드리뷰 커멘트는 다섯번 여섯번 달리지 않습니다. 리뷰어가 보통 그냥 포기하게 되거든요.

(3)번 유형 중에서 배우는데에도 게으른 개발자라면 성장 가능성이 매우 낮습니다. 언젠가 도태될 개발자입니다만, 게으름이 장점이 될 수 있는 분야에서 일하면 좋을 수 있습니다. 서비스 개발 말고도 CI / CD나 대쉬보드, 알람 등과 같은 것에 관심을 둔다면 팀에 가치를 가져올 수 있수도 있습니다.

(4)번이라면 언젠가 팀/회사 내에서 도태가 될 개발자죠. 사실 대화 몇 번 해보고 실제 코딩 실력을 보면 대충 각은 나오는데, 입만 살고 코딩 실력이 없으면 최악의 팀원입니다. 이러한 팀원으로 인하여 팀 분위기가 와해되고 뒷담화까지도 빈번하게 이루어지기도 합니다. 제발 이러한 개발자가 되지 마시고, 이러한 개발자가 있다면 피하세요.

따라서 가장 중요한 것은 개발자로서 언제나

- "고집을 버려야 한다"

- "누구에게나 배울 수 있다는 겸손한 자세를 가져야 한다"

는 것이라고 생각합니다. 경력 5년 이하의 개발자들은 쉽지만 경력이 5년이 넘어가면 이게 잘 안되는 개발자분들이 있습니다. 그래서 연차가 올라가면 피드백 내용에 대해서 다시 생각해보고, 다른 개발자들의 의견도 존중해주고, 대화하는 방식도 바꿔야하기도 합니다. 그게 어떻게 보면 다른 개발자를 성장시키면서 회사를 이끌어 나갈 수 있는 테크리드가 되어가는 과정이 아닌가 생각합니다. 이러한 되면 본인 뿐만 아니라 개발자들이 서로에게 배우는 분위기가 형성되어 결과적으로 팀 전체가 높은 수준의 개발 프로세스를 가질 수 있게 되기도 합니다. 개인의 관점에서도 배우는 것이 늘어나게 되고 자기 계발이 자연스럽게 따라오기 때문에 더 성공적인 개발자가 될 수 있지 않나 생각합니다.

그러면 다음에는 어떠한식으로 다른 개발자들과 생각하고 대화하면 좋을지에 대한 글 하나 더 써보도록 하겠습니다.

다음편: "개발자 안티패턴3: 정답을 단정짓지 말라"

개발자 안티패턴4 - 남의 문제를 지적하지 말라

Unikys — Wed, 20 Oct 2021 02:58:16 +0900

제목을 다소 과하게 잡기는 했는데 이 부분에 대해서 제가 스트레스를 받은 적이 많아서 꼭 이야기하고 싶었던 내용 중 하나입니다. 사실 제목과 다르게 남의 문제를 지적하는 건 사실 괜찮습니다. 이거 보여주고 싶어서 어그로 끌어보았습니다. 제가 여기서 집중하고자 하는 부분은 '남의 문제를 지적'하는 행위 자체가 아니라 '어떻게 지적하느냐'에 대해서 조금 더 이야기해보고 싶었습니다. 제가 최근에 몇 년 새에 겪었던 두 가지 케이스를 이야기해드리고자 합니다.

1. 이상주의 개발자 D와의 협업

가끔 보면 개발자 중에 이상주의자들이 많습니다. 이상주의자란 무엇이냐 하면 항상 이상적인 세계를 꿈꾸듯, 이상주의 개발자는 항상 이상적인 코드와 이상적인 인프라를 상상하는 개발자들입니다. 이러한 이상적인 것을 추구하는 것이 나쁘다는 것은 아니고 어떻게 추구하느냐에 따라 크게 다릅니다.

어느 날 팀에 CI와 코드에 대한 정적 분석(static analysis)이 부족하다고 판단해서 최근에 회사에서 새로운 CI 툴과 소나큐브를 연동하기 시작한다는 소식을 듣고 제가 한번 자진해서 저희 팀의 코드베이스를 연동시키고 정적 분석까지 할 수 있게 준비한 적이 있습니다. 빌드의 실패 / 성공에 따라 슬렉 메시지도 내보낼 수 있게 연동하고 팀에 공유를 했습니다. 여기서 이상주의 개발자 D의 반응은 어땠을까요.

D: "도커 이미지도 푸시하고 자동 배포까지 되면 더 좋겠네요."

여기서 참 한숨이 나오더라고요. 지금은 회사에서 근본적으로 자동배포를 막아놨기 때문입니다. 물론 자동배포를 하기 위한 비즈니스 요구사항들에 대한 테스트 커버리지도 안 좋은 상태이기도 하고요. 그런데 현재 상황을 고려하지도 않은 채 본인이 생각하고 있는 가장 이상적인 그림에 대해서만 언급을 합니다. 이 개발자에게 코드리뷰 같은 곳에서 코멘트를 달면 어떻게 반응을 할까요?

저: "이 부분은 이러이러하게 고쳐주시면 좋을 것 같습니다."
D: "원래 코드가 그랬어요."

저: "이 부분을 효율적으로 고쳐주시면 좋을 것 같습니다."
D: "아 그게 원래 그렇게 구현은 안 했는데, 이렇게도 해보고 저렇게도 해보고 {어쩌고 저쩌고 엄청 긴 변명}

일단 본인이 지적당하는 것에 대한 변명을 많이 하기도 하고, 본인이 생각하는 이상적인 그림으로 하지 못한 것은 전적으로 본인 탓이 아닌 남 또는 환경의 탓으로 돌리는 경우가 많았습니다.

2. 주관이 뚜렷한 입만 살아있는 개발자 J와의 협업

몇 년 전 한 개발자 J가 입사를 하였는데 나이는 저보다 조금 많아 보였습니다. 어쨌든 새로 온 개발자와 친숙해지기 위하여 가끔 테크톡을 하곤 했습니다. 이 개발자는 그러한 테크톡을 정말로 좋아하는 개발자였습니다. 이상주의 개발자와 약간 비슷하기는 한데 자기 주관이 더 뚜렷한 스타일입니다. 이 개발자와 했던 많은 이야기들이 기억나곤 합니다.

J: "저는 reflection 사용하는 것을 너무 싫어합니다."
저: "네 맞아요. 당장은 편할 때도 있지만 나중에 유지보수가 너무 힘들어요."

J: "저는 annotation을 싫어합니다."
저: "네 맞아요. 저도 동작을 annotation으로 바꾸면 영향도 파악이 어려워서 적용하는 것을 선호하지 않습니다"

여러 부분들이 맞기도 하고 저도 많이 배웠던 것 같습니다. 이러한 테크톡을 좋아하는 개발자와 간간히 테크톡을 하면 저도 많이 배우기도 해서 좋아합니다. 단지, 한번 말 걸면 1시간 동안 혼자서 계속 주저리주저리 한다는 게 문제였죠. 본인의 생각이 확고하여 새로운 생각이나 접근 방법을 쉽게 받아들이지 못하는 고집스러운 타입이기도 했습니다. 하지만 여기서 제일 큰 문제는 본인의 주관에 받는 실력을 갖추지 못했다는 것입니다. 저는 당시 테크리드였지만 다른 일을 하고 있었고 어느 날 이 개발자 J와 다른 개발자 S가 동업을 하는 것을 옆에서 들은 적이 있습니다.

J: "구현을 이렇게 하는 게 마음에 안 드네요."
S: "그러면 어떻게 해야 될까요?"
J: "잘 모르겠지만, 그냥 이렇게 하는 것이 마음에 안 들어요."
S: "..."

J는 어떠한 식으로 하면 안 좋을지 어느 정도의 감이 있습니다. 하지만 실제로 어떻게 문제를 풀어나가야 할지 모르고 일단 반대부터 하고 시작합니다. 이것 때문에 개발자 S가 저한테 따로 와서 엄청 한탄하더라고요. 그렇다면 이러한 개발자들이 어떠한 악영향을 미치게 될까요.

이러한 개발자들의 영향

앞선 개발자 D는 원래 있는 팀에서 단기로 파견 나왔던 개발자입니다. 이 개발자는 코딩은 그래도 어느 정도 실력이 있지만, 다른 사람과의 협업에 있어서 팀워크를 방해하고 다른 팀원들의 성취감을 박탈합니다. 팀적인 분위기에서 악영향을 미치게 되는 개발자라고 볼 수 있습니다. 왜 이전 팀에서 파견이 나왔을지 확신은 없지만 약간 의심은 들게 만드는 그러한 개발자입니다. 참고로 지금은 다시 다른 팀으로 또 파견 간 상태입니다.

개발자 J는 어떨까요. 개발자 S는 저보다 회사를 조금 더 오래 다녔고, 개발자 J는 저보다 회사를 조금 늦게 입사를 했던 상황이었고, 저와 개발자 S, 그리고 개발자 J가 묶여서 한 서비스를 구축해나가고 있었습니다. 이때 같이 동업 안 했던 개발자들은 개발자 J가 정말 일 잘하는 것으로 생각하고, 외부의 평가는 엄청나게 좋죠. 하지만 같이 일 해본 사람은 실제 밑천이 다 드러났기 때문에 부정적인 반응이 대부분이었습니다. 개발자 S는 저한테 와서 엄청 신세한탄을 하곤 했습니다. 같이 일을 하는 사업부서와 매니저 급에서도 어느 순간 눈치를 채기는 했지만 그 시간이 조금 걸리기는 했습니다. 나중에는 결국 저희 매니저가 개발자 J를 다른 급한 프로젝트가 있는 팀으로 파견시켜 버렸습니다. 그전까지 개발자 J가 미친 영향은 단순히 팀적 분위기의 와해뿐만 아니라 다른 개발자들의 생산성에도 영향을 주어서 팀 전체의 생산성을 저하시키게 되는 결과로 이어졌습니다. 나중에 개발자 J는 다른 팀으로 갔었고 이후에 어느 순간 퇴사한 것을 알게 되었습니다.

남의 문제를 지적하기 전에 현재 상황을 먼저 이해하고 적극적으로 도와주세요

어떠한 문제를 지적할 때에는 현실을 직시하고 단기적으로 불가능한 것과 가능한 것을 이해하는 것이 필요하고 현재 상황을 먼저 고민해 보고 문제를 지적하는 것이 좋을 것입니다.

Q: 문제를 지적함으로써 해결 가능한 문제인가? 다른 어떠한 이유로 해결이 불가능한 문제인가?

A: 해결이 안 된다면 굳이 지적할 필요가 없습니다. 지적만 하지 말고 어떠한 이유로 해결이 안 되는지 확인하고 그것이 해소될 수 있도록 도와주세요.

Q: 어떻게 해결해야 할지 본인이 잘 알고 있는가?

A: 모른다면 직접 여기저기 물어보고 조사해서 공유하세요. 누군가가 알고 있다면 그 사람에게 도움을 청하세요. 문제 해결을 다른 사람한테 미루지 마시고 적극적으로 나서세요.

Q: 해결할 방법은 아는데 시간이 없어서 직접 나서서 도와주고 해결할 수 없는가?

A: 특히 코드리뷰나 디자인 리뷰를 할 때 "이렇게 하시면 안 되요"라고만 달지 마세요. 그리고 논의에는 참석 안 하다가 뒤늦게 와서 "그렇게 하시면 안 되요" 한마디 던지고 가지 마세요. 정말 얄미워요. 항상 방향성도 같이 알려주거나 방향성을 간단하게 문서화해서 공유하세요.

상황에 따라 다르기는 하지만, 일반적인 코드리뷰나 디자인 리뷰에서의 문제 제시는 방향성에 대한 토론 또는 방향성 제시와 함께 해주세요. 그렇게 하는 것이 상대방에 대한 동기부여와 활력을 불어넣어 주게 되고, 팀적인 신뢰를 쌓을 수 있는 가장 간단하게 할 수 있는 노력입니다.

어떻게 이러한 개발자들의 채용을 막아야 하나?

솔직히 방법이 없습니다. 면접에서는 이러한 개발자들이 더욱더 활개 치며 본인의 생각과 이상적인 방향을 이야기하듯이 풀면 어느 면접자가 매료 안 될 수 있을까요. 그러한 이상적인 모습을 회사에 반영할 수만 있다면 정말 이러한 인재는 그대로 채용하는 게 맞겠죠. 저는 그래서 인터뷰할 때 살짝 돌려서 묻는 질문들이 있습니다. "본인이 가장 실패했을 때"를 물어본다던지 "현재 구현한 알고리즘의 부족한 부분"에 대해서 물어보면 이 사람이 다른 사람의 의견을 듣는 사람인지 아닌지 최소한 고집이 있는 사람인지는 구분할 확률이 높습니다. 그것 외에는 단편적으로 짧은 시간의 면접에서 다 파악하는 것은 사실상 불가능하기 때문에 이러한 개발자의 입사를 완전히 막을 수는 없다고 생각합니다.

어떠한 식으로 개선시켜줘야 할까?

사실 사람을 바꿔서 쓰는 게 아니라서 힘듭니다. 이미 오랫동안 형성되어 온 성격을 회사에서 바꾸는 것은 어렵지만 적어도 주변의 환경이나 분위기 구성은 바꿀 수 있게 도와줘야 하지 않나 생각합니다.

서로 칭찬하고 격려하는 분위기를 만듭니다.

Acknowledgement라고도 하는데, 일단 각 팀 구성원의 작은 성과라도, 작은 버그의 원인 발견이라도 칭찬하고 고맙다고 해주는 분위기가 중요하다고 생각합니다. 이렇게 하면 개발자들은 성취감을 느끼게 되고, 자진해서 야근(?)까지 하게 되는 기이한 현상도 보이게 됩니다. 다른 사람들이 칭찬하고 있는데 그 와중에 와서 얼굴에 침 뱉고 갈 수는 없겠죠. 그러니까 이러한 개발자들이 활개 치기 전에(?) 먼저 선수 쳐서 빠르게 칭찬해 줍시다.

저: 저번에 R이 프로세스를 자동화시켜 줬어요. 정말 고마워요. 덕분에 잠을 더 잘 수 있게 되었어요.

물론 이 개발자에게도 비슷하게 칭찬도 해주고 자진해서 개선할 수 있게 독려하면 좋은 것 같습니다.

저: D가 자동배포에 대한 좋은 의견 내주었는데, 향후 개선할 점으로 인지하고 티켓을 하나 만들어 놔 주세요.

이상주의 개발자들의 말을 무시하는 것보다 활용하는 것이 효율적입니다. 궁극적으로 그렇게 하면 이점이 많아지는 경우가 많으니까요. 하지만 위의 D의 케이스를 보면 현재 어떠한 상황이고 어떠한 제약사항이 있는지 모르는 것이 분명했습니다. 따라서 이 부분을 도와주는 것이 좋 습니다.

현재 상황 분석을 도와주고 단계별로 비전을 제시하고 업무를 줍니다.

만약 어떠한 제약조건 때문에 이상적인 구현 방법으로 나갈 수 없는 상황에 있을 때에는 이러한 개발자들에게 직접 해결하도록 맡기는 것도 좋은 방법 입니다. 이미 본인은 이상적으로 어떠한 방향으로 가는 것이 좋을지 알고 있지만 현재의 제약사항들을 잘 이해하고 있지 못하기 때문에 이에 대해서 잘 설명하고 단계별로 그 방향으로 나아갈 수 있는 업무를 주면 좋다고 생각합니다.

저: D가 말하는 방향이 맞습니다. 그런데 그 방향으로 가기 위해서는 먼저 테스트 커버리지가 좋아야 하는 문제가 있습니다. D가 방향성에 대해 잘 아는 것 같으니 직접 해결해줄 수 있나요?

근데 실력이 없는 J의 상황이었다면 어떻게 반응 했을까요?

저: 저번에는 J가 정말 좋은 의견 내주었는데 혹시 J가 직접 디자인 진행해주실 수 있으신가요?
J: 못 합니다. 제 역할이 아닙니다. 다른 일 하고 있습니다.

네, 다른 사람들은 놀고 있는게 아니죠. 사사건건 딴지 걸면서 이러한 반응을 한다면 지뢰입니다. 이렇게 바뀌지 않을 것 같다는 확신이 있다면 또 다른 방법을 찾아봐야겠죠.

혼자 활개칠 수 있는 협업이 덜 필요한 프로젝트 투입 시켜줍니다.

문제가 되는 이상주의 개발자들은 머리는 이미 저 높이 올라가있는데 현실 실력은 시궁창인 것이 문제입니다. 그래도 머리로는 어디로 가야할지 알고 있기 때문에 사실 이러한 개발자들은 그러한 프로세스 개선이나 플랫폼/인프라 개선하는 일에 투입되는 것이 효율적일 때가 많습니다. 확장성과 속도가 중요한 서비스보다는 좀 느리지만 품질을 더 중요한 쪽에서 일을 하면 더 적성에 맞을 때가 많다고 생각합니다. 이러한 개발자를 다른 개발자와 협업하게 되면 다른 개발자들에게 악영향을 미치므로 협업은 최소화할 수 있는 단독 프로젝트를 시켜주는 것도 괜찮 습니다. 물론 개발자 J와 같이 처음부터 실력이 뒷받침되지 않는 경우에는 단독 프로젝트를 통해서 외부에 대한 평가를 제대로 받게 되는 효과도 있습니다. 저는 이 방법으로 다른 사람들에게 J의 실제 실력에 대해 알려주었습니다.

근데 이러한 실력 없는 이상주의 개발자들이 항상 하는 장애나 어떠한 문제가 발생경우 "꼭" 하는 말이 있습니다.

제발 이런 말은 하지 마세요. "제가 그렇게 하면 안 된다고 했잖아요"

제발 이러한 말은 하지 맙시다. 개발자들이 실수를 하는 것은 당연한 것이고, 버그가 배포되거나 장애가 발생하는 것은 언젠가는 반드시 일어납니다. 개발자라면 피할 수 없는 숙명이기 때문에 누구누구의 잘잘못을 따지고 추궁하는 것보다는 이후에 비슷한 장애 발생시의 회복 절차와 재발 방지에 집중하는 것이 훨씬 생산적입니다.

나중에 와서 그렇게 말 할 거였으면 제발 문제를 봤을 때 먼저 적극적인 자세로 직접 고쳐주세요.

다음편: 개발자 안티패턴5 - "제 역할이 아니에요"

개발자 안티패턴1 - 레거시라고 책임 회피하지 말아라

Unikys — Mon, 11 Oct 2021 19:23:17 +0900

정말 이거 하소연하고 싶어서 미쳐버릴 것 같네요. 여러 오래된 서비스를 제공하고 있는 팀들과 협업하다보면 이러한 이야기를 자주 듣곤 합니다.

"너무 옛날 시스템이라서요"

"문서화가 전혀 안 되어있어서요"

"개발 했던 개발자가 팀을 떠나서요"

"옛날에 다른팀에서 지원해줬던 개발자가 개발한거라서요"

하.. 이런 핑계들 좀 안 하면 안 될까요. 이러한 소리 들으면 정말 답답하고 한숨만 납니다. 물론 저도 개발자인지라 가끔 특정한 기준 아래에 이러한 핑계를 대기는 합니다.

"처음 서비스를 인수인계 받고 담당하게 되는 세 달 동안만 이런 핑계 허용"

세달은 프리패스로 책임 회피가 가능한 마법의 문장들이죠. 물론 세달 동안 서비스의 구석구석 100% 전부다 이해할 수는 없지만, 최소한 메인 플로우, 문제가 있다면 그러한 문제가 왜 발생했는지, 흐름을 파악하고 코드를 읽는 건 한두주 정도면 누구나 할 수 있습니다. "개발자라면" 너무나 당연하고 해야 할 일인데 레거시 시스템이라고 이해하려는 노력을 기울이지 않고 몇년째 이러한 핑계를 대고 있는 개발자들을 보면 정말 답답합니다. 특히, 해당 팀에서 담당하는 현역으로 돌아가는 서비스인데 매니저급에서 이러한 핑계들을 대고 있으면 진짜 화만 납니다. 제가 소심하다보니 대놓고 이러한 말들을 못해서 여기다가나마 한번 소리질러 봅니다.

Q: "너무 옛날 시스템이라서요"

A: "그러면 차라리 서비스 내리세요"

Q: "문서화가 전혀 안 되어있어서요"

A: "코드가 제일 정환한 문서에요"

Q: "개발 했던 개발자가 팀을 떠나서요"

A: "일단 먼저 인수인계 프로세스를 검토하세요"

Q: "옛날에 다른팀에서 지원해줬던 개발자가 개발한거라서요"

A: "본인 서비스에 주인의식 좀 가지세요"

아 참 아무리 뭐라해도... 이건 인정입니다.

"코드가 없어서요"

개발자 안티패턴0 - 예고편

Unikys — Thu, 7 Oct 2021 18:04:30 +0900

개발자로 일하다보면 정말 답답하게 행동하는 사람들이 너무나 많은데 그냥 갑자기 하소연이 하고 싶어지네요.

사실 트위터 정도의 짧은 글로 써도 되는 시리즈이기는 하지만, 트위터는 쉽게 쓰고 쉽게 지워져버리니 블로그에 짧게나마 짧게 짧게 쓰려고 합니다.

어떠한 주제로 글을 쓸거냐면:

"제발 개발자라면 이런것 좀 하지 말아라"

입니다. 그래서 개발자 안티패턴으로 쓰려고 합니다.

절대 제 주위에 답답하고 짜증나게 하는 개발자들만 많아서 이런거 쓰는건 이니지만(..), 그냥 오며가며 여러 개발자들과 동업하다보면 특정한 행동이 답답한 경우가 많아서 그러한 경험들을 돌이켜보며 하소연하려고 합니다.

참고로 저는 상대가 답답하게 하면 그 행동이 고쳐질 때까지 지적하고 귀찮게 합니다. 그래서 제 주위에 그런 사람이 많지는 않습니다(..)

시작~

[0] Trunk based development 시작

Unikys — Tue, 5 Oct 2021 18:32:59 +0900

이번에 회사 내에서 컨퍼런스 발표를 하려고 간단하게 자료 조금 준비했던게 있어서 블로그에 간단하게 공유하려고 합니다.

최근의 경험들을 바탕으로 어떠한식으로 서비스 개발이 이루어지고 있는지에 대한 개발 프로세스를 소개하려고 합니다.

앞으로 글을 대략 5개 정도로 나눠서 Trunk based development 방법론에 대해서 다루려고 합니다. 개인적으로는 기존의 깃플로우나 깃헙플로우와 비교했을 때 보다 월등하게 좋아서 관련 경험들과 노하우들을 공유하려고 합니다. 개발 방법론에 대한 이야기라 글이 많지는 않겠지만, 대략적으로 아래의 5개 정도가 될 것 같고 두주에 글 하나 정도씩 업데이트를 목표로 하겠습니다.

- [1] Trunk based development 소개

- [2] Trunk based development 방법

- [3] Trunk based development에서의 코드리뷰 방법

- [4] Trunk based development에서의 배포 방법

- [5] Trunk based development에서의 테스트 방법

시작~

[잡담] 10월 10일 근황

Unikys — Tue, 10 Oct 2017 23:17:14 +0900

거의 반년만에 근황 글을 쓰게 되네요. 반년간 너무나 많은 일들이 있었고, 많은 일들 덕분에 너무나 바쁘고 정신없이 지내고 있습니다. 며칠전 장모님이 미국을 방문하게 되어 오랜만에 조금 여유가 생기게 되었네요. 요즘들어서 드는 생각은 확실히 육아는 최소 3명이 해야 좀 더 개인의 삶이 존재한다는 것이네요. 아무튼 최근 근황을 요약하자면 아래와 같습니다.

* 재택근무

아내와 저도 서로 육아가 힘들다보니 최근에 재택근무를 참 많이 하게 된 것 같네요. 재택근무를 하면 좋은 점도 있지만 나쁜 점도 참 많은 것 같습니다. 일단 좋은 점은 집에서 그냥 일하면 되니까 출퇴근에 대한 시간 제약없이 그냥 짬짬이 생기는 시간을 활용하면 된다는 것이고, 안 좋은 점 또한 시간 제약이 없다는 점인 것 같습니다. 딱 정해진 출퇴근 시간은 없고, 회사에서 일할 때 만큼 효율은 안 나니까 "오늘 하루 회사에서 일했다면 이 정도 일은 했겠지" 싶은 양을 채워야지만 만족하고 자게 되는 것 같습니다. 덕분에 재택근무하기 전날과 하는 날은 본의 아니게 집에서 새벽까지 컴퓨터를 붙들고 있는 경우가 많네요.

이제는 재택근무를 하기로 했으면 아예 작정하고 애 재우고나면 전날에 새벽2시까지 일하고, 아침에 애 일어나면 놀아주다가 8~10시 2시간 정도 일하다가 그냥 온 가족이 다 같이 외출해서 애가 낮잠자는 2시쯤 귀가, 2시부터 4시정도까지 또 일하다가 아이가 자기 전인 9시까지는 가족과 함께 시간을 보내게 됩니다. 집중해서 일하는 효율이 나지 않기 때문에, 애가 자고나면 그때부터 또 새벽2시까지 집에서 일을 하게 되는 경우가 다반사네요. 출퇴근 시간이 없다는게 꼭 좋은 것만은 아니고, 집에서 노트북을 붙들고 앉아있는 것도 가시방석이고 아내한테도 미안하고 재택근무가 능사만은 아니다라는 것을 느끼게 된 기간이네요.

* 그 놈의 영어울렁증, 특히 회의...

미국에서 일하고 있지만 영어는 언제나 힘드네요. 매일매일하는 스탠드업 미팅은 뭐 그냥 자기 할일을 이야기하는거니까 그냥 저냥 말할만 한데, 문제는 서로의 의견을 이야기하고 논리로 상대를 이겨야하는 회의입니다. 솔직히 저는 회의를 들어가게 되면 말 한마디도 안 하고 나오는 경우가 다반사입니다... 최근에 팀에서 대표해서 회의를 참여하고 있는데 이것 또한 참 힘드네요. 그래도 오늘은 한마디라고 하고나오자라는 생각을 하여 4마디 정도는 하고 나온 것 같네요. 한국말로 하는 회의를 했으면 '그런식으로 말하지 말라'고 다 뒤집어 엎었을 것 같은 생각이 들지만 영어라서 제가 참고 넘어갑니다. (물론 집에 와서는 부들부들..)

한국에서도 가끔 회의를 하다보면 회의에서 투닥투닥하다가 회의 끝나면 아무일 없다는 듯이 웃으면서 인사하고 식사하고 그랬던 것도 많이 했지만, 여기서는 모든게 영어가 되다보니 "그때 쟤가 무슨 말 어떻게 표현했었지?"와 같은 생각을 자꾸 되새기게 되고 그게 자꾸 머리속에 남아서 결국 저한테 남는 것은 "쟤는 고집불통"이라는 생각 뿐인 것 같네요. 그런데 미국에서의 회의 느낌은 회의 안에서 싸우고, 끝나면 진짜 원래대로 그냥 남남이 되어버리는 느낌인 것 같습니다.

물론 오늘 회의 중에 그렇게 역정을 내던 개발자가 나중에 단체메세지로 "Sorry I was so excited"라고 하는 것을 보고, 아 얘네도 회의 시간에 싸우는 것이 신경 쓰이기는 하는구나 싶었네요. 한국은 그냥 식사하면서 자연스럽게 없던 일하는 경우가 많은데, 이렇게 확실하게 이야기를 하니까 조금 더 마음이 덜 신경 쓰이는 것 같기도 합니다.

* 둘째 임신

요즘 바빴던 근본적인 원인을 꼽으라면, 둘째가 임신 되었기 때문인 것 같습니다. 아이 하나일 때에 육아를 한 다음 밤잠 쪼개가며 개인의 시간을 어떻게든 만들어 보았지만, 둘째가 임신되고나서는 이것저것 신경써야 할 것들이 더 많다보니 너무 피곤해서 밤잠을 쪼갤 엄두도 안 나게 되었습니다. 재택근무도 일주일에 두번씩 하는 경우가 생기게 되고, 그러다보니 앞서 썼던 것처럼 일주일에 4일은 새벽까지 집에서 그냥 일하는 시간으로 보냈던 것 같습니다. 그래도 이제 임신 초기는 어느 정도 지나가서 아내도 이제 조금 더 안정감을 찾고 있어서 이제 짬짬이 다시 시간이 나지 않을까 생각했습니다. 게다가 마침 둘째 임신과 함께 장모님이 잠시 한국에서 오셔서 아이 보는 것과 저녁식사를 해주셔서 시간이 날 줄 알았지요.

* 집 살 준비

아직까지도 집을 사지는 못했지만 시애틀의 미친듯이 올라가는 집값 때문에 조금이라도 빨리 일단 집을 사기로 했습니다. 아직 오퍼단계라 뭔가 마무리는 안 되었지만, 어제 오퍼 카운터 받고 리카운터도 해보고, 이 집이 안되면 바로 다른 새로운 집으로 오퍼 넣을 준비하다가 오늘은 새벽에 여러 가지 생각으로 잠이 안 오네요. 그 동안 몇달간 집을 사려고 집도 보러다니고, 기본적인 집 사는 프로세스 공부도 하고 여러 가지 일이 있었네요. 집 사는 프로세스는 일단 오퍼를 한번 넣어보니 조금 알게 되는 것 같네요. 그래도 여전히 부동산 관련 영어는 너무 어렵네요. 나중에 경험을 토대로 요약 글을 하나 써봐야겠다고 생각했습니다. 미국에서 처음으로 집을 사는거라 두근거리기도 하고 기대되기도 하고, 오퍼를 넣어서 경매 들어가는 것도 신기하고, 셀러가 황당한 조건을 요구하면 좀 화가 나서 때려치우고 싶다가도 잠시 뒤에 생각하면 또 셀러한테 미안하기도 하고 잠 복잡 미묘한 감정들이 많이 오가고 있는 집구매입니다. 모쪼록 조만간 잘 마무리 되면 좋겠네요. 이쪽을 신경쓰고 은행 왔다갔다하는 것도 참 스트레스고 피곤하네요.

* 그래도 계속 되는 공부, 또 공부

사실 블로그 글을 올리지 못한 또 다른 이유가 있다면, 개인적으로 제가 어느 정도 잘 알고 있다라는 느낌을 받지 않으면 글을 쓰는 것을 약간 꺼리게 되는데, 지금까지는 그러한 깊이 있는 공부보다는 넓게 이것저것 공부 많이 한 것 같네요. 특히 요즘은 기능 개발보다는 빌드 시스템 구축하는 것이 약간 재미를 느끼고 있어서 매니저한테 1:1 면담 때 그렇게 이야기하고 조금 더 빌드와 관련된 일을 하고 있습니다. 그 동안 조금이라도 접했던 것과 느낌을 정리해 보면..

- CMake: 레퍼런스가 참 없지만, 안드로이드 스튜디오가 밀고 있어서(?) 더 뜰 것 같은 느낌

- GYP: 레퍼런스가 더 없는 느낌=죽은 프로젝트 느낌..

- Python: 매일매일 쓰고 있네요. 그런데 아직 깊이 있는 공부까지는 필요 없는 것 같네요. 잘 몰라도 구글님이 다 알아서 해주시고 계십니다.

- Ruby: 아직 봐도 잘 모르겠네요. 그냥 코드 읽는 수준, 고치기에는 아직 겁나는 수준..

- Dashing: 루비 대쉬보드 프레임워크인데 제약이 너무 많아서 커스터마이징을 많이 했었네요.

- Elastic search / Kibana: 요즘 조금씩 하고 있는 놈들인데, 비쥬얼라이제이션이 재미있네요. 동료들한테 이거 한번 보여주면 눈 돌아가더군요.

저희 조직 빌드 시스템의 구축은 대부분 파이썬으로 되어있어서 매일매일 파이썬을 뜯어 고치고 문제 분석하고 있네요. 빌드 시스템을 개선하거나 문제 있는 점을 찾아서 고치는 이러한 일들이 약간 제 적성이 많이 맞는 것 같아서 요즘 이쪽으로 공부하고 일하는 것이 너무나 재미있네요. 그래서 매니저 면담 때마다 하는 말이..

"I really like to make my life, and everybody's' life better."

귀찮게 같은 일 반복하고, 에러 분석하는데 매번 다른 빌드시스템 들낙날락하는 것들 싹 다 단순화하고 데이터를 한눈에 알아보게 만드는게 요즘 제 일이고 즐거움입니다. 여기서는 그것을 OE: Operational Excellence라 하며 약간은 귀찮지만, 어찌되었든 처리하면 모두가 득이 되는 일들을 묶어서 칭하는 것 같아요. 뭐, 다른 말로 하면 저는 약간 잡일꾼이 된 것 같네요. 잡일꾼이지만 아직은 보람을 느끼고 재미가 있으니 언젠가 이쪽에서의 경험들과 힘들었던 부분들을 글로 쓸 수 있으면 좋겠네요. 그런데 일단은 집사고, 이사하고, 둘째 태어나고, 하면 언제가 될지 모르겠지만, 언젠가 다시 잠이 안 오는 새벽 글을 쓸 기회들이 많이 생기면 좋기도 합니다.

끝.

[잡담] 3월 29일 근황

Unikys — Wed, 29 Mar 2017 03:46:06 +0900

* 열심히 하겠다는 그 다짐 = 3일

지난번에 근황글을 쓰고 며칠 정말 열심히 글을 썼습니다. 저도 공부가 필요했던 부분도 있었고, 쓰다가 제대로 마무리 못했던 글을 몇 달간은 붙잡고 있는 것이 싫어서 후다닥 썼는데 역시나 딱 작심삼일이었던 것 같네요. 또 다시 정체기가 왔네요. 이제 이번주에 가족들이 한국에서 오기 때문에 그 동안 자유 방임 상태로 놔두었던 집을 청소해야 하고 노총각(아재?) 냄새가 조금이라도 사라질 수 있게 이불들도 빨고 할게 많습니다. 세금보고도 아직 마무리 못해서 얼른 해야 하는데 집에 오면 저도 모르게 티비를 틀어버리는 것이 습관이 되어버린 것 같습니다. 오늘 다시 한번 다짐을 해서 가족이 오는 금요일 전까지 글 몇개라도 더 쓰고자 합니다. 지금 다짐하면 또 3일 뒤는 딱 금요일이 될테니까요.

* 여기저기서 연락오다

지난 주에 갑자기 그렇게 동기부여가 되었던 것은 이상하게 여기저기서 연락이 엄청 많이 와서 그랬던 것 같습니다. 제 책으로 공부하다가 궁금해서 문의하시는 분들도 꽤 있었고, 책을 교재삼아 스터디하신다는 분들 고마운 몇 분께도 문의 메일이 오고, 학교 강사를 부탁하는 메일도 받고, 개발자로서 조언 문의도 오고 정말 의외로 많은 다양한 분들께 연락이 와서 제가 이렇게 나태하게 있으면 안 되겠다는 느낌이 팍 왔습니다. 덕분에 사흘은 열심히 했는데 갑자기 약빨이 떨어진 것 같네요. 제가 자주 동기부여가 되게 그러한 다양한 문의들이 쏟아지면 좋겠네요. 이상하게 그러한 연락들은 한꺼번에 확 왔다가 또 한동안 잠잠하다가 반복하는 것 같습니다. 마치 일이 바쁠 때에 항상 더 몰려오듯이 말이죠. 이번에는 즐겁게 여러 가지 문의들을 답변 했던 것 같고, 제가 아직 한국에 있었으면 더 많은 경험들을 할 수 있었을텐데 하는 아쉬움도 있네요.

* 대충하면 언젠가는 걸린다

프로그래밍은 조금이라도 대충하고 테스트를 안 하면 바로 이렇게 티가 나는 것 같아요. 책으로 스터디하신다는 한 분은 책에 잘못 되어있는 부분을 짚어 내시더라고요. 예제 중에서 그냥 잘못 된 사용의 예로 만들었는데, 그거는 어짜피 잘못 되었으니까 테스트할 필요가 없다고 생각하고 그냥 느낌이 가는대로 막 짜니까 바로 잘못 짠게 걸렸네요 ㅠ 이래서 유닛 테스트와 코드 커버리지가 중요하다는 것을 다시금 느끼게 되었습니다. 유닛테스트를 만들 때에는 의도된 잘못된 결과도 원래는 유닛테스트에 넣는게 맞는다는 것도 다시 떠오르는 경험이었습니다. 종이에 박혀있는 제가 작성했던 내용이 잘못 되었다는 생각을 하니까 죄송스럽고 부끄럽고 그러네요. 그래서 바로 출판사에 연락해서 다음판 출력 때에는 수정되어서 나간다고 하니까 참고 부탁드리겠습니다.

속깊은 자바스크립트 정오표 링크

* 시애틀에서의 생활

얼마전 오랜만에 룸메였던 지금은 구글에 다니고 있는 친구한테 페이스북 메세지로 연락이 왔었습니다. 결혼해서 베이쪽에서 맞벌이로 여행을 많이 다니면서 삶을 즐기고 있는 친구입니다. 그런데 얼핏 들어보니 베이쪽은 집 값이 정말로 많이 비싸고 세금까지 많이 뗀다고 해서 외벌이는 가능하냐고 물었는데 좀 힘들거라고 하더군요. 처음에는 베이쪽에서도 일자리를 알아보려고 했었을 때에는 미쳐 생각도 하지 못했는데, 지금 시애틀 쪽에서는 일자리를 구하고 보니 외벌이로 충분히 세가족은 먹고 살만해서 이쪽으로 오기를 잘했다는 생각이 들기도 하네요.

물론 시애틀의 가장 아쉬운 것은 날씨라고 생각합니다. 겨울에는 어딘가로 벗어나고 싶기는 하네요. 겨울의 시애틀 날씨는 익숙하게 들어온대로 일주일에 6.5일은 구름이 껴있는 것 같습니다. 0.5일, 한 반나절 정도 반짝 해가 나왔다가 들어가고 그러네요. 매년 이제 휴가를 모아서 겨울에는 캘리포니아든 한국이든 한달정도씩 휴가를 다녀야겠습니다.

예전에 들었던 한가지 사실은 시애틀이 구름은 많이 끼고 가랑비가 많이 내리기는 하지만 실제 강수량 자체만 따지면 그렇게 많이 오는 지역이 아니라고 하네요. 여기 사람들을 보면 실제로 현지인들은 우산을 잘 들고 다니지 않습니다. 우산을 안 쓰고 모자달린 코트나 후디를 입고 돌아다니는 사람은 90% 현지인인 것 같습니다. 시애틀에 있는 또 다른 재미난 풍경은 호텔이나 회사 앞에 우산꽂이가 있어서 자유롭게 우산을 가져다가 쓸 수 있다는 점입니다. 보면 항상 우산꽂이에 우산은 없지만 실제로 우산을 쓰고 다니는 사람은 은근히 없는 신기한 동네입니다. 여기서 우산을 사려면 20불은 넘어서 저도 회사 우산 하나 집에 언제 가져다 놓을까 눈치만 보고 있습니다 크크

그런데 이렇게 날씨가 우중충한 것으로 유명한 것과 다르게 사람들이 많이 모르는 것이 있다면 바로 여름의 시애틀이 아닌가 싶습니다. 여름의 시애틀은 제가 지금까지 지낸 그 어느 지역보다도 너무나 좋았던 기억이 나네요. 며칠전 잠깐 날씨가 엄청 좋길래, 이제부터 이렇게 날씨가 좋을까? 물어보니 아니라고 이야기하더군요 ㅠ

"This is just an exception"

5월 정도는 되어야 날씨가 좋아진다고 하네요. 날씨가 좋아지는 5월만 기다리고 있습니다. 작년에는 10월부터 슬슬 우중충해졌으니 여름에는 무조건 시애틀에 있을 것 같습니다. 직장 동료들끼리도 그러한 이야기를 가끔 합니다. 여름에 시애틀에서 다른 곳으로 여행가면 그게 제일 멍청한 짓이라고요. 이렇게 저는 여름 날씨만을 기다립니다.

* 가족도 기다리며

이제 가족이 이번주에 미국으로 오니 저는 회사 출퇴근 시간을 다시 조정하고 있습니다. 기존에는 7시쯤 퇴근했다면 이제 다시 아침에 8시쯤 출근해서 5시 퇴근하는 패턴으로 적응 중입니다. 그래서 지금 오후 1시반에 너무나 졸리네요. 제 자리는 매니저의 바로 앞이기는 하지만 그냥 대놓고 의자에 기대어 좀 자다가 이 글을 마저 씁니다. 이제 가족이 돌아오면 몸이 바빠질테니 블로그는 이제 다시 짬짬이 글을 쓰는 소소한 즐거움을 찾게 되지 않을까 싶네요. 목표는 여전히 가족이 오기 전에 쓰던 Bootstrap 글 하나를 더 쓰는 것입니다. 그러면 내일 저녁에는 올릴 수 있기를 기대합니다. 물론 집 청소와 냉장고 청소를 깨끗하게 하고난 다음이겠지만요(...)

[현재 작성 중인 글]

- [Bootstrap] CSS 기능: 폼 양식과 테이블

- [티스토리 스틴 편집] 반응형 스킨과 구글맵 충돌 해결

- [Git] git commit 수정하기

- [C++팁] 5개

[작성 예정]

- [Bootstrap] 자바스크립트 기능

- [Bootstrap] 컴포넌트 기능

- [밑바닥부터 홈페이지 만들기] 메뉴 관련 문의/요청 내용 정리

- [Git] git branch

- [자바스크립트] DOM 접근의 성능 이슈?!

끝.

[시애틀생활] 시애틀 공항(SEA-TAC) 입국 절차(APC 입국수속)

Unikys — Mon, 27 Mar 2017 06:00:46 +0900

APC 입국 수속을 처음으로 경험했던 것이 시애틀 공항이어서 처음에는 시애틀 공항이 특이한가 생각했지만, APC에 대해서 찾아보니 미국 내 조금 큰 공항들은 이미 많이 하고 있는 것 같네요. 다른 공항들은 지금 어떤지 모르겠지만, 처음으로 겪어봤던 시애틀 공항의 입국 수속 절차는 '최악'이었습니다. 그래서 몇 번 시애틀 공항으로 입국을 해보니 이제 조금 파악이 되는 것 같아 글을 써봅니다.

* 일반적인 공항의 입국 순서

일단 먼저 다른 공항의 기본적인 해외에서 입국 절차는 아래에서 크게 벗어나지 않습니다.

비행기 도착
입국 수속
짐 찾기
세관 신고
공항으로 나가기

여기서 (2) 입국 수속과 (3) 짐 찾기 사이에 영주권 등의 비자로 입국을 하게 되면 별도의 프로세스를 거치게 되는 경우도 있고, (4) 세관 신고를 할 때 잘못 걸리면(?) 짐 검사를 추가적으로 하기도 합니다. 조금 빡빡한 공항의 경우에는 모든 사람들이 (4) 세관 신고를 하면서 짐을 다시 한번 엑스레이에 넣어서 보내는 경우도 있습니다.

* 시애틀(SEA-TAC) 공항 입국 순서

그러면 시애틀 공항의 경우는 어떠한지 살펴보면 조금 달랐던 부분은 바로 (2) 입국 수속하는 부분과 (5) 공항으로 나가는 부분입니다. 위의 일반적인 순서에서 조금 더 세분화 되어있다고 보면 됩니다.

비행기 도착
입국 수속

APC 입국 수속
대면 입국 수속

짐 찾기
세관 신고

큰 짐 붙이기

공항으로 나가기

큰 짐 찾기

* APC 입국 수속

여기서 다른 공항들과 다르게 특이했던 것은 바로 APC 입국수속이라는 것이었습니다. 비행기에서 내려서 사람들 가는대로 입국 수속하는 곳에 도착하면 파란색의 1번 줄인 APC 줄과 2번 줄인 빨간색의 비자 줄이 두 가지로 나뉘게 됩니다. APC는 Automated Passport Control의 약자로 시애틀 공항에는 APC로 입국이 가능합니다. 시애틀 말고도 다른 대형 공항들에서도 이미 도입되었다고 나오는데, 활성화 된 이후로 처음으로 들어온 공항이 시애틀 공항이라 많이 당황했었습니다. 기본적인 APC에 대한 내용과 어떠한 공항에 설치되어있는지 확인하려면 아래 주소로 들어가면 됩니다.

http://www.yvr.ca/en/business/self-service-border-products/automated-passport-control?gclid=CjwKEAjwh9PGBRCfso2n3ODgvUcSJAAhpW5omsvQxrCdQLQutj5nzXVI7vNxUz-w0RHskqCXHUtJuRoCbIPw_wcB

APC를 사용하려면 조건이 있는데 다음과 같습니다.

미국 시민권자
그린카드를 소지한 미국 영주권자
ESTA로 한번 이상 이미 미국을 방문했던 사람

위와 같은 사람들이 APC 입국 대상자이고 나머지 다른 비자는 일반 비자 수속으로 가야 합니다. APC는 각 사람마다 현재 동반 인원, 세관신고할 물품을 입력할 수 있는 키오스크가 있습니다. 처음에 키오스크의 화면을 보면 "미국여권", "그린카드", "해외 여권" 중에서 선택을 하도록 되어있는데, 미국 시민권자면 미국여권, 영주권자면 그린카드, ESTA면 해외여권을 선택하면 됩니다. 그 다음에는 여권이나 그린카드를 스캔하고, 가족 구성원이 있으면 추가하고 스캔해야 합니다. 각 가족 구성원들은 또 모두 사진을 키오스크에서 찍도록 되어있으니 사진도 찍어야 합니다.

이렇게 입국 인원을 입력하고나면 세관신고서에 적혀있는 내용을 그대로 입력하게 되어있습니다. 따라서 APC를 통해서 입국하는 경우에는 사실 세관신고서를 작성할 필요가 없다는 것입니다. 세관신고 물품들 입력을 다 하게 되면 작은 종이로 추가 면접 필요 여부가 출력 되어서 나오게 됩니다. 만약 종이에 크게 "X" 표시가 되어있으면 추가로 대인 면접 입국 수속을 다시 해야 하는 번거로움이 있으니, 세관신고를 필요로 하는 물건들은 들고 오지 않는 것이 편합니다. 특히 음식물을 들여오는 경우에는 따로 대인 면접 입국 수속을 다시 해야 됩니다. 여기서 음식물을 조금 많이 가져오면 나중에 짐을 찾고나서 한번 더 검사를 해야 하는 번거로움이 있기도 합니다.

그러면 APC 입국 수속의 절차를 다시 정리해보면 아래와 같습니다.

APC 입국 수속 줄 대기
키오스크가 비면 키오스크로 이동
가족 구성원마다

"미국여권", "그린카드", "해외여권" 중에서 선택
사진 촬영

세관신고 물품 입력
키오스크에서 출력된 종이에..

X 표시가 있는 경우(특이사항 있는 경우) 추가 대인 입국 수속 줄 대기 후 입국수속
X 표시가 없으면 짐 찾는 곳으로 이동

특히 추가 대인 입국 수속을 필요로 하는 경우에는 APC 키오스크를 기다리던 줄과는 별개로 뒤쪽에 하나 더 있는 줄에서 한번더 줄서서 대인 입국 수속을 해야 됩니다. 이 경우에는 어떠한 물품이 특이사항으로 걸린 것인지 물어보므로 그게 맞게 대답하면 됩니다. 음식물이 조금 많거나 특이 사항이 많으면 여기서 종이에 따로 열외 표시를 하는 경우에는 나중에 이 종이를 내면서 따로 짐검사를 추가로 받아야 합니다.

* 비자 입국 수속

위의 APC 조건 이외의 모든 사람은 비자 줄에 서야 하는데, ESTA 비자나 영주권을 처음으로 발급 받아서 입국하는 경우에도 비자 입국 수속 줄에 서야 합니다. 이쪽에 줄을 서게 되면 일반적으로 하던 입국 수속과 동일하고 지문을 수집하게 됩니다. 비자 입국 수속은 보통 줄이 길게 늘어지기도 하지만, APC가 활성화 되면서 오히려 APC 쪽에 사람들이 줄을 많이 서고 비자 입국 수속에 많이 서지 않는 경우도 있는 것 같습니다. 이 경우에 세관 신고서를 작성하였다면, 특히 음식을 들여오게 된다면 이쪽 줄이 길지 않다면 대인 입국 수속을 해야 하므로 비자 입국 수속에 처음부터 서는 것도 방법입니다. 물론 이러한 경우에는 세관신고서를 미리 작성해두어야 합니다.

영주권으로 처음 입국하는 경우에는 따로 왼쪽의 데스크에 가서 인적사항과 주소지 확인 등을 하는 추가적인 입국 수속 절차가 필요합니다. 따라서 영주권인 경우에는 입국 수속만 두시간 가량 걸릴 수 있으므로 미리 간식거리를 가방에 넣어두는 것도 나쁘지 않습니다.

* 짐 찾고 세관신고서 제출

입국수속하고 아래층으로 내려오면 짐을 찾을 수 있는데 양쪽의 에스컬레이터 중간에 무료로 카트를 이용할 수 있으므로 짐이 많은 경우 카트를 무료로 이용하면 됩니다. 카트 여기에서만 무료로 이용 가능하고 공항으로 나가게 되면 5불씩 이용료를 내야 합니다.

짐을 찾고 세관 신고서는 APC 입국 수속을 할 때 받았던 종이를 내면 됩니다. 비자 입국 수속시에는 따로 작성해둔 세관 신고서를 내면 되고요. 이를 제출할 때 위의 APC 입국 수속 종이에 열외 표시가 되어있으면 추가로 짐 검사를 받아야 하는데, 무작위로 뽑힌다고 하지만 특이사항이 많으면 그냥 열외 시켜버리는 것 같기도 합니다. 열외가 되면 왼쪽편에 큰 엑스레이 박스가 있는 쪽으로 가서 모든 짐을 통과 시키고 거기서 또 특이사항이 있다고 판단되면 모든 짐을 열어서 보여줘야 합니다.

저도 지난번에 음식을 이것저것 들고 들어가다가 열외가 되었는데, 저는 다행히 그냥 엑스레이 통과만 하더니 가라고 했지만, 앞에 어떤 애가 둘 있는 중국인 가족은 박스를 테이프로 꽁꽁 싼 짐을 전부다 뜯고 있더라고요. 그러니 너무 많은 것을 싸가지고 오는 것은 조심해야 합니다.

* 다시 짐 붙이기

세관신고서를 제출하고 카트를 끌고 가다보면 건장한 남성들이 막아섭니다. 저는 이러한 경우를 시애틀 공항에서 처음 경험해서 처음에는 많이 당황했는데, 큰 짐은 자기들이 다시 컨베이어벨트로 붙인다고 하고 카트를 가지고 갑니다. 따라서 큰 짐들은 컨베이어 벨트에 다시 짐을 붙이듯 보내고 작은 짐들과 몸만 지하철에 탑승해서 입국장으로 가면 됩니다.

* 다시 짐 찾기

지하철을 내려서 걸어나오다보면 에스컬레이터를 타고 입국장으로 내려오게 됩니다. 아까 만약 다시 짐을 붙였던 경우에는 보통 나와서 오른쪽 끝에 있는 1번 컨베이어벨트에서 짐이 다시 나오는 것 같습니다. 물론 앞서 건장한 남성들이 이야기는 해주지만 말이 너무 빨라서 저는 못 알아 듣겠더군요. 이제부터 이쪽 입국장에서는 카트도 유료라서 짐이 많은 경우에는 카트를 5불내고 빌리고 아니면 짐을 들고 주차장 또는 버스/택스 탑승하는 곳으로 이동하면 됩니다.

* 시애틀(SEA-TAC) 공항 특이한 점 정리

위에도 있는 내용이지만, 일단 APC 입국수속이 따로 있다는 점, 그리고 짐을 찾은 다음에 세관 신고 후 큰 짐들은 다시 한번더 붙여야 한다는 점이 시애틀 공항만의 특이한 프로세스 였던 것 같습니다. 이외에는 다른 공항들의 입국 수속과 크게 다르지 않으니 그대로 하면 문제 없이 입국 수속이 가능할 겁니다.

[IT영어] TL; DR

Unikys — Thu, 23 Mar 2017 06:00:40 +0900

회사 내의 위키를 보다가 문득 가끔씩 봤지만 뭔지 모르는 약어인지 태그인지 정체 불명의 단어(?)를 보게 되었습니다.

TL; DR

사실 오늘 처음 본게 아니라 지금까지 은근히 이 요상한 단어(?)를 많이 봤던 것 같습니다. 그냥 얼핏 보기에는 뭔가 <br> 태그 등과 같이 HTML 태그를 잘못 쳐서 오타가 생긴건가하는 생각을 하고 지금까지는 그냥 무시했습니다. 그런데 오늘 보고는 그래도 시간적 여유가 좀 있어서 도대체 이게 뜻이 뭔지 검색해보았습니다.

TL; DR = Too Long; Didn't Read = 너무 길어서 안 읽음

...... 이게 뭐지 크크크 뭔가 심오한 뜻이 있나 했네요.... 이게 뭔가를 나타내는 뜻일거라고는 생각을 했지만 전혀 예상치 못한 뜻이었네요 크크크 그냥 인터넷 신조어로 너무 길어서 안 읽었다는 뜻이었습니다. 가끔 글이 너무 길 때 리플로 TL; DR로 키배에서 사용하는 용어 같네요.

근데 오늘 봤던 용법은 위키에서 위에는 길게 이미지로 설명이 되어있는 가이드라인이 있고 아래에는 짧은 커맨드라인의 가이드라인 제목이 tl; dr로 되어있었습니다. 따라서, 다른 용법으로 자세한 설명을 없앤 요약 또는 간단한 방법 등으로도 사용되는 것 같습니다.

위키피디아를 보니 레딧에서는 너무나 긴 글인 경우 TL; DR 요청을 많이 한다고 합니다. 마찬가지로 요약을 요청할 때에 이렇게 많이 쓴다고 합니다. 그래서 요약이 없는 경우에는 이렇게 리플을 단다고도 하네요.

"Please include a TL;DR"

그런데 막상 뜻이나 용법을 알고보니 자신이 직접 글을 쓸 때 요약 내용이라고 할 때 이외에는 키배할 때에만 사용하는 용어 같기도 합니다. 개발자들 중에서 특히 너드들이 많아서 부연설명을 참 쓸데없이 많이하는 경우가 많던데 그럴때 쓸 수 있을까 고민이 되네요. 그런데 저는 영어로 싸울 자신이 없어서 쓸 일은 별로 없겠지만 알고나니 재미있네요.

읽을거리

https://en.wikipedia.org/wiki/TL;DR