흑백과 디지털

  Java 에 보면 native 라는 키워드가 존재한다. 이 코드는 java 가 구현된 부분이 C 또는 C++ 같은 코드로 구현되는 경우 이런 키워드를 사용한다고 배웠다. 내 기억으로는 난 java를 2003년 정도에 배웠던 것 같다. 그 때 이런 키워드를 공부했던 기억이 있다. 

 2010년 중반 쯤에 웹뷰를 이용해서 안드로이드 앱을 개발했다. 이 때 javascript 에서 java 를 호출 하는 코드는 native 라고 했다. 

뭔지 모르겠지만 뭔가 새로운 언어 또는 상위 계층언어 입장에서 오래된 언어 또는 하위 계층(여기서 하위계층은 기계에 가깝다는 의미다.)을 native 라고 부른다는 느낌이 든다. 

아마 오래전 C 언어 입장에서는 assembly 어가 native 일 것이다. assembly 입장에서는 01 로 이루어진 바이너리가 native 일 것이다. 

AI 로 프로그래밍 하는 바이브 코딩이  활성화 된다면 AI 가 만드는 코드 입장에서는 사람이 만드는 코드를 native 라고 인식하는 시대가 곧 도래할 것 같다. 

 내 개인 클라우드 서버에서 certbot 을 이용해서 https 인증서를 사용하고 있었다. 그런데 이게 동작하지 않아서 한참 원인을 찾다보니 godaddy API 가 더이상 동작하지 않음을 알게 되었다. 내 경우 root 도메인 인증서 발급을 위해 DNS 인증 방식을 사용하고 있다. 좀더 자세히 설명하면 내가 이 도메인의 주인임을 증명하기 위해 DNS 의 txt 레코드를 변경해서 인증하는 방식을 사용하고 있다. 그런데 이 동작을 자동화하기 위해서는 DNS 서버에서 제공하는 API가 필요하다. 

 어째든 godaddy API 가 더 이상 무료가 아니게 되면서 문제가 발생했다. 이런. 다른 무료 DNS 서버 제공업체를 찾아야 할 것 같다. 일이 귀찮게 되었다. 

 개발을 한지 이제 15년 정도 되어 가는 것 같다. 그러나 일정은 계산하는 것은 아직도 어렵다. 

개발 경력이 낮을 때에는 요청하는 기능이 개발 가능한지 불가능한지에 대해서도 예측이 안되기 때문에 일정을 계산하기 어려웠다. 경력이 쌓이고 나서는 요청받은 기능이 개발적으로 불가능하면 기획이라든지 요구사항을 조금씩 협상해 가면서 일이 가능하도록 유도하는 기술이 쌓이게 된다. 그런데 이 때도 일정 계산은 어렵다. 이 때부터 개발과정은 일정과 완성도 사이의 적절한 타협을 하게 된다. 경우에 따라서는 양보할 수 없는 완성도라는 것도 있다보니 (참고로 여기서 말하는 완성도 의미는 사용편의성, 유지보수편의성, 적정한 사용자 UI, 차후 기능확장성, 적절한 속도, 프로그램의 안정성 등등을 모두 포함하는 말이다. ) 일정이 예상했던 일정보다 늘어나기도 한다. 그러나 반대로 일정이 줄어드는 일은 없다. 이 때는 완성도를 높이기 위해 작업하기 때문이다. 

완성도 문제 이외에도 많은 문제가 일정 계산을 어렵게 한다. 개발 과정에서 기획에서 고려하지 못했던 요소가 드러나기도 하고, 예전에 그냥 무시했던 코드가 갑자기 이거 이번 기회에 고쳐야겠는데 라는 마음이 생기기도 하고. 해당 기능을 구현하기 위해서는 특정 라이브러리의 버전업이 필요할 것 같은데, 그러면 기존에 잘 동작했던 것이 문제가 생기기도 하고. 갑자기 다른 업무 때문에 회의가 잡혀서 개발 시간을 까먹기도 하고. 등등의 문제로 일정 계산이 아직도 나에게는 어렵기만 하다.