Logic in Code,
Freedom in Travel.

"우리 서버는 요청이 잘 가는데요, 우리는 문제가 없어요" 라는 말은 조심스러워 해야 하는 말이다.구체적인 원인을 찾는데만 3개월이 걸린 이슈가 있었다.PG사(결제 대행사) 서버가 우리쪽 서버로 "완료" 통지(Webhook)를 보냈는데, 우리 서버에는 아무런 요청도, 로그도 남지 않는 현상이 있었다. PG사는 "너희 서버가 503(Service Unavailable)을 응답하고 있어"라고 주장했고, 나는 "Nginx, Apache 로그를 다 뒤져봐도 요청 온 흔적조차 없다" 고 응답했다. PG사의 웹훅 버그 가능성부터 /etc/hosts 설정을 통해 전혀 다른 IP로 DNS 캐싱이 되어 있는 것은 아닌지 의심했다. 하지만 PG사는 단순히 'curl' 요청 결과만을 근거로 문제가 없다는 답변만 반복할 뿐..

PHP 와 Node.js 생태계에서 개발하면서 문서가 너무 없거나, 너무 많아서 원하는 내용을 찾기 힘든 경우가 많았다.1. 문서가 부실한 이유: "개발자의 딜레마와 현실"오픈소스가 문서화보다 기능 구현에 쏠릴 수 밖에 없는 원인 The Code is Truth코드를 작성한 사람은 코드의 흐름을 너무 잘 알고 있을 것이다. 그래서 주석이나 문서 없이도 변수명과 함수 구조만 보면 잘 안다. 프로그래밍 언어 특성에 따라 자바스크립트 생태계는 코드를 빨리 짜고 배포하는 문화가 강하다. "일단 동작하게 만드는 것(Make it work)"이 우선시되다 보니 문서는 뒷전으로 밀리는 것 같다. 이로인해 `README.md`에 설치 방법만 있고, 구체적인 사용법이나 엣지 케이스에 대한 설명이 없는 경우가 많은 것 같..

우리가 커밋을 하고 코드를 push/merge 할 때에는 잘 동작하고 테스트도 잘 통과되었기 때문에 그랬을 것이다. 내가 서비스의 이해도가 깊고, 코드를 장악하고 있고, 테스트 커버리지가 100 이 나온다 하더라도 주의하고 침착해야 한다. 코드 한줄로 회사가 문을 닫을수도 있는게 개발자, 엔지니어로서의 책임이라 생각된다. 엔지니어의 책임으로서 꼭 알아야 할 1가지가 있다면 git add -p 이다.git add -p는 변경된 파일의 일부만 선택적으로 스테이지에 추가할 수 있도록 도와주는 기능이다. 전체 파일을 한 번에 커밋하지 않고, 필요한 부분만 선택해서 커밋하고 싶을 때 사용하며 매번 사용하는 습관을 들이면 좋다.습관을 들인다면 10년후 누군가 내 코드의 의도를 쉽게 파악하는데 도움이 된다. 누가 ..

새로운 토큰을 상장하기 위해서는 스마트 컨트릭트(Smart Contract) 를 검토해야했다.해당 토큰이 어떤 로직으로 작동하며, 보안상 취약점이나 비정상적인 동작 가능성이 있는지를 스마트 컨트릭트를 통해 확인할 수 있다.그래서 새로운 토큰을 상장하기 위해서는 스마트 컨트릭트를 확인하고 특약이 필요한지 검토 후 계약을 해야한다. Smart Contract 검토 목적Contract 검토 내용Tokenomics 구조 파악 : 발행량, 공급량, 디플레이션 구조 등소유권(Ownership) 및 관리자 권한 : 특정 주소에 과도한 권한이 집중되어 있는지이벤트 및 트랜잭션 로그 확인: 정상적인 기록 구조가 있는지위험 로직 존재 여부 : 거래 중단, 밴 기능, 과도한 세금(Tax), 자동 유동성 이동 등네트워크별 차..

단일 모듈의 프로젝트를 멀티모듈로 전환하면서 IDEA 캐싱으로 인해 단일 모듈의 Gradle 파일을 캐싱하고 있었다. 이로 인해 .git 디렉토리를 제회하고 모두 삭제를 해보았고, 프로젝트 삭제하고 다시 클론했는데 해결되지 않았다. 2개의 간편하고 무식하면서 간단한 방법이었지만 해결이 안되어 IDEA 캐싱을 진행해 보았다. 무척이나 간단하다.

no newline at end of file 란 무엇일까, Github, GitLab을 사용하다 보면 한번쯤 보고 지나쳤을 키워드이다. Git GUI 클라이언트 툴인 Fork 에서도 no newline at end of file 이라는 문장을 쉽지 않게 볼 수 있었다. [위키백과]POSIX(포직스, /ˈpɒzɪks/)는 이식 가능 운영 체제 인터페이스(移植可能運營體制 interface, portable operating system interface)[1]의 약자로, 서로 다른 UNIX OS의 공통 API를 정리하여 이식성이 높은 유닉스 응용 프로그램을 개발하기 위한 목적으로 IEEE가 책정한 애플리케이션 인터페이스 규격이다. 이러한 인터페이스 규격이 나온 배경을 알아야 하는데, 찾아본 사례로는..