Reimaginer

기존에 s3에 있는 한글 이름을 가진 엑셀 파일을 변경하고 싶어서 맥에서 같은 이름의 엑셀 파일을 만들어서 다시 업로드했다. 그런데, 덮어써지지 않았다. 엥? 그래서 이래저래 삽질을 하다보니 유니코드에서 한글의 조합형(NFD)과 완성형(NFC)이 있다는 것을 알게 되었고, 맥은 조합형을 사용한 다는 것을 알게 되었다. 그래서 엑셀 파일을 구글 드라이브를 통해서 만들고 다시 s3에 업로드 했더니 잘 되었다. 말그대로 한글 조합형(NFD)는 한글을 초성중성종성을 분리하여 유니코드로 표현한 것이다. 예를 들어, '템' 이라고하는 글자가 있다면 'ㅌ', 'ㅔ', 'ㅁ'이라고 분리해서 유니코드로 표현한다. 완성형(NFC)는 완성된 하나의 글자를 유니코드로 표현한 것이다. 예를 들어, '템'이라고 하는 글자가 있다..

보호되어 있는 글입니다.

최근 소프트웨어를 만드는 개발자의 연봉 상승이 언론 기사를 통해서 주목받고 있다. 주변의 개발자 지인들도 그런 흐름에 마음이 싱숭생숭하여 이직을 준비한다는 이야기를 듣는다. 그리고 몇번의 이직을 경험해본 나에게 이렇게 묻는 경우가 종종 있다. "뭘 공부해야 할까?" 나는 이 질문 자체가 잘못되었다고 생각한다. 공부해서 이직을 하는 것이 아니라고 생각하기 때문이다. 그 이유를 설명하기 위해서는 내가 생각하는 이직의 정의를 먼저 이야기할 필요가 있다. 이직이란? 이직은 원래 다니고 있는 직장에서 비슷한 업무를 하고 있는 다른 직장으로 옮기는 것을 의미한다. 만약 업무가 바뀐다면 나는 이것을 이직이라기 보다는 전직이라고 말한다. 그리고 기존의 업무 경험이 없는 상태에서 직업을 얻는 것은 신입으로 구직을 했다고..

테스트 코드가 작성하는 것이 어렵다고 많이 이야기한다. 테스트 코드가 없는 상태로 성장한 프로젝트들, 그리고 외부 의존성(DB, 외부 API, 파일 쓰기 등)이 많은 프로젝트들의 코드가 보통 테스트가 어려운 경우가 많다. 과연 그때 우리는 어떤 선택을 해야할까? 추측하건데 보통은 그냥 작성하고 배포한 후, 직접 API를 호출해보거나 확인해볼 수 있는 UI를 통해서 테스트를 해볼것이다. 이런 사용자 테스트는 비용이 크다. 테스트할 여러가지 상황을 재현하기도 쉽지 않을 수 있고, 버그 발견 후 수정하고 다시 확인하는데도 오래 걸린다. 혹자는 실 사용자에게 테스트를 넘길 수도 있다. 테스트 없이 그냥 서비스를 배포하는 것이다. 이런 상황에서 예상되는 결과는 다음과 같다. 문제없이 기능이 배포 되었다. 문제가 ..

휴일에 버그를 발견했다. 한동안 존재하던 버그였다. 발견하자 마자 바로 고쳤다. 바로 공유할까 하다가 휴일 끝나고 공유해야지 라고 생각하고 휴일을 보냈다. 그리고 평일에 까먹었다. 다른 동료가 데이터를 보던 도중에 그 버그가 있었다는 것을 발견했다. 다음 부터는 문제가 있으면 바로 공유해달라는 피드백을 받았다. --- 개발자가 자의적으로 어떤 버그는 큰 영향이 없는 버그라고 판단하고 공유를 하지 않을 수도 있다. 그러나 데이터를 기반으로 의사결정하는 경우에 (공유받지 못한) 그 이벤트를 통해서 영향받은 데이터가 팀의 의사결정이 올바르지 않은 방향으로 가도록 할 수 있다. 버그가 있었고 그 버그가 데이터를 왜곡했고 팀은 왜곡된 데이터로 잘못된 의사결정을 할 수 있다는 뜻이다. 공유를 하지 않은 개발자의 판..

