How to calculate size of a codebook lookup table to break block cipher? I was reading a book called Serious Cryptography. There is a page saying that block size must be large enough to prevent codebook attacks:

When 16-bit blocks are used, the lookup table needs only 2^16 × 16 = 2^20 bits
of memory, or 128 kilobytes. With 32-bit blocks, memory needs
grow to 16 gigabytes, which is still manageable. But with 64-bit
blocks, you’d have to store 2 70 bits (a zetabit, or 128 exabytes), so
forget about it. Codebook attacks won’t be an issue for larger blocks.

Where is the 2^16 * 16 coming from? I think it's supposed to be 2^16 + 2^16 the sum of ciphertext possibilities and the sum of plaintext possibilities that match this specific ciphertext, right?
Where is $2^{16}\cdot16$ bits coming from?

The $2^{16}$ term is the number of possible 16-bit blocks. The $16$ bit term is the space needed to store a block (that can be a block of ciphertext, with the plaintext used as index; or vice versa). The two are multiplied to get the total size, much like the price for $n$ things is $n$ times the price for one thing.
If we added the number of plaintexts and ciphertexts blocks, we'd get a number of blocks, not a size. And while we need to be able to manipulate all the plaintexts and all the ciphertexts, we do not need space to store both all the plaintexts and all the ciphertexts: one kind comes for free as the index of the table, which uses no space. Much like if we want to store what output from 0 to 9 correspond to input 0 to 9, we need 10 digits (like 8730629415), telling that 0 corresponds to 8, 1 to 7, 2 to 3,… 9 to 5; rather than 20 digits.
In this table of $2^{16}$ values, there are never two identical values. That makes it slightly compressible, down to $\log_2((2^{16})!)$ bit, a 9% saving.
Such a table needs not cover all plaintext/ciphertext pairs to be useful. A much smaller table can allow some attack. For example, a table with $2^8$ entries instead of $2^{16}$ allows decryption of about one block out of $2^8$.