C사에서 어느날(2020-12-15) 링크드인으로 정성담긴 포지션 제안이 왔다. 많은 리쿠르터 분들이 연락을 주셨었지만 보통은 무시했는데, 글의 정성을 보고 한번 진행해봐야겠다고 생각했다. 전화 통화를 통해서 채용 과정에 대해서 설명을 들었다. 1. 코딩 테스트 2. 면접관과 1:1 코딩 테스트 2회 3. 면접관과 1:1 코딩테스트 1회, 아키텍팅 테스트 1회, 컬쳐핏 면접 다른 리쿠르터에게도 이 설명을 듣고 하기 싫어져서 안 했었지만, 이번에는 가볍게 한번 진행해보기로 했다. 모든 면접은 비대면으로 진행했고 총 한달이 소요되었다. 코딩 테스트 프로그래머스에서 진행했다. 난이도는 어렵지 않았다. 자바로 풀라고 해서 그게 좀 귀찮았다. 나의 코딩테스트 스타일에 대해서 간단히 소개하면, 최대한 빨리 간단한 ..

올해 나름 책을 많이 읽었다고 생각했는데, 완독한 책이 10권 밖에 안되서 아쉽다. 내년에는 20권을 목표로 고고! 사피엔스 - 유발 하라리 사피엔스 이제 우리는 무엇을 인간이라고 할 것인가지금으로부터 10만 년 전, 지구에는 호모 사피엔스뿐만 아니라 네안데르탈인, 호모 에렉투스 등 최소 6종의 인간 종이 살아 있었다. 이후 호모 사피엔스 book.naver.com 인간으로서 인간이라는 종을 메타 인지하고 앞으로의 인간과 나에 대해서 고민하게 되었던 책. 미라클 모닝 - 할 엘로드 미라클모닝 아마존 종합 베스트셀러 1위!전 세계 18개국 판권 수출출간 첫해에 아마존 역사상 가장 높은 별점을 받은 책출간 전부터 [르몽드]가 격찬한 “기다려지는 아침을 만들어주는 책”저자는 우리 모 book.naver.com..

문제 상황 직접 http 요청(curl)을 할 경우에는 응답에 CORS 관련 헤더가 적절하게 내려오는데, 하이브리드 앱 웹 뷰에서 그 API를 호출하면 CORS 오류가 발생 실제 요청을 수행하는 backend 서버 까지 여러 레이어가 있는 상황 (사용자 요청 --> NGINX --> GATEWAY --> BACKEND SERVER) 문제 접근 CORS 문제라고 판단하고 관련 헤더가 잘 세팅이 되는 지 확인 잘 되는 것 확인 후 로그 분석했지만 딱히 문제 없음 CORS에 집중해서 직접호출과 웹뷰에서 API 호출을 비교 특정 시스템 웹뷰에서 특정 문제가 있는지 확인 결국 못찾음... 실제 문제 CORS랑 전혀 상관없는 nginx의 request body 크기 제한 이슈 사이즈가 큰 파일을 request bo..

백앤드 개발자는 서비스의 비즈니스 관련 요구사항을 정리하고 코드로 풀어낸다. 작성한 서버 프로그램은 사용자의 요청을 수행한다. 요구사항은 끊임없이 변하고 서비스는 성장한다. 그에 따라서 코드의 양도 많아지고 복잡해진다. 복잡함 때문에 변화의 속도는 느려지고 개발자들은 고통받는다. 유능한 백앤드 개발자는 이 복잡함을 잘 다루는 개발자일 것이다. 복잡함은 여러 형태로 나타난다. 우선 여기저기 의존(참조, 결합)가 많은 코드들이 있을 수 있다. 흔히 말하는 결합도가 높은 코드이다. 그리고 같은 기능이 여기저기 구현되어 관리가 되지 않는 코드가 있을 수 있다. 그리고 용어의 일관성이 없어 코드를 읽기가 어려운 경우도 있다. 나도 이런 복잡함을 경험해왔고 지금도 경험 중인 백앤드 개발자이다. 도메인 주도 설계(D..

몇 년전 우울감이 가득한 날이면, 미드 시즌 3,4를 봤다. 특히 클레어의 남편이자, 세 남매의 아버지의 필을 보면 나는 기분이 좋아졌다. 약간 바보같기도 하지만 자기만의 취미도 확실하고 유머러스하며 가족들을 잘 챙기는 그를 보면 그의 역할을 내가 하고 싶다는 생각을 했다. 최근에는 미드 과 을 가끔 본다. 처럼 가끔은 한심하지만 가족처럼 내 주변에서 희노애락을 같이 느끼는 친구들이 있다면 인생이 외롭지 않을 것 같다고 생각했다. 은 비슷한 친구들이 직장에 있으면 참 좋겠다는 생각이 들게 했다. 막연하게 그런 관계가 이미 있거나 생길 것이라 여기며 살아오다가, 어느날 문득 그런 관계 자체가 판타지라는 생각이 들었다. 사람들은 그런 커뮤니티를 끊임없이 욕망하기 때문에 앞서 이야기한 컨텐츠들을 소비하고 있는..

지난 주 화요일에 정형외과에서 진료를 받고 수요일 (2020-08-05)에 첫번째 도수치료를 받았다. 병원은 회사 근처에 있고, 우리 회사 사람들에게 할인을 해주는 병원에서 하게 되었다. 진단 도수 치료선생님을 만나서 x-ray 사진을 같이 보면서 진단을 했다. 나는 현재 일자목, 일자허리이다. 코어 근육이 약하다. 그래서 허리도 계속 불편하고 연결되어 있는 어깨, 승모도 불편해진다고 했다. 코어 근육이 정확히 어떤 근육인지는 제대로 설명듣지 못했다. 원인 계속 척추기립근을 이용해서 허리를 세우려고 하면서 일자 허리가 되고 허리 통증이 생긴다. 걸을 때 8자로 걷는다. 그러면 아무리 오래 걸어도 코어 근육이 단련되지 않는 다고 한다. 구강호흡을 하는데 그렇게 되면 2차 호흡근을 사용하게 되어 근육이 더 ..

보호되어 있는 글입니다.

한두달 전쯤 독서 모임에서 번개를 했다. 남산을 좀 걷다가 시원한 카페에서 음료를 마시고 해방촌의 작은 서점들을 갔다. 서점들은 작고 책이 빼곡 했다. 걸어 오면서 사람들과 이런 독립 서점들을 운영하는 사람들의 생계를 걱정하는 대화를 하기도 했고, 마침 책 선물도 하고 싶어 기어코 책을 샀다. 우선 선물할 책으로는 이 책을 샀다. 그리고 내가 읽을 책으로는 항상 궁금하던 이 책을 샀다. 나는 여름을 살고 싶어한다. 선물로 줄 책은 여름안에서 여름을 기념하는 책이라면, 내가 읽을 책은 여름 밖의 이야기를 다룬 책이다. 오늘 을 다 읽었다. 바깥은 여름은 단편 소설집이다. 다음의 소설들이 포함되어 있다. 입동: 어린 자식을 잃은 부모 이야기 노찬성과 에반: 늙은 유기견을 키우는 조손 가정 이야기 건너편: 이..

1장. 표기법과 메타모델 UML을 사용하는 방법들 스케치, 청사진, 프로그래밍 언어 필자의 편견으로는, 이 셋 중에서 가장 보편적인 것은 UML을 스케치로 생각하는 것이다. 이 방식에서는 개발자가 시스템의 어떤 측면에 대해 다른 사람과 의사 소통하는 것을 돕는 목적으로 UML을 사용한다. ... 스케치는 순공학(Forward Engineerging) 또는 역공학(Reverse Engineering)에 사용될 수 있다. 스케치의 핵심은 선택성이다. 순공학에서는 작성하고자 하는 코드의 어떤 문제에 대해서 대강 스케치를 해서 팀 내의 사람들과 의논을 한다. 이 책은 설계를 스케치하는 용도의 UML을 소개하는 책이다. 적법한 UML이란 무엇인가? 언어의 두가지 카테고리 규범적인 규칙(Perscriptive ru..

보호되어 있는 글입니다.

비즈니스 로직과 상관없지만 해야하는 일들이 있을 때, Spring 프레임워크에서 제공하는 Event를 사용하여 비즈니스 코드와 비즈니스와 관련 없는 코드의 의존을 분리한다. 예를 들어, 비즈니스 특정 행위를 로그 테이블에 적재해야 할 때, 나의 판단에는 비즈니스의 흐름에 로그 테이블에 적재하는 코드를 넣는 것은 비즈니스 흐름을 읽는 데 방해가 된다. 그래서 이벤트를 발생시키고 해당 이벤트의 Listener 객체가 해당 작업을 수행하도록 한다. 참고; https://javacan.tistory.com/entry/Handle-DomainEvent-with-Spring-ApplicationEventPublisher-EventListener-TransactionalEventListener 스프링 Applicat..

https://stackoverflow.com/questions/41149529/sql-error-1064-sqlstate-42000-caused-by-org-hibernate-exception-sqlgrammar SQL Error: 1064, SQLState: 42000 - Caused by: org.hibernate.exception.SQLGrammarException: could not execute statement I am really exhausted in solving the below error. Any help is very much appreciated. org.springframework.dao.InvalidDataAccessResourceUsageException: could not..

최근의 나의 주요 작업은 하나의 도메인 단위로 서비스를 재구성하는 것이다. 예를 들어, 포인트 관련된 기능이 하나의 DB를 가지고 여러 서버 애플리케이션에서 구현되어 있다면, 포인트 관련된 서비스를 만들고 각 서버 앱들이 포인트 서비스 API를 호출하도록 변경한다. 그리고 포인트 서비스용 DB를 따로 분리한다. 포인트 서비스는 API 수준의 기능을 노출하고 DB는 숨기는 것이다. 작업 방식은 보통 기능을 추출하고 기능단위로 API를 구현하고, 기존 서버 앱들이 해당 API를 호출하도록 작업한다. 굉장히 위험한 작업이기 때문에 기존 서버앱의 수정을 최소화 하고 롤백가능한 구조로 작업을 진행한다. 오늘 적어볼 나의 시행착오는 도메인 모델의 이름에 대한 것이다. 보통 기존 서비스들은 DB의 테이블과 거의 비슷..

요즘도 꾸준히 좋은 개발자란 무엇인지 고민하고 있다. 최근에 좋은 개발자의 덕목 세가지를 다시 한번 생각해보고 정리해 보았다. 과거에 정리했던것과 내용이 많이 달라졌다. 참고: 좋은 개발자의 덕목 달라진 내 생각을 여기에 정리해두었다. 앞으로는 어떻게 달라질지 또 궁금하다. 협력 능력 대다수의 문제는 함께 해결해야 합니다. 그래서 좋은 개발자는 협력에 대해서 고민하고 개선하려고 노력해야합니다. 협력 능력을 두가지로 분류해보겠습니다. 첫번째는 소통능력입니다. 자신의 문제를 효과적으로 전달할 줄 알아야합니다. 그리고 친화력, 공감 능력, 갈등 조정 능력 같은 대인관계 기술들도 꾸준히 훈련하도록 노력해야합니다. 개인적으로 강조하고 싶은 것은 잘 듣고 설득 당하는 것입니다. 이는 문제를 해결함에 있어서 타인의 ..

프로젝트 시작할 때, 항상 잘 쪼개서 계획해보자